idnits 2.17.1 draft-ietf-mmusic-rfc2326bis-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 10662. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 10673. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 10680. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 10686. 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 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 -- 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? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 8162 has weird spacing: '...trolled by Re...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2008) is 5652 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) -- Looks like a reference, but probably isn't: '9' on line 1454 == Missing Reference: 'H6' is mentioned on line 1707, but not defined == Missing Reference: 'H10' is mentioned on line 3785, but not defined == Missing Reference: 'H15' is mentioned on line 7138, but not defined == Missing Reference: 'CSeq' is mentioned on line 10213, but not defined == Missing Reference: 'Timestamp' is mentioned on line 10215, but not defined == Unused Reference: 'NOSSDAV-1997-1' is defined on line 8191, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3gpp-26234' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-pub-180-2' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3851 (Obsoleted by RFC 5751) ** 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) == Outdated reference: A later version (-22) exists of draft-ietf-mmusic-rtsp-nat-07 -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 1644 (Obsoleted by RFC 6247) -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 2070 (Obsoleted by RFC 2854) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 3388 (Obsoleted by RFC 5888) Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 18 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 Intended status: Standards Track A. Rao 5 Expires: May 7, 2009 Cisco 6 R. Lanphier 8 M. Westerlund 9 Ericsson AB 10 M. Stiemerling (Ed.) 11 NEC 12 November 3, 2008 14 Real Time Streaming Protocol 2.0 (RTSP) 15 draft-ietf-mmusic-rfc2326bis-19 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on May 7, 2009. 42 Abstract 44 This memorandum defines RTSP version 2.0 which is a revision of the 45 Proposed Standard RTSP version 1.0 which is defined in RFC 2326. 47 The Real Time Streaming Protocol, or RTSP, is an application-level 48 protocol for control over the delivery of data with real-time 49 properties. RTSP provides an extensible framework to enable 50 controlled, on-demand delivery of real-time data, such as audio and 51 video. Sources of data can include both live data feeds and stored 52 clips. This protocol is intended to control multiple data delivery 53 sessions, provide a means for choosing delivery channels such as UDP, 54 multicast UDP and TCP, and provide a means for choosing delivery 55 mechanisms based upon RTP (RFC 3550). 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9 60 1.1. Scope and Background . . . . . . . . . . . . . . . . . . 9 61 1.2. RTSP Specificication Update . . . . . . . . . . . . . . 10 62 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 10 63 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . 11 64 1.5. Media Properties . . . . . . . . . . . . . . . . . . . . 14 65 1.5.1. Random Access . . . . . . . . . . . . . . . . . . . 15 66 1.5.2. Retention . . . . . . . . . . . . . . . . . . . . . 15 67 1.5.3. Content Modifications . . . . . . . . . . . . . . . 16 68 1.5.4. Mapping to the Attributes . . . . . . . . . . . . . 16 69 2. RTSP Introduction . . . . . . . . . . . . . . . . . . . . . . 17 70 2.1. Protocol Properties . . . . . . . . . . . . . . . . . . 17 71 2.2. RTSP's Relationship to HTTP . . . . . . . . . . . . . . 18 72 2.3. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 19 73 2.4. Overall Operation . . . . . . . . . . . . . . . . . . . 20 74 2.5. RTSP States . . . . . . . . . . . . . . . . . . . . . . 21 75 2.6. Relationship with Other Protocols . . . . . . . . . . . 22 76 3. RTSP Use Cases . . . . . . . . . . . . . . . . . . . . . . . 23 77 3.1. On-demand Playback of Stored Content . . . . . . . . . . 23 78 3.2. Unicast distribution of Live Content . . . . . . . . . . 24 79 3.3. On-demand Playback using Multicast . . . . . . . . . . . 25 80 3.4. Inviting an RTSP server into a conference . . . . . . . 25 81 3.5. Live Content using Multicast . . . . . . . . . . . . . . 26 82 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 28 83 4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 28 84 4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 28 85 4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 30 86 4.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . 30 87 4.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 30 88 4.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . 31 89 4.7. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 31 90 4.8. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 32 91 5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 33 92 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 33 93 5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 34 94 5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 34 95 5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 34 96 6. General Header Fields . . . . . . . . . . . . . . . . . . . . 35 97 7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 98 7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 36 99 7.2. Request Header Fields . . . . . . . . . . . . . . . . . 38 100 8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 40 101 8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 40 102 8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 40 103 8.2. Response Header Fields . . . . . . . . . . . . . . . . . 43 104 9. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 105 9.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 46 106 9.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 47 107 10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 48 108 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 48 109 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 49 110 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 50 111 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 51 112 10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 51 113 10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 52 114 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 53 115 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 55 116 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 56 117 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 57 118 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 58 119 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 60 120 13.3.1. Changing Transport Parameters . . . . . . . . . . . 63 121 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 64 122 13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 64 123 13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 68 124 13.4.3. Updating current PLAY Requests . . . . . . . . . . . 68 125 13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 70 126 13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 71 127 13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 71 128 13.4.7. Playing Live with Recording . . . . . . . . . . . . 72 129 13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 72 130 13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 73 131 13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 74 132 13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 75 133 13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 76 134 13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 77 135 13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 79 136 13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 80 137 13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 81 138 13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 82 139 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 86 140 15. Status Code Definitions . . . . . . . . . . . . . . . . . . . 88 141 15.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 88 142 15.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 88 143 15.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 88 144 15.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 88 145 15.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 88 146 15.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 89 147 15.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 89 148 15.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 89 149 15.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 89 150 15.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 89 151 15.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 90 152 15.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 90 153 15.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 90 154 15.4.2. 405 Method Not Allowed . . . . . . . . . . . . . . . 90 155 15.4.3. 451 Parameter Not Understood . . . . . . . . . . . . 90 156 15.4.4. 452 reserved . . . . . . . . . . . . . . . . . . . . 90 157 15.4.5. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 91 158 15.4.6. 454 Session Not Found . . . . . . . . . . . . . . . 91 159 15.4.7. 455 Method Not Valid in This State . . . . . . . . . 91 160 15.4.8. 456 Header Field Not Valid for Resource . . . . . . 91 161 15.4.9. 457 Invalid Range . . . . . . . . . . . . . . . . . 91 162 15.4.10. 458 Parameter Is Read-Only . . . . . . . . . . . . . 91 163 15.4.11. 459 Aggregate Operation Not Allowed . . . . . . . . 91 164 15.4.12. 460 Only Aggregate Operation Allowed . . . . . . . . 91 165 15.4.13. 461 Unsupported Transport . . . . . . . . . . . . . 92 166 15.4.14. 462 Destination Unreachable . . . . . . . . . . . . 92 167 15.4.15. 463 Destination Prohibited . . . . . . . . . . . . . 92 168 15.4.16. 464 Data Transport Not Ready Yet . . . . . . . . . . 92 169 15.4.17. 465 Notification Reason Unknown . . . . . . . . . . 92 170 15.4.18. 470 Connection Authorization Required . . . . . . . 92 171 15.4.19. 471 Connection Credentials not accepted . . . . . . 93 172 15.4.20. 472 Failure to establish secure connection . . . . . 93 173 15.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 93 174 15.5.1. 551 Option not supported . . . . . . . . . . . . . . 93 175 16. Header Field Definitions . . . . . . . . . . . . . . . . . . 94 176 16.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 103 177 16.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 103 178 16.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 104 179 16.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 104 180 16.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 104 181 16.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 105 182 16.7. Authorization . . . . . . . . . . . . . . . . . . . . . 105 183 16.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 105 184 16.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 105 185 16.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 106 186 16.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 108 187 16.12. Connection-Credentials . . . . . . . . . . . . . . . . . 108 188 16.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 109 189 16.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 109 190 16.15. Content-Language . . . . . . . . . . . . . . . . . . . . 109 191 16.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 110 192 16.17. Content-Location . . . . . . . . . . . . . . . . . . . . 110 193 16.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 110 194 16.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 110 195 16.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 110 196 16.21. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 111 197 16.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 111 198 16.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 112 199 16.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 112 200 16.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 112 201 16.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 113 202 16.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 113 203 16.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 113 204 16.29. Media-Properties . . . . . . . . . . . . . . . . . . . . 113 205 16.30. Media-Range . . . . . . . . . . . . . . . . . . . . . . 115 206 16.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 115 207 16.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 115 208 16.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 116 209 16.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 117 210 16.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 117 211 16.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 117 212 16.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 118 213 16.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 119 214 16.39. Referer . . . . . . . . . . . . . . . . . . . . . . . . 120 215 16.40. Retry-After . . . . . . . . . . . . . . . . . . . . . . 120 216 16.41. Request-Status . . . . . . . . . . . . . . . . . . . . . 120 217 16.42. Require . . . . . . . . . . . . . . . . . . . . . . . . 121 218 16.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 122 219 16.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 123 220 16.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 124 221 16.46. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 125 222 16.47. Server . . . . . . . . . . . . . . . . . . . . . . . . . 126 223 16.48. Session . . . . . . . . . . . . . . . . . . . . . . . . 126 224 16.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 127 225 16.50. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 127 226 16.51. Transport . . . . . . . . . . . . . . . . . . . . . . . 128 227 16.52. Unsupported . . . . . . . . . . . . . . . . . . . . . . 134 228 16.53. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 134 229 16.54. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 134 230 16.55. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 135 231 16.56. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 135 232 17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 233 17.1. Proxies and Protocol Extensions . . . . . . . . . . . . 137 234 18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 235 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 140 236 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 140 237 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 140 238 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 141 239 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 142 240 19.3.2. User approved TLS procedure . . . . . . . . . . . . 143 241 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 242 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 145 243 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 147 244 20.2.1. Generic Protocol elements . . . . . . . . . . . . . 147 245 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 150 246 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 154 247 20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 162 248 21. Security Considerations . . . . . . . . . . . . . . . . . . . 163 249 21.1. Remote denial of Service Attack . . . . . . . . . . . . 165 250 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 167 251 22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 167 252 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 167 253 22.1.2. Registering New Feature-tags with IANA . . . . . . . 168 254 22.1.3. Registered entries . . . . . . . . . . . . . . . . . 168 255 22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 168 256 22.2.1. Description . . . . . . . . . . . . . . . . . . . . 168 257 22.2.2. Registering New Methods with IANA . . . . . . . . . 168 258 22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 169 259 22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 169 260 22.3.1. Description . . . . . . . . . . . . . . . . . . . . 169 261 22.3.2. Registering New Status Codes with IANA . . . . . . . 169 262 22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 169 263 22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 169 264 22.4.1. Description . . . . . . . . . . . . . . . . . . . . 169 265 22.4.2. Registering New Headers with IANA . . . . . . . . . 170 266 22.4.3. Registered entries . . . . . . . . . . . . . . . . . 170 267 22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 171 268 22.5.1. Accept-Credentials policies . . . . . . . . . . . . 171 269 22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 171 270 22.6. Cache-Control Cache Directive Extensions . . . . . . . 172 271 22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 172 272 22.7.1. Description . . . . . . . . . . . . . . . . . . . . 173 273 22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 173 274 22.7.3. Registered Values . . . . . . . . . . . . . . . . . 173 275 22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 173 276 22.8.1. Description . . . . . . . . . . . . . . . . . . . . 173 277 22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 173 278 22.8.3. Registered Values . . . . . . . . . . . . . . . . . 174 279 22.9. Range header formats . . . . . . . . . . . . . . . . . . 174 280 22.10. RTP-Info header parameters . . . . . . . . . . . . . . . 174 281 22.10.1. Desctiption . . . . . . . . . . . . . . . . . . . . 174 282 22.10.2. Registration Rules . . . . . . . . . . . . . . . . . 175 283 22.10.3. Registered Values . . . . . . . . . . . . . . . . . 175 284 22.11. Seek-Style Policies . . . . . . . . . . . . . . . . . . 175 285 22.11.1. Description . . . . . . . . . . . . . . . . . . . . 175 286 22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 175 287 22.11.3. Registered Values . . . . . . . . . . . . . . . . . 176 288 22.12. Transport Header Registries . . . . . . . . . . . . . . 176 289 22.12.1. Transport Protocol Specification . . . . . . . . . . 176 290 22.12.2. Transport modes . . . . . . . . . . . . . . . . . . 177 291 22.12.3. Transport Parameters . . . . . . . . . . . . . . . . 178 292 22.13. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 178 293 22.13.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 178 294 22.13.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 179 295 22.13.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 180 296 22.14. SDP attributes . . . . . . . . . . . . . . . . . . . . . 181 297 22.15. Media Type Registration for text/parameters . . . . . . 182 298 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 184 299 23.1. Normative References . . . . . . . . . . . . . . . . . . 184 300 23.2. Informative References . . . . . . . . . . . . . . . . . 186 301 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 189 302 A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 189 303 A.2. Media on Demand using Pipelining . . . . . . . . . . . . 193 304 A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 195 305 A.4. Single Stream Container Files . . . . . . . . . . . . . 199 306 A.5. Live Media Presentation Using Multicast . . . . . . . . 201 307 A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 202 308 Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 204 309 B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 204 310 B.2. State variables . . . . . . . . . . . . . . . . . . . . 204 311 B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 204 312 B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 205 313 Appendix C. Media Transport Alternatives . . . . . . . . . . . . 210 314 C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 210 315 C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 210 316 C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 210 317 C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 211 318 C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 212 319 C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 212 320 C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 212 321 C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 213 322 C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 213 323 C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 213 324 C.2.3. Handling Media Clock Time Jumps in the RTP Media 325 Layer . . . . . . . . . . . . . . . . . . . . . . . 217 326 C.2.4. Handling RTP Timestamps after PAUSE . . . . . . . . 220 327 C.2.5. RTSP / RTP Integration . . . . . . . . . . . . . . . 223 328 C.2.6. Scaling with RTP . . . . . . . . . . . . . . . . . . 223 329 C.2.7. Maintaining NPT synchronization with RTP 330 timestamps . . . . . . . . . . . . . . . . . . . . . 223 331 C.2.8. Continuous Audio . . . . . . . . . . . . . . . . . . 223 332 C.2.9. Multiple Sources in an RTP Session . . . . . . . . . 223 333 C.2.10. Usage of SSRCs and the RTCP BYE Message During an 334 RTSP Session . . . . . . . . . . . . . . . . . . . . 223 335 C.3. Future Additions . . . . . . . . . . . . . . . . . . . . 224 336 Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 225 337 D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 225 338 D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 225 339 D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 226 340 D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 227 341 D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 227 342 D.1.5. Directionality of media stream . . . . . . . . . . . 227 343 D.1.6. Range of Presentation . . . . . . . . . . . . . . . 228 344 D.1.7. Time of Availability . . . . . . . . . . . . . . . . 229 345 D.1.8. Connection Information . . . . . . . . . . . . . . . 229 346 D.1.9. Entity Tag . . . . . . . . . . . . . . . . . . . . . 229 347 D.2. Aggregate Control Not Available . . . . . . . . . . . . 230 348 D.3. Aggregate Control Available . . . . . . . . . . . . . . 230 349 D.4. RTSP external SDP delivery . . . . . . . . . . . . . . . 231 350 Appendix E. Text format for Parameters . . . . . . . . . . . . . 233 351 Appendix F. Requirements for Unreliable Transport of RTSP . . . 234 352 Appendix G. Backwards Compatibility Considerations . . . . . . . 236 353 G.1. Play Request in Play mode . . . . . . . . . . . . . . . 236 354 G.2. Using Persistent Connections . . . . . . . . . . . . . . 236 355 Appendix H. Open Issues . . . . . . . . . . . . . . . . . . . . 237 356 Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 238 357 Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 245 358 J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 245 359 Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 247 360 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 248 361 Intellectual Property and Copyright Statements . . . . . . . . . 249 363 1. Introduction 365 1.1. Scope and Background 367 This memo defines version 2.0 of the Real Time Streaming Protocol 368 (RTSP 2.0) which is an application-level protocol for control over 369 the delivery of data with real-time properties, typically streaming 370 media. Streaming media is, for instance, video on demand or audio 371 live streaming. Put simply, RTSP acts as a "network remote control" 372 for multimedia servers, as you know it from your TV set. 374 The protocol operates between RTSP 2.0 clients and servers, but also 375 supports the usage of RTSP 2.0 proxies between clients and servers. 376 Basically, clients can request information about streaming media from 377 setranrvers, by asking for a description of the media or use media 378 description provided externally. Based on the media description 379 clients can request to play out the media, pause it, or stop it 380 completely, as known from a regular TV remote control. The requested 381 media can consist of multiple audio and video streams that are 382 delivered as a time-synchronized streams from servers to clients. 384 This memorandum describes the use of RTSP over a reliable connection 385 based transport level protocol, such as TCP. For security, TLS over 386 a connection oriented transport is supported. 388 There is no dependency on an special RTSP connection in the protocol. 389 Instead, an RTSP server maintains a session labeled by an identifier 390 to associate groups of media streams and their states. An RTSP 391 session is not tied to a transport-level connection such as a TCP 392 connection. During a session, a client may open and close multiple 393 reliable transport connections to the server to issue RTSP requests 394 for that session. 396 The set of streams to be controlled in an RTSP session is defined by 397 a presentation description. This memorandum does not define a format 398 for the presentation description. However Appendix D describes how 399 SDP [RFC4566] is used for this purpose. The streams controlled by 400 RTSP may use RTP [RFC3550] for their data transport, but the 401 operation of RTSP does not depend on the transport mechanism used to 402 carry continuous media. RTSP is intentionally similar in syntax and 403 operation to HTTP/1.1 [RFC2616] so that extension mechanisms to HTTP 404 may also be applied to RTSP. 406 The RTSP 2.0 protocol supports the following operations: 408 Retrieval of media from media server: The client can either request 409 a presentation description via RTSP DESCRIBE, HTTP or some 410 other method. If the presentation is being multicast, the 411 presentation description contains the multicast addresses and 412 ports to be used for the continuous media. If the presentation 413 is to be sent only to the client via unicast, the client 414 provides the destination. 416 Invitation of a media server to a conference: A media server can be 417 "invited" to join an existing conference to play back media 418 into the presentation. This mode is useful, for example, in 419 distributed teaching applications. Several parties in the 420 conference may take turns "pushing the remote control buttons". 421 Note: This functionality will require RTSP external application 422 level functionality. 424 RTSP requests may be handled by proxies, tunnels and caches as in 425 HTTP/1.1 [RFC2616]. 427 1.2. RTSP Specificication Update 429 This memorandum specifies RTSP 2.0 which is an update of RTSP 1.0, a 430 proposed standard defined in [RFC2326]. The goal of this version is 431 to correct the many flaws that have been identified in RTSP 1.0 since 432 its publication. The corrections are such that backwards 433 compatibility was impossible. Thus a new version was deemed the most 434 appropriate solution to get a more functional protocol. There are no 435 plans to revise RTSP 1.0. Appendix I catalogs the changes of this 436 version in relation to RTSP 1.0. 438 RTSP 2.0 as specified in this memo has reduced functionality compared 439 to RTSP 1.0 and aims at specifying the RTSP core, functionality and 440 rules for extensions, and basic interaction with the media delivery 441 protocol RTP [RFC3550]. 443 Any other functionality would need to be published as extension 444 documents. This specification provides rules for such extensions and 445 defines registries to avoid naming collisions. 447 1.3. Notational Conventions 449 Since some of the definitions and syntax are identical to HTTP/1.1, 450 this specification only points to the section where they are defined 451 rather than copying it. For brevity, [HX.Y] is to be taken to refer 452 to Section X.Y of the current HTTP/1.1 specification ([RFC2616]). 454 All the mechanisms specified in this document are described in both 455 prose and the Augmented Backus-Naur form (ABNF) described in detail 456 in [RFC5234]. 458 Indented and smaller-type paragraphs are used to provide informative 459 background and motivation. This is intended to give readers who were 460 not involved with the formulation of the specification an 461 understanding of why things are the way they are in RTSP. 463 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 464 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 465 document are to be interpreted as described in [RFC2119]. 467 The word, "unspecified" is used to indicate functionality or features 468 that are not defined in this specification. Such functionality 469 cannot be used in a standardized manner without further definition in 470 an extension specification to RTSP. 472 1.4. Terminology 474 Some of the terminology has been adopted from HTTP/1.1 [RFC2616]. 475 Terms not listed here are defined as in HTTP/1.1. 477 Aggregate control: The concept of controlling multiple streams using 478 a single timeline, generally maintained by the server. A client, 479 for example, uses aggregate control when it issues a single play 480 or pause message to simultaneously control both the audio and 481 video in a movie. A session which is under aggregate control is 482 referred to as an aggregated session. 484 Aggregate control URI: The URI used in an RTSP request to refer to 485 and control an aggregated session. It normally, but not always, 486 corresponds to the presentation URI specified in the session 487 description. See Section 13.3 for more information. 489 Conference: A multiparty, multimedia presentation, where "multi" 490 implies greater than or equal to one. 492 Client: The client requests media service from the media server. 494 Connection: A transport layer virtual circuit established between 495 two programs for the purpose of communication. 497 Container file: A file which may contain multiple media streams 498 which often constitutes a presentation when played together. The 499 concept of a container file is not embedded in the protocol. 500 However, RTSP servers may offer aggregate control on the media 501 streams within these files. 503 Continuous media: Data where there is a timing relationship between 504 source and sink; that is, the sink needs to reproduce the timing 505 relationship that existed at the source. The most common examples 506 of continuous media are audio and motion video. Continuous media 507 can be real-time (interactive or conversational), where there is a 508 "tight" timing relationship between source and sink, or streaming 509 (playback), where the relationship is less strict. 511 Entity: The information transferred as the payload of a request or 512 response. An entity consists of meta-information in the form of 513 entity-header fields and content in the form of an entity-body, as 514 described in Section 9. 516 Feature-tag: A tag representing a certain set of functionality, i.e. 517 a feature. 519 IRI: Internationalized Resource Identifier, is the same as an URI, 520 with the exception that it allows characters from the whole 521 Universal Character Set (Unicode/ISO 10646), rather than the US- 522 ASCII only. See [RFC3987] for more information. 524 Live: Normally used to describe a presentation or session with media 525 coming from an ongoing event. This generally results in the 526 session having an unbound or only loosely defined duration, and 527 sometimes no seek operations are possible. 529 Media initialization: Datatype/codec specific initialization. This 530 includes such things as clock rates, color tables, etc. Any 531 transport-independent information which is required by a client 532 for playback of a media stream occurs in the media initialization 533 phase of stream setup. 535 Media parameter: Parameter specific to a media type that may be 536 changed before or during stream playback. 538 Media server: The server providing playback services for one or more 539 media streams. Different media streams within a presentation may 540 originate from different media servers. A media server may reside 541 on the same host or on a different host from which the 542 presentation is invoked. 544 Media server indirection: Redirection of a media client to a 545 different media server. 547 (Media) stream: A single media instance, e.g., an audio stream or a 548 video stream as well as a single whiteboard or shared application 549 group. When using RTP, a stream consists of all RTP and RTCP 550 packets created by a source within an RTP session. 552 Message: The basic unit of RTSP communication, consisting of a 553 structured sequence of octets matching the syntax defined in 554 Section 20 and transmitted over a connection or a connectionless 555 transport. 557 Non-Aggregated Control: Control of a single media stream. This is 558 only possible in RTSP sessions with a single media. 560 Participant: Member of a conference. A participant may be a 561 machine, e.g., a playback server. 563 Presentation: A set of one or more streams presented to the client 564 as a complete media feed and described by a presentation 565 description as defined below. Presentations with more than one 566 media stream are often handled in RTSP under aggregate control. 568 Presentation description: A presentation description contains 569 information about one or more media streams within a presentation, 570 such as the set of encodings, network addresses and information 571 about the content. Other IETF protocols such as SDP ([RFC4566]) 572 use the term "session" for a presentation. The presentation 573 description may take several different formats, including but not 574 limited to the session description protocol format, SDP. 576 Response: An RTSP response. If an HTTP response is meant, that is 577 indicated explicitly. 579 Request: An RTSP request. If an HTTP request is meant, that is 580 indicated explicitly. 582 Request-URI: The URI used in a request to indicate the resource on 583 which the request is to be performed. 585 RTSP agent: Refers to either an RTSP client, an RTSP server, or an 586 RTSP Proxy. In this specification, there are many capabilities 587 that are common to these three entities such as the capability to 588 send requests or receive responses. This term will be used when 589 describing functionality that is applicable to all three of these 590 entities. 592 RTSP session: A stateful abstraction upon which the main control 593 methods of RTSP operate. An RTSP session is a server entity; it 594 is created, maintained and destroyed by the server. It is 595 established by an RTSP server upon the completion of a successful 596 SETUP request (when a 200 OK response is sent) and is labelled 597 with a session identifier at that time. The session exists until 598 timed out by the server or explicitly removed by a TEARDOWN 599 request. An RTSP session is a stateful entity; an RTSP server 600 maintains an explicit session state machine (see Appendix A) where 601 most state transitions are triggered by client requests. The 602 existence of a session implies the existence of state about the 603 session's media streams and their respective transport mechanisms. 604 A given session can have one or more media streams associated with 605 it. An RTSP server uses the session to aggregate control over 606 multiple media streams. 608 Transport initialization: The negotiation of transport information 609 (e.g., port numbers, transport protocols) between the client and 610 the server. 612 URI: Universal Resource Identifier, see [RFC3986]. The URIs used in 613 RTSP are generally URLs as they give a location for the resource. 614 As URLs are a subset of URIs, they will be referred to as URIs to 615 cover also the cases when an RTSP URI would not be an URL. 617 URL: Universal Resource Locator, is an URI which identifies the 618 resource through its primary access mechanism, rather than 619 identifying the resource by name or by some other attribute(s) of 620 that resource. 622 1.5. Media Properties 624 When RTSP handles media it is important to consider the different 625 properties a media instance for playback can have. This 626 specification considers the below listed media properties in its 627 protocol operations. They are derived from the differencies between 628 a number of supported usages. 630 On-demand: Media that has a fixed (given) duration that doesn't 631 change during the life time of the RTSP session and are known at 632 the time of the creation of the session. It is expected that the 633 content of the media will not change, even if the representation, 634 i.e encoding, quality, etc, may change. Generally one can seek 635 within the media i.e. randomly access any range of the media 636 stream to playback. 638 Dynamic On-demand: This is a variation of the on-demand case where 639 external methods are used to manipulate the actual content of the 640 media setup for the RTSP session. The main example is where a 641 playlist determines the content of the session. 643 Live: Live media represents a progressing content stream (such as 644 broadcast TV) where the duration may or may not be known. It is 645 not seakable, only the content presently being delivered can be 646 accessed. 648 Live with Recording: A Live stream that is combined with a server 649 side capability to store and retain the content of the live 650 session for random access playback within the part of the already 651 recorded content. The actual behavior of the media stream is very 652 much depending on the retention policy for the media stream. 653 Either the server will be able to capture the complete media 654 stream, or it will have a limitation in how much will be retained. 655 The media range will dynamically change as the session progress. 656 For servers with a limited amount of storage available for 657 recording, there will be a sliding window that goes forwards while 658 data is made available and content that is older than the 659 limitation will be discarded. 661 Considering the above usages one get the following media properties 662 and their different instance values. 664 1.5.1. Random Access 666 Random Access, i.e. if one can request that the playback point is 667 moved from one point in the media duration to another. The following 668 different values are considered: 670 Random Access: Yes the media are seekable to any out of a large 671 number of points within the media. Due to media encoding 672 limitations a particular point may not be reachable, but seeking 673 to a point close by is enabled. A floating point number of 674 seconds may be provied to express the worst case distance between 675 random access points. 677 Return To Start: Seeking is only possible to begining of the 678 content. 680 No seeking: Seeking is not possible at all. 682 1.5.2. Retention 684 Media may have different retention policy in place that affect the 685 operation on the media. The following different media retention 686 policies are envisioned and taken into consideration where 687 applicable. 689 Unlimited: The media will not be removed as long as the RTSP session 690 are in existence. 692 Time Limited: The media will at least not be removed before given 693 wall clock time. After that time it may or may not be available 694 any more. 696 Duration limited: Each indiviudal unit of the media will be retained 697 for the specified duration. 699 1.5.3. Content Modifications 701 There is also the question of how the content may change during time 702 for a give media resource: 704 Unmutable: The content of the media will not change, even if the 705 representation, i.e encoding, quality, etc, may change. 707 Dynamic: Between explicit updates the media content will not change, 708 but the content may change due to external methods or triggers, 709 such as playlists. 711 Time Progressing: As times progress new content will become 712 available. If the content also is retained it will become longer 713 and longer as everything between the start point and the point in 714 currently being made available can be accessed. 716 1.5.4. Mapping to the Attributes 718 This section exemplifies how one would map the above listed usages to 719 the properties and their values. 721 On-demand: Random Access: Random Access=5s, Content Modifications: 722 Unmutable, Retention: unlimted or time limited. 724 Dynamic On-demand: Random Access: Random Access=3s, Content 725 Modifications: Dynamic, Retention: unlimted or time limited. 727 Live: Random Access: No seeking, Content Modifications: Time 728 Progressing, Retention: Duration limited=0.0s 730 Live with Recording: Random Access: Random Access=3s, Content 731 Modifications: Time Progressing, Retention: Duration limited=2H 733 2. RTSP Introduction 735 2.1. Protocol Properties 737 RTSP has the following properties: 739 Extendable: New methods and parameters can be easily added to RTSP. 741 Secure: RTSP re-uses web security mechanisms, either at the 742 transport level (TLS, [RFC5246]) or within the protocol itself. 743 All HTTP authentication mechanisms such as basic ([RFC2616]) and 744 digest authentication ([RFC2617]) are directly applicable. 746 Transport-independent: RTSP does not preclude the use of unreliable 747 datagram protocol (UDP) ([RFC0768]) as it would be possible to 748 implement application-level reliability. The use of a 749 connectionless datagram protocol such as UDP requires additional 750 definition that may be provided as extensions to the core RTSP 751 specification. The reliable stream protocol TCP ([RFC0793]) and 752 the secured reliable stream protocol TLS over TCP [RFC5246] are 753 the currently defined transport protocols for RTSP messages. 755 Media-delivery protocol independent: The operation of RTSP does not 756 depend on the transport mechanism used to carry continuous media. 757 While most real-time media will use RTP as a transport protocol, 758 RTSP does not preclude the use of other protocols such as MPEG-2 759 [ISO.13818-1.2000]. The use of other protocols requires 760 additional definition that may be provided as extensions to the 761 core RTSP specification. 763 Multi-server capable: Each media stream within a presentation can 764 reside on a different server. The client automatically 765 establishes several concurrent control sessions with the different 766 media servers. Media synchronization in those cases is performed 767 at the transport level. 769 Separation of stream control and conference initiation: Stream 770 control is divorced from inviting a media server to a conference. 771 In particular, SIP [RFC3261] or H.323 [ITU.H323.1996] may be used 772 to invite a server to a conference; however, the exact procedures 773 are unspecified. 775 Suitable for professional applications: RTSP supports frame- level 776 accuracy through SMPTE time stamps to allow remote digital 777 editing. 779 Presentation description neutral: The protocol does not impose a 780 particular presentation description or metafile format and can 781 convey the type of format to be used. However, the presentation 782 description is required to contain at least one RTSP URI. 784 Proxy and firewall friendly: The protocol should be readily handled 785 by both application and transport-layer (SOCKS [RFC1961]) 786 firewalls. A firewall may need to understand the SETUP method to 787 open a "hole" for the media stream. 789 HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so that 790 the existing infrastructure can be reused. This infrastructure 791 includes PICS (Platform for Internet Content Selection 792 [W3C.REC-PICS-services] [W3C.REC-PICS-labels]) for associating 793 labels with content. However, RTSP does not just add methods to 794 HTTP since controlling continuous media requires server state in 795 most cases. 797 Appropriate server control: If a client can start a stream, it needs 798 to be able to stop a stream. Servers should not start streaming 799 to clients in such a way that clients cannot stop the stream. 801 Transport negotiation: The client can negotiate the transport method 802 prior to actually needing to process a continuous media stream. 804 2.2. RTSP's Relationship to HTTP 806 RTSP is intentionally similar in syntax and operation to HTTP/1.1 807 [RFC2616] so that extension mechanisms to HTTP can in some cases also 808 be applied to RTSP. However, RTSP differs in a number of important 809 aspects from HTTP: 811 * RTSP introduces a number of new methods and has a different 812 protocol identifier. 814 * RTSP has the notion of a session built into the protocol. 816 * An RTSP server needs to maintain state in almost all cases, as 817 opposed to the stateless nature of HTTP. 819 * Both an RTSP server and client can issue requests. 821 * Data is usually carried out-of-band by a different protocol. 822 Session descriptions returned in a DESCRIBE response (see 823 Section 13.2) and interleaving of RTP with RTSP over TCP are 824 exceptions to this rule (see Section 14). 826 * RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 827 8859-1, consistent with HTML internationalization efforts 828 [RFC2070]. 830 * The Request-URI always contains the absolute URI. Because of 831 backward compatibility with a historical blunder, HTTP/1.1 832 [RFC2616] carries only the absolute path in the request and 833 puts the host name in a separate header field. 834 This makes "virtual hosting" easier, where a single host with 835 one IP address hosts several document trees. 837 2.3. Extending RTSP 839 Since not all media servers have the same functionality, media 840 servers by necessity will support different sets of requests. For 841 example: 843 o A server may not be capable of seeking (absolute positioning) if 844 it is to support live events only. 846 o Some servers may not support setting stream parameters and thus 847 not support GET_PARAMETER and SET_PARAMETER. 849 o Some server may support an RTSP extension. 851 It is up to the creators of presentation descriptions not to ask the 852 impossible of a server. This situation is similar in HTTP/1.1 853 [RFC2616], where the methods described in [H19.5] are not likely to 854 be supported across all servers. 856 RTSP can be extended in three ways, listed here in order of the 857 magnitude of changes supported: 859 o Existing methods can be extended with new parameters, e.g. 860 headers, as long as these parameters can be safely ignored by the 861 recipient. If the client needs negative acknowledgement when a 862 method extension is not supported, a tag corresponding to the 863 extension may be added in the field of the Require or Proxy- 864 Require headers (see Section 16.35). 866 o New methods can be added. If the recipient of the message does 867 not understand the request, it MUST respond with error code 501 868 (Not Implemented) so that the sender can avoid using this method 869 again. A client may also use the OPTIONS method to inquire about 870 methods supported by the server. The server MUST list the methods 871 it supports using the Public response header. 873 o A new version of the protocol can be defined, allowing almost all 874 aspects (except the position of the protocol version number) to 875 change. A new version of the protocol MUST be registered through 876 an IETF standard track document. 878 The basic capability discovery mechanism can be used to both discover 879 support for a certain feature and to ensure that a feature is 880 available when performing a request. For detailed explanation of 881 this see Section 11. 883 2.4. Overall Operation 885 Each presentation and media stream is identified by an RTSP URI. The 886 overall presentation and the properties of the media the presentation 887 is composed of are defined by a presentation description file, the 888 format of which is outside the scope of this specification. The 889 presentation description file may be obtained by the client using 890 HTTP or other means such as email and may not necessarily be stored 891 on the media server. 893 For the purposes of this specification, a presentation description is 894 assumed to describe one or more presentations, each of which 895 maintains a common time axis. For simplicity of exposition and 896 without loss of generality, it is assumed that the presentation 897 description contains exactly one such presentation. A presentation 898 may contain several media streams. 900 The presentation description file contains a description of the media 901 streams making up the presentation, including their encodings, 902 language, and other parameters that enable the client to choose the 903 most appropriate combination of media. In this presentation 904 description, each media stream that is individually controllable by 905 RTSP is identified by an RTSP URI, which points to the media server 906 handling that particular media stream and names the stream stored on 907 that server. Several media streams can be located on different 908 servers; for example, audio and video streams can be split across 909 servers for load sharing. The description also enumerates which 910 transport methods the server is capable of. 912 Besides the media parameters, the network destination address and 913 port need to be determined. Several modes of operation can be 914 distinguished: 916 Unicast: The media is transmitted to the source of the RTSP request 917 or the requested destination, with the port number chosen by the 918 client. Alternatively, the media is transmitted on the same 919 reliable stream as RTSP. 921 Multicast, server chooses address: The media server picks the 922 multicast address and port. This is the typical case for a live 923 or near-media-on-demand transmission. The address is provided by 924 the session description. 926 Multicast, client chooses address: If the server is to participate 927 in an existing multicast conference, the multicast address, port 928 and encryption key are given by the conference description, 929 established by means outside the scope of this specification, for 930 example by a SIP created conference. 932 2.5. RTSP States 934 RTSP controls a stream which may be sent via a separate protocol, 935 independent of the control channel. For example, RTSP control may be 936 transported on a TCP connection while the media data is conveyed via 937 UDP. Thus, data delivery continues even if no RTSP requests are 938 received by the media server. Also, during its lifetime a single 939 media stream may be controlled by RTSP requests issued sequentially 940 on different TCP connections. Therefore, the server needs to 941 maintain "session state" to be able to correlate RTSP requests with a 942 stream. The state transitions are described in Appendix A. 944 Many methods in RTSP do not contribute to state. However, the 945 following play a central role in defining the allocation and usage of 946 stream resources on the server: SETUP, PLAY, PAUSE, REDIRECT, and 947 TEARDOWN. 949 SETUP: Causes the server to allocate resources for a stream and 950 create an RTSP session. 952 PLAY: Starts data transmission on a stream allocated via SETUP. 954 PAUSE: Temporarily halts a stream without freeing server resources. 956 REDIRECT: Indicates that the session should be moved to a new server 957 or location 959 TEARDOWN: Frees resources associated with the stream. The RTSP 960 session ceases to exist on the server. 962 RTSP methods that contribute to state use the Session header field 963 (Section 16.49) to identify the RTSP session whose state is being 964 manipulated. The server generates session identifiers in response to 965 SETUP requests (Section 13.3). 967 2.6. Relationship with Other Protocols 969 RTSP has some overlap in functionality with HTTP. It also may 970 interact with HTTP in that the initial contact with streaming content 971 will often be made through a web page. The current protocol 972 specification aims to allow different hand-off points between a web 973 server and the media server implementing RTSP. For example, the 974 presentation description can be retrieved using HTTP or RTSP, which 975 reduces round trips in web-browser-based scenarios, yet also allows 976 for stand alone RTSP servers and clients which do not rely on HTTP at 977 all. However, RTSP differs fundamentally from HTTP in that most data 978 delivery takes place out-of-band in a different protocol. HTTP is an 979 asymmetric protocol where the client issues requests and the server 980 responds. In RTSP, both the media client and media server can issue 981 requests. RTSP requests are also stateful; they may set parameters 982 and continue to control a media stream long after the request has 983 been acknowledged. 985 Re-using HTTP functionality has advantages in at least two areas, 986 namely security and proxies. The requirements are very similar, so 987 having the ability to adopt HTTP work on caches, proxies and 988 authentication is valuable. 990 RTSP assumes the existence of a presentation description format that 991 can express both static and temporal properties of a presentation 992 containing several media streams. Session Description Protocol (SDP) 993 [RFC4566] is generally the format of choice; however, RTSP is not 994 bound to it. For data delivery, most real-time media will use RTP as 995 a transport protocol. While RTSP works well with RTP, it is not tied 996 to RTP. 998 3. RTSP Use Cases 1000 This section describes the most important and considered use cases 1001 for RTSP. They are listed in descending order of importance in 1002 regards to ensuring that all necessary functionality is present. 1003 This specification only fully supports usage of the two first. Also 1004 in these first two cases, there are special cases or exceptions that 1005 are not supported without extensions, e.g. the redirection of media 1006 to another address than the controlling entity. 1008 3.1. On-demand Playback of Stored Content 1010 An RTSP capable server stores content suitable for being streamed to 1011 a client. A client desiring playback of any of the stored content 1012 uses RTSP to set up the media transport required to deliver the 1013 desired content. RTSP is then used to initiate, halt and manipulate 1014 the actual transmission (playout) of the content. RTSP is also 1015 required to provide necessary description and synchronization 1016 information for the content. 1018 The above high level description can be broken down into a number of 1019 functions that RTSP needs to be capable of. 1021 Presentation Description: Provide initialization information about 1022 the presentation (content); for example, which media codecs are 1023 needed for the content. Other information that is important 1024 includes the number of media stream the presentation contains, 1025 the transport protocols used for the media streams, and 1026 identifiers for these media streams. This information is 1027 required before setup of the content is possible and to 1028 determine if the client is even capable of using the content. 1030 This information need not be sent using RTSP; other external 1031 protocols can be used to transmit the transport presentation 1032 descriptions. Two good examples are the use of HTTP [RFC2616] 1033 or email to fetch or receive presentation descriptions like SDP 1034 [RFC4566] 1036 Setup: Set up some or all of the media streams in a presentation. 1037 The setup itself consist of selecting the protocol for media 1038 transport and the necessary parameters for the protocol, like 1039 addresses and ports. 1041 Control of Transmission: After the necessary media streams have been 1042 established the client can request the server to start 1043 transmitting the content. The client must be allowed to start 1044 or stop the transmission of the content at arbitrary times. 1045 The client must also be able to start the transmission at any 1046 point in the timeline of the presentation. 1048 Synchronization: For media transport protocols like RTP [RFC3550] it 1049 might be beneficial to carry synchronization information within 1050 RTSP. This may be due to either the lack of inter-media 1051 synchronization within the protocol itself, or the potential 1052 delay before the synchronization is established (which is the 1053 case for RTP when using RTCP). 1055 Termination: Terminate the established contexts. 1057 For this use case there are a number of assumptions about how it 1058 works. These are: 1060 On-Demand content: The content is stored at the server and can be 1061 accessed at any time during a time period when it is intended 1062 to be available. 1064 Independent sessions: A server is capable of serving a number of 1065 clients simultaneously, including from the same piece of 1066 content at different points in that presentations time-line. 1068 Unicast Transport: Content for each individual client is transmitted 1069 to them using unicast traffic. 1071 It is also possible to redirect the media traffic to a different 1072 destination than that of the entity controlling the traffic. 1073 However, allowing this without appropriate mechanisms for checking 1074 that the destination approves of this allows for distributed denial 1075 of service attacks (DDoS). 1077 3.2. Unicast distribution of Live Content 1079 This use cases is similar to the above on-demand content case (see 1080 Section 3.1) the difference is the nature of the content itself. 1081 Live content is continuously distributed as it becomes available from 1082 a source; i.e., the main difference from on-demand is that one starts 1083 distributing content before the end of it has become available to the 1084 server. 1086 In many cases the consumer of live content is only interested in 1087 consuming what is actually happens "now"; i.e., very similar to 1088 broadcast TV. However in this case it is assumed that there exist no 1089 broadcast or multicast channel to the users, and instead the server 1090 functions as a distribution node, sending the same content to 1091 multiple receivers, using unicast traffic between server and client. 1092 This unicast traffic and the transport parameters are individually 1093 negotiated for each receiving client. 1095 Another aspect of live content is that it often has a very limited 1096 time of availability, as it is only is available for the duration of 1097 the event the content covers. An example of such a live content 1098 could be a music concert which lasts 2 hour and starts at a 1099 predetermined time. Thus there is need to announce when and for how 1100 long the live content is available. 1102 In some cases, the server providing live content may be saving some 1103 or all of the content to allow clients to pause the stream and resume 1104 it from the paused point, or to "rewind" and play continuously from a 1105 point earlier than the live point. Hence, this use case does not 1106 necessarily exclude playing from other than the live point of the 1107 stream, playing with scales other than 1.0, etc. 1109 3.3. On-demand Playback using Multicast 1111 It is possible to use RTSP to request that media be delivered to a 1112 multicast group. The entity setting up the session (the controller) 1113 will then control when and what media is delivered to the group. 1114 This use case has some potential for denial of service attacks by 1115 flooding a multicast group. Therefore, a mechanism is needed to 1116 indicate that the group actually accepts the traffic from the RTSP 1117 server. 1119 An open issue in this use case is how one ensures that all receivers 1120 listening to the multicast or broadcast receives the session 1121 presentation configuring the receivers. This memo has to rely on a 1122 external solution to solve this issue. 1124 3.4. Inviting an RTSP server into a conference 1126 If one has an established conference or group session, it is possible 1127 to have an RTSP server distribute media to the whole group. 1128 Transmission to the group is simplest when controlled by a single 1129 participant or leader of the conference. Shared control might be 1130 possible, but would require further investigation and possibly 1131 extensions. 1133 This use case assumes that there exists either multicast or a 1134 conference focus that redistribute media to all participants. 1136 This use case is intended to be able to handle the following 1137 scenario: A conference leader or participant (hereafter called the 1138 controller) has some pre-stored content on an RTSP server that he 1139 wants to share with the group. The controller sets up an RTSP 1140 session at the streaming server for this content and retrieves the 1141 session description for the content. The destination for the media 1142 content is set to the shared multicast group or conference focus. 1144 When desired by the controller, he/she can start and stop the 1145 transmission of the media to the conference group. 1147 There are several issues with this use case that are not solved by 1148 this core specification for RTSP: 1150 Denial of service: To avoid an RTSP server from being an unknowing 1151 participant in a denial of service attack the server needs to 1152 be able to verify the destination's acceptance of the media. 1153 Such a mechanism to verify the approval of received media does 1154 not yet exist; instead, only policies can be used, which can be 1155 made to work in controlled environments. 1157 Distributing the presentation description to all participants in the 1158 group: To enable a media receiver to correctly decode the content 1159 the media configuration information needs to be distributed 1160 reliably to all participants. This will most likely require 1161 support from an external protocol. 1163 Passing control of the session: If it is desired to pass control of 1164 the RTSP session between the participants, some support will be 1165 required by an external protocol to exchange state information 1166 and possibly floor control of who is controlling the RTSP 1167 session. 1169 If there interest in this use case, further work is required on the 1170 necessary extensions. 1172 3.5. Live Content using Multicast 1174 This use case in its simplest form does not require any use of RTSP 1175 at all; this is what multicast conferences being announced with SAP 1176 [RFC2974] and SDP are intended to handle. However in use cases where 1177 more advanced features like access control to the multicast session 1178 are desired, RTSP could be used for session establishment. 1180 A client desiring to join a live multicasted media session with 1181 cryptographic (encryption) access control could use RTSP in the 1182 following way. The source of the session announces the session and 1183 gives all interested an RTSP URI. The client connects to the server 1184 and requests the presentation description, allowing configuration for 1185 reception of the media. In this step it is possible for the client 1186 to use secured transport and any desired level of authentication; for 1187 example, for billing or access control. An RTSP link also allows for 1188 load balancing between multiple servers. 1190 If these were the only goals, they could be achieved by simply using 1191 HTTP. However, for cases where the sender likes to keep track of 1192 each individual receiver of a session, and possibly use the session 1193 as a side channel for distributing key-updates or other information 1194 on a per-receiver basis, and the full set of receivers is not know 1195 prior to the session start, the state establishment that RTSP 1196 provides can be beneficial. In this case a client would establish an 1197 RTSP session for this multicast group with the RTSP server. The RTSP 1198 server will not transmit any media, but instead will point to the 1199 multicast group. The client and server will be able to keep the 1200 session alive for as long as the receiver participates in the session 1201 thus enabling, for example, the server to push updates to the client. 1203 This use case will most likely not be able to be implemented without 1204 some extensions to the server-to-client push mechanism. Here the 1205 PLAY_NOTIFY method (see Section 13.5) with a suitable extension could 1206 provide clear benefits. 1208 4. Protocol Parameters 1210 4.1. RTSP Version 1212 HTTP specification section [H3.1] applies, with "HTTP" replaced by 1213 "RTSP". This specification defines version 2.0 of RTSP. 1215 4.2. RTSP IRI and URI 1217 RTSP 2.0 defines and registers three URI schemas "rtsp", "rtsps" and 1218 "rtspu". The usage of the last, "rtspu", is unspecified in RTSP 2.0, 1219 and is defined here to register and reserve the URI scheme that is 1220 defined in RTSP 1.0. The "rtspu" scheme indicates undefined 1221 transport of the RTSP messages over unreliable transport (UDP). The 1222 syntax of "rtsp" and "rtsps" URIs has been changed from RTSP 1.0. 1224 This specification also defines the format of the RTSP IRI [RFC3987] 1225 that can be used as RTSP resource identifiers and locators, in web 1226 pages, user interfaces, on paper, etc. However, the RTSP request 1227 message format only allows usage of the absolute URI format. The 1228 RTSP IRI format SHALL use the rules and transformation for IRIs 1229 defined in [RFC3987]. This way RTSP 2.0 URIs for request can be 1230 produced from an RTSP IRI. 1232 The RTSP IRI and URI are both syntax restricted compared to the 1233 generic syntax defined in [RFC3986] and RFC [RFC3987]: 1235 o An absolute URI requires the authority part; i.e., a host identity 1236 must be provided. 1238 o Parameters in the path element are prefixed with the reserved 1239 separator ";". 1241 The RTSP URI and IRI is case sensitive, with the exception of those 1242 parts that [RFC3986] and [RFC3987] defines as case-insensitive; for 1243 example, the scheme and host part. 1245 The fragment identifier is used as defined in sections 3.5 and 4.3 of 1246 [RFC3986], i.e. the fragment is to be stripped from the URI by the 1247 requestor and not included in the request. The user agent also needs 1248 to interpret the value of the fragment based on the media type the 1249 request relates to; i.e., the media type indicated in Content-Type 1250 header in the response to DESCRIBE. 1252 The syntax of any URI query string is unspecified and responder 1253 (usually the server) specific. The query is, from the requestor's 1254 perspective, an opaque string and needs to be handled as such. 1256 The URI scheme "rtsp" requires that commands are issued via a 1257 reliable protocol (within the Internet, TCP), while the scheme 1258 "rtsps" identifies a reliable transport using secure transport (TLS 1259 [RFC5246], see (Section 19). 1261 For the scheme "rtsp", if no port number is provided in the authority 1262 part of the URI port number 554 SHALL be used. For the scheme 1263 "rtsps", the TCP port 322 is registered and SHALL be assumed. 1265 A presentation or a stream is identified by a textual media 1266 identifier, using the character set and escape conventions of URIs 1267 [RFC3986]. URIs may refer to a stream or an aggregate of streams; 1268 i.e., a presentation. Accordingly, requests described in 1269 (Section 13) can apply to either the whole presentation or an 1270 individual stream within the presentation. Note that some request 1271 methods can only be applied to streams, not presentations, and vice 1272 versa. 1274 For example, the RTSP URI: 1276 rtsp://media.example.com:554/twister/audiotrack 1278 may identify the audio stream within the presentation "twister", 1279 which can be controlled via RTSP requests issued over a TCP 1280 connection to port 554 of host media.example.com. 1282 Also, the RTSP URI: 1284 rtsp://media.example.com:554/twister 1286 identifies the presentation "twister", which may be composed of audio 1287 and video streams, but could also be something else like a random 1288 media redirector. 1290 This does not imply a standard way to reference streams in URIs. 1291 The presentation description defines the hierarchical 1292 relationships in the presentation and the URIs for the individual 1293 streams. A presentation description may name a stream "a.mov" and 1294 the whole presentation "b.mov". 1296 The path components of the RTSP URI are opaque to the client and do 1297 not imply any particular file system structure for the server. 1299 This decoupling also allows presentation descriptions to be used 1300 with non-RTSP media control protocols simply by replacing the 1301 scheme in the URI. 1303 4.3. Session Identifiers 1305 Session identifiers are strings of any arbitrary length but with a 1306 minimum length of 8 characters. A session identifier MUST be chosen 1307 cryptographically random (see [RFC4086]) and MUST be at least 8 1308 characters long (can contain a maximum of 48 bits of entropy) to make 1309 guessing it more difficult. It is RECOMMENDED that it contains 128 1310 bits of entropy, i.e. approxamitely 22 characters from a high quality 1311 generator. (see Section 21.) However, it needs to be noted that the 1312 session identifier does not provide any security against session 1313 hijacking unless it is kept confidential between client, server and 1314 trusted proxies. 1316 4.4. SMPTE Relative Timestamps 1318 A SMPTE relative timestamp expresses time relative to the start of 1319 the clip. Relative timestamps are expressed as SMPTE time codes for 1320 frame-level access accuracy. The time code has the format 1322 hours:minutes:seconds:frames.subframes, 1324 with the origin at the start of the clip. The default smpte format 1325 is "SMPTE 30 drop" format, with frame rate is 29.97 frames per 1326 second. Other SMPTE codes MAY be supported (such as "SMPTE 25") 1327 through the use of alternative use of "smpte-type". For SMPTE 30, 1328 the "frames" field in the time value can assume the values 0 through 1329 29. The difference between 30 and 29.97 frames per second is handled 1330 by dropping the first two frame indices (values 00 and 01) of every 1331 minute, except every tenth minute. If the frame and the subframe 1332 values are zero, they may be omitted. Subframes are measured in one- 1333 hundredth of a frame. 1335 Examples: 1337 smpte=10:12:33:20- 1338 smpte=10:07:33- 1339 smpte=10:07:00-10:07:33:05.01 1340 smpte-25=10:07:00-10:07:33:05.01 1342 4.5. Normal Play Time 1344 Normal play time (NPT) indicates the stream absolute position 1345 relative to the beginning of the presentation, not to be confused 1346 with the Network Time Protocol (NTP) [RFC1305]. The timestamp 1347 consists of a decimal fraction. The part left of the decimal may be 1348 expressed in either seconds or hours, minutes, and seconds. The part 1349 right of the decimal point measures fractions of a second. 1351 The beginning of a presentation corresponds to 0.0 seconds. Negative 1352 values are not defined. The special constant "now" is defined as the 1353 current instant of a live event. It MAY only be used for live 1354 events, and SHALL NOT be used for on-demand (i.e., non-live) content. 1356 NPT is defined as in DSM-CC [ISO.13818-6.1995]: "Intuitively, NPT is 1357 the clock the viewer associates with a program. It is often 1358 digitally displayed on a VCR. NPT advances normally when in normal 1359 play mode (scale = 1), advances at a faster rate when in fast scan 1360 forward (high positive scale ratio), decrements when in scan reverse 1361 (high negative scale ratio) and is fixed in pause mode. NPT is 1362 (logically) equivalent to SMPTE time codes." 1364 Examples: 1366 npt=123.45-125 1367 npt=12:05:35.3- 1368 npt=now- 1370 The syntax conforms to ISO 8601 [ISO.8601.2000]. The npt-sec 1371 notation is optimized for automatic generation, the npt-hhmmss 1372 notation for consumption by human readers. The "now" constant 1373 allows clients to request to receive the live feed rather than the 1374 stored or time-delayed version. This is needed since neither 1375 absolute time nor zero time are appropriate for this case. 1377 4.6. Absolute Time 1379 Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps, 1380 using UTC (GMT). Fractions of a second may be indicated. 1382 Example for November 8, 1996 at 14h37 and 20 and a quarter seconds 1383 UTC: 1385 19961108T143720.25Z 1387 4.7. Feature-tags 1389 Feature-tags are unique identifiers used to designate features in 1390 RTSP. These tags are used in Require (Section 16.42), Proxy-Require 1391 (Section 16.35), Proxy-Supported (Section 16.36), and Unsupported 1392 (Section 16.52) header fields. 1394 A feature-tag definition MUST indicate which combination of clients, 1395 servers or proxies they applies to. 1397 The creator of a new RTSP feature-tag should either prefix the 1398 feature-tag with a reverse domain name (e.g., 1399 "com.example.mynewfeature" is an apt name for a feature whose 1400 inventor can be reached at "example.com"), or register the new 1401 feature-tag with the Internet Assigned Numbers Authority (IANA) (see 1402 IANA Section 22). 1404 The usage of feature-tags is further described in Section 11 that 1405 deals with capability handling. 1407 4.8. Entity Tags 1409 Entity tags are opaque strings that are used to compare two entities 1410 from the same resource, for example in caches or to optimize setup 1411 after a redirect. Further explanation is present in [H3.11]. For an 1412 explanation of how to compare entity tags see [H13.3]. Entity tags 1413 can be carried in the ETag header (see Section 16.21) or in SDP (see 1414 Appendix D.1.9). 1416 Entity tags are used in RTSP to make some methods conditional. The 1417 methods are made conditional through the inclusion of headers, see 1418 Section 16.24 and Section 16.26. Note that RTSP entity tags apply to 1419 the complete presentation; i.e., both the session description and the 1420 individual media streams. Thus entity tags can be used to verify at 1421 setup time after a redirect that the same session description applies 1422 to the media at the new location using the If-Match header. 1424 5. RTSP Message 1426 RTSP is a text-based protocol and uses the ISO 10646 character set in 1427 UTF-8 encoding (RFC 3629 [RFC3629]). Lines SHALL be terminated by 1428 CRLF. 1430 Text-based protocols make it easier to add optional parameters in 1431 a self-describing manner. Since the number of parameters and the 1432 frequency of commands is low, processing efficiency is not a 1433 concern. Text-based protocols, if done carefully, also allow easy 1434 implementation of research prototypes in scripting languages such 1435 as Tcl, Visual Basic and Perl. 1437 The ISO 10646 character set avoids tricky character set switching, 1438 but is invisible to the application as long as US-ASCII is being 1439 used. This is also the encoding used for RTCP [RFC3550]. ISO 8859-1 1440 translates directly into Unicode with a high-order octet of zero. 1441 ISO 8859-1 characters with the most-significant bit set are 1442 represented as 1100001x 10xxxxxx. (See RFC 3629 [RFC3629]) 1444 Requests contain methods, the object the method is operating upon and 1445 parameters to further describe the method. Methods are idempotent 1446 unless otherwise noted. Methods are also designed to require little 1447 or no state maintenance at the media server. 1449 5.1. Message Types 1451 RTSP messages consist of requests from client to server or server to 1452 client and responses in the reverse direction. Request Section 7 and 1453 Response Section 8 messages use the generic message format of RFC 822 1454 [9] for transferring entities (the payload of the message). Both 1455 types of message consist of a start-line, zero or more header fields 1456 (also known as "headers"), an empty line (i.e., a line with nothing 1457 preceding the CRLF) indicating the end of the header fields, and 1458 possibly a message-body. 1460 generic-message = start-line 1461 *(message-header CRLF) 1462 CRLF 1463 [ message-body ] 1464 start-line = Request-Line | Status-Line 1466 In the interest of robustness, servers SHOULD ignore any empty 1467 line(s) received where a Request-Line is expected. In other words, 1468 if the server is reading the protocol stream at the beginning of a 1469 message and receives a CRLF first, it should ignore the CRLF. 1471 5.2. Message Headers 1473 See [H4.2]. 1475 Unknown message headers SHALL be ignored by a RTSP server or client. 1476 An RTSP Proxy SHALL forward unknown message headers. Message headers 1477 defined outside of this specification that are required to be 1478 interpret by the RTSP agent will need to use feature tags 1479 (Section 4.7) and include it in the appropriate Require 1480 (Section 16.42) or Proxy-Require (Section 16.35) header. 1482 5.3. Message Body 1484 See [H4.3]. 1486 Unlike HTTP, the presence of a message-body in either a request or a 1487 response MUST be signaled by the inclusion of a Content-Length header 1488 field (see Section 16.16). 1490 5.4. Message Length 1492 When a message body is included with a message, the length of that 1493 body is determined by one of the following (in order of precedence): 1495 1. Any response message which MUST NOT include a message body (such 1496 as the 1xx, 204, and 304 responses) is always terminated by the 1497 first empty line after the header fields, regardless of the 1498 entity-header fields present in the message. (Note: An empty 1499 line is a line with nothing preceding the CRLF.) 1501 2. If a Content-Length header field (Section 16.16) is present, its 1502 value in bytes represents the length of the message-body. If 1503 this header field is not present, a value of zero is assumed. 1505 Unlike an HTTP message, an RTSP message MUST contain a Content-Length 1506 header field whenever it contains a message body. Note that RTSP 1507 does not support the HTTP/1.1 "chunked" transfer coding (see 1508 [H3.6.1]). 1510 Given the moderate length of presentation descriptions returned, 1511 the server should always be able to determine its length, even if 1512 it is generated dynamically, making the chunked transfer encoding 1513 unnecessary. 1515 6. General Header Fields 1517 See [H4.5], except that the Pragma, Trailer, Transfer-Encoding, 1518 Upgrade, and Warning headers are not defined. RTSP further defines 1519 the CSeq, Pipelined-Requests, Proxy-Supported and Timestamp headers. 1520 The general headers are listed in Table 1: 1522 +--------------------+--------------------+ 1523 | Header Name | Defined in Section | 1524 +--------------------+--------------------+ 1525 | Cache-Control | Section 16.10 | 1526 | | | 1527 | Connection | Section 16.11 | 1528 | | | 1529 | CSeq | Section 16.19 | 1530 | | | 1531 | Date | Section 16.20 | 1532 | | | 1533 | Media-Properties | Section 16.29 | 1534 | | | 1535 | Media-Range | Section 16.30 | 1536 | | | 1537 | Pipelined-Requests | Section 16.32 | 1538 | | | 1539 | Proxy-Supported | Section 16.36 | 1540 | | | 1541 | Seek-Style | Section 16.45 | 1542 | | | 1543 | Supported | Section 16.49 | 1544 | | | 1545 | Timestamp | Section 16.50 | 1546 | | | 1547 | Via | Section 16.55 | 1548 +--------------------+--------------------+ 1550 Table 1: The general headers used in RTSP 1552 7. Request 1554 A request message uses the format outlined below regardless of the 1555 direction of a request, client to server or server to client: 1557 o Request line, containing the method to be applied to the resource, 1558 the identifier of the resource, and the protocol version in use; 1560 o Zero or more Header lines, that can be of the following types: 1561 general (Section 6), request (Section 7.2), or entity 1562 (Section 9.1); 1564 o One empty line (CRLF) to indicate the end of the header section; 1566 o Optionally a message body (entity), consisting of one or more 1567 lines. The length of the message body in bytes is indicated by 1568 the Content-Length entity header. 1570 7.1. Request Line 1572 The request line provides the key information about the request: what 1573 method, on what resources and using which RTSP version. The methods 1574 that are defined by this specification are listed in Table 2. 1576 +---------------+--------------------+ 1577 | Method | Defined in Section | 1578 +---------------+--------------------+ 1579 | DESCRIBE | Section 13.2 | 1580 | | | 1581 | GET_PARAMETER | Section 13.8 | 1582 | | | 1583 | OPTIONS | Section 13.1 | 1584 | | | 1585 | PAUSE | Section 13.6 | 1586 | | | 1587 | PLAY | Section 13.4 | 1588 | | | 1589 | PLAY_NOTIFY | Section 13.5 | 1590 | | | 1591 | REDIRECT | Section 13.10 | 1592 | | | 1593 | SETUP | Section 13.3 | 1594 | | | 1595 | SET_PARAMETER | Section 13.9 | 1596 | | | 1597 | TEARDOWN | Section 13.7 | 1598 +---------------+--------------------+ 1600 Table 2: The RTSP Methods 1602 The syntax of the RTSP request line is the following: 1604 CRLF 1606 Note: This syntax cannot be freely changed in future versions of 1607 RTSP. This line needs to remain parsable by older RTSP 1608 implementations since it indicates the RTSP version of the message. 1610 In contrast to HTTP/1.1 [RFC2616], RTSP requests identify the 1611 resource through an absolute RTSP URI (scheme, host, and port) (see 1612 Section 4.2) rather than just the absolute path. 1614 HTTP/1.1 requires servers to understand the absolute URI, but 1615 clients are supposed to use the Host request header. This is 1616 purely needed for backward-compatibility with HTTP/1.0 servers, a 1617 consideration that does not apply to RTSP. 1619 An asterisk "*" can be used instead of an absolute URI in the 1620 Request-URI part to indicate that the request does not apply to a 1621 particular resource, but to the server or proxy itself, and is only 1622 allowed when the request method does not necessarily apply to a 1623 resource. 1625 For example: 1627 OPTIONS * RTSP/2.0 1629 An OPTIONS in this form will determine the capabilities of the server 1630 or the proxy that first receives the request. If the capability of 1631 the specific server needs to be determined, without regard to the 1632 capability of an intervening proxy, the server should be addressed 1633 explicitly with an absolute URI that contains the server's address. 1635 For example: 1637 OPTIONS rtsp://example.com RTSP/2.0 1639 7.2. Request Header Fields 1641 The RTSP headers in Table 3 can be included in a request, as request 1642 headers, to modify the specifics of the request. Some of these 1643 headers may also be used in the response to a request, as response 1644 headers, to modify the specifics of a response (Section 8.2). 1646 +--------------------+--------------------+ 1647 | Header | Defined in Section | 1648 +--------------------+--------------------+ 1649 | Accept | Section 16.1 | 1650 | | | 1651 | Accept-Credentials | Section 16.2 | 1652 | | | 1653 | Accept-Encoding | Section 16.3 | 1654 | | | 1655 | Accept-Language | Section 16.4 | 1656 | | | 1657 | Authorization | Section 16.7 | 1658 | | | 1659 | Bandwidth | Section 16.8 | 1660 | | | 1661 | Blocksize | Section 16.9 | 1662 | | | 1663 | From | Section 16.23 | 1664 | | | 1665 | If-Match | Section 16.24 | 1666 | | | 1667 | If-Modified-Since | Section 16.25 | 1668 | | | 1669 | If-None-Match | Section 16.26 | 1670 | | | 1671 | Notify-Reason | Section 16.31 | 1672 | | | 1673 | Proxy-Require | Section 16.35 | 1674 | | | 1675 | Range | Section 16.38 | 1676 | | | 1677 | Referer | Section 16.39 | 1678 | | | 1679 | Request-Status | Section 16.41 | 1680 | | | 1681 | Require | Section 16.42 | 1682 | | | 1683 | Scale | Section 16.44 | 1684 | | | 1685 | Session | Section 16.48 | 1686 | | | 1687 | Speed | Section 16.46 | 1688 | | | 1689 | Supported | Section 16.49 | 1690 | | | 1691 | Transport | Section 16.51 | 1692 | | | 1693 | User-Agent | Section 16.53 | 1694 +--------------------+--------------------+ 1696 Table 3: The RTSP request headers 1698 Detailed headers definition are provided in Section 16. 1700 New request headers may be defined. If the receiver of the request 1701 is required to understand the request header, the request MUST 1702 include a corresponding feature tag in a Require or Proxy-Require 1703 header to ensure the processing of the header. actually happens. 1705 8. Response 1707 [H6] applies except that HTTP-Version is replaced by RTSP-Version. 1708 Also, RTSP defines additional status codes and does not define some 1709 of the HTTP codes. The valid response codes and the methods they can 1710 be used with are listed in Table 4. 1712 After receiving and interpreting a request message, the recipient 1713 responds with an RTSP response message. 1715 8.1. Status-Line 1717 The first line of a Response message is the Status-Line, consisting 1718 of the protocol version followed by a numeric status code and the 1719 textual phrase associated with the status code, with each element 1720 separated by SP characters. No CR or LF is allowed except in the 1721 final CRLF sequence. 1723 SP SP CRLF 1725 8.1.1. Status Code and Reason Phrase 1727 The Status-Code element is a 3-digit integer result code of the 1728 attempt to understand and satisfy the request. These codes are fully 1729 defined in Section 15. The Reason-Phrase is intended to give a short 1730 textual description of the Status-Code. The Status-Code is intended 1731 for use by automata and the Reason-Phrase is intended for the human 1732 user. The client is not required to examine or display the Reason- 1733 Phrase. 1735 The first digit of the Status-Code defines the class of response. 1736 The last two digits do not have any categorization role. There are 5 1737 values for the first digit: 1739 1xx: Informational - Request received, continuing process 1741 2xx: Success - The action was successfully received, understood, and 1742 accepted 1744 3rr: Redirection - Further action needs to be taken in order to 1745 complete the request 1747 4xx: Client Error - The request contains bad syntax or cannot be 1748 fulfilled 1750 5xx: Server Error - The server failed to fulfill an apparently valid 1751 request 1753 The individual values of the numeric status codes defined for 1754 RTSP/2.0, and an example set of corresponding Reason-Phrases, are 1755 presented in Table 4. The reason phrases listed here are only 1756 recommended; they may be replaced by local equivalents without 1757 affecting the protocol. Note that RTSP adopts most HTTP/1.1 1758 [RFC2616] status codes and adds RTSP-specific status codes starting 1759 at x50 to avoid conflicts with newly defined HTTP status codes. 1761 RTSP status codes are extensible. RTSP applications are not required 1762 to understand the meaning of all registered status codes, though such 1763 understanding is obviously desirable. However, applications MUST 1764 understand the class of any status code, as indicated by the first 1765 digit, and treat any unrecognized response as being equivalent to the 1766 x00 status code of that class, with the exception that an 1767 unrecognized response MUST NOT be cached. For example, if an 1768 unrecognized status code of 431 is received by the client, it can 1769 safely assume that there was something wrong with its request and 1770 treat the response as if it had received a 400 status code. In such 1771 cases, user agents SHOULD present to the user the entity returned 1772 with the response, since that entity is likely to include human- 1773 readable information which will explain the unusual status. 1775 +------+----------------------------------------+-----------------+ 1776 | Code | Reason | Method | 1777 +------+----------------------------------------+-----------------+ 1778 | 100 | Continue | all | 1779 | | | | 1780 | | | | 1781 | 200 | OK | all | 1782 | | | | 1783 | | | | 1784 | 300 | Multiple Choices | all | 1785 | | | | 1786 | 301 | Moved Permanently | all | 1787 | | | | 1788 | 302 | Found | all | 1789 | | | | 1790 | 303 | See Other | all | 1791 | | | | 1792 | 305 | Use Proxy | all | 1793 | | | | 1794 | | | | 1795 | 400 | Bad Request | all | 1796 | | | | 1797 | 401 | Unauthorized | all | 1798 | 402 | Payment Required | all | 1799 | | | | 1800 | 403 | Forbidden | all | 1801 | | | | 1802 | 404 | Not Found | all | 1803 | | | | 1804 | 405 | Method Not Allowed | all | 1805 | | | | 1806 | 406 | Not Acceptable | all | 1807 | | | | 1808 | 407 | Proxy Authentication Required | all | 1809 | | | | 1810 | 408 | Request Timeout | all | 1811 | | | | 1812 | 410 | Gone | all | 1813 | | | | 1814 | 411 | Length Required | all | 1815 | | | | 1816 | 412 | Precondition Failed | DESCRIBE, SETUP | 1817 | | | | 1818 | 413 | Request Entity Too Large | all | 1819 | | | | 1820 | 414 | Request-URI Too Long | all | 1821 | | | | 1822 | 415 | Unsupported Media Type | all | 1823 | | | | 1824 | 451 | Parameter Not Understood | SET_PARAMETER | 1825 | | | | 1826 | 452 | reserved | n/a | 1827 | | | | 1828 | 453 | Not Enough Bandwidth | SETUP | 1829 | | | | 1830 | 454 | Session Not Found | all | 1831 | | | | 1832 | 455 | Method Not Valid In This State | all | 1833 | | | | 1834 | 456 | Header Field Not Valid | all | 1835 | | | | 1836 | 457 | Invalid Range | PLAY, PAUSE | 1837 | | | | 1838 | 458 | Parameter Is Read-Only | SET_PARAMETER | 1839 | | | | 1840 | 459 | Aggregate Operation Not Allowed | all | 1841 | | | | 1842 | 460 | Only Aggregate Operation Allowed | all | 1843 | | | | 1844 | 461 | Unsupported Transport | all | 1845 | | | | 1846 | 462 | Destination Unreachable | all | 1847 | | | | 1848 | 463 | Destination Prohibited | SETUP | 1849 | | | | 1850 | 464 | Data Transport Not Ready Yet | PLAY | 1851 | | | | 1852 | 465 | Notification Reason Unknown | PLAY_NOTIFY | 1853 | | | | 1854 | 470 | Connection Authorization Required | all | 1855 | | | | 1856 | 471 | Connection Credentials not accepted | all | 1857 | | | | 1858 | 472 | Failure to establish secure connection | all | 1859 | | | | 1860 | | | | 1861 | 500 | Internal Server Error | all | 1862 | | | | 1863 | 501 | Not Implemented | all | 1864 | | | | 1865 | 502 | Bad Gateway | all | 1866 | | | | 1867 | 503 | Service Unavailable | all | 1868 | | | | 1869 | 504 | Gateway Timeout | all | 1870 | | | | 1871 | 505 | RTSP Version Not Supported | all | 1872 | | | | 1873 | 551 | Option not support | all | 1874 +------+----------------------------------------+-----------------+ 1876 Table 4: Status codes and their usage with RTSP methods 1878 8.2. Response Header Fields 1880 The response-header fields allow the request recipient to pass 1881 additional information about the response which cannot be placed in 1882 the Status-Line. These header fields give information about the 1883 server and about further access to the resource identified by the 1884 Request-URI. All headers currently classified as response headers 1885 are listed in Table 5. 1887 +------------------------+--------------------+ 1888 | Header | Defined in Section | 1889 +------------------------+--------------------+ 1890 | Accept-Credentials | Section 16.2 | 1891 | | | 1892 | Accept-Ranges | Section 16.5 | 1893 | | | 1894 | Connection-Credentials | Section 16.12 | 1895 | | | 1896 | ETag | Section 16.21 | 1897 | | | 1898 | Location | Section 16.28 | 1899 | | | 1900 | Proxy-Authenticate | Section 16.33 | 1901 | | | 1902 | Public | Section 16.37 | 1903 | | | 1904 | Range | Section 16.38 | 1905 | | | 1906 | Retry-After | Section 16.40 | 1907 | | | 1908 | RTP-Info | Section 16.43 | 1909 | | | 1910 | Scale | Section 16.44 | 1911 | | | 1912 | Session | Section 16.48 | 1913 | | | 1914 | Server | Section 16.47 | 1915 | | | 1916 | Speed | Section 16.46 | 1917 | | | 1918 | Transport | Section 16.51 | 1919 | | | 1920 | Unsupported | Section 16.52 | 1921 | | | 1922 | Vary | Section 16.54 | 1923 | | | 1924 | WWW-Authenticate | Section 16.56 | 1925 +------------------------+--------------------+ 1927 Table 5: The RTSP response headers 1929 Response-header field names can be extended reliably only in 1930 combination with a change in the protocol version. However the usage 1931 of feature-tags in the request allows the responding party to learn 1932 the capability of the receiver of the response. New or experimental 1933 header fields MAY be given the semantics of response-header fields if 1934 all parties in the communication recognize them to be response-header 1935 fields. Unrecognized header fields in responses are treated as 1936 entity-header fields. 1938 9. Entity 1940 Request and Response messages MAY transfer an entity if not otherwise 1941 restricted by the request method or response status code. An entity 1942 consists of entity-header fields and an entity-body, although some 1943 responses will only include the entity-headers. 1945 The SET_PARAMETER and GET_PARAMETER request and response, and 1946 DESCRIBE response MAY have an entity. All 4xx and 5xx responses MAY 1947 also have an entity. 1949 In this section, both sender and recipient refer to either the client 1950 or the server, depending on who sends and who receives the entity. 1952 9.1. Entity Header Fields 1954 Entity-header fields define meta-information about the entity-body 1955 or, if no body is present, about the resource identified by the 1956 request. The entity header fields are listed in Table 6. 1958 +------------------+--------------------+ 1959 | Header | Defined in Section | 1960 +------------------+--------------------+ 1961 | Allow | Section 16.6 | 1962 | | | 1963 | Content-Base | Section 16.13 | 1964 | | | 1965 | Content-Encoding | Section 16.14 | 1966 | | | 1967 | Content-Language | Section 16.15 | 1968 | | | 1969 | Content-Length | Section 16.16 | 1970 | | | 1971 | Content-Location | Section 16.17 | 1972 | | | 1973 | Content-Type | Section 16.18 | 1974 | | | 1975 | Expires | Section 16.22 | 1976 | | | 1977 | Last-Modified | Section 16.27 | 1978 +------------------+--------------------+ 1980 Table 6: The RTSP entity headers 1982 The extension-header mechanism allows additional entity-header fields 1983 to be defined without changing the protocol, but these fields cannot 1984 be assumed to be recognizable by the recipient. Unrecognized header 1985 fields SHOULD be ignored by the recipient and forwarded by proxies. 1987 9.2. Entity Body 1989 See [H7.2] with the addition that an RTSP message with an entity body 1990 MUST include the Content-Type and Content-Length headers. 1992 10. Connections 1994 RTSP requests can be transmitted using the two different connection 1995 scenarios listed below: 1997 o persistent - a transport connection is used for several request/ 1998 response transactions; 2000 o transient - a transport connection is used for a single request/ 2001 response transaction. 2003 RFC 2326 attempted to specify an optional mechanism for transmitting 2004 RTSP messages in connectionless mode over a transport protocol such 2005 as UDP. However, it was not specified in sufficient detail to allow 2006 for interoperable implementations. In an attempt to reduce 2007 complexity and scope, and due to lack of interest, RTSP 2.0 does not 2008 attempt to define a mechanism for supporting RTSP over UDP or other 2009 connectionless transport protocols. A side-effect of this is that 2010 RTSP requests SHALL NOT be sent to multicast groups since no 2011 connection can be established with a specific receiver in multicast 2012 environments. 2014 Certain RTSP headers, such as the CSeq header (Section 16.19), which 2015 may appear to be relevant only to connectionless transport scenarios 2016 are still retained and must be implemented according to the 2017 specification. In the case of CSeq, it is quite useful for matching 2018 responses to requests if the requests are pipelined (see Section 12). 2019 It is also useful in proxies for keeping track of the different 2020 requests when aggregating several client requests on a single TCP 2021 connection. 2023 10.1. Reliability and Acknowledgements 2025 When RTSP messages are transmitted using reliable transport 2026 protocols, they MUST NOT be retransmitted at the RTSP protocol level. 2027 Instead, the implementation must rely on the underlying transport to 2028 provide reliability. The RTSP implementation may use any indication 2029 of reception acknowledgement of the message from the underlying 2030 transport protocols to optimize the RTSP behavior. 2032 If both the underlying reliable transport such as TCP and the RTSP 2033 application retransmit requests, each packet loss or message loss 2034 may result in two retransmissions. The receiver typically cannot 2035 take advantage of the application-layer retransmission since the 2036 transport stack will not deliver the application-layer 2037 retransmission before the first attempt has reached the receiver. 2038 If the packet loss is caused by congestion, multiple 2039 retransmissions at different layers will exacerbate the 2040 congestion. 2042 Lack of acknowledgement of an RTSP request should be handled within 2043 the constraints of the connection timeout considerations described 2044 below (Section 10.4). 2046 10.2. Using Connections 2048 A TCP transport can be used for both persistent connections (for 2049 several message exchanges) and transient connections (for a single 2050 message exchange). Implementations of this specification MUST 2051 support RTSP over TCP. The scheme of the RTSP URI (Section 4.2) 2052 indicates the default port that the server will listen on. 2054 A server MUST handle both persistent and transient connections. 2056 Transient connections facilitate mechanisms for fault tolerance. 2057 They also allow for application layer mobility. A server and 2058 client pair that support transient connections can survive the 2059 loss of a TCP connection; e.g., due to a NAT timeout. When the 2060 client has discovered that the TCP connection has been lost, it 2061 can set up a new one when there is need to communicate again. 2063 A persistent connection MAY be used for all transactions between the 2064 server and client, including messages for multiple RTSP sessions. 2065 However a persistent connection MAY also be closed after a few 2066 message exchanges. For example, a client may use a persistent 2067 connection for the initial SETUP and PLAY message exchanges in a 2068 session and then close the connection. Later, when the client wishes 2069 to send a new request, such as a PAUSE for the session, a new 2070 connection would be opened. This connection may either be transient 2071 or persistent. 2073 An RTSP agent SHOULD NOT have more than one connection to the server 2074 at any given point. If a client or proxy handles multiple RTSP 2075 sessions on the same server, it SHOULD use only one connection for 2076 managing those sessions. 2078 This saves connection resources on the server. It also reduces 2079 complexity by and enabling the server to maintain less state about 2080 its sessions and connections. 2082 Unlike HTTP, RTSP allows a server to send requests to a client. 2083 However, this can be supported only if a client establishes a 2084 persistent connection with the server. In cases where a persistent 2085 connection does not exist between a server and its client, due to the 2086 lack of a signalling channel the server may be forced to drop an RTSP 2087 session without notifying the client. An example of such a case is 2088 when the server desires to send a REDIRECT request for an RTSP 2089 session to the client but is not able to do so because it cannot 2090 reach the client. 2092 Without a persistent connection between the client and the server, 2093 the media server has no reliable way of reaching the client. 2094 Also, this is the only way that requests from a server to its 2095 client are likely to traverse firewalls. 2097 In light of the above, it is RECOMMENDED that clients use persistent 2098 connections whenever possible. A client that supports persistent 2099 connections MAY "pipeline" its requests (see Section 12). 2101 10.3. Closing Connections 2103 The client MAY close a connection at any point when no outstanding 2104 request/response transactions exist for any RTSP session being 2105 managed through the connection. The server, however, SHOULD NOT 2106 close a connection until all RTSP sessions being managed through the 2107 connection have been timed out (Section 16.48). A server SHOULD NOT 2108 close a connection immediately after responding to a session-level 2109 TEARDOWN request for the last RTSP session being controlled through 2110 the connection. Instead, it should wait for a reasonable amount of 2111 time for the client to receive the TEARDOWN response, take 2112 appropriate action, and initiate the connection closing. The server 2113 SHOULD wait at least 10 seconds after sending the TEARDOWN response 2114 before closing the connection. 2116 This is to ensure that the client has time to issue a SETUP for a 2117 new session on the existing connection after having torn the last 2118 one down. 10 seconds should give the client ample opportunity get 2119 its message to the server. 2121 A server SHOULD NOT close the connection directly as a result of 2122 responding to a request with an error code. 2124 Certain error responses such as "460 Only Aggregate Operation 2125 Allowed" (Section 15.4.12) are used for negotiating capabilities 2126 of a server with respect to content or other factors. In such 2127 cases, it is inefficient for the server to close a connection on 2128 an error response. Also, such behavior would prevent 2129 implementation of advanced/special types of requests or result in 2130 extra overhead for the client when testing for new features. On 2131 the flip side, keeping connections open after sending an error 2132 response poses a Denial of Service security risk (Section 21). 2134 If a server closes a connection while the client is attempting to 2135 send a new request, the client will have to close its current 2136 connection, establish a new connection and send its request over the 2137 new connection. 2139 An RTSP message should not be terminated by closing the connection. 2140 Such a message MAY be considered to be incomplete by the receiver and 2141 discarded. An RTSP message is properly terminated as defined in 2142 Section 5. 2144 10.4. Timing Out Connections and RTSP Messages 2146 Receivers of a request (responder) SHOULD respond to requests in a 2147 timely manner even when a reliable transport such as TCP is used. 2148 Similarly, the sender of a request (requestor) SHOULD wait for a 2149 sufficient time for a response before concluding that the responder 2150 will not be acting upon its request. 2152 A responder SHOULD respond to all requests within 5 seconds. If the 2153 responder recognizes that processing of a request will take longer 2154 than 5 seconds, it SHOULD send a 100 (Continue) response as soon as 2155 possible. It SHOULD continue sending a 100 response every 5 seconds 2156 thereafter until it is ready to send the final response to the 2157 requestor. After sending a 100 response, the receiver MUST send a 2158 final response indicating the success or failure of the request. 2160 A requestor SHOULD wait at least 10 seconds for a response before 2161 concluding that the responder will not be responding to its request. 2162 After receiving a 100 response, the requestor SHOULD continue waiting 2163 for further responses. If more than 10 seconds elapses without 2164 receiving any response, the requestor MAY assume that the responder 2165 is unresponsive and abort the connection. 2167 A requestor SHOULD wait longer than 10 seconds for a response if it 2168 is experiencing significant transport delays on its connection to the 2169 responder. The requestor is capable of determining the RTT of the 2170 request/response cycle using the Timestamp header (Section 16.50) in 2171 any RTSP request. 2173 10.5. Showing Liveness 2175 The mechanisms for showing liveness of the client is, any RTSP 2176 request with a Session header, if RTP & RTCP is used an RTCP message, 2177 or through any other used media protocol capable of indicating 2178 liveness of the RTSP client. It is RECOMMENDED that a client does 2179 not wait to the last second of the timeout before trying to send a 2180 liveness message. The RTSP message may be lost or when using 2181 reliable protocols, such as TCP, the message may take some time to 2182 arrive safely at the receiver. To show liveness between RTSP request 2183 issued to accomplish other things, the following mechanisms can be 2184 used, in descending order of preference: 2186 RTCP: If RTP is used for media transport RTCP SHOULD be used. If 2187 RTCP is used to report transport statistics, it SHALL also work 2188 as keep alive. The server can determine the client by used 2189 network address and port together with the fact that the client 2190 is reporting on the servers SSRC(s). A downside of using RTCP 2191 is that it only gives statistical guarantees to reach the 2192 server. However that probability is so low that it can be 2193 ignored in most cases. For example, a session with 60 seconds 2194 timeout and enough bitrate assigned to RTCP messages to send a 2195 message from client to server on average every 5 seconds. That 2196 client have for a network with 5 % packet loss, the probability 2197 to fail showing liveness sign in that session within the 2198 timeout interval of 2.4*E-16. In sessions with shorter timeout 2199 times, or much higher packet loss, or small RTCP bandwidths 2200 SHOULD also use any of the mechanisms below. 2202 SET_PARAMETER: When using SET_PARAMETER for keep alive, no body 2203 SHOULD be included. This method is the RECOMMENDED RTSP method 2204 to use in request only intended to perform keep-alive. 2206 OPTIONS: This method does also work. However it causes the server 2207 to perform more unnecessary processing and result in bigger 2208 responses than necessary for the task. The reason for this is 2209 that the server needs to determine what capabilities that are 2210 associated with the media resource to correctly populate the 2211 Public and Allow headers. 2213 The timeout parameter MAY be included in a SETUP response, and SHALL 2214 NOT be included in requests. The server uses it to indicate to the 2215 client how long the server is prepared to wait between RTSP commands 2216 or other signs of life before closing the session due to lack of 2217 activity (see below and Appendix B). The timeout is measured in 2218 seconds, with a default of 60 seconds. The length of the session 2219 timeout SHALL NOT be changed in a established session. 2221 10.6. Use of IPv6 2223 Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP 2224 2.0 has been updated for explicit IPv6 support. Implementations of 2225 RTSP 2.0 MUST understand literal IPv6 addresses in URIs and headers. 2227 11. Capability Handling 2229 This section describes the available capability handling mechanism 2230 which allows RTSP to be extended. Extensions to this version of the 2231 protocol are basically done in two ways. First, new headers can be 2232 added. Secondly, new methods can be added. The capability handling 2233 mechanism is designed to handle both cases. 2235 When a method is added, the involved parties can use the OPTIONS 2236 method to discover wether it is supported. This is done by issuing a 2237 OPTIONS request to the other party. Depending on the URI it will 2238 either apply in regards to a certain media resource, the whole server 2239 in general, or simply the next hop. The OPTIONS response MUST 2240 contain a Public header which declares all methods supported for the 2241 indicated resource. 2243 It is not necessary to use OPTIONS to discover support of a method, 2244 the client could simply try the method. If the receiver of the 2245 request does not support the method it will respond with an error 2246 code indicating the the method is either not implemented (501) or 2247 does not apply for the resource (405). The choice between the two 2248 discovery methods depends on the requirements of the service. 2250 Feature-Tags are defined to handle functionality additions that are 2251 not new methods. Each feature-tag represents a certain block of 2252 functionality. The amount of functionality that a feature-tag 2253 represents can vary significantly. A feature-tag can for example 2254 represent the functionality a single RTSP header provides. Another 2255 feature-tag can represent much more functionality, such as the 2256 "play.basic" feature-tag which represents the minimal playback 2257 implementation. 2259 Feature-tags are used to determine wether the client, server or proxy 2260 supports the functionality that is necessary to achieve the desired 2261 service. To determine support of a feature-tag, several different 2262 headers can be used, each explained below: 2264 Supported: The supported header is used to determine the complete 2265 set of functionality that both client and server have. The 2266 intended usage is to determine before one needs to use a 2267 functionality that it is supported. It can be used in any 2268 method, however OPTIONS is the most suitable one as it at the 2269 same time determines all methods that are implemented. When 2270 sending a request the requestor declares all its capabilities 2271 by including all supported feature-tags. This results in that 2272 the receiver learns the requestors feature support. The 2273 receiver then includes its set of features in the response. 2275 Proxy-Supported: The Proxy-Supported header is used similar to the 2276 Supported header, but instead of giving the supported 2277 functionality of the client or server it provides both the 2278 requestor and the responder a view of what functionality the 2279 proxy chain between the two supports. Proxies are required to 2280 add this header whenever the Supported header is present, but 2281 proxies may independently of the requestor add it. 2283 Require: The Require header can be included in any request where the 2284 end-point, i.e. the client or server, is required to understand 2285 the feature to correctly perform the request. This can, for 2286 example, be a SETUP request where the server is required to 2287 understand a certain parameter to be able to set up the media 2288 delivery correctly. Ignoring this parameter would not have the 2289 desired effect and is not acceptable. Therefore the end-point 2290 receiving a request containing a Require MUST negatively 2291 acknowledge any feature that it does not understand and not 2292 perform the request. The response in cases where features are 2293 not supported are 551 (Option Not Supported). Also the 2294 features that are not supported are given in the Unsupported 2295 header in the response. 2297 Proxy-Require: This method has the same purpose and workings as 2298 Require except that it only applies to proxies and not the end- 2299 point. Features that needs to be supported by both proxies and 2300 end-point needs to be included in both the Require and Proxy- 2301 Require header. 2303 Unsupported: This header is used in a 551 error response, to 2304 indicate which feature(s) that was not supported. Such a 2305 response is only the result of the usage of the Require and/or 2306 Proxy-Require header where one or more feature where not 2307 supported. This information allows the requestor to make the 2308 best of situations as it knows which features are not 2309 supported. 2311 12. Pipelining Support 2313 Pipelining is a general method to improve performance of request 2314 response protocols by allowing the requesting entity to have more 2315 than one request outstanding and send them over the same persistent 2316 connection. For RTSP where the relative order of requests will 2317 matter it is important to maintain the order of the requests. 2318 Because of this the the responding entity SHALL process the incoming 2319 requests in their sending order. The sending order can be determined 2320 by the CSeq header and its sequence number. For TCP the delivery 2321 order will be the same as the sending order. The processing of the 2322 request SHALL also have been finished before processing the next 2323 request from the same entity. The responses MUST be sent in the 2324 order the requests was processed. 2326 RTSP 2.0 has extended support for pipelining compared to RTSP 1.0. 2327 The major improvement is to allow all requests to setup and initiate 2328 media playback to be pipelined after each other. This is 2329 accomplished by the utilization of the Pipelined-Requests header (see 2330 Section 16.32). This header allows a client to request that two or 2331 more requests is to be processed in the same RTSP session context 2332 which the first request creates. In other words a client can request 2333 that two or more media streams are set-up and then played without 2334 needing to wait for a single response. This speeds up the initial 2335 startup time for an RTSP session with at least one RTT. 2337 If a pipelined request builds on the succesful completion of one or 2338 more prior requests the requestor must verify that all requests were 2339 executed as expected. A common example will be two SETUP requests 2340 and a PLAY request. In case one of the SETUP fails unexpectedly, the 2341 PLAY request can still be succesfully executed. However, not as 2342 expected by the requesting client as only a single media instead of 2343 two will be played. In this case the client can send a PAUSE 2344 request, correct the failing SETUP request and then request it to be 2345 played. 2347 13. Method Definitions 2349 The method indicates what is to be performed on the resource 2350 identified by the Request-URI. The method name is case-sensitive. 2351 New methods may be defined in the future. Method names SHALL NOT 2352 start with a $ character (decimal 24) and MUST be a token as defined 2353 by the ABNF [RFC5234] in the syntax chapter Section 20. The methods 2354 are summarized in Table 7. 2356 +---------------+-----------+--------+--------------+---------------+ 2357 | method | direction | object | Server req. | Client req. | 2358 +---------------+-----------+--------+--------------+---------------+ 2359 | DESCRIBE | C -> S | P,S | recommended | recommended | 2360 | | | | | | 2361 | GET_PARAMETER | C -> S | P,S | optional | optional | 2362 | | | | | | 2363 | | S -> C | | | | 2364 | | | | | | 2365 | OPTIONS | C -> S | P,S | R=Req, | Sd=Req, R=Opt | 2366 | | | | Sd=Opt | | 2367 | | | | | | 2368 | | S -> C | | | | 2369 | | | | | | 2370 | PAUSE | C -> S | P,S | required | required | 2371 | | | | | | 2372 | PLAY | C -> S | P,S | required | required | 2373 | | | | | | 2374 | PLAY_NOTIFY | S -> C | P,S | required | required | 2375 | | | | | | 2376 | REDIRECT | S -> C | P,S | optional | required | 2377 | | | | | | 2378 | SETUP | C -> S | S | required | required | 2379 | | | | | | 2380 | SET_PARAMETER | C -> S | P,S | required | optional | 2381 | | | | | | 2382 | | S -> C | | | | 2383 | | | | | | 2384 | TEARDOWN | C -> S | P,S | required | required | 2385 +---------------+-----------+--------+--------------+---------------+ 2387 Table 7: Overview of RTSP methods, their direction, and what objects 2388 (P: presentation, S: stream) they operate on. Legend: R=Respond, 2389 Sd=Send, Opt: Optional, Req: Required 2391 Note on Table 7: GET_PARAMETER is recommended, but not required. 2392 For example, a fully functional server can be built to deliver 2393 media without any parameters. SET_PARAMETER is required however 2394 due to its usage for keep-alive. PAUSE is now required due to 2395 that it is the only way of getting out of the state machines play 2396 state without terminating the whole session. 2398 If an RTSP agent does not support a particular method, it MUST return 2399 501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD 2400 NOT try this method again for the given agent / resource combination. 2401 An RTSP proxy whos main function is to log or audit and not modify 2402 transport or media handling in any way MAY forward RTSP messages with 2403 unknown methods. Note, the proxy stil needs to perform the minimal 2404 required processing, like adding the Via header. 2406 13.1. OPTIONS 2408 The semantics of the RTSP OPTIONS method is equivalent to that of the 2409 HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is 2410 bi-directional, in that a client can request it to a server and vice 2411 versa. A client MUST implement the capability to send an OPTIONS 2412 request and a server or a proxy MUST implement the capability to 2413 respond to an OPTIONS request. The client, server or proxy MAY also 2414 implement the converse of their required capability. 2416 An OPTIONS request may be issued at any time. Such a request does 2417 not modify the session state. However, it may prolong the session 2418 lifespan (see below). The URI in an OPTIONS request determines the 2419 scope of the request and the corresponding response. If the Request- 2420 URI refers to a specific media resource on a given host, the scope is 2421 limited to the set of methods supported for that media resource by 2422 the indicated RTSP agent. A Request-URI with only the host address 2423 limits the scope to the specified RTSP agent's general capabilities 2424 without regard to any specific media. If the Request-URI is an 2425 asterisk ("*"), the scope is limited to the general capabilities of 2426 the next hop (i.e. the RTSP agent in direct communication with the 2427 request sender). 2429 Regardless of scope of the request, the Public header MUST always be 2430 included in the OPTIONS response listing the methods that are 2431 supported by the responding RTSP agent. In addition, if the scope of 2432 the request is limited to a media resource, the Allow header MUST be 2433 included in the response to enumerate the set of methods that are 2434 allowed for that resource unless the set of methods completely 2435 matches the set in the Public header. If the given resource is not 2436 available, the RTSP agent SHOULD return an appropriate response code 2437 such as 3rr or 4xx. The Supported header MAY be included in the 2438 request to query the set of features that are supported by the 2439 responding RTSP agent. 2441 The OPTIONS method can be used to keep an RTSP session alive. 2442 However, it is not the preferred means of session keep-alive 2443 signalling, see Section 16.48. An OPTIONS request intended for 2444 keeping alive an RTSP session MUST include the Session header with 2445 the associated session ID. Such a request SHOULD also use the media 2446 or the aggregated control URI as the Request-URI. 2448 Example: 2450 C->S: OPTIONS * RTSP/2.0 2451 CSeq: 1 2452 User-Agent: PhonyClient/1.2 2453 Require: 2454 Proxy-Require: gzipped-messages 2455 Supported: play.basic 2457 S->C: RTSP/2.0 200 OK 2458 CSeq: 1 2459 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE 2460 Supported: play.basic, implicit-play, gzipped-messages 2461 Server: PhonyServer/1.1 2463 Note that some of the feature-tags in Require and Proxy-Require are 2464 fictional features. 2466 13.2. DESCRIBE 2468 The DESCRIBE method is used to retrieve the description of a 2469 presentation or media object from a server. The Request-URI of the 2470 DESCRIBE request identifies the media resource of interest. The 2471 client MAY include the Accept header in the request to list the 2472 description formats that it understands. The server SHALL respond 2473 with a description of the requested resource and return the 2474 description in the entity of the response. The DESCRIBE reply- 2475 response pair constitutes the media initialization phase of RTSP. 2477 Example: 2479 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 2480 CSeq: 312 2481 User-Agent: PhonyClient 1.2 2482 Accept: application/sdp, application/example 2484 S->C: RTSP/2.0 200 OK 2485 CSeq: 312 2486 Date: Thu, 23 Jan 1997 15:35:06 GMT 2487 Server: PhonyServer 1.1 2488 Content-Base: rtsp://server.example.com/fizzle/foo/ 2489 Content-Type: application/sdp 2490 Content-Length: 358 2492 v=0 2493 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46 2494 s=SDP Seminar 2495 i=A Seminar on the session description protocol 2496 u=http://www.example.com/lectures/sdp.ps 2497 e=seminar@example.com (Seminar Management) 2498 c=IN IP4 0.0.0.0 2499 a=recvonly 2500 a=control:* 2501 t=2873397496 2873404696 2502 m=audio 3456 RTP/AVP 0 2503 a=control:audio 2504 m=video 2232 RTP/AVP 31 2505 a=control:video 2507 The DESCRIBE response SHOULD contain all media initialization 2508 information for the resource(s) that it describes. Servers SHOULD 2509 NOT use the DESCRIBE response as a means of media indirection by 2510 having the description point at another server, instead usage of 3rr 2511 responses are recommended. 2513 By forcing a DESCRIBE response to contain all media initialization 2514 for the set of streams that it describes, and discouraging the use 2515 of DESCRIBE for media indirection, any looping problems can be 2516 avoided that might have resulted from other approaches. 2518 Media initialization is a requirement for any RTSP-based system, but 2519 the RTSP specification does not dictate that this is required to be 2520 done via the DESCRIBE method. There are three ways that an RTSP 2521 client may receive initialization information: 2523 o via an RTSP DESCRIBE request 2525 o via some other protocol (HTTP, email attachment, etc.) 2526 o via some form of a user interface 2528 If a client obtains a valid description from an alternate source, the 2529 client MAY use this description for initialization purposes without 2530 issuing a DESCRIBE request for the same media. 2532 It is RECOMMENDED that minimal servers support the DESCRIBE method, 2533 and highly recommended that minimal clients support the ability to 2534 act as "helper applications" that accept a media initialization file 2535 from a user interface, and/or other means that are appropriate to the 2536 operating environment of the clients. 2538 13.3. SETUP 2540 The SETUP request for an URI specifies the transport mechanism to be 2541 used for the streamed media. The SETUP method may be used in two 2542 different cases; Create an RTSP session and change the transport 2543 parameters of already set up media stream. SETUP can be used in all 2544 three states; INIT, and READY, for both purposes and in PLAY to 2545 change the transport parameters. There is also a third possibile 2546 usage for the SETUP method which is not specified in this memo: 2547 adding a media to a session. Using SETUP to add media to an existing 2548 session, when the session is in PLAY state, is unspecified. 2550 The Transport header, see Section 16.51, specifies the transport 2551 parameters acceptable to the client for data transmission; the 2552 response will contain the transport parameters selected by the 2553 server. This allows the client to enumerate in descending order of 2554 preference the transport mechanisms and parameters acceptable to it, 2555 while the server can select the most appropriate. It is expected 2556 that the session description format used will enable the client to 2557 select a limited number possible configurations that are offered to 2558 the server to choose from. All transport related parameters shall be 2559 included in the Transport header, the use of other headers for this 2560 purpose is discouraged due to middleboxes, such as firewalls or NATs. 2562 For the benefit of any intervening firewalls, a client SHALL indicate 2563 the known transport parameters, even if it has no influence over 2564 these parameters, for example, where the server advertises a fixed 2565 multicast address as destination. 2567 Since SETUP includes all transport initialization information, 2568 firewalls and other intermediate network devices (which need this 2569 information) are spared the more arduous task of parsing the 2570 DESCRIBE response, which has been reserved for media 2571 initialization. 2573 The client SHALL include the Accept-Ranges header in the request 2574 indicating all supported unit formats in the Range header. This 2575 allows the server to know which format it may use in future session 2576 related responses, such as PLAY response without any range in the 2577 request. If the client does not support a time format necessary for 2578 the presentation the server SHALL respond using 456 (Header Field Not 2579 Valid for Resource) and include the Accept-Ranges header with the 2580 range unit formats supported for the resource. 2582 In a SETUP response the server SHALL include the Accept-Ranges header 2583 (see Section 16.5) to indicate which time formats that are acceptable 2584 to use for this media resource. 2586 The SETUP response 200 OK SHALL include the Media-Properties header 2587 (see Section 16.29 ). The combination of the parameters of the 2588 Media-Properties header indicate the nature of the content present in 2589 the session (see also Section 1.5). For example, a live stream with 2590 time shifting is indicated by 2592 o Random Access set to Random-Access, 2594 o Content Modifications set to Time Progressing, 2596 o Retention set to Time-Duration (with specific recording window 2597 time value). 2599 The SETUP response 200 OK SHALL include the Media-Range header (see 2600 Section 16.30) if the media is Time-Progressing. 2602 A basic example for SETUP: 2604 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 2605 CSeq: 302 2606 Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589", 2607 RTP/AVP/TCP;unicast;interleaved=0-1 2608 Accept-Ranges: NPT, UTC 2609 User-Agent: PhonyClient/1.2 2611 S->C: RTSP/2.0 200 OK 2612 CSeq: 302 2613 Date: Thu, 23 Jan 1997 15:35:06 GMT 2614 Server: PhonyServer 1.1 2615 Session: 47112344;timeout=60 2616 Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/ 2617 "192.0.2.53:4589"; src_addr="192.0.2.241:6256"/ 2618 "192.0.2.241:6257"; ssrc=2A3F93ED 2619 Accept-Ranges: NPT 2620 Media-Properties: Random-Access=3.2, Time-Progressing, 2621 Time-Duration=3600.0 2623 Media-Range: npt=0-2893.23 2625 In the above example the client wants to create an RTSP session 2626 containing the media resource "rtsp://example.com/foo/bar/baz.rm". 2627 The transport parameters acceptable to the client is either RTP/AVP/ 2628 UDP (UDP per default) to be received on client port 4588 and 4589 or 2629 RTP/AVP interleaved on the RTSP control channel. The server selects 2630 the RTP/AVP/UDP transport and adds the ports it will send and 2631 received RTP and RTCP from, and the RTP SSRC that will be used by the 2632 server. 2634 The server MUST generate a session identifier in response to a 2635 successful SETUP request, unless a SETUP request to a server includes 2636 a session identifier, in which case the server MUST bundle this setup 2637 request into the existing session (aggregated session) or return 2638 error 459 (Aggregate Operation Not Allowed) (see Section 15.4.11). 2639 An Aggregate control URI MUST be used to control an aggregated 2640 session. This URI MUST be different from the stream control URIs of 2641 the individual media streams included in the aggregate. The 2642 Aggregate control URI is to be specified by the session description 2643 if the server supports aggregated control and aggregated control is 2644 desired for the session. However even if aggregated control is 2645 offered the client MAY chose to not set up the session in aggregated 2646 control. If an Aggregate control URI is not specified in the session 2647 description, it is normally an indication that non-aggregated control 2648 should be used. The SETUP of media streams in an aggregate which has 2649 not been given an aggregated control URI is unspecified. 2651 While the session ID sometimes has enough information for 2652 aggregate control of a session, the Aggregate control URI is still 2653 important for some methods such as SET_PARAMETER where the control 2654 URI enables the resource in question to be easily identified. The 2655 Aggregate control URI is also useful for proxies, enabling them to 2656 route the request to the appropriate server, and for logging, 2657 where it is useful to note the actual resource that a request was 2658 operating on. 2660 A session will exist until it is either removed by a TEARDOWN request 2661 or is timed-out by the server. The server MAY remove a session that 2662 has not demonstrated liveness signs from the client(s) within a 2663 certain timeout period. The default timeout value is 60 seconds; the 2664 server MAY set this to a different value and indicate so in the 2665 timeout field of the Session header in the SETUP response. For 2666 further discussion see Section 16.48. Signs of liveness for an RTSP 2667 session are: 2669 o Any RTSP request from a client(s) which includes a Session header 2670 with that session's ID. 2672 o If RTP is used as a transport for the underlying media streams, an 2673 RTCP sender or receiver report from the client(s) for any of the 2674 media streams in that RTSP session. RTCP Sender Reports may for 2675 example be received in sessions where the server is invited into a 2676 conference session and is as valid for keep-alive. 2678 If a SETUP request on a session fails for any reason, the session 2679 state, as well as transport and other parameters for associated 2680 streams SHALL remain unchanged from their values as if the SETUP 2681 request had never been received by the server. 2683 13.3.1. Changing Transport Parameters 2685 A client MAY issue a SETUP request for a stream that is already set 2686 up or playing in the session to change transport parameters, which a 2687 server MAY allow. If it does not allow changing of parameters, it 2688 MUST respond with error 455 (Method Not Valid In This State). 2689 Reasons to support changing transport parameters, is to allow for 2690 application layer mobility and flexibility to utilize the best 2691 available transport as it becomes available. If a client receives a 2692 455 when trying to change transport parameters while the server is in 2693 play state, it MAY try to put the server in ready state using PAUSE, 2694 before issuing the SETUP request again. If also that fails the 2695 changing of transport parameters will require that the client 2696 performs a TEARDOWN of the affected media and then setting it up 2697 again. In aggregated session avoiding tearing down all the media at 2698 the same time will avoid the creation of a new session. 2700 All transport parameters MAY be changed. However the primary usage 2701 expected is to either change transport protocol completely, like 2702 switching from Interleaved TCP mode to UDP or vise versa or change 2703 delivery address. 2705 In a SETUP response for a request to change the transport parameters 2706 while in Play state, the server SHALL include the Range to indicate 2707 from what point the new transport parameters are used. Further, if 2708 RTP is used for delivery, the server SHALL also include the RTP-Info 2709 header to indicate from what timestamp and RTP sequence number the 2710 change has taken place. If both RTP-Info and Range is included in 2711 the response the "rtp_time" parameter and range MUST be for the 2712 corresponding time, i.e. be used in the same way as for PLAY to 2713 ensure the correct synchronization information is available. 2715 If the transport parameters change while in PLAY state results in a 2716 change of synchronization related information, for example changing 2717 RTP SSRC, the server MUST provide in the SETUP response the necessary 2718 synchronization information. However the server is RECOMMENDED to 2719 avoid changing the synchronization information if possible. 2721 13.4. PLAY 2723 This section describes the usage of the PLAY method in general, for 2724 aggregated sessions, and in different usage scenarios. 2726 13.4.1. General Usage 2728 The PLAY method tells the server to start sending data via the 2729 mechanism specified in SETUP and which part of the media should be 2730 played out. PLAY requests are valid when the session is in READY or 2731 PLAY states. A PLAY request MUST include a Session header to 2732 indicate which session the request applies to. 2734 Upon receipt of the PLAY request, the server SHALL position the 2735 normal play time to the beginning of the range specified in the 2736 received Range header and delivers stream data until the end of the 2737 range if given, or until a new PLAY request is received, else to the 2738 end of the media is reached. To allow for precise composition 2739 multiple ranges MAY be specified in one PLAY Request. The range 2740 values are valid if all given ranges are part of any media within the 2741 aggregate. If a given range value points outside of the media, the 2742 response SHALL be the 457 (Invalid Range) error code. 2744 The below example will first play seconds 10 through 15, then, 2745 immediately following, seconds 20 to 25, and finally seconds 30 2746 through the end. 2748 C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0 2749 CSeq: 835 2750 Session: 12345678 2751 Range: npt=10-15, npt=20-25, npt=30- 2752 Seek-Style: RAP 2753 User-Agent: PhonyClient/1.2 2755 See the description of the PAUSE request for further examples. 2757 A PLAY request without a Range header is legal. It SHALL start 2758 playing a stream from the beginning (npt=0-) unless the stream has 2759 been paused or is currently playing. If a stream has been paused via 2760 PAUSE, stream delivery resumes at the pause point. If a stream is 2761 currently playing, the new PLAY begins at the current stream 2762 position. The stream SHALL play until the end of the media. The 2763 Range header MUST NOT contain a time parameter. The usage of time in 2764 PLAY method has been deprecated. If a request with time parameter is 2765 received the server SHOULD respond with a 457 (Invalid Range) to 2766 indicate that the time parameter is not supported. If no range is 2767 specified in the request, the start position SHALL still be returned 2768 in the reply. If the medias that are part of an aggregate has 2769 different lengths, the PLAY request SHALL be performed as long as the 2770 given range is valid for any media, for example the longest media. 2771 Media will be sent whenever it is available for the given play-out 2772 point. 2774 A client desiring to play the media from the beginning MUST send a 2775 PLAY request with a Range header pointing at the beginning, e.g. 2776 npt=0-. If a PLAY request is received without a Range header when 2777 media delivery has stopped at the end, the server SHOULD respond with 2778 a 457 "Invalid Range" error response. In that response the current 2779 pause point in a Range header SHALL be included. 2781 All range specifiers in this specification allow for ranges with 2782 unspecified begin times (e.g. "npt=-30"). When used in a PLAY 2783 request, the server treats this as a request to start/resume playback 2784 from the current pause point, ending at the end time specified in the 2785 Range header. If the pause point is located later than the given end 2786 value, a 457 (Invalid Range) response SHALL be given. 2788 Server MUST include a "Range" header in any PLAY response. The 2789 response MUST use the same format as the request's range header 2790 contained. If no Range header was in the request, the format used in 2791 any previous PLAY request within the session SHOULD be used. If no 2792 format has been indicated in a previous request the server MAY use 2793 any time format supported by the media and indicated in the Accept- 2794 Ranges header in the SETUP respone. It is RECOMMENDED that NPT is 2795 used if supported by the media. 2797 For any error response to a PLAY request, the server's response 2798 depends on the current session state. If the session is in ready 2799 state, the current pause-point is returned. For time-progressing 2800 content where the pause-point moves with real-time due to limited 2801 retention, the current resume point is returned. For sessions in 2802 playing state, the current playout point and the remaining parts of 2803 the range request is returned. 2805 A PLAY response MAY include a header(s) carrying synchronization 2806 information. As the information necessary is dependent on the media 2807 transport format, further rules specifying the header and its usage 2808 is needed. For RTP the RTP-Info header is specified, see 2809 Section 16.43, and used in the following example. 2811 Here is a simple example for a single audio stream where the client 2812 requests the media starting from 3.52 seconds and to the end. The 2813 server sends a 200 OK response with the actual play time (equal to 2814 the requested in this case) and the RTP-Info header that contains the 2815 necessary parameters for the RTP stack. 2817 C->S: PLAY rtsp://example.com/audio RTSP/2.0 2818 CSeq: 836 2819 Session: 12345678 2820 Range: npt=3.52- 2821 User-Agent: PhonyClient/1.2 2823 S->C: RTSP/2.0 200 OK 2824 CSeq: 836 2825 Date: Thu, 23 Jan 1997 15:35:06 GMT 2826 Server: PhonyServer 1.0 2827 Range: npt=3.52-324.39 2828 RTP-Info:url="rtsp://example.com/audio" 2829 ssrc=0D12F123:seq=14783;rtptime=2345962545 2831 S->C: RTP Packet TS=2345962545 => NPT=3.52 2832 Duration=4.15 seconds 2834 For media with random-acces properties, the server MUST reply with 2835 the actual range that will be played back, i.e. for which duration 2836 any media (having content at this time) is delivered. This may 2837 differ from the requested range if alignment of the requested range 2838 to valid frame boundaries is required for the media source. Note 2839 that some media streams in an aggregate may need to be delivered from 2840 even earlier points. Also, some media format have a very long 2841 duration per individual data unit, therefore it might be necessary 2842 for the client to parse the data unit, and select where to start. 2843 The client can express its desired handling by the server by 2844 including the Seek-Style header (Section 16.45) in the PLAY request, 2845 if desired. 2847 In the following example the client receives the first media packet 2848 that stretches all the way up and past the requested playtime. Thus, 2849 it is the client's decision if to render to the user the time between 2850 3.52 and 7.05, or to skip it. In most cases it is probably most 2851 suitable to not render that time period. 2853 C->S: PLAY rtsp://example.com/audio RTSP/2.0 2854 CSeq: 836 2855 Session: 12345678 2856 Range: npt=7.05- User-Agent: PhonyClient/1.2 2858 S->C: RTSP/2.0 200 OK 2859 CSeq: 836 2860 Date: Thu, 23 Jan 1997 15:35:06 GMT 2861 Server: PhonyServer 1.0 2862 Range: npt=3.52- 2863 RTP-Info:url="rtsp://example.com/audio" 2864 ssrc=0D12F123:seq=14783;rtptime=2345962545 2866 S->C: RTP Packet TS=2345962545 => NPT=3.52 2867 Duration=4.15 seconds 2869 After playing the desired range, the presentation does NOT transition 2870 to the READY state, media delivery simply stops. A PAUSE request 2871 MUST be issued before the stream enters the READY state. A PLAY 2872 request while the stream is still in the PLAYING state is legal, and 2873 can be issued without an intervening PAUSE request. Such a request 2874 SHALL replace the current PLAY action with the new one requested, 2875 i.e. being handle the same as the request was received in ready 2876 state. In the case the first time range in Range header has a open 2877 start time (-endtime), the server SHALL continue to play from where 2878 it currently was until the specified end point. This is useful to 2879 change ongoing playback to play another sequence, or end at another 2880 point than in the previous request. 2882 The following example plays the whole presentation starting at SMPTE 2883 time code 0:10:20 until the end of the clip. Note: The RTP-Info 2884 headers has been broken into several lines to fit the page. 2886 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0 2887 CSeq: 833 2888 Session: 12345678 2889 Range: smpte=0:10:20- 2890 User-Agent: PhonyClient/1.2 2892 S->C: RTSP/2.0 200 OK 2893 CSeq: 833 2894 Date: Thu, 23 Jan 1997 15:35:06 GMT 2895 Server: PhonyServer 1.0 2896 Range: smpte=0:10:22-0:15:45 2897 RTP-Info:url="rtsp://example.com/twister.en" 2898 ssrc=0D12F123:seq=14783;rtptime=2345962545 2900 For playing back a recording of a live presentation, it may be 2901 desirable to use clock units: 2902 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0 2903 CSeq: 835 2904 Session: 12345678 2905 Range: clock=19961108T142300Z-19961108T143520Z 2906 User-Agent: PhonyClient/1.2 2908 S->C: RTSP/2.0 200 OK 2909 CSeq: 835 2910 Date: Thu, 23 Jan 1997 15:35:06 GMT 2911 Server:PhonyServer 1.0 2912 Range: clock=19961108T142300Z-19961108T143520Z 2913 RTP-Info:url="rtsp://example.com/meeting.en" 2914 ssrc=0D12F123:seq=53745;rtptime=484589019 2916 13.4.2. Aggregated Sessions 2918 PLAY requests can operate on sessions controlling a single media and 2919 on aggregated sessions controlling multiple media. 2921 In an aggregated session the PLAY request MUST contain an aggregated 2922 control URI. A server SHALL responde with error 460 (Only Aggregate 2923 Operation Allowed) if the client PLAY Request-URI is for one of the 2924 media. The media in an aggregate SHALL be played in sync. If a 2925 client wants individual control of the media it needs to use separate 2926 RTSP sessions for each media. 2928 For aggregated sessions where the initial SETUP request (creating a 2929 session) is followed by one or more additional SETUP request, a PLAY 2930 request MAY be pipelined after those additional SETUP requests 2931 without awaiting their responses. This procedure can reduce the 2932 delay from start of session establishment until media play-out has 2933 started with one round trip time. However an client needs to be 2934 aware that using this procedure will result in the playout of the 2935 server state established at the time of processing the PLAY, i.e., 2936 after the processing of all the requests prior to the PLAY request in 2937 the pipeline. This may not be the intended one due to failure of any 2938 of the prior requests. However a client easily determine this based 2939 on the responses from those requests. In case of failure the client 2940 can halt the media playout using PAUSE and try to establish the 2941 intended state again before issuing another PLAY request. 2943 13.4.3. Updating current PLAY Requests 2945 Clients can issue PLAY request while the stream is In PLAYING state 2946 and thus updating their request. The possibility to replace a 2947 current PLAY request with a new one replaces the following RTSP 1.0 2948 functions based on PLAY in play state: 2950 o The queued play functionality described in RFC 2326 [RFC2326] is 2951 removed and multiple ranges can be used to achieve a similar 2952 functionality in combination with the possibility to replace 2953 previous play messages. 2955 o The use of PLAY for keep-alive signaling, i.e. PLAY request 2956 without a range header in PLAY state, has also been deprecated. 2957 Instead a client can use, SET_PARAMETER (recommended) or OPTIONS 2958 (allowed) for keep alive. 2960 The important difference compared to a PLAY request in ready state is 2961 the handling of the current playpoint and how the range header in 2962 request is constructed. The session is actively playing media and 2963 the playpoint will be moving making the exact time a request will 2964 take action is hard to predict. Depending on how the PLAY header 2965 appears two different cases exist: total replacement or continuation. 2966 A total replacement is signalled by having the first range 2967 specification have an explicit start value, e.g. npt=45- or 2968 npt=45-60, in which case the server stops playout at the current 2969 playout point and then starts delivering media according to the Range 2970 header. This is equivalent to having the client first send a PAUSE 2971 and then a new play request that isn't based on the pause point. In 2972 the case of continuation the first range specifier has an open start 2973 point and a explict stop value (Z), e.g. npt=-60, which indicate that 2974 it SHALL convert the range specifier being played prior to this PLAY 2975 request (X to Y) into (X to Z) and continue as this was the request 2976 originally played. For both total replacement and continuation the 2977 PLAY request SHALL remove any additional range specifiers present in 2978 the previous request and add any that is present in the new PLAY 2979 request. 2981 An example of this behavior. The server has received requests to 2982 play ranges 10 to 15 and then 13 to 20 (that is, overlapping ranges). 2983 If the new PLAY request arrives at the server 4 seconds after the 2984 previous one, it will take effect while the server plays the first 2985 range (10-15). Thus changing the behavior of this range to continue 2986 to play to 25 seconds, i.e. the equivalent single request would be 2987 PLAY with range: npt=10-25. Note that the second range (13-20) is 2988 deleted and never comes into effect. If the new PLAY request would 2989 arrive as the second range in the first request was playing (13-20 2990 and shown below), then the equivalent single request would be play 2991 with range:npt=10-15,npt=13-25. 2993 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 2994 CSeq: 834 2995 Session: 12345678 2996 Range: npt=10-15, npt=13-20 2997 User-Agent: PhonyClient/1.2 2999 S->C: RTSP/2.0 200 OK 3000 CSeq: 834 3001 Date: Thu, 23 Jan 1997 15:35:06 GMT 3002 Server: PhonyServer 1.0 3003 Range: npt=10-15, npt=13-20 3004 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3005 ssrc=0D12F123:seq=5712;rtptime=934207921, 3006 url="rtsp://example.com/fizzle/videotrack" 3007 ssrc=789DAF12:seq=57654;rtptime=2792482193 3008 Session: 12345678 3010 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3011 CSeq: 835 3012 Session: 12345678 3013 Range: npt=-25 3014 User-Agent: PhonyClient/1.2 3016 S->C: RTSP/2.0 200 OK 3017 CSeq: 835 3018 Date: Thu, 23 Jan 1997 15:35:09 GMT 3019 Server: PhonyServer 1.0 3020 Range: npt=14-25 3021 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3022 ssrc=0D12F123:seq=5712;rtptime=934239921, 3023 url="rtsp://example.com/fizzle/videotrack" 3024 ssrc=789DAF12:seq=57654;rtptime=2792842193 3025 Session: 12345678 3027 13.4.4. Playing On-Demand Media 3029 On-demand media is indicated by the content of the Media-Properties 3030 header in the SETUP response by (see also Section 16.29): 3032 o Random-Access property is set to Random Acces; 3034 o Content Modifications set to unmutable; 3036 o Retetion set Unlimited or Time-Limited. 3038 Playing on-demand media follows the general usage as described in 3039 Section 13.4.1. 3041 13.4.5. Playing Dynamic On-Demand Media 3043 Dynamic on-demand media is indicated by the content of the Media- 3044 Properties header in the SETUP response by (see also Section 16.29): 3046 o Random-Access set to Random Access; 3048 o Content Modifications set to dynamic; 3050 o Retetion set unlimited or Time-Limited. 3052 Playing on-demand media follows the general usage as described in 3053 Section 13.4.1 as long as the media has not been changed. 3055 There are ways for the client to get informed about changed of media 3056 resources in play state, if the resource was changed. The client 3057 will receive a PLAY_NOTIFY request with Notify-Reason header set to 3058 media-properties-update (see Section 13.5.2. The client can use the 3059 value of the Media-Range to decide further actions, if the Media- 3060 Range header is present in the PLAY_NOTIFY request. The second way 3061 is that the client issues a GET_PARAMETER request without a body but 3062 including a Media-Range header. The 200 OK response SHALL include 3063 the current Media-Range header (see Section 16.30). 3065 13.4.6. Playing Live Media 3067 Live media is indicated by the content of the Media-Properties header 3068 in the SETUP response by (see also Section 16.29): 3070 o Random-Access set to no-seeking; 3072 o Content Modifications set to Time-Progressing; 3074 o Retetion with Time-Duration set to 0.0. 3076 For live media, the SETUP response 200 OK SHALL include the Media- 3077 Range header (see Section 16.30). 3079 A client MAY send PLAY requests without the Range header, if the 3080 request include the Range header it SHALL use a symbolic value 3081 representing "now". For NPT that range specification is "npt=now-". 3082 The server SHALL include the Range header in the response and it MUST 3083 indicate a explict time value and not a symbolic value. In other 3084 words npt=now- is not a valid to use in the respone. Instead the 3085 time since session start is recommended expressed as an open 3086 interval, e.g. "npt=96.23-". An absolute time value (clock) for the 3087 corresponding time MAY be given, i.e. "clock=20030213T143205Z-". The 3088 UTC clock format SHOULD only be used if client has shown support for 3089 it. 3091 13.4.7. Playing Live with Recording 3093 Certain media server may offer recording services of live sessions to 3094 their clients. This recording would normally be from the begining of 3095 the media session. Clients can randomly access the media between now 3096 and the begining of the media session. This live media with 3097 recording is indicated by the content of the Media-Properties header 3098 in the SETUP response by (see also Section 16.29): 3100 o Random-Access set to random-access; 3102 o Content Modifications set to Time-Progressing; 3104 o Retetion set to Time-limited or Unlimited 3106 The SETUP response 200 OK SHALL include the Media-Range header (see 3107 Section 16.30) for this type of media. For live media with recording 3108 the Range header indicates the current playback time in the media and 3109 the Media Range indicates the currently available media window around 3110 the current time. This window can cover recorded content in the past 3111 (seen from current time in the media) or recorded content in the 3112 future (seen from current time in the media). The server adjusts the 3113 play point to the requested border of the window, if the client 3114 requests a play point that is located outside the recording windows, 3115 e.g., if requested to far in the past, the server selects the oldest 3116 range in the recording. The considerations in Section 13.5.3 apply, 3117 if a client requests playback at Scale (Section 16.44) values other 3118 than 1.0 (Normal playback rate) while playing live media with 3119 recording. 3121 13.4.8. Playing Live with Time-Shift 3123 Certain media server may offer time-shift services to their clients. 3124 This time shift records a fixed interval in the past, i.e., a sliding 3125 window recording mechanism, but not past this interval. Clients can 3126 randomly access the media between now and the interval. This live 3127 media with recording is indicated by the content of the Media- 3128 Properties header in the SETUP response by (see also Section 16.29): 3130 o Random-Access set to random-access; 3132 o Content Modifications set to Time-Progressing; 3134 o Retetion set to Time-Duration and a value indicating the recording 3135 interval (>0). 3137 The SETUP response 200 OK SHALL include the Media-Range header (see 3138 Section 16.30) for this type of media. For live media with recording 3139 the Range header indicates the current time in the media and the 3140 Media Range indicates a window around the current time. This window 3141 can cover recorded content in the past (seen from current time in the 3142 media) or recorded content in the future (seen from current time in 3143 the media). The server adjusts the play point to the requested 3144 border of the window, if the client requests a play point that is 3145 located outside the recording windows, e.g., if requested to far in 3146 the past, the server selects the oldest range in the recording. The 3147 considerations in Section 13.5.3 apply, if a client requests playback 3148 at Scale (Section 16.44) values other than 1.0 (Normal playback rate) 3149 while playing live media with time-shift. 3151 13.5. PLAY_NOTIFY 3153 The PLAY_NOTIFY method is issued by a server to inform a client about 3154 an ansynchronous event for a session in play state. The Session 3155 header MUST be presented in a PLAY_NOTIFY request and indicates the 3156 scope of the request. Sending of PLAY_NOTIFY requests requires a 3157 persistent connection between server and client, otherwise there is 3158 no way for the server to send this request method to the client. 3160 PLAY_NOTIFY requests have an end-to-end (i.e. server to client) 3161 scope, as they carry the Session header, and apply only to the given 3162 session. The client SHOULD immediately return a response to the 3163 server. 3165 PLAY_NOTIFY requests MAY be used with a message body, depending on 3166 the value of the Notify-Reason header. It is described in the 3167 particular section for each Notify-Reason if a message body is used. 3168 However, currently there is no Notify-Reason that allows using a 3169 message body. There is the need to obey some limitations, when 3170 adding new Notify-Reasons that intend to use a message body: The 3171 server can send any type of message body, but it is not ensured that 3172 the client can understand the received message body. This is related 3173 to DESCRIBE (seeSection 13.2 ), but there the client can state its 3174 acceptable message bodies by using the Accept header. In case of 3175 PLAY_NOTIFY, the server does not know which message bodies are 3176 understood by the client. 3178 The Notify-Reason header (see Section 16.31) specifies the reason why 3179 the server sends the PLAY_NOTIFY request. This is extensible and new 3180 reasons MAY be added in the future. In case the client does not 3181 understand the reason for the notification it SHALL respond with an 3182 465 (Notification Reason Unknown) (Section 15.4.17) error code. 3183 Servers can send PLAY_NOTIFY with these types: 3185 o end-of-stream (see Section 13.5.1); 3187 o media-properties-update (see Section 13.5.2); 3189 o and scale-change (see Section 13.5.3). 3191 13.5.1. End-of-Stream 3193 A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream 3194 indicates the end of the media streams has been reached or will be in 3195 the near future for the given session aggregate. The request SHALL 3196 NOT be issued unless the server is in the playing state. The end of 3197 the media stream delivery notification may be for either succesful 3198 completion of the PLAY request currently being served or indicate 3199 some error resulting in failure to complete the request. The 3200 Request-Status header (Section 16.41) SHALL be included to indicate 3201 which request the notification is for and its completion status. The 3202 message response status codes (Section 8.1.1) are used to indicate 3203 how the PLAY request concluded. In case a PLAY_NOTIFY was issues 3204 prior to the actual completion and some error occured resulting in 3205 that the previosuly sent was in error a new Notification MUST be sent 3206 including the correct status for the completion and all additional 3207 information. 3209 PLAY_NOTIFY requests with Notify-Reason header set to end-of-stream 3210 MUST include a Range header. The Range header indicates the point in 3211 the stream or streams where delivery was/are ending with the 3212 timescale that has been used by the client in the PLAY request being 3213 fulfilled. For normal play time it is not alllowed to use "now" as 3214 server do know the real ending time of the media stream and now 3215 carries no information to determine what has/will be delivered. When 3216 end-of-stream notifications are issued prior to having sent the last 3217 media packets, this is evident as the end time in the Range header is 3218 beyond the current time in the media being received by the client, 3219 e.g., npt=-15, if npt is currently at 14.2 seconds. 3221 If RTP is used as media transport, a RTP-Info header MUST be 3222 included, and the RTP-Info header MUST indicate the last sequence 3223 number in the seq parameter. 3225 A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream 3226 MUST NOT carry a message body. 3228 This example request notifies the client about a future end-of-stream 3229 event: 3231 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 3232 CSeq: 854 3233 Notify-Reason: end-of-stream 3234 Request-Status: cseq=853 status=200 reason="OK" 3235 Range: npt=-145 3236 RTP-Info:url="rtsp://example.com/audio" 3237 ssrc=0D12F123:seq=14783;rtptime=2345962545 3238 Session: uZ3ci0K+Ld-M 3240 C->S: RTSP/2.0 200 OK 3241 CSeq: 854 3242 User-Agent: PhonyClient/1.2 3244 13.5.2. Media-Properties-Update 3246 A PLAY_NOTIFY request with Notify-Reason header set to media- 3247 properties-update indicates an update of the media properties for the 3248 given session (see Section 16.29) and/or the available media range 3249 that can be played as indicated by Media-Range (Section 16.30). 3250 PLAY_NOTIFY requests with Notify-Reason header set to media- 3251 properties-update MUST include a Media-Properties and Date header and 3252 SHOULD include a Media-Range header. 3254 This notification SHALL be sent for media that are time-progressing 3255 every time a event happens that changes the basis for making 3256 estimations on how the media range progress. In addition it is 3257 RECOMMENDED that the server sends these notification every 5 minutes 3258 for time-progressing content to ensure the long term stability of the 3259 client estimation and allowing for clock skew detection by the 3260 client. Requests for the just mentioned reasons SHALL include Media- 3261 Range header to provide current Media duration and the Range header 3262 to indicate the current playing point and any remaining parts of the 3263 requsted range. 3265 A PLAY_NOTIFY request with Notify-Reason header set to media- 3266 properties-update MUST NOT carry a message body. 3268 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 3269 Date: Tue, 14 Apr 2008 15:48:06 GMT 3270 CSeq: 854 3271 Notify-Reason: media-properties-update 3272 Session: uZ3ci0K+Ld-M 3273 Media-Properties: Time-Progressing, 3274 Time-Limited=20080415T153919.36Z, Random-Access=5.0 3275 Media-Range: npt=0-1:37:21.394 3276 Range: npt=1:15:49.873- 3278 C->S: RTSP/2.0 200 OK 3279 CSeq: 854 3280 User-Agent: PhonyClient/1.2 3282 13.5.3. Scale-Change 3284 When a client request playback at Scale (Section 16.44) values other 3285 than 1.0 (Normal playback rate) then the server may be forced to 3286 changed the rate. For time progressing media with some retention, 3287 i.e. the server stores already sent content, a client requesting to 3288 play with Scale values larger than 1 may catch up with front end of 3289 the media. The server will be unable to continue provide content at 3290 Scale larger than 1 as content only made available by the server at 3291 Scale=1. Another case is when Scale < 1 and the media retention is 3292 time_duration limited. In this case the playback point can reach the 3293 the oldest media unit available, and further playback at this scale 3294 becomes impossible as there will be no media available. To avoid 3295 having the client loose any media, the scale will need to be adjusted 3296 to the same rate which the media is removed from the storage buffer, 3297 commonly scale=1.0. 3299 To minimize impact on playback in any of the above cases the server 3300 SHALL modify the playback properties and set Scale to a supportable 3301 value (commonly 1.0) and continue delivery the media. When doing 3302 this modification it MUST send a PLAY_NOTIFY message with the Notify- 3303 Reason header set to "Scale-Change". The request SHALL contain a 3304 Range header with the media time where the change took effect, a 3305 Scale header with the new value in use, Session header with the ID 3306 for the session it applies to and a Date header with the server wall 3307 clock time of the change. For time progressing content also the 3308 Media-Range and the Media-Properties at this point in time SHALL be 3309 included. 3311 For media streams being delivered using RTP also a RTP-Info header 3312 SHALL be included. It MUST contain the rtptime parameter with a 3313 value corresponding to the point of change in that media and 3314 optionally the sequence number. 3316 A PLAY_NOTIFY request with Notify-Reason header set to "Scale-Change" 3317 MUST NOT carry a message body. 3319 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 3320 Date: Tue, 14 Apr 2008 15:48:06 GMT 3321 CSeq: 854 3322 Notify-Reason: scale-change 3323 Session: uZ3ci0K+Ld-M 3324 Media-Properties: Time-Progressing, 3325 Time-Limited=20080415T153919.36Z, Random-Access=5.0 3326 Media-Range: npt=0-1:37:21.394 3327 Range: npt=1:37:21.394- 3328 Scale: 1 3329 RTP-Info: url="rtsp://example.com/fizzle/foo/audio" 3330 ssrc=0D12F123:rtptime=2345962545 3332 C->S: RTSP/2.0 200 OK 3333 CSeq: 854 3334 User-Agent: PhonyClient/1.2 3336 13.6. PAUSE 3338 The PAUSE request causes the stream delivery to immediately be 3339 interrupted (halted). A PAUSE request MUST be done either with the 3340 aggregated control URI for aggregated sessions, resulting in all 3341 media being halted, or the media URI for non-aggregated sessions. 3342 Any attempt to do muting of a single media with an PAUSE request in 3343 an aggregated session SHALL be responded with error 460 (Only 3344 Aggregate Operation Allowed). After resuming playback, 3345 synchronization of the tracks MUST be maintained. Any server 3346 resources are kept, though servers MAY close the session and free 3347 resources after being paused for the duration specified with the 3348 timeout parameter of the Session header in the SETUP message. 3350 Example: 3352 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 3353 CSeq: 834 3354 Session: 12345678 3355 User-Agent: PhonyClient/1.2 3357 S->C: RTSP/2.0 200 OK 3358 CSeq: 834 3359 Date: Thu, 23 Jan 1997 15:35:06 GMT 3360 Range: npt=45.76- 3362 The PAUSE request causes stream delivery to be interrupted 3363 immediately on receipt of the message and the pause point is set to 3364 the current point in the presentation. That pause point in the media 3365 stream needs to be maintained. A subsequent PLAY request without 3366 Range header SHALL resume from the pause point and play until media 3367 end. 3369 The pause point after any PAUSE request SHALL be returned to the 3370 client by adding a Range header with what remains unplayed of the 3371 PLAY request's ranges, i.e. including all the remaining ranges part 3372 of multiple range specification. For media with random access 3373 properties If one desires to resume playing a ranged request, one 3374 simply includes the Range header from the PAUSE response. Any play- 3375 request including symbolic values, such as the NPT timescale's "now" 3376 MUST be resolved into the actual stream position where the pause 3377 point is. For example a Play request with a range specification of 3378 "npt=now-" will need to be responded with an explicit value such as 3379 "npt=157.321-". For media that is time-progressing and has retention 3380 duration=0 the follow-up PLAY request to start media delivery again, 3381 will need to use "npt=now-" and not the answer in the pause-respone. 3382 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3383 CSeq: 834 3384 Session: 12345678 3385 Range: npt=10-30 3386 User-Agent: PhonyClient/1.2 3388 S->C: RTSP/2.0 200 OK 3389 CSeq: 834 3390 Date: Thu, 23 Jan 1997 15:35:06 GMT 3391 Server: PhonyServer 1.0 3392 Range: npt=10-30 3393 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3394 ssrc=0D12F123:seq=5712;rtptime=934207921, 3395 url="rtsp://example.com/fizzle/videotrack" 3396 ssrc=4FAD8726:seq=57654;rtptime=2792482193 3397 Session: 12345678 3399 After 11 seconds, i.e. at 21 seconds into the presentation: 3400 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 3401 CSeq: 835 3402 Session: 12345678 3403 User-Agent: PhonyClient/1.2 3405 S->C: RTSP/2.0 200 OK 3406 CSeq: 835 3407 Date: 23 Jan 1997 15:35:09 GMT 3408 Server: PhonyServer 1.0 3409 Range: npt=21-30 3410 Session: 12345678 3412 If a client issues a PAUSE request and the server acknowledges and 3413 enters the READY state, the proper server response, if the player 3414 issues another PAUSE, is still 200 OK. The 200 OK response MUST 3415 include the Range header with the current pause point. See examples 3416 below: 3418 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 3419 CSeq: 834 3420 Session: 12345678 3421 User-Agent: PhonyClient/1.2 3423 S->C: RTSP/2.0 200 OK 3424 CSeq: 834 3425 Session: 12345678 3426 Date: Thu, 23 Jan 1997 15:35:06 GMT 3427 Range: npt=45.76-98.36 3429 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 3430 CSeq: 835 3431 Session: 12345678 3432 User-Agent: PhonyClient/1.2 3434 S->C: RTSP/2.0 200 OK 3435 CSeq: 835 3436 Session: 12345678 3437 Date: 23 Jan 1997 15:35:07 GMT 3438 Range: npt=45.76-98.36 3440 13.7. TEARDOWN 3442 The TEARDOWN client to server request stops the stream delivery for 3443 the given URI, freeing the resources associated with it. A TEARDOWN 3444 request MAY be performed on either an aggregated or a media control 3445 URI. However some restrictions apply depending on the current state. 3446 The TEARDOWN request SHALL contain a Session header indicating what 3447 session the request applies to. 3449 A TEARDOWN using the aggregated control URI or the media URI in a 3450 session under non-aggregated control (single media session) MAY be 3451 done in any state (Ready, and Play). A successful request SHALL 3452 result in that media delivery is immediately halted and the session 3453 state is destroyed. This SHALL be indicated through the lack of a 3454 Session header in the response. 3456 A TEARDOWN using a media URI in an aggregated session MAY only be 3457 done in Ready state. Such a request only removes the indicated media 3458 stream and associated resources from the session. This may result in 3459 that a session returns to non-aggregated control, due to that it only 3460 contains a single media after the requests completion. A session 3461 that will exist after the processing of the TEARDOWN request SHALL in 3462 the response to that TEARDOWN request contain a Session header. Thus 3463 the presence of the Session header indicates to the receiver of the 3464 response if the session is still existing or has been removed. 3466 Example: 3468 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0 3469 CSeq: 892 3470 Session: 12345678 3471 User-Agent: PhonyClient/1.2 3473 S->C: RTSP/2.0 200 OK 3474 CSeq: 892 3475 Server: PhonyServer 1.0 3477 13.8. GET_PARAMETER 3479 The GET_PARAMETER request retrieves the value of any specified 3480 parameter or parameters for a presentation or stream specified in the 3481 URI. If the Session header is present in a request, the value of a 3482 parameter MUST be retrieved in the specified session context. There 3483 exist two ways of specifying the parameters to retrive. The first is 3484 by including headers that has been defined such that you can use them 3485 for this purpose. Header for this purpose should allow empty, or 3486 stripped value parts to avoid having to specify bogus data when 3487 indicating the desire to retrive a value. The succesful completion 3488 of the request should also be evident from any filled out values in 3489 the response. The Media-Range header (Section 16.30) is one such 3490 header. The other is to specify a body (entity) that lists the 3491 parameter(s) that are desirable to retrieve. The Content-Type header 3492 (Section 16.18) is used to specify which format the entity has. 3494 The method MAY also be used without a body (entity) or any header 3495 that request parameters for keep-alive purpose. Any request that is 3496 successful, i.e., a 200 OK response is received, then the keep-alive 3497 timer has been updated. Any non-required header present in such a 3498 request may or may not been processed. Normaly the presence of 3499 filled out values in the header will be indication that the header 3500 has been processed. However, for cases when this is difficult to 3501 determine, it is recommended to use a feature-tag and the Require 3502 header. Due to this reason it is usually easier if any parameters to 3503 be retrieved are sent in the body, rather than using any header. 3505 Parameters specified within the body of the message must all be 3506 understood by the request receiving agent. If one or more parameters 3507 are not understood a 451 (Parameter Not Understood) SHALL be sent 3508 including a body listing these parameters that wasn't understood. If 3509 all parameters are understood their value is filled in and returned 3510 in the response message body. 3512 Example: 3514 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 3515 CSeq: 431 3516 Content-Type: text/parameters 3517 Session: 12345678 3518 Content-Length: 26 3519 User-Agent: PhonyClient/1.2 3521 packets_received 3522 jitter 3524 C->S: RTSP/2.0 200 OK 3525 CSeq: 431 3526 Content-Length: 38 3527 Content-Type: text/parameters 3529 packets_received: 10 3530 jitter: 0.3838 3532 13.9. SET_PARAMETER 3534 This method requests to set the value of a parameter or a set of 3535 parameters for a presentation or stream specified by the URI. The 3536 method MAY also be used without a body (entity). It is the 3537 RECOMMENDED method to use in request sent for the sole purpose of 3538 updating the keep-alive timer. If this request is successful, i.e. a 3539 200 OK response is received, then the keep-alive timer has been 3540 updated. Any non-required header present in such a request may or 3541 may not been processed. To allow a client to determine if any such 3542 header has been processed, it is necessary to use a feature tag and 3543 the Require header. Due to this reason it is RECOMMENDED that any 3544 parameters are sent in the body, rather than using any header. 3546 A request is RECOMMENDED to only contain a single parameter to allow 3547 the client to determine why a particular request failed. If the 3548 request contains several parameters, the server MUST only act on the 3549 request if all of the parameters can be set successfully. A server 3550 MUST allow a parameter to be set repeatedly to the same value, but it 3551 MAY disallow changing parameter values. If the receiver of the 3552 request does not understand or cannot locate a parameter, error 451 3553 (Parameter Not Understood) SHALL be used. In the case a parameter is 3554 not allowed to change, the error code is 458 (Parameter Is Read- 3555 Only). The response body SHALL contain only the parameters that have 3556 errors. Otherwise no body SHALL be returned. 3558 Note: transport parameters for the media stream MUST only be set with 3559 the SETUP command. 3561 Restricting setting transport parameters to SETUP is for the 3562 benefit of firewalls. 3564 The parameters are split in a fine-grained fashion so that there 3565 can be more meaningful error indications. However, it may make 3566 sense to allow the setting of several parameters if an atomic 3567 setting is desirable. Imagine device control where the client 3568 does not want the camera to pan unless it can also tilt to the 3569 right angle at the same time. 3571 Example: 3573 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 3574 CSeq: 421 3575 User-Agent: PhonyClient/1.2 3576 Content-length: 20 3577 Content-type: text/parameters 3579 barparam: barstuff 3581 S->C: RTSP/2.0 451 Parameter Not Understood 3582 CSeq: 421 3583 Content-length: 10 3584 Content-type: text/parameters 3586 barparam: barstuff 3588 13.10. REDIRECT 3590 The REDIRECT method is issued by a server to inform a client that it 3591 required to connect to another server location to access the resource 3592 indicated by the Request-URI. The presence of the Session header in 3593 a REDIRECT request indicates the scope of the request, and determines 3594 the specific semantics of the request. 3596 A REDIRECT request with a Session header has end-to-end (i.e. server 3597 to client) scope and applies only to the given session. Any 3598 intervening proxies SHOULD NOT disconnect the control channel while 3599 there are other remaining end-to-end sessions. The OPTIONAL Location 3600 header, if included in such a request, SHALL contain a complete 3601 absolute URI pointing to the resource to which the client SHOULD 3602 reconnect. Specifically, the Location SHALL NOT contain just the 3603 host and port. A client may receive a REDIRECT request with a 3604 Session header, if and only if, an end-to-end session has been 3605 established. 3607 A client may receive a REDIRECT request without a Session header at 3608 any time when it has communication or a connection established with a 3609 server. The scope of such a request is limited to the next-hop (i.e. 3610 the RTSP agent in direct communication with the server) and applies, 3611 as well, to the control connection between the next-hop RTSP agent 3612 and the server. A REDIRECT request without a Session header 3613 indicates that all sessions and pending requests being managed via 3614 the control connection MUST be redirected. The OPTIONAL Location 3615 header, if included in such a request, SHOULD contain an absolute URI 3616 with only the host address and the OPTIONAL port number of the server 3617 to which the RTSP agent SHOULD reconnect. Any intervening proxies 3618 SHOULD do all of the following in the order listed: 3620 1. respond to the REDIRECT request 3622 2. disconnect the control channel from the requesting server 3624 3. connect to the server at the given host address 3626 4. pass the REDIRECT request to each applicable client (typically 3627 those clients with an active session or an unanswered request) 3629 Note: The proxy is responsible for accepting REDIRECT responses 3630 from its clients; these responses MUST NOT be passed on to either 3631 the original server or the redirected server. 3633 The lack of a Location header in any REDIRECT request is indicative 3634 of the server no longer being able to fulfill the current request and 3635 having no alternatives for the client to continue with its normal 3636 operation. It is akin to a server initiated TEARDOWN that applies 3637 both to sessions as well as the general connection associated with 3638 that client. 3640 When the Range header is not included in a REDIRECT request, the 3641 client SHOULD perform the redirection immediately and return a 3642 response to the server. The server can consider the session as 3643 terminated and can free any associated state after it receives the 3644 successful (2xx) response. The server MAY close the signalling 3645 connection upon receiving the response and the client SHOULD close 3646 the signalling connection after sending the 2xx response. The 3647 exception to this is when the client has several sessions on the 3648 server being managed by the given signalling connection. In this 3649 case, the client SHOULD close the connection when it has received and 3650 responded to REDIRECT requests for all the sessions managed by the 3651 signalling connection. 3653 If the OPTIONAL Range header is included in a REDIRECT request, it 3654 indicates when the redirection takes effect. The range value MUST be 3655 an open ended single value, e.g. npt=59-, indicating the play out 3656 time when redirection SHALL occur. Alternatively, a range with a 3657 time= parameter indicates the wall clock time by when the redirection 3658 MUST take place. When the time= parameter is present in the range, 3659 any range value MUST be ignored even though it MUST be syntactically 3660 correct. To allow a client to determine that redirect time without 3661 being time synchronized with the server, the server SHALL include a 3662 Date header in the request. When the indicated redirect point is 3663 reached, a client MUST issue a TEARDOWN request and SHOULD close the 3664 signalling connection after receiving a 2xx response. The normal 3665 connection considerations apply for the server. 3667 The differentiation of REDIRECT requests with and without range 3668 headers is to allow for clear and explicit state handling. As the 3669 state in the server needs to be kept until the point of 3670 redirection, the handling becomes more clear if the client is 3671 required to TEARDOWN the session at the redirect point. 3673 If the REDIRECT request times out following the rules in Section 10.4 3674 the server MAY terminate the session or transport connection that 3675 would be redirected by the request. This is a safeguard against 3676 misbehaving clients that refuses to respond to a REDIRECT request. 3677 That should not provide any benefit. 3679 After a REDIRECT request has been processed, a client that wants to 3680 continue to send or receive media for the resource identified by the 3681 Request-URI will have to establish a new session with the designated 3682 host. If the URI given in the Location header is a valid resource 3683 URI, a client SHOULD issue a DESCRIBE request for the URI. 3685 Note: The media resource indicated by the Location header can be 3686 identical, slightly different or totally different. This is the 3687 reason why a new DESCRIBE request SHOULD be issued. 3689 If the Location header contains only a host address, the client MAY 3690 assume that the media on the new server is identical to the media on 3691 the old server, i.e. all media configuration information from the old 3692 session is still valid except for the host address. However the 3693 usage of conditional SETUP using ETag identifiers are RECOMMENDED to 3694 verify the assumption. 3696 This example request redirects traffic for this session to the new 3697 server at the given absolute time: 3699 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0 3700 CSeq: 732 3701 Location: rtsp://s2.example.com:8001 3702 Range: npt=0- ;time=19960213T143205Z 3703 Session: uZ3ci0K+Ld-M 3705 C->S: RTSP/2.0 200 OK 3706 CSeq: 732 3707 User-Agent: PhonyClient/1.2 3709 14. Embedded (Interleaved) Binary Data 3711 In order to fulfill certain requirements on the network side, e.g. in 3712 conjunction with network address translators that block RTP traffic 3713 over UDP, it may be necessary to interleave RTSP messages and media 3714 stream data. This interleaving should generally be avoided unless 3715 necessary since it complicates client and server operation and 3716 imposes additional overhead. Also head of line blocking may cause 3717 problems. Interleaved binary data SHOULD only be used if RTSP is 3718 carried over TCP. 3720 Stream data such as RTP packets is encapsulated by an ASCII dollar 3721 sign (24 decimal), followed by a one-byte channel identifier, 3722 followed by the length of the encapsulated binary data as a binary, 3723 two-byte integer in network byte order. The stream data follows 3724 immediately afterwards, without a CRLF, but including the upper-layer 3725 protocol headers. Each $ block SHALL contain exactly one upper-layer 3726 protocol data unit, e.g., one RTP packet. 3727 0 1 2 3 3728 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 3729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3730 | "$" = 24 | Channel ID | Length in bytes | 3731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3732 : Length number of bytes of binary data : 3733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3735 The channel identifier is defined in the Transport header with the 3736 interleaved parameter (Section 16.51). 3738 When the transport choice is RTP, RTCP messages are also interleaved 3739 by the server over the TCP connection. The usage of RTCP messages is 3740 indicated by including a range containing a second channel in the 3741 interleaved parameter of the Transport header, see Section 16.51. If 3742 RTCP is used, packets SHALL be sent on the first available channel 3743 higher than the RTP channel. The channels are bi-directional and 3744 therefore RTCP traffic are sent on the second channel in both 3745 directions. 3747 RTCP is sometime needed for synchronization when two or more 3748 streams are interleaved in such a fashion. Also, this provides a 3749 convenient way to tunnel RTP/RTCP packets through the TCP control 3750 connection when required by the network configuration and transfer 3751 them onto UDP when possible. 3753 C->S: SETUP rtsp://example.com/bar.file RTSP/2.0 3754 CSeq: 2 3755 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 3756 Accept-Ranges: NPT, SMPTE, UTC 3757 User-Agent: PhonyClient/1.2 3759 S->C: RTSP/2.0 200 OK 3760 CSeq: 2 3761 Date: Thu, 05 Jun 1997 18:57:18 GMT 3762 Transport: RTP/AVP/TCP;unicast;interleaved=5-6 3763 Session: 12345678 3764 Accept-Ranges: NPT 3766 C->S: PLAY rtsp://example.com/bar.file RTSP/2.0 3767 CSeq: 3 3768 Session: 12345678 3769 User-Agent: PhonyClient/1.2 3771 S->C: RTSP/2.0 200 OK 3772 CSeq: 3 3773 Session: 12345678 3774 Date: Thu, 05 Jun 1997 18:59:15 GMT 3775 RTP-Info: url="rtsp://example.com/bar.file" 3776 ssrc=0D12F123:seq=232433;rtptime=972948234 3777 Range: npt=0-56.8 3779 S->C: $005{2 byte length}{"length" bytes data, w/RTP header} 3780 S->C: $005{2 byte length}{"length" bytes data, w/RTP header} 3781 S->C: $006{2 byte length}{"length" bytes RTCP packet} 3783 15. Status Code Definitions 3785 Where applicable, HTTP status [H10] codes are reused. Status codes 3786 that have the same meaning are not repeated here. See Table 4 for a 3787 listing of which status codes may be returned by which requests. All 3788 error messages, 4xx and 5xx MAY return a body containing further 3789 information about the error. 3791 15.1. Success 1xx 3793 15.1.1. 100 Continue 3795 See, [H10.1.1]. 3797 15.2. Success 2xx 3799 15.2.1. 200 OK 3801 See, [H10.2.1]. 3803 15.3. Redirection 3xx 3805 The notation "3rr" indicates response codes from 300 to 399 inclusive 3806 which are meant for redirection. The response code 304 is excluded 3807 from this set, as it is not used for redirection. 3809 See [H10.3] for definition of status code 300 to 305. However 3810 comments are given for some to how they apply to RTSP. 3812 Within RTSP, redirection may be used for load balancing or 3813 redirecting stream requests to a server topologically closer to the 3814 client. Mechanisms to determine topological proximity are beyond the 3815 scope of this specification. 3817 A 3rr code MAY be used to respond to any request. It is RECOMMENDED 3818 that they are used if necessary before a session is established, i.e. 3819 in response to DESCRIBE or SETUP. However in cases where a server is 3820 not able to send a REDIRECT request to the client, the server MAY 3821 need to resort to using 3rr responses to inform a client with a 3822 established session about the need for redirecting the session. If 3823 an 3rr response is received for an request in relation to a 3824 established session, the client SHOULD send a TEARDOWN request for 3825 the session, and MAY reestablish the session using the resource 3826 indicated by the Location. 3828 If the the Location header is used in a response it SHALL contain an 3829 absolute URI pointing out the media resource the client is redirected 3830 to, the URI SHALL NOT only contain the host name. 3832 15.3.1. 300 Multiple Choices 3834 See [H10.3.1]. 3836 15.3.2. 301 Moved Permanently 3838 The request resource are moved permanently and resides now at the URI 3839 given by the location header. The user client SHOULD redirect 3840 automatically to the given URI. This response MUST NOT contain a 3841 message-body. The Location header MUST be included in the response. 3843 15.3.3. 302 Found 3845 The requested resource resides temporarily at the URI given by the 3846 Location header. The Location header MUST be included in the 3847 response. This response is intended to be used for many types of 3848 temporary redirects; e.g., load balancing. It is RECOMMENDED that 3849 the server set the reason phrase to something more meaningful than 3850 "Found" in these cases. The user client SHOULD redirect 3851 automatically to the given URI. This response MUST NOT contain a 3852 message-body. 3854 This example shows a client being redirected to a different server: 3856 C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0 3857 CSeq: 2 3858 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 3859 Accept-Ranges: NPT, SMPTE, UTC 3860 User-Agent: PhonyClient/1.2 3862 S->C: RTSP/2.0 302 Try Other Server 3863 CSeq: 2 3864 Location: rtsp://s2.example.com:8001/fizzle/foo 3866 15.3.4. 303 See Other 3868 This status code SHALL NOT be used in RTSP. However, it was allowed 3869 to use in RTSP 1.0 (RFC 2326). 3871 15.3.5. 304 Not Modified 3873 If the client has performed a conditional DESCRIBE or SETUP (see 3874 Section 16.25) and the requested resource has not been modified, the 3875 server SHOULD send a 304 response. This response MUST NOT contain a 3876 message-body. 3878 The response MUST include the following header fields: 3880 o Date 3882 o ETag and/or Content-Location, if the header(s) would have been 3883 sent in a 200 response to the same request. 3885 o Expires, Cache-Control, and/or Vary, if the field-value might 3886 differ from that sent in any previous response for the same 3887 variant. 3889 This response is independent for the DESCRIBE and SETUP requests. 3890 That is, a 304 response to DESCRIBE does NOT imply that the resource 3891 content is unchanged (only the session description) and a 304 3892 response to SETUP does NOT imply that the resource description is 3893 unchanged. The ETag and If-Match headers may be used to link the 3894 DESCRIBE and SETUP in this manner. 3896 15.3.6. 305 Use Proxy 3898 See [H10.3.6]. 3900 15.4. Client Error 4xx 3902 15.4.1. 400 Bad Request 3904 The request could not be understood by the server due to malformed 3905 syntax. The client SHOULD NOT repeat the request without 3906 modifications [H10.4.1]. If the request does not have a CSeq header, 3907 the server MUST NOT include a CSeq in the response. 3909 15.4.2. 405 Method Not Allowed 3911 The method specified in the request is not allowed for the resource 3912 identified by the Request-URI. The response MUST include an Allow 3913 header containing a list of valid methods for the requested resource. 3914 This status code is also to be used if a request attempts to use a 3915 method not indicated during SETUP. 3917 15.4.3. 451 Parameter Not Understood 3919 The recipient of the request does not support one or more parameters 3920 contained in the request. When returning this error message the 3921 sender SHOULD return a entity body containing the offending 3922 parameter(s). 3924 15.4.4. 452 reserved 3926 This error code was removed from RFC 2326 [RFC2326] and is obsolete. 3928 15.4.5. 453 Not Enough Bandwidth 3930 The request was refused because there was insufficient bandwidth. 3931 This may, for example, be the result of a resource reservation 3932 failure. 3934 15.4.6. 454 Session Not Found 3936 The RTSP session identifier in the Session header is missing, 3937 invalid, or has timed out. 3939 15.4.7. 455 Method Not Valid in This State 3941 The client or server cannot process this request in its current 3942 state. The response SHALL contain an Allow header to make error 3943 recovery possible. 3945 15.4.8. 456 Header Field Not Valid for Resource 3947 The server could not act on a required request header. For example, 3948 if PLAY contains the Range header field but the stream does not allow 3949 seeking. This error message may also be used for specifying when the 3950 time format in Range is impossible for the resource. In that case 3951 the Accept-Ranges header SHALL be returned to inform the client of 3952 which format(s) that are allowed. 3954 15.4.9. 457 Invalid Range 3956 The Range value given is out of bounds, e.g., beyond the end of the 3957 presentation. 3959 15.4.10. 458 Parameter Is Read-Only 3961 The parameter to be set by SET_PARAMETER can be read but not 3962 modified. When returning this error message the sender SHOULD return 3963 a entity body containing the offending parameter(s). 3965 15.4.11. 459 Aggregate Operation Not Allowed 3967 The requested method may not be applied on the URI in question since 3968 it is an aggregate (presentation) URI. The method may be applied on 3969 a media URI. 3971 15.4.12. 460 Only Aggregate Operation Allowed 3973 The requested method may not be applied on the URI in question since 3974 it is not an aggregate control (presentation) URI. The method may be 3975 applied on the aggregate control URI. 3977 15.4.13. 461 Unsupported Transport 3979 The Transport field did not contain a supported transport 3980 specification. 3982 15.4.14. 462 Destination Unreachable 3984 The data transmission channel could not be established because the 3985 client address could not be reached. This error will most likely be 3986 the result of a client attempt to place an invalid dest_addr 3987 parameter in the Transport field. 3989 15.4.15. 463 Destination Prohibited 3991 The data transmission channel was not established because the server 3992 prohibited access to the client address. This error is most likely 3993 the result of a client attempt to redirect media traffic to another 3994 destination with a dest_addr parameter in the Transport header. 3996 15.4.16. 464 Data Transport Not Ready Yet 3998 The data transmission channel to the media destination is not yet 3999 ready for carrying data. However the responding entity still expects 4000 that the data transmission channel will be established at this point 4001 in time. Note however that this may result in a permanent failure 4002 like 462 "Destination Unreachable". 4004 An example when this error may occur is in the case a client sends a 4005 PLAY request to a server prior to ensuring that the TCP connections 4006 negotiated for carrying media data was successful established (In 4007 violation of this specification). The server would use this error 4008 code to indicate that the requested action could not be performed due 4009 to the failure of completing the connection establishment. 4011 15.4.17. 465 Notification Reason Unknown 4013 The client has received a PLAY_NOTIFY (Section 13.5) with a Notify- 4014 Reason header (Section 16.31) indicates a reson that are unknown to 4015 the client. 4017 15.4.18. 470 Connection Authorization Required 4019 The secured connection attempt need user or client authorization 4020 before proceeding. The next hops certificate is included in this 4021 response in the Accept-Credentials header. 4023 15.4.19. 471 Connection Credentials not accepted 4025 When performing a secure connection over multiple connections, a 4026 intermediary has refused to connect to the next hop and carry out the 4027 request due to unacceptable credentials for the used policy. 4029 15.4.20. 472 Failure to establish secure connection 4031 A proxy fails to establish a secure connection to the next hop RTSP 4032 agent. This is primarily caused by a fatal failure at the TLS 4033 handshake, for example due to server not accepting any cipher suits. 4035 15.5. Server Error 5xx 4037 15.5.1. 551 Option not supported 4039 A feature-tag given in the Require or the Proxy-Require fields was 4040 not supported. The Unsupported header SHALL be returned stating the 4041 feature for which there is no support. 4043 16. Header Field Definitions 4045 +---------------+----------------+--------+---------+------+ 4046 | method | direction | object | acronym | Body | 4047 +---------------+----------------+--------+---------+------+ 4048 | DESCRIBE | C -> S | P,S | DES | r | 4049 | | | | | | 4050 | GET_PARAMETER | C -> S, S -> C | P,S | GPR | R,r | 4051 | | | | | | 4052 | OPTIONS | C -> S | P,S | OPT | | 4053 | | | | | | 4054 | | S -> C | | | | 4055 | | | | | | 4056 | PAUSE | C -> S | P,S | PSE | | 4057 | | | | | | 4058 | PLAY | C -> S | P,S | PLY | | 4059 | | | | | | 4060 | PLAY_NOTIFY | S -> C | P,S | PNY | R | 4061 | | | | | | 4062 | REDIRECT | S -> C | P,S | RDR | | 4063 | | | | | | 4064 | SETUP | C -> S | S | STP | | 4065 | | | | | | 4066 | SET_PARAMETER | C -> S, S -> C | P,S | SPR | R,r | 4067 | | | | | | 4068 | TEARDOWN | C -> S | P,S | TRD | | 4069 +---------------+----------------+--------+---------+------+ 4071 Table 8: Overview of RTSP methods, their direction, and what objects 4072 (P: presentation, S: stream) they operate on. Body notes if a method 4073 is allowed to carry body and in which direction, R = Request, 4074 r=response. Note: It is allowed for all error messages 4xx and 5xx to 4075 have a body 4077 The general syntax for header fields is covered in Section 5.2. This 4078 section lists the full set of header fields along with notes on 4079 meaning, and usage. The syntax definition for header fields are 4080 present in Section 20.2.3. Throughout this section, we use [HX.Y] to 4081 refer to Section X.Y of the current HTTP/1.1 specification RFC 2616 4082 [RFC2616]. Examples of each header field are given. 4084 Information about header fields in relation to methods and proxy 4085 processing is summarized in Table 9, Table 10, Table 11, and 4086 Table 12. 4088 The "where" column describes the request and response types in which 4089 the header field can be used. Values in this column are: 4091 R: header field may only appear in requests; 4093 r: header field may only appear in responses; 4095 2xx, 4xx, etc.: A numerical value or range indicates response codes 4096 with which the header field can be used; 4098 c: header field is copied from the request to the response. 4100 An empty entry in the "where" column indicates that the header field 4101 may be present in both requests and responses. 4103 The "proxy" column describes the operations a proxy may perform on a 4104 header field. An empty proxy column indicates that the proxy SHALL 4105 NOT do any changes to that header, all allowed operations are 4106 explicitly stated: 4108 a: A proxy can add or concatenate the header field if not present. 4110 m: A proxy can modify an existing header field value. 4112 d: A proxy can delete a header field value. 4114 r: A proxy needs to be able to read the header field, and thus 4115 this header field cannot be encrypted. 4117 The rest of the columns relate to the presence of a header field in a 4118 method. The method names when abbreviated, are according to Table 8: 4120 c: Conditional; requirements on the header field depend on the 4121 context of the message. 4123 m: The header field is mandatory. 4125 m*: The header field SHOULD be sent, but clients/servers need to be 4126 prepared to receive messages without that header field. 4128 o: The header field is optional. 4130 *: The header field is SHALL be present if the message body is not 4131 empty. See Section 16.16, Section 16.18 and Section 5.3 for 4132 details. 4134 -: The header field is not applicable. 4136 "Optional" means that a Client/Server MAY include the header field in 4137 a request or response. The Client/Server behavior when receiving 4138 such headers varies, for some it may ignore the header field, in 4139 other case it is request to process the header. This is regulated by 4140 the method and header descriptions. Example of such headers that 4141 require processing are the Require and Proxy-Require header fields 4142 discussed in Section 16.42 and Section 16.35. A "mandatory" header 4143 field MUST be present in a request, and MUST be understood by the 4144 Client/Server receiving the request. A mandatory response header 4145 field MUST be present in the response, and the header field MUST be 4146 understood by the Client/Server processing the response. "Not 4147 applicable" means that the header field MUST NOT be present in a 4148 request. If one is placed in a request by mistake, it MUST be 4149 ignored by the Client/Server receiving the request. Similarly, a 4150 header field labeled "not applicable" for a response means that the 4151 Client/Server MUST NOT place the header field in the response, and 4152 the Client/Server MUST ignore the header field in the response. 4154 An RTSP agent SHALL ignore extension headers that are not understood. 4156 The From and Location header fields contain an URI. If the URI 4157 contains a comma, or semicolon, the URI MUST be enclosed in double 4158 quotas ("). Any URI parameters are contained within these quotas. 4159 If the URI is not enclosed in double quotas, any semicolon- delimited 4160 parameters are header-parameters, not URI parameters. 4162 +----------------+------+-----+-----+-----+------+-----+------+-----+ 4163 | Header | Wher | Pro | DES | OPT | SETU | PLA | PAUS | TRD | 4164 | | e | xy | | | P | Y | E | | 4165 +----------------+------+-----+-----+-----+------+-----+------+-----+ 4166 | Accept | R | | o | - | - | - | - | - | 4167 | | | | | | | | | | 4168 | Accept-Credent | R | r | o | o | o | o | o | o | 4169 | ials | | | | | | | | | 4170 | | | | | | | | | | 4171 | Accept-Encodin | R | r | o | - | - | - | - | - | 4172 | g | | | | | | | | | 4173 | | | | | | | | | | 4174 | Accept-Languag | R | r | o | - | - | - | - | - | 4175 | e | | | | | | | | | 4176 | | | | | | | | | | 4177 | Accept-Ranges | R | r | - | - | m | - | - | - | 4178 | | | | | | | | | | 4179 | Accept-Ranges | r | r | - | - | o | - | - | - | 4180 | | | | | | | | | | 4181 | Accept-Ranges | 456 | r | - | - | - | o | - | - | 4182 | | | | | | | | | | 4183 | Allow | r | am | c | c | c | - | - | - | 4184 | | | | | | | | | | 4185 | Allow | 405 | am | m | m | m | m | m | m | 4186 | | | | | | | | | | 4187 | Authorization | R | | o | o | o | o | o | o | 4188 | | | | | | | | | | 4189 | Bandwidth | R | | o | o | o | o | - | - | 4190 | | | | | | | | | | 4191 | Blocksize | R | | o | - | o | o | - | - | 4192 | | | | | | | | | | 4193 | Cache-Control | | r | o | - | o | - | - | - | 4194 | | | | | | | | | | 4195 | Connection | | | o | o | o | o | o | o | 4196 | | | | | | | | | | 4197 | Connection-Cre | 470, | ar | o | o | o | o | o | o | 4198 | dentials | 407 | | | | | | | | 4199 | | | | | | | | | | 4200 | Content-Base | r | | o | - | - | - | - | - | 4201 | | | | | | | | | | 4202 | Content-Base | 4xx, | | o | o | o | o | o | o | 4203 | | 5xx | | | | | | | | 4204 | | | | | | | | | | 4205 | Content-Encodi | R | r | - | - | - | - | - | - | 4206 | ng | | | | | | | | | 4207 | | | | | | | | | | 4208 | Content-Encodi | r | r | o | - | - | - | - | - | 4209 | ng | | | | | | | | | 4210 | | | | | | | | | | 4211 | Content-Encodi | 4xx, | r | o | o | o | o | o | o | 4212 | ng | 5xx | | | | | | | | 4213 | | | | | | | | | | 4214 | Content-Langua | R | r | - | - | - | - | - | - | 4215 | ge | | | | | | | | | 4216 | | | | | | | | | | 4217 | Content-Langua | r | r | o | - | - | - | - | - | 4218 | ge | | | | | | | | | 4219 | | | | | | | | | | 4220 | Content-Langua | 4xx, | r | o | o | o | o | o | o | 4221 | ge | 5xx | | | | | | | | 4222 | | | | | | | | | | 4223 | Content-Length | r | r | * | - | - | - | - | - | 4224 | | | | | | | | | | 4225 | Content-Length | 4xx, | r | * | * | * | * | * | * | 4226 | | 5xx | | | | | | | | 4227 | | | | | | | | | | 4228 | Content-Locati | r | | o | - | - | - | - | - | 4229 | on | | | | | | | | | 4230 | | | | | | | | | | 4231 | Content-Locati | 4xx, | | o | o | o | o | o | o | 4232 | on | 5xx | | | | | | | | 4233 | | | | | | | | | | 4234 | Content-Type | r | | * | - | - | - | - | - | 4235 | Content-Type | 4xx, | | * | * | * | * | * | * | 4236 | | 5xx | | | | | | | | 4237 | | | | | | | | | | 4238 | CSeq | Rc | rm | m | m | m | m | m | m | 4239 | | | | | | | | | | 4240 | Date | | am | o | o | o | o | o | o | 4241 | | | | | | | | | | 4242 | ETag | r | r | o | - | o | - | - | - | 4243 | | | | | | | | | | 4244 | Expires | r | r | o | - | - | - | - | - | 4245 | | | | | | | | | | 4246 | From | R | r | o | o | o | o | o | o | 4247 | | | | | | | | | | 4248 | If-Match | R | r | - | - | o | - | - | - | 4249 | | | | | | | | | | 4250 | If-Modified-Si | R | r | o | - | o | - | - | - | 4251 | nce | | | | | | | | | 4252 | | | | | | | | | | 4253 | If-None-Match | R | r | o | - | - | - | - | - | 4254 | | | | | | | | | | 4255 | Last-Modified | r | r | o | - | - | - | - | - | 4256 | | | | | | | | | | 4257 | Location | 3rr | | o | o | o | o | o | o | 4258 +----------------+------+-----+-----+-----+------+-----+------+-----+ 4260 Table 9: Overview of RTSP header fields (A-L) related to methods 4261 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 4263 +------------+-------+------+----+-----+-------+------+-------+-----+ 4264 | Header | Where | Prox | DE | OPT | SETUP | PLAY | PAUSE | TRD | 4265 | | | y | S | | | | | | 4266 +------------+-------+------+----+-----+-------+------+-------+-----+ 4267 | Media- | | | - | - | r | r | r | - | 4268 | Properties | | | | | | | | | 4269 | | | | | | | | | | 4270 | Media- | | | - | - | r | r | r | - | 4271 | Range | | | | | | | | | 4272 | | | | | | | | | | 4273 | Pipelined- | | amdr | - | o | o | o | o | o | 4274 | Requests | | | | | | | | | 4275 | | | | | | | | | | 4276 | Proxy- | 407 | amr | m | m | m | m | m | m | 4277 | Authentica | | | | | | | | | 4278 | te | | | | | | | | | 4279 | | | | | | | | | | 4280 | Proxy- | R | rd | o | o | o | o | o | o | 4281 | Authorizat | | | | | | | | | 4282 | ion | | | | | | | | | 4283 | Proxy- | R | ar | o | o | o | o | o | o | 4284 | Require | | | | | | | | | 4285 | | | | | | | | | | 4286 | Proxy- | r | r | c | c | c | c | c | c | 4287 | Require | | | | | | | | | 4288 | | | | | | | | | | 4289 | Proxy- | R | amr | c | c | c | c | c | c | 4290 | Supported | | | | | | | | | 4291 | | | | | | | | | | 4292 | Proxy- | r | | c | c | c | c | c | c | 4293 | Supported | | | | | | | | | 4294 | | | | | | | | | | 4295 | Public | r | admr | - | m | - | - | - | - | 4296 | | | | | | | | | | 4297 | Public | 501 | admr | m | m | m | m | m | m | 4298 | | | | | | | | | | 4299 | Range | R | | - | - | - | o | - | - | 4300 | | | | | | | | | | 4301 | Range | r | | - | - | c | m | m | - | 4302 | | | | | | | | | | 4303 | Referer | R | | o | o | o | o | o | o | 4304 | | | | | | | | | | 4305 | Request- | R | | - | - | - | - | - | - | 4306 | Status | | | | | | | | | 4307 | | | | | | | | | | 4308 | Require | R | | o | o | o | o | o | o | 4309 | | | | | | | | | | 4310 | Retry-Afte | 3rr,5 | | o | o | o | - | - | - | 4311 | r | 03 | | | | | | | | 4312 | | | | | | | | | | 4313 | RTP-Info | r | | - | - | c | c | - | - | 4314 | | | | | | | | | | 4315 | Scale | | | - | - | - | o | - | - | 4316 | | | | | | | | | | 4317 | Seek-Style | R | | - | - | - | o | - | - | 4318 | | | | | | | | | | 4319 | Seek-Style | r | | - | - | - | m | - | - | 4320 | | | | | | | | | | 4321 | Session | R | r | - | o | o | m | m | m | 4322 | | | | | | | | | | 4323 | Session | r | r | - | c | m | m | m | o | 4324 | | | | | | | | | | 4325 | Server | R | r | - | o | - | - | - | - | 4326 | | | | | | | | | | 4327 | Server | r | r | o | o | o | o | o | o | 4328 | | | | | | | | | | 4329 | Speed | | | - | - | - | o | - | - | 4330 | | | | | | | | | | 4331 | Supported | R | amr | o | o | o | o | o | o | 4332 | | | | | | | | | | 4333 | Supported | r | amr | c | c | c | c | c | c | 4334 | | | | | | | | | | 4335 | Timestamp | R | admr | o | o | o | o | o | o | 4336 | | | | | | | | | | 4337 | Timestamp | c | admr | m | m | m | m | m | m | 4338 | | | | | | | | | | 4339 | Transport | | amr | - | - | m | - | - | - | 4340 | | | | | | | | | | 4341 | Unsupporte | r | | c | c | c | c | c | c | 4342 | d | | | | | | | | | 4343 | | | | | | | | | | 4344 | User-Agent | R | | m* | m* | m* | m* | m* | m* | 4345 | | | | | | | | | | 4346 | Vary | r | | c | c | c | c | c | c | 4347 | | | | | | | | | | 4348 | Via | R | amr | o | o | o | o | o | o | 4349 | | | | | | | | | | 4350 | Via | c | dr | m | m | m | m | m | m | 4351 | | | | | | | | | | 4352 | WWW- | 401 | | m | m | m | m | m | m | 4353 | Authentica | | | | | | | | | 4354 | te | | | | | | | | | 4355 +------------+-------+------+----+-----+-------+------+-------+-----+ 4357 Table 10: Overview of RTSP header fields (P-W) related to methods 4358 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 4360 +------------------------+---------+-------+-----+-----+-----+-----+ 4361 | Header | Where | Proxy | GPR | SPR | RDR | PNY | 4362 +------------------------+---------+-------+-----+-----+-----+-----+ 4363 | Accept-Credentials | R | r | o | o | o | - | 4364 | | | | | | | | 4365 | Allow | 405 | amr | m | m | m | - | 4366 | | | | | | | | 4367 | Authorization | R | | o | o | o | - | 4368 | | | | | | | | 4369 | Bandwidth | R | | - | o | - | - | 4370 | | | | | | | | 4371 | Blocksize | R | | - | o | - | - | 4372 | | | | | | | | 4373 | Connection | | | o | o | o | - | 4374 | | | | | | | | 4375 | Connection-Credentials | 470,407 | ar | o | o | o | - | 4376 | | | | | | | | 4377 | Content-Base | R | | o | o | - | - | 4378 | | | | | | | | 4379 | Content-Base | r | | o | o | - | - | 4380 | | | | | | | | 4381 | Content-Base | 4xx,5xx | | o | o | o | - | 4382 | | | | | | | | 4383 | Content-Encoding | R | r | o | o | - | - | 4384 | | | | | | | | 4385 | Content-Encoding | r | r | o | o | - | - | 4386 | | | | | | | | 4387 | Content-Encoding | 4xx,5xx | r | o | o | o | - | 4388 | | | | | | | | 4389 | Content-Language | R | r | o | o | - | - | 4390 | | | | | | | | 4391 | Content-Language | r | r | o | o | - | - | 4392 | | | | | | | | 4393 | Content-Language | 4xx,5xx | r | o | o | o | - | 4394 | | | | | | | | 4395 | Content-Length | R | r | * | * | - | - | 4396 | | | | | | | | 4397 | Content-Length | r | r | * | * | - | - | 4398 | | | | | | | | 4399 | Content-Length | 4xx,5xx | r | * | * | * | - | 4400 | | | | | | | | 4401 | Content-Location | R | | o | o | - | - | 4402 | | | | | | | | 4403 | Content-Location | r | | o | o | - | - | 4404 | | | | | | | | 4405 | Content-Location | 4xx,5xx | | o | o | o | - | 4406 | | | | | | | | 4407 | Content-Type | R | | * | * | - | - | 4408 | | | | | | | | 4409 | Content-Type | r | | * | * | - | - | 4410 | | | | | | | | 4411 | Content-Type | 4xx | | * | * | * | - | 4412 | | | | | | | | 4413 | CSeq | R,c | mr | m | m | m | m | 4414 | | | | | | | | 4415 | Date | R | a | o | o | m | - | 4416 | | | | | | | | 4417 | Date | r | am | o | o | o | - | 4418 | | | | | | | | 4419 | From | R | r | o | o | o | - | 4420 | | | | | | | | 4421 | Last-Modified | R | r | - | - | - | - | 4422 | | | | | | | | 4423 | Last-Modified | r | r | o | - | - | - | 4424 | | | | | | | | 4425 | Location | 3rr | | o | o | o | - | 4426 | | | | | | | | 4427 | Location | R | | - | - | m | - | 4428 | | | | | | | | 4429 | Media-Properties | | | - | - | - | | 4430 | | | | | | | | 4431 | Media-Range | R | | o | - | - | c | 4432 | | | | | | | | 4433 | Media-Range | r | | c | - | - | - | 4434 | | | | | | | | 4435 | Notify-Reason | R | | - | - | - | m | 4436 | | | | | | | | 4437 | Pipelined-Requests | | amdr | o | o | o | - | 4438 | | | | | | | | 4439 | Proxy-Authenticate | 407 | amr | m | m | m | - | 4440 | | | | | | | | 4441 | Proxy-Authorization | R | rd | o | o | o | - | 4442 | | | | | | | | 4443 | Proxy-Require | R | ar | o | o | o | - | 4444 | | | | | | | | 4445 | Proxy-Require | r | r | c | c | c | - | 4446 | | | | | | | | 4447 | Proxy-Supported | R | amr | c | c | c | - | 4448 | | | | | | | | 4449 | Proxy-Supported | r | | c | c | c | - | 4450 | | | | | | | | 4451 | Public | 501 | admr | m | m | m | - | 4452 +------------------------+---------+-------+-----+-----+-----+-----+ 4454 Table 11: Overview of RTSP header fields (A-P) related to methods 4455 GET_PARAMETER, SET_PARAMETER, PLAY_NOTIFY, and REDIRECT. 4457 +------------------+---------+-------+-----+-----+-----+-----+ 4458 | Header | Where | Proxy | GPR | SPR | RDR | PNY | 4459 +------------------+---------+-------+-----+-----+-----+-----+ 4460 | Range | R | | - | - | o | m | 4461 | | | | | | | | 4462 | Referer | R | | o | o | o | - | 4463 | | | | | | | | 4464 | Request-Status | R | | - | - | - | m | 4465 | | | | | | | | 4466 | Require | R | r | o | o | o | - | 4467 | | | | | | | | 4468 | Retry-After | 3rr,503 | | o | o | - | - | 4469 | | | | | | | | 4470 | Scale | | | - | - | - | c | 4471 | | | | | | | | 4472 | Seek-Style | | | - | - | - | - | 4473 | | | | | | | | 4474 | Session | R | r | o | o | o | m | 4475 | Session | r | r | c | c | o | m | 4476 | | | | | | | | 4477 | Server | R | r | o | o | o | - | 4478 | | | | | | | | 4479 | Server | r | r | o | o | - | - | 4480 | | | | | | | | 4481 | Supported | R | adrm | o | o | o | - | 4482 | | | | | | | | 4483 | Supported | r | adrm | c | c | c | - | 4484 | | | | | | | | 4485 | Timestamp | R | adrm | o | o | o | - | 4486 | | | | | | | | 4487 | Timestamp | c | adrm | m | m | m | - | 4488 | | | | | | | | 4489 | Unsupported | r | arm | c | c | c | - | 4490 | | | | | | | | 4491 | User-Agent | R | r | m* | m* | - | - | 4492 | | | | | | | | 4493 | User-Agent | r | r | - | - | m* | - | 4494 | | | | | | | | 4495 | Vary | r | | c | c | - | - | 4496 | | | | | | | | 4497 | Via | R | amr | o | o | o | - | 4498 | | | | | | | | 4499 | Via | c | dr | m | m | m | - | 4500 | | | | | | | | 4501 | WWW-Authenticate | 401 | | m | m | m | - | 4502 +------------------+---------+-------+-----+-----+-----+-----+ 4504 Table 12: Overview of RTSP header fields (R-W) related to methods 4505 GET_PARAMETER, SET_PARAMETER, PLAY_NOTIFY, and REDIRECT. 4507 16.1. Accept 4509 The Accept request-header field can be used to specify certain 4510 presentation description content types which are acceptable for the 4511 response. 4513 See [H14.1] for syntax. 4515 Example of use: 4516 Accept: application/example ;q=1.0, application/sdp 4518 16.2. Accept-Credentials 4520 The Accept-Credentials header is a request header used to indicate to 4521 any trusted intermediary how to handle further secured connections to 4522 proxies or servers. See Section 19 for the usage of this header. It 4523 SHALL NOT be included in server to client requests. 4525 In a request the header SHALL contain the method (User, Proxy, or 4526 Any) for approving credentials selected by the requestor. The method 4527 SHALL NOT be changed by any proxy, unless it is "proxy" when a proxy 4528 MAY change it to "user" to take the role of user approving each 4529 further hop. If the method is "User" the header contains zero or 4530 more of credentials that the client accepts. The header may contain 4531 zero credentials in the first RTSP request to a RTSP server when 4532 using the "User" method. This as the client has not yet received any 4533 credentials to accept. Each credential SHALL consist of one URI 4534 identifying the proxy or server, the hash algorithm identifier, and 4535 the hash over that entity's DER encoded certificate [RFC5280] in 4536 Base64 [RFC4648]. All RTSP clients and proxies SHALL implement the 4537 SHA-256[FIPS-pub-180-2] algorithm for computation of the hash of the 4538 DER encoded certificate. The SHA-256 algorithm is identified by the 4539 token "sha-256". 4541 The intention with allowing for other hash algorithms is to enable 4542 the future retirement of algorithms that are not implemented 4543 somewhere else than here. Thus the definition of future algorithms 4544 for this purpose is intended to be extremely limited. A feature tag 4545 can be used to ensure that support for the replacement algorithm 4546 exist. 4548 Example: 4549 Accept-Credentials:User 4550 "rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=, 4551 "rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M= 4553 16.3. Accept-Encoding 4555 See [H14.3]. 4557 16.4. Accept-Language 4559 See [H14.4]. Note that the language specified applies to the 4560 presentation description and any reason phrases, not the media 4561 content. 4563 16.5. Accept-Ranges 4565 The Accept-Ranges request and response-header field allows indication 4566 of the format supported in the Range header. The client SHALL 4567 include the header in SETUP requests to indicate which formats it 4568 support to receive in PLAY and PAUSE responses, and REDIRECT 4569 requests. The server SHALL include the header in SETUP and 456 error 4570 responses to indicate the formats supported for the resource 4571 indicated by the request URI. 4572 Accept-Ranges: NPT, SMPTE 4574 This header has the same syntax as [H14.5] and the syntax is defined 4575 in Section 20.2.3. However, new range-units are defined. 4577 16.6. Allow 4579 The Allow entity-header field lists the methods supported by the 4580 resource identified by the Request-URI. The purpose of this field is 4581 to strictly inform the recipient of valid methods associated with the 4582 resource. An Allow header field MUST be present in a 405 (Method Not 4583 Allowed) response. See [H14.7] for syntax definition. The Allow 4584 header MUST also be present in all OPTIONS responses where the 4585 content of the header will not include exactly the same methods as 4586 listed in the Public header. 4588 The Allow SHALL also be included in SETUP and DESCRIBE responses, if 4589 the methods allowed for the resource is different than the minimal 4590 implementation set. 4592 Example of use: 4593 Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE 4595 16.7. Authorization 4597 See [H14.8]. 4599 16.8. Bandwidth 4601 The Bandwidth request-header field describes the estimated bandwidth 4602 available to the client, expressed as a positive integer and measured 4603 in bits per second. The bandwidth available to the client may change 4604 during an RTSP session, e.g., due to mobility, congestion, etc. 4606 Example: 4607 Bandwidth: 62360 4609 16.9. Blocksize 4611 The Blocksize request-header field is sent from the client to the 4612 media server asking the server for a particular media packet size. 4613 This packet size does not include lower-layer headers such as IP, 4614 UDP, or RTP. The server is free to use a blocksize which is lower 4615 than the one requested. The server MAY truncate this packet size to 4616 the closest multiple of the minimum, media-specific block size, or 4617 override it with the media-specific size if necessary. The block 4618 size MUST be a positive decimal number, measured in octets. The 4619 server only returns an error (4xx) if the value is syntactically 4620 invalid. 4622 16.10. Cache-Control 4624 The Cache-Control general-header field is used to specify directives 4625 that MUST be obeyed by all caching mechanisms along the request/ 4626 response chain. 4628 Cache directives MUST be passed through by a proxy or gateway 4629 application, regardless of their significance to that application, 4630 since the directives may be applicable to all recipients along the 4631 request/response chain. It is not possible to specify a cache- 4632 directive for a specific cache. 4634 Cache-Control should only be specified in a SETUP request and its 4635 response. Note: Cache-Control does not govern the caching of 4636 responses as for HTTP, instead it applies to the media stream 4637 identified by the SETUP request. The RTSP requests are generally not 4638 cacheable, for further information see Section 18. Below is the 4639 description of the cache directives that can be included in the 4640 Cache-Control header. 4642 no-cache: Indicates that the media stream MUST NOT be cached 4643 anywhere. This allows an origin server to prevent caching even 4644 by caches that have been configured to return stale responses 4645 to client requests. Note, there is no security function 4646 enforcing that the content can't be cached. 4648 public: Indicates that the media stream is cacheable by any cache. 4650 private: Indicates that the media stream is intended for a single 4651 user and MUST NOT be cached by a shared cache. A private (non- 4652 shared) cache may cache the media streams. 4654 no-transform: An intermediate cache (proxy) may find it useful to 4655 convert the media type of a certain stream. A proxy might, for 4656 example, convert between video formats to save cache space or 4657 to reduce the amount of traffic on a slow link. Serious 4658 operational problems may occur, however, when these 4659 transformations have been applied to streams intended for 4660 certain kinds of applications. For example, applications for 4661 medical imaging, scientific data analysis and those using end- 4662 to-end authentication all depend on receiving a stream that is 4663 bit-for-bit identical to the original media stream. Therefore, 4664 if a response includes the no-transform directive, an 4665 intermediate cache or proxy MUST NOT change the encoding of the 4666 stream. Unlike HTTP, RTSP does not provide for partial 4667 transformation at this point, e.g., allowing translation into a 4668 different language. 4670 only-if-cached: In some cases, such as times of extremely poor 4671 network connectivity, a client may want a cache to return only 4672 those media streams that it currently has stored, and not to 4673 receive these from the origin server. To do this, the client 4674 may include the only-if-cached directive in a request. If it 4675 receives this directive, a cache SHOULD either respond using a 4676 cached media stream that is consistent with the other 4677 constraints of the request, or respond with a 504 (Gateway 4678 Timeout) status. However, if a group of caches is being 4679 operated as a unified system with good internal connectivity, 4680 such a request MAY be forwarded within that group of caches. 4682 max-stale: Indicates that the client is willing to accept a media 4683 stream that has exceeded its expiration time. If max-stale is 4684 assigned a value, then the client is willing to accept a 4685 response that has exceeded its expiration time by no more than 4686 the specified number of seconds. If no value is assigned to 4687 max-stale, then the client is willing to accept a stale 4688 response of any age. 4690 min-fresh: Indicates that the client is willing to accept a media 4691 stream whose freshness lifetime is no less than its current age 4692 plus the specified time in seconds. That is, the client wants 4693 a response that will still be fresh for at least the specified 4694 number of seconds. 4696 must-revalidate: When the must-revalidate directive is present in a 4697 SETUP response received by a cache, that cache MUST NOT use the 4698 entry after it becomes stale to respond to a subsequent request 4699 without first revalidating it with the origin server. That is, 4700 the cache is required to do an end-to-end revalidation every 4701 time, if, based solely on the origin server's Expires, the 4702 cached response is stale.) 4704 proxy-revalidate: The proxy-revalidate directive has the same 4705 meaning as the must-revalidate directive, except that it does 4706 not apply to non-shared user agent caches. It can be used on a 4707 response to an authenticated request to permit the user's cache 4708 to store and later return the response without needing to 4709 revalidate it (since it has already been authenticated once by 4710 that user), while still requiring proxies that service many 4711 users to revalidate each time (in order to make sure that each 4712 user has been authenticated). Note that such authenticated 4713 responses also need the public cache control directive in order 4714 to allow them to be cached at all. 4716 max-age: When an intermediate cache is forced, by means of a max- 4717 age=0 directive, to revalidate its own cache entry, and the 4718 client has supplied its own validator in the request, the 4719 supplied validator might differ from the validator currently 4720 stored with the cache entry. In this case, the cache MAY use 4721 either validator in making its own request without affecting 4722 semantic transparency. 4724 However, the choice of validator might affect performance. The best 4725 approach is for the intermediate cache to use its own validator when 4726 making its request. If the server replies with 304 (Not Modified), 4727 then the cache can return its now validated copy to the client with a 4728 200 (OK) response. If the server replies with a new entity and cache 4729 validator, however, the intermediate cache can compare the returned 4730 validator with the one provided in the client's request, using the 4731 strong comparison function. If the client's validator is equal to 4732 the origin server's, then the intermediate cache simply returns 304 4733 (Not Modified). Otherwise, it returns the new entity with a 200 (OK) 4734 response. 4736 16.11. Connection 4738 See [H14.10]. The use of the connection option "close" in RTSP 4739 messages SHOULD be limited to error messages when the server is 4740 unable to recover and therefore see it necessary to close the 4741 connection. The reason is that the client has the choice of 4742 continuing using a connection indefinitely, as long as it sends valid 4743 messages. 4745 16.12. Connection-Credentials 4747 The Connection-Credentials response header is used to carry the chain 4748 of credentials of any next hop that need to be approved by the 4749 requestor. It SHALL only be used in server to client responses. 4751 The Connection-Credentials header in an RTSP response SHALL, if 4752 included, contain the credential information (in form of a list of 4753 certificates providing the chain of certification) of the next hop 4754 that an intermediary needs to securely connect to. The header MUST 4755 include the URI of the next hop (proxy or server) and a base64 4756 [RFC4648] encoded binary structure containg a sequence of DER encoded 4757 X.509v3 certificates[RFC5280] . 4759 The binary structure starts with the number of certificates 4760 (NR_CERTS) included as a 16 bit unsigned integer. This is followed 4761 by NR_CERTS number of 16 bit unsigned integers providing the size in 4762 octets of each DER encoded certificate. This is followed by NR_CERTS 4763 number of DER encoded X.509v3 certificates in a sequence (chain). 4765 The proxy or server's certificate must come first in the structure. 4766 Each following certificate must directly certify the one preceding 4767 it. Because certificate validation requires that root keys be 4768 distributed independently, the self-signed certificate which 4769 specifies the root certificate authority may optionally be omitted 4770 from the chain, under the assumption that the remote end must already 4771 possess it in order to validate it in any case. 4773 Example: 4775 Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC... 4777 Where MIIDNTCC... is a BASE64 encoding of the following structure: 4779 0 1 2 3 4780 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 4781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4782 | Number of certifcates | Size of certificate #1 | 4783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4784 | Size of certificate #2 | Size of certificate #3 | 4785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4786 : DER Encoding of Certificate #1 : 4787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4788 : DER Encoding of Certificate #2 : 4789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4790 : DER Encoding of Certificate #3 : 4791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4793 16.13. Content-Base 4795 The Content-Base entity-header field may be used to specify the base 4796 URI for resolving relative URIs within the entity. 4797 Content-Base: rtsp://media.example.com/movie/twister 4798 If no Content-Base field is present, the base URI of an entity is 4799 defined either by its Content-Location (if that Content-Location URI 4800 is an absolute URI) or the URI used to initiate the request, in that 4801 order of precedence. Note, however, that the base URI of the 4802 contents within the entity-body may be redefined within that entity- 4803 body. 4805 16.14. Content-Encoding 4807 See [H14.11]. 4809 16.15. Content-Language 4811 See [H14.12]. 4813 16.16. Content-Length 4815 The Content-Length general-header field contains the length of the 4816 body (entity) of the message (i.e. after the double CRLF following 4817 the last header). Unlike HTTP, it MUST be included in all messages 4818 that carry body beyond the header portion of the message. If it is 4819 missing, a default value of zero is assumed. It is interpreted 4820 according to [H14.13]. 4822 16.17. Content-Location 4824 See [H14.14]. 4826 16.18. Content-Type 4828 See [H14.17]. Note that the content types suitable for RTSP are 4829 likely to be restricted in practice to presentation descriptions and 4830 parameter-value types. 4832 16.19. CSeq 4834 The CSeq general-header field specifies the sequence number for an 4835 RTSP request-response pair. This field MUST be present in all 4836 requests and responses. For every RTSP request containing the given 4837 sequence number, the corresponding response will have the same 4838 number. Any retransmitted request MUST contain the same sequence 4839 number as the original (i.e. the sequence number is not incremented 4840 for retransmissions of the same request). For each new RTSP request 4841 the CSeq value SHALL be incremented by one. The initial sequence 4842 number MAY be any number, however it is RECOMMENDED to start at 0. 4843 Each sequence number series is unique between each requester and 4844 responder, i.e. the client has one series for its request to a server 4845 and the server has another when sending request to the client. Each 4846 requester and responder is identified with its network address. 4848 Proxies that aggregate several sessions on the same transport will 4849 regularly need to renumber the CSeq header field in requests and 4850 responses to fulfill the rules for the header. 4852 Example: 4853 CSeq: 239 4855 16.20. Date 4857 See [H14.18]. An RTSP message containing a body MUST include a Date 4858 header if the sending host has a clock. Servers SHOULD include a 4859 Date header in all other RTSP messages. 4861 16.21. ETag 4863 The ETag response header MAY be included in DESCRIBE or SETUP 4864 responses. The entity tags (Section 4.8) returned in a DESCRIBE 4865 response, and the one in SETUP refers to the presentation, i.e. both 4866 the returned session description and the media stream. This allows 4867 for verification that one has the right session description to a 4868 media resource at the time of the SETUP request. However it has the 4869 disadvantage that a change in any of the parts results in 4870 invalidation of all the parts. 4872 If the ETag is provided both inside the entity, e.g. within the 4873 "a=etag" attribute in SDP, and in the response message, then both 4874 tags SHALL be identical. It is RECOMMENDED that the ETag is 4875 primarily given in the RTSP response message, to ensure that caches 4876 can use the ETag without requiring content inspection. However for 4877 session descriptions that are distributed outside of RTSP, for 4878 example using HTTP, etc. it will be necessary to include the entity 4879 tag in the session description as specified in Appendix D.1.9. 4881 SETUP and DESCRIBE requests can be made conditional upon the ETag 4882 using the headers If-Match (Section 16.24) and If-None-Match ( 4883 Section 16.26). 4885 16.22. Expires 4887 The Expires entity-header field gives a date and time after which the 4888 description or media-stream should be considered stale. The 4889 interpretation depends on the method: 4891 DESCRIBE response: The Expires header indicates a date and time 4892 after which the presentation description (body) SHOULD be 4893 considered stale. 4895 SETUP response: The Expires header indicate a date and time after 4896 which the media stream SHOULD be considered stale. 4898 A stale cache entry may not normally be returned by a cache (either a 4899 proxy cache or an user agent cache) unless it is first validated with 4900 the origin server (or with an intermediate cache that has a fresh 4901 copy of the entity). See Section 18 for further discussion of the 4902 expiration model. 4904 The presence of an Expires field does not imply that the original 4905 resource will change or cease to exist at, before, or after that 4906 time. 4908 The format is an absolute date and time as defined by HTTP-date in 4910 [H3.3]; it MUST be in RFC1123-date format: 4912 An example of its use is 4913 Expires: Thu, 01 Dec 1994 16:00:00 GMT 4915 RTSP/2.0 clients and caches MUST treat other invalid date formats, 4916 especially including the value "0", as having occurred in the past 4917 (i.e., already expired). 4919 To mark a response as "already expired," an origin server should use 4920 an Expires date that is equal to the Date header value. To mark a 4921 response as "never expires," an origin server SHOULD use an Expires 4922 date approximately one year from the time the response is sent. 4923 RTSP/2.0 servers SHOULD NOT send Expires dates more than one year in 4924 the future. 4926 16.23. From 4928 See [H14.22]. 4930 16.24. If-Match 4932 See [H14.24]. 4934 The If-Match request-header field is especially useful for ensuring 4935 the integrity of the presentation description, in both the case where 4936 it is fetched via means external to RTSP (such as HTTP), or in the 4937 case where the server implementation is guaranteeing the integrity of 4938 the description between the time of the DESCRIBE message and the 4939 SETUP message. By including the ETag given in or with the session 4940 description in a SETUP request, the client ensures that resources set 4941 up are matching the description. A SETUP request for which the ETag 4942 validation check fails, SHALL responde using 412 (Precondition 4943 Failed). 4945 This validation check is also very useful if a session has been 4946 redirected from one server to another. 4948 16.25. If-Modified-Since 4950 The If-Modified-Since request-header field is used with the DESCRIBE 4951 and SETUP methods to make them conditional. If the requested variant 4952 has not been modified since the time specified in this field, a 4953 description will not be returned from the server (DESCRIBE) or a 4954 stream will not be set up (SETUP). Instead, a 304 (Not Modified) 4955 response SHALL be returned without any message-body. 4957 An example of the field is: 4959 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 4961 16.26. If-None-Match 4963 See [H14.26]. 4965 This request header can be used with one or several entity tags to 4966 make DESCRIBE requests conditional. A new session description is 4967 retrieved only if another entity than the ones already available 4968 would be included. If the entity available for delivery is matching 4969 the one the client already has, then a 304 (Not Modified) response is 4970 given. 4972 16.27. Last-Modified 4974 The Last-Modified entity-header field indicates the date and time at 4975 which the origin server believes the presentation description or 4976 media stream was last modified. See [H14.29]. For the methods 4977 DESCRIBE, the header field indicates the last modification date and 4978 time of the description, for SETUP that of the media stream. 4980 16.28. Location 4982 See [H14.30]. 4984 16.29. Media-Properties 4986 This general header is used in SETUP response or PLAY_NOTIFY requests 4987 to indicate the media's properties that currently are applicable to 4988 the RTSP session. PLAY_NOTIFY MAY be used to modify these properties 4989 at any point. However, the client MUST have received the update 4990 prior to any action related to the new media properties take affect. 4991 For aggregated sessions the Media-Properties header will be returned 4992 in each SETUP response and the one that applies is the response to 4993 the last request. 4995 The media properties expressed by this header is the one applicable 4996 to all media in the RTSP session. So for aggregated sessions the 4997 header expressed the combined media-properties. As a result 4998 aggregation of media MAY result in a change of the media properties, 4999 and thus the content of the Media-Properties header contained in 5000 subsequent SETUP responses. 5002 The header contains a list of property values that are applicable to 5003 the currently setup media or aggregate of media as indicated by the 5004 RTSP URI in the request. No ordering are enforced within the header. 5005 Property values should be grouped into a single group that handles a 5006 particular orthogonal property. Values or groups that express 5007 multiple properties SHOULD NOT be used. The list of properties that 5008 can be expressed MAY be extended at any time. Unknown property 5009 values SHALL be ignored. 5011 This specification defines the following 3 groups and their property 5012 values: 5014 Random Access: 5016 Random-Access: Indicates that random access is possible. May 5017 optionally include a floating point value in seconds indicating 5018 the longest duration between any two random access points in 5019 the media. 5021 Begining-Only: Seeking is limited to the begining only. 5023 No-Seeking: No seeking is possible. 5025 Content Modifications 5027 Unmutable: The content will not be changed during the life-time 5028 of the RTSP session. 5030 Dynamic: The content may be changed based on external methods or 5031 triggers 5033 Time-Progressing The media accesible progress as wall clock time 5034 progresses. 5036 Retention 5038 Unlimited: Content will be retained for the duration of the life- 5039 time of the RTSP session. 5041 Time-Limited: Content will be retained at least until the 5042 specified wall clock time. The time must be provided in the 5043 absolute time format specified in Section Section 4.6. 5045 Time-Duration Each individual media unit is retained for at least 5046 the specified time duration. This definition allows for 5047 retaining data with a time based sliding window. The time 5048 duration is expressed as floating point number in seconds. 0.0 5049 is a valid value as this indicates that no data is retained in 5050 a time-progressing session. 5052 An Example of this header for first an on-demand content and then a 5053 live stream without recording. 5055 On-demand: 5056 Media-Properties: Random-Acess=2.5s, Unlimited, Unmutable 5058 Live stream without recording/timeshifting: 5059 Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0 5061 16.30. Media-Range 5063 The Media-Range general header is used to give the range of the media 5064 at the time of sending the RTSP message. This header SHALL be 5065 included in SETUP response, and PLAY and PAUSE response for media 5066 that are Time-Progressing, and PLAY and PAUSE response after any 5067 change for media that are Dynamic, and in PLAY_NOTIFY request that 5068 are sent due to Media-Property-Update. Media-Range header without 5069 any range specifications MAY be included in GET_PARAMETER requests to 5070 the server to request the current value. The server SHALL in this 5071 case include the curent value at the time of sending the response. 5073 The header SHALL include range specification for all time formats 5074 supported for the media, as indicated in Accept-Ranges header 5075 (Section 16.5) when setting up the media. The server MAY include 5076 more than one range specification of any given time format to 5077 indicate media that has non-continous range. 5079 For media that has the Time-Progressing property, the Media-Range 5080 values will only be valid for the particular point in time when it 5081 was issued. As wall clock progresses so will also the media range. 5082 However it shall be assumed that media time progress in direct 5083 relationship to wall clock time (with the exception of clock skew) so 5084 that a reasoanbly accurate estiamation of the media range can be 5085 calculated. 5087 16.31. Notify-Reason 5089 The Notify Reason header is solely used in the PLAY_NOTIFY method. 5090 It indiciates the reason why the server has sent the asynchronous 5091 PLAY_NOTIFY request (see Section 13.5). 5093 16.32. Pipelined-Requests 5095 The Pipelined-Requests general header is used to indicate that a 5096 request is to be executed in the context created by previous 5097 requests. The primary usage of this header is to allow pipelining of 5098 SETUP requests so that any additional SETUP request after the first 5099 one doesn't need to wait for the session ID to be sent back to the 5100 requesting entity. The header contains a unique identifier that is 5101 scoped by the persistent connection used to send the requests. 5103 Upon receiving a request with the Pipelined-Requests the responding 5104 entity SHALL look up if there exist a binding between this Pipelined- 5105 Requests identifier for the current persistent connection and an RTSP 5106 session ID. If that exist then the received request is processed the 5107 same way as if it did contain the Session header with the looked up 5108 session ID. If there doesn't exist a mapping and no Session header 5109 is included in the request, the responding entity SHALL create a 5110 binding upon the succesful completion of a session creating request, 5111 i.e. SETUP. If the request failed to create an RTSP session no 5112 binding SHALL be created. In case the request contains both a 5113 Session header and the Pipelined-Requests header the Pipelined- 5114 Requests SHALL be ignored. 5116 Note: Based on the above definition at least the first request 5117 containing a new unique Pipelined-Requests will be required to be a 5118 SETUP request (unless the protocol is extended with new methods of 5119 creating a session). After that first one, additional SETUP requests 5120 or request of any type using the RTSP session context may include the 5121 Pipelined-Requests header. 5123 For all responses to request that contained the Pipelined-Requests, 5124 the Session header and the Pipelined-Requests SHALL both be included, 5125 assuming that it is allowed for that response and that the binding 5126 between the header values exist. Pipelined-Requests SHOULD NOT be 5127 used in requests after that the client has received the RTSP Session 5128 ID. This as using the real session ID allows the request to be used 5129 also in cases the persistent connection has been terminated and a new 5130 connection is needed. 5132 It is the sender of the request that is responsible for using a 5133 previously unused identifier within this transport connection scope 5134 when a new RTSP session is to be cretated with this method. A server 5135 side binding SHALL be deleted upon the termination of the related 5136 RTSP session. Note: Although this definition would allow for reusing 5137 previously used pipelining identifiers, this is NOT RECOMMENDED to 5138 allow for better error handling and logging. 5140 RTSP Proxies may need to translate Pipelined-Requests identifier 5141 values from incoming request to outgoing to allow for aggregation of 5142 requests onto a persistent connection. 5144 16.33. Proxy-Authenticate 5146 See [H14.33]. 5148 16.34. Proxy-Authorization 5150 See [H14.34]. 5152 16.35. Proxy-Require 5154 The Proxy-Require request-header field is used to indicate proxy- 5155 sensitive features that MUST be supported by the proxy. Any Proxy- 5156 Require header features that are not supported by the proxy MUST be 5157 negatively acknowledged by the proxy to the client using the 5158 Unsupported header. The proxy SHALL use the 551 (Option Not 5159 Supported) status code in the response. Any feature-tag included in 5160 the Proxy-Require does not apply to the end-point (server or client). 5161 To ensure that a feature is supported by both proxies and servers the 5162 tag needs to be included in also a Require header. 5164 See Section 16.42 for more details on the mechanics of this message 5165 and a usage example. See discussion in the proxies section 5166 (Section 17.1) about when to consider that a feature requires proxy 5167 support. 5169 Example of use: 5170 Proxy-Require: play.basic 5172 16.36. Proxy-Supported 5174 The Proxy-Supported header field enumerates all the extensions 5175 supported by the proxy using feature-tags. The header carries the 5176 intersection of extensions supported by the forwarding proxies. The 5177 Proxy-Supported header MAY be included in any request by a proxy. It 5178 SHALL be added by any proxy if the Supported header is present in a 5179 request. When present in a request, the receiver MUST in the 5180 response copy the received Proxy-Supported header. 5182 The Proxy-Supported header field contains a list of feature-tags 5183 applicable to proxies, as described in Section 4.7. The list are the 5184 intersection of all feature-tags understood by the proxies. To 5185 achieve an intersection, the proxy adding the Proxy-Supported header 5186 includes all proxy feature-tags it understands. Any proxy receiving 5187 a request with the header, checks the list and removes any feature- 5188 tag it do not support. A Proxy-Supported header present in the 5189 response SHALL NOT be touched by the proxies. 5191 Example: 5193 C->P1: OPTIONS rtsp://example.com/ RTSP/2.0 5194 Supported: foo, bar, blech 5195 User-Agent: PhonyClient/1.2 5197 P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0 5198 Supported: foo, bar, blech 5199 Proxy-Supported: proxy-foo, proxy-bar, proxy-blech 5200 Via: 2.0 prox1.example.com 5202 P2->S: OPTIONS rtsp://example.com/ RTSP/2.0 5203 Supported: foo, bar, blech 5204 Proxy-Supported: proxy-foo, proxy-blech 5205 Via: 2.0 prox1.example.com, 2.0 prox2.example.com 5207 S->C: RTSP/2.0 200 OK 5208 Supported: foo, bar, baz 5209 Proxy-Supported: proxy-foo, proxy-blech 5210 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 5211 Via: 2.0 prox1.example.com, 2.0 prox2.example.com 5213 16.37. Public 5215 The Public response header field lists the set of methods supported 5216 by the response sender. This header applies to the general 5217 capabilities of the sender and its only purpose is to indicate the 5218 sender's capabilities to the recipient. The methods listed may or 5219 may not be applicable to the Request-URI; the Allow header field 5220 (section 14.7) MAY be used to indicate methods allowed for a 5221 particular URI. 5223 Example of use: 5224 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 5226 In the event that there are proxies between the sender and the 5227 recipient of a response, each intervening proxy MUST modify the 5228 Public header field to remove any methods that are not supported via 5229 that proxy. The resulting Public header field will contain an 5230 intersection of the sender's methods and the methods allowed through 5231 by the intervening proxies. 5233 In general proxies should allow all methods to transparently pass 5234 through from the sending RTSP agent to the receiving RTSP agent, 5235 but there may be cases where this is not desirable for a given 5236 proxy. Modification of the Public response header field by the 5237 intervening proxies ensures that the request sender gets an 5238 accurate response indicating the methods that can be used on the 5239 target agent via the proxy chain. 5241 16.38. Range 5243 The Range header specifies a time range in PLAY (Section 13.4), PAUSE 5244 (Section 13.6), SETUP (Section 13.3), REDIRECT (Section 13.10), and 5245 PLAY_NOTIFY (Section 13.5) requests and responses. 5247 The range can be specified in a number of units. This specification 5248 defines smpte (Section 4.4), npt (Section 4.5), and clock 5249 (Section 4.6) range units. While byte ranges [H14.35.1] and other 5250 extended units MAY be used, their behavior is unspecified since they 5251 are not normally meaningful in RTSP. Servers supporting the Range 5252 header MUST understand the NPT range format and SHOULD understand the 5253 SMPTE range format. If the Range header is sent in a time format 5254 that is not understood, the recipient SHOULD return 456 (Header Field 5255 Not Valid for Resource) and include an Accept-Ranges header 5256 indicating the supported time formats for the given resource. 5258 The Range header MAY contain a time parameter in UTC, specifying the 5259 time at which the operation is to be made effective. This 5260 functionality SHALL be used only with the REDIRECT method. 5262 Example: 5263 Range: clock=19960213T143205Z-;time=19970123T143720Z 5265 The notation is similar to that used for the HTTP/1.1 [RFC2616] 5266 byte-range header. It allows clients to select an excerpt from 5267 the media object, and to play from a given point to the end as 5268 well as from the current location to a given point. 5270 Ranges are half-open intervals, including the first point, but 5271 excluding the second point. In other words, a range of A-B starts 5272 exactly at time A, but stops just before B. Only the start time of a 5273 media unit such as a video or audio frame is relevant. For example, 5274 assume that video frames are generated every 40 ms. A range of 10.0- 5275 10.1 would include a video frame starting at 10.0 or later time and 5276 would include a video frame starting at 10.08, even though it lasted 5277 beyond the interval. A range of 10.0-10.08, on the other hand, would 5278 exclude the frame at 10.08. 5280 By default, range intervals increase, where the second point is 5281 larger than the first point. 5283 Example: 5284 Range: npt=10-15 5286 However, range intervals can also decrease if the Scale header (see 5287 Section 16.44) indicates a negative scale value. For example, this 5288 would be the case when a playback in reverse is desired. 5290 Example: 5291 Scale: -1 5292 Range: npt=15-10 5294 Decreasing ranges are still half open intervals as described above. 5295 Thus, for range A-B, A is closed and B is open. In the above 5296 example, 15 is closed and 10 is open. An exception to this rule is 5297 the case when B=0 in a decreasing range. In this case, the range is 5298 closed on both ends, as otherwise there would be no way to reach 0 on 5299 a reverse playback for formats that have such a notion, like NPT and 5300 SMPTE. 5302 Example: 5303 Scale: -1 5304 Range: npt=15-0 5306 In this range both 15 and 0 are closed. 5308 A decreasing range interval without a corresponding negative Scale 5309 header is not valid. 5311 16.39. Referer 5313 See [H14.36]. The URI refers to that of the presentation 5314 description, typically retrieved via HTTP. 5316 16.40. Retry-After 5318 See [H14.37]. 5320 16.41. Request-Status 5322 This request header is used to indicate the end result for requests 5323 that takes time to complete, such a PLAY (Section 13.4). It is sent 5324 in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report 5325 how the PLAY request concluded, either in success or in failure. The 5326 header carries a reference to the request is reports on using the 5327 CSeq number for the session indicated by the Session header in the 5328 request. It provies both a numerical status code (according to 5329 Section 8.1.1) and a human readable reason phrase. 5331 Example: 5332 Request-Status: cseq=63 status=500 reason="Media data unavailable" 5334 16.42. Require 5336 The Require request-header field is used by clients or servers to 5337 ensure that the other end-point supports features that are required 5338 in respect to this request. It can also be used to query if the 5339 other end-point supports certain features, however the use of the 5340 Supported (Section 16.49) is much more effective in this purpose. 5341 The server MUST respond to this header by using the Unsupported 5342 header to negatively acknowledge those feature-tags which are NOT 5343 supported. The response SHALL use the error code 551 (Option Not 5344 Supported). This header does not apply to proxies, for the same 5345 functionality in respect to proxies see Proxy-Require header 5346 (Section 16.35) with the exception of media modifying proxies. Media 5347 modifying proxies due to their nature of handling media in a way that 5348 is very similar to what a server, do need to understand also the 5349 server features to correctly serve the client. 5351 This is to make sure that the client-server interaction will 5352 proceed without delay when all features are understood by both 5353 sides, and only slow down if features are not understood (as in 5354 the example below). For a well-matched client-server pair, the 5355 interaction proceeds quickly, saving a round-trip often required 5356 by negotiation mechanisms. In addition, it also removes state 5357 ambiguity when the client requires features that the server does 5358 not understand. 5360 Example (Not complete): 5361 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/2.0 5362 CSeq: 302 5363 Require: funky-feature 5364 Funky-Parameter: funkystuff 5366 S->C: RTSP/2.0 551 Option not supported 5367 CSeq: 302 5368 Unsupported: funky-feature 5370 In this example, "funky-feature" is the feature-tag which indicates 5371 to the client that the fictional Funky-Parameter field is required. 5372 The relationship between "funky-feature" and Funky-Parameter is not 5373 communicated via the RTSP exchange, since that relationship is an 5374 immutable property of "funky-feature" and thus should not be 5375 transmitted with every exchange. 5377 Proxies and other intermediary devices SHALL ignore this header. If 5378 a particular extension requires that intermediate devices support it, 5379 the extension should be tagged in the Proxy-Require field instead 5380 (see Section 16.35). See discussion in the proxies section 5381 (Section 17.1) about when to consider that a feature requires proxy 5382 support. 5384 16.43. RTP-Info 5386 The RTP-Info response-header field is used to set RTP-specific 5387 parameters in the PLAY response. For streams using RTP as transport 5388 protocol the RTP-Info header SHOULD be part of a 200 response to 5389 PLAY. 5391 The exclusion of the RTP-Info in a PLAY response for RTP 5392 transported media will result in that a client needs to 5393 synchronize the media streams using RTCP. This may have negative 5394 impact as the RTCP can be lost, and does not need to be 5395 particulary timely in their arrival. Also functionality as 5396 informing the client from which packet a seek has occurred is 5397 affected. 5399 The RTP-Info MAY also be included in SETUP responses to provide 5400 synchronization information when changing transport parameters, see 5401 Section 13.3. 5403 The header can carry the following parameters: 5405 url: Indicates the stream URI which for which the following RTP 5406 parameters correspond, this URI MUST be the same used in the 5407 SETUP request for this media stream. Any relative URI SHALL 5408 use the Request-URI as base URI. This parameter SHALL be 5409 present. 5411 ssrc: The Synchronization source (SSRC) that the RTP timestamp and 5412 sequence number provide applies to. This parameter SHALL be 5413 present. 5415 seq: Indicates the sequence number of the first packet of the stream 5416 that is direct result of the request. This allows clients to 5417 gracefully deal with packets when seeking. The client uses 5418 this value to differentiate packets that originated before the 5419 seek from packets that originated after the seek. Note that a 5420 client may not receive the packet with the expressed sequence 5421 number, and instead packets with a higher sequence number, due 5422 to packet loss or reordering. This parameter is RECOMMENDED to 5423 be present. 5425 rtptime: SHALL indicate the RTP timestamp value corresponding to the 5426 start time value in the Range response header, or if not 5427 explicitly given the implied start point. The client uses this 5428 value to calculate the mapping of RTP time to NPT or other 5429 media timescale. This parameter SHOULD be present to ensure 5430 inter-media synchronization is achieved. There exist no 5431 requirement that any received RTP packet will have the same RTP 5432 timestamp value as the one in the parameter used to establish 5433 synchronization. 5435 A mapping from RTP timestamps to NTP timestamps (wall clock) is 5436 available via RTCP. However, this information is not sufficient 5437 to generate a mapping from RTP timestamps to media clock time 5438 (NPT, etc.). Furthermore, in order to ensure that this 5439 information is available at the necessary time (immediately at 5440 startup or after a seek), and that it is delivered reliably, this 5441 mapping is placed in the RTSP control channel. 5443 In order to compensate for drift for long, uninterrupted 5444 presentations, RTSP clients should additionally map NPT to NTP, 5445 using initial RTCP sender reports to do the mapping, and later 5446 reports to check drift against the mapping. 5448 Example: 5449 Range:npt=3.25-15 5450 RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102; 5451 rtptime=12345678,url="rtsp://example.com/foo/video" 5452 ssrc=9A9DE123:seq=30211;rtptime=29567112 5454 Lets assume that Audio uses a 16kHz RTP timestamp clock and Video 5455 a 90kHz RTP timestamp clock. Then the media synchronization is 5456 depicted in the following way. 5458 NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6 5459 Audio PA A 5460 Video V PV 5462 X: NPT time value = 3.25, from Range header. 5463 A: RTP timestamp value for Audio from RTP-Info header (12345678). 5464 V: RTP timestamp value for Video from RTP-Info header (29567112). 5465 PA: RTP audio packet carrying an RTP timestamp of 12344878. Which 5466 corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2 5467 PV: RTP video packet carrying an RTP timestamp of 29573412. Which 5468 corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32 5470 16.44. Scale 5472 A scale value of 1 indicates normal play at the normal forward 5473 viewing rate. If not 1, the value corresponds to the rate with 5474 respect to normal viewing rate. For example, a ratio of 2 indicates 5475 twice the normal viewing rate ("fast forward") and a ratio of 0.5 5476 indicates half the normal viewing rate. In other words, a ratio of 2 5477 has normal play time increase at twice the wallclock rate. For every 5478 second of elapsed (wallclock) time, 2 seconds of content will be 5479 delivered. A negative value indicates reverse direction. For 5480 certain media transports this may require certain considerations to 5481 work consistent, see Appendix C.1 for description on how RTP handles 5482 this. 5484 Unless requested otherwise by the Speed parameter, the data rate 5485 SHOULD NOT be changed. Implementation of scale changes depends on 5486 the server and media type. For video, a server may, for example, 5487 deliver only key frames or selected key frames. For audio, for 5488 example, it may time-scale the audio while preserving pitch or, less 5489 desirably, deliver fragments of audio. 5491 The server should try to approximate the viewing rate, but may 5492 restrict the range of scale values that it supports. The response 5493 MUST contain the actual scale value chosen by the server. 5495 If the server does not implement the possibility to scale, it will 5496 not return a Scale header. A server supporting Scale operations for 5497 PLAY SHALL indicate this with the use of the "play.scale" feature- 5498 tags. 5500 When indicating a negative scale for a reverse playback, the Range 5501 header MUST indicate a decreasing range as described in 5502 Section 16.38. 5504 Example of playing in reverse at 3.5 times normal rate: 5505 Scale: -3.5 5506 Range: npt=15-10 5508 16.45. Seek-Style 5510 When a client sends a PLAY request with a Range header to perform a 5511 random access to the media, the client does not know if the server 5512 will pick the first media samples or the first random access point 5513 prior to the request range. Depending on use case, the client may 5514 have a strong preference. To express this preference and provide the 5515 client with information on how the server actually acted on that 5516 preference the Seek-Style header is defined. 5518 Seek-Style is a general header that MAY be included in any PLAY 5519 request to indicate the client's preference for any media stream that 5520 has random access properties. The server SHALL always include the 5521 header in any PLAY response for media with random access properties 5522 to indicate what policy was applied. A Server that receives a 5523 unknown Seek-Style policy SHALL ignore it and select the server 5524 default policy. 5526 This specification defines the following seek policies that may be 5527 requested: 5529 RAP: Random Access Point (RAP) is the behavior of requesting the 5530 server to locate the closest previous random access point that 5531 exist in the media aggregate and deliver from that. By requesting 5532 a RAP media quality will be the best possible as all media will be 5533 delivered from a point where full media state can be established 5534 in the media decoder. 5536 First-Prior: The first-prior policy will start delivery with the 5537 media unit that has a playout time first prior to the requested 5538 time. For discrete media that would only include media units that 5539 would still be rendered at the request time. For continous media 5540 that is media that will be render during the requested start time 5541 of the range. 5543 Next: The next media units after the provided start time of the 5544 range. For continous framed media that would mean the first next 5545 frame after the provided time. For discrete media the first unit 5546 that is to be rendered after the provided time. The main usage is 5547 for this case is when the client knows it has all media up to a 5548 certain point and would like to continue delivery so that a 5549 complete non-interrupted media playback can be achieved. Example 5550 of such scenarios include switching from a broadcast/multicast 5551 delivery to a unicast based delivery. This policy SHALL only be 5552 used on the client's explicit request. 5554 Please note that these expressed preferences exist for optimizing the 5555 startup time or the media quality. The "Next" policy breaks the 5556 normal definition of the Range header to enable a client to request 5557 media with minimal overlap, although some may still occur for 5558 aggregated sessions. RAP and First-Prior both fulfill the 5559 requirement of providing media from the requested range and forward. 5560 However, unless RAP is used, the media quality for many media codecs 5561 using predictive methods can be severly degraded unless additional 5562 data is available as, for example, already buffered, or through other 5563 side channels. 5565 16.46. Speed 5567 The Speed request-header field requests the server to deliver data to 5568 the client at a particular speed, contingent on the server's ability 5569 and desire to serve the media stream at the given speed. 5570 Implementation by the server is OPTIONAL. The default is the bit 5571 rate of the stream. 5573 The parameter value is expressed as a decimal ratio, e.g., a value of 5574 2.0 indicates that data is to be delivered twice as fast as normal. 5575 A speed of zero is invalid. All speeds may not be possible to 5576 support. Therefore the actual used speed MUST be included in the 5577 response. The lack of a response header is indication of lack of 5578 support from the server of this functionality. Support of the speed 5579 functionality are indicated by the "play.speed" feature-tag. 5581 Example: 5582 Speed: 2.5 5584 Use of this field changes the bandwidth used for data delivery. It 5585 is meant for use in specific circumstances where preview of the 5586 presentation at a higher or lower rate is necessary. Implementors 5587 should keep in mind that bandwidth for the session may be negotiated 5588 beforehand (by means other than RTSP), and therefore re-negotiation 5589 may be necessary. When data is delivered over UDP, it is highly 5590 recommended that means such as RTCP be used to track packet loss 5591 rates. If the data transport is performed over non-dedicated best- 5592 effort networks the sender is required to perform congestion control 5593 of the stream(s). This can result in that the communicated speed is 5594 impossible to maintain. 5596 16.47. Server 5598 See [H14.38], however the header syntax is corrected in 5599 Section 20.2.3. 5601 16.48. Session 5603 The Session request-header and response-header field identifies an 5604 RTSP session. An RTSP session is created by the server as a result 5605 of a successful SETUP request and in the response the session 5606 identifier is given to the client. The RTSP session exist until 5607 destroyed by a TEARDOWN or timed out by the server. 5609 The session identifier is chosen by the server (see Section 4.3) and 5610 MUST be returned in the SETUP response. Once a client receives a 5611 session identifier, it SHALL be included in any request related to 5612 that session. This means that the Session header MUST be included in 5613 a request using the following methods: PLAY, PAUSE, and TEARDOWN, and 5614 MAY be included in SETUP, OPTIONS, SET_PARAMETER, GET_PARAMETER, and 5615 REDIRECT, and SHALL NOT be included in DESCRIBE. In an RTSP response 5616 the session header SHALL be included in methods, SETUP, PLAY, and 5617 PAUSE, and MAY be included in methods, TEARDOWN, and REDIRECT, and if 5618 included in the request of the following methods it SHALL also be 5619 included in the response, OPTIONS, GET_PARAMETER, and SET_PARAMETER, 5620 and SHALL NOT be included in DESCRIBE. 5622 Note that a session identifier identifies an RTSP session across 5623 transport sessions or connections. RTSP requests for a given session 5624 can use different URIs (Presentation and media URIs). Note, that 5625 there are restrictions depending on the session which URIs that are 5626 acceptable for a given method. However, multiple "user" sessions for 5627 the same URI from the same client will require use of different 5628 session identifiers. 5630 The session identifier is needed to distinguish several delivery 5631 requests for the same URI coming from the same client. 5633 The response 454 (Session Not Found) SHALL be returned if the session 5634 identifier is invalid. 5636 16.49. Supported 5638 The Supported header field enumerates all the extensions supported by 5639 the client or server using feature tags. The header carries the 5640 extensions supported by the message sending entity. The Supported 5641 header MAY be included in any request. When present in a request, 5642 the receiver MUST respond with its corresponding Supported header. 5643 Note, also in 4xx and 5xx responses is the supported header included. 5645 The Supported header field contains a list of feature-tags, described 5646 in Section 4.7, that are understood by the client or server. 5648 Example: 5650 C->S: OPTIONS rtsp://example.com/ RTSP/2.0 5651 Supported: foo, bar, blech 5652 User-Agent: PhonyClient/1.2 5654 S->C: RTSP/2.0 200 OK 5655 Supported: bar, blech, baz 5657 16.50. Timestamp 5659 The Timestamp general-header field describes when the agent sent the 5660 request. The value of the timestamp is of significance only to the 5661 agent and may use any timescale. The responding agent MUST echo the 5662 exact same value and MAY, if it has accurate information about this, 5663 add a floating point number indicating the number of seconds that has 5664 elapsed since it has received the request. The timestamp is used by 5665 the agent to compute the round-trip time to the responding agent so 5666 that it can adjust the timeout value for retransmissions. It also 5667 resolves retransmission ambiguities for unreliable transport of RTSP. 5669 16.51. Transport 5671 The Transport request and response header field indicates which 5672 transport protocol is to be used and configures its parameters such 5673 as destination address, compression, multicast time-to-live and 5674 destination port for a single stream. It sets those values not 5675 already determined by a presentation description. 5677 A Transport request header field MAY contain a list of transport 5678 options acceptable to the client, in the form of multiple transport 5679 specification entries. Transport specifications are comma separated, 5680 listed in decreasing order of preference. Parameters may be added to 5681 each transport specififcation, separated by a semicolon. The server 5682 MUST return a Transport response-header field in the response to 5683 indicate the values actually chosen if any. If not transport 5684 specification is supported no transport header is returned and the 5685 request SHALL be responded using the status code 461 (Unsupported 5686 Transport) (Section 15.4.13). In case more than one transport 5687 specification was present in the request, the server MUST return the 5688 single (transport-spec) which was actually chosen if any. The number 5689 of transport-spec entries is expected to be limited as the client 5690 will get guidance on what configurations that are possible from the 5691 presentation description. 5693 The Transport header field MAY also be used in subsequent SETUP 5694 requests to change transport parameters. A server MAY refuse to 5695 change parameters of an existing stream. 5697 A transport specification may only contain one of any given parameter 5698 within it. Parameters MAY be given in any order. Additionally, it 5699 may only contain either of the unicast or the multicast transport 5700 type parameter. All parameters needs to be understood in a transport 5701 specification, if not the transport specification SHALL be ignored. 5702 RTSP proxies of any type that uses or modifies the transport 5703 specification, e.g. acces proxy or security proxy, SHALL remove 5704 specifications with unknown parameters before forwarding the RTSP 5705 message. If that result in no remaing transport specification the 5706 proxy shall send a 461 (Unsupported Transport) (Section 15.4.13) 5707 response without any Transport header. 5709 The Transport header field is restricted to describing a single 5710 media stream. (RTSP can also control multiple streams as a single 5711 entity.) Making it part of RTSP rather than relying on a 5712 multitude of session description formats greatly simplifies 5713 designs of firewalls. 5715 The general syntax for the transport specifier is a list of slash 5716 separated tokens: 5718 Value1/Value2/Value3... 5719 Which for RTP transports take the form: 5720 RTP/profile/lower-transport. 5722 The default value for the "lower-transport" parameters is specific to 5723 the profile. For RTP/AVP, the default is UDP. 5725 There are two different methods for how to specify where the media 5726 should be delivered for unicast transport: 5728 dest_addr: The presence of this parameter and its values indicates 5729 the destination address or addresses (host address and port 5730 pairs for IP flows) necessary for the media transport. 5732 No dest_addr: The lack of the dest_addr parameter indicates that the 5733 server SHALL send media to same address for which the RTSP 5734 messages originates. Does not work for transports requiring 5735 explicitly given destination ports. 5737 The choice of method for indicating where the media is to be 5738 delivered depends on the use case. In some case the only allowed 5739 method will be to use no explicit address indication and have the 5740 server deliver media to the source of the RTSP messages. 5742 For Multicast there is several methods for specifying addresses but 5743 they are different in how they work compared with unicast: 5745 dest_addr with client picked address: The address and relevant 5746 parameters like TTL (scope) for the actual multicast group to 5747 deliver the media to. There are security implications 5748 (Section 21) with this method that needs to be addressed if 5749 using this method because a RTSP server can be used as a DoS 5750 attacker on a existing multicast group. 5752 dest_addr using Session Decription Information: The information 5753 included in the transport header can all be comming from the 5754 session description, e.g. the SDP c= and m= line. This 5755 mitigates some of the security issues of the previous methods 5756 as it is the session provider that picks the multicast group 5757 and scope. The client SHALL include the information if it is 5758 available in the session description. 5760 No dest_addr: The lack of an explicit multicast group request the 5761 server to decide the group address and its scope. For this to 5762 work the server needs to have a context about what scope that 5763 works. This method is currently under specified. 5765 An RTSP proxy will need to take care. If the media is not desired to 5766 be routed through the proxy, the proxy will need to introduce the 5767 destination indication. 5769 Below are the configuration parameters associated with transport: 5771 General parameters: 5773 unicast / multicast: This parameter is a mutually exclusive 5774 indication of whether unicast or multicast delivery will be 5775 attempted. One of the two values MUST be specified. Clients 5776 that are capable of handling both unicast and multicast 5777 transmission needs to indicate such capability by including two 5778 full transport-specs with separate parameters for each. 5780 layers: The number of multicast layers to be used for this media 5781 stream. The layers are sent to consecutive addresses starting 5782 at the dest_addr address. If the parameter is not included, it 5783 defaults to a single layer. 5785 dest_addr: A general destination address parameter that can contain 5786 one or more address specifications. Each combination of 5787 Protocol/Profile/Lower Transport needs to have the format and 5788 interpretation of its address specification defined. For RTP/ 5789 AVP/UDP and RTP/AVP/TCP, the address specification is a tuple 5790 containing a host address and port. Note, only a single 5791 destination entity per transport spec is intended. The usage 5792 of multiple destination to distribute a single media to 5793 multiple entities is unspecified. 5795 The client originating the RTSP request MAY specify the 5796 destination address of the stream recipient with the host 5797 address part of the tuple. When the destination address is 5798 specified, the recipient may be a different party than the 5799 originator of the request. To avoid becoming the unwitting 5800 perpetrator of a remote-controlled denial-of-service attack, a 5801 server MUST perform security checks (see Section 21.1) and 5802 SHOULD log such attempts before allowing the client to direct a 5803 media stream to a recipient address not chosen by the server. 5804 Implementations cannot rely on TCP as reliable means of client 5805 identification. If the server does not allow the host address 5806 part of the tuple to be set, it SHALL return 463 (Destination 5807 Prohibited). 5809 The host address part of the tuple MAY be empty, for example 5810 ":58044", in cases when only destination port is desired to be 5811 specified. Responses to request including the Transport header 5812 with a dest_addr parameter SHOULD include the full destination 5813 address that is actually used by the server. The server MUST 5814 NOT remove address information present already in the request 5815 when responding unless the protocol requires it. 5817 src_addr: A general source address parameter that can contain one or 5818 more address specifications. Each combination of Protocol/ 5819 Profile/Lower Transport needs to have the format and 5820 interpretation of its address specification defined. For RTP/ 5821 AVP/UDP and RTP/AVP/TCP, the address specification is a tuple 5822 containing a host address and port. 5824 This parameter MUST be specified by the server if it transmits 5825 media packets from another address than the one RTSP messages 5826 are sent to. This will allow the client to verify source 5827 address and give it a destination address for its RTCP feedback 5828 packets if RTP is used. The address or addresses indicated in 5829 the src_addr parameter SHOULD be used both for sending and 5830 receiving of the media streams data packets. The main reasons 5831 are threefold: First, indicating the port and source address(s) 5832 lets the receiver know where from the packets is expected to 5833 originate. Secondly, traversal of NATs are greatly simplified 5834 when traffic is flowing symmetrically over a NAT binding. 5835 Thirdly, certain NAT traversal mechanisms, needs to know to 5836 which address and port to send so called "binding packets" from 5837 the receiver to the sender, thus creating a address binding in 5838 the NAT that the sender to receiver packet flow can use. 5840 This information may also be available through SDP. 5841 However, since this is more a feature of transport than 5842 media initialization, the authoritative source for this 5843 information should be in the SETUP response. 5845 mode: The mode parameter indicates the methods to be supported for 5846 this session. Valid values are PLAY and RECORD. If not 5847 provided, the default is PLAY. The RECORD value was defined in 5848 RFC 2326 and is in this specification unspecified but reserved. 5850 interleaved: The interleaved parameter implies mixing the media 5851 stream with the control stream in whatever protocol is being 5852 used by the control stream, using the mechanism defined in 5853 Section 14. The argument provides the channel number to be 5854 used in the $ statement and MUST be present. This parameter 5855 MAY be specified as a range, e.g., interleaved=4-5 in cases 5856 where the transport choice for the media stream requires it, 5857 e.g. for RTP with RTCP. The channel number given in the 5858 request are only a guidance from the client to the server on 5859 what channel number(s) to use. The server MAY set any valid 5860 channel number in the response. The declared channel(s) are 5861 bi-directional, so both end-parties MAY send data on the given 5862 channel. One example of such usage is the second channel used 5863 for RTCP, where both server and client sends RTCP packets on 5864 the same channel. 5866 This allows RTP/RTCP to be handled similarly to the way 5867 that it is done with UDP, i.e., one channel for RTP and 5868 the other for RTCP. 5870 Multicast-specific: 5872 ttl: multicast time-to-live for IPv4. When included in requests the 5873 value indicate the TTL value that the client request the server 5874 to use. In a response, the value actually being used by the 5875 server is returned. A server will need to consider what values 5876 that are reasonable and also the authority of the user to set 5877 this value. Corresponding function are not needed for IPv6 as 5878 the scoping is part of the address. 5880 RTP-specific: 5882 These parameters are MAY only be used if the media transport protocol 5883 is RTP. 5885 ssrc: The ssrc parameter, if included in a SETUP response, indicates 5886 the RTP SSRC [RFC3550] value(s) that will be used by the media 5887 server for RTP packets within the stream. It is expressed as 5888 an eight digit hexadecimal value. 5890 The ssrc parameter SHALL NOT be specified in requests. The 5891 functionality of specifying the ssrc parameter in a SETUP 5892 request is deprecated as it is incompatible with the 5893 specification of RTP in RFC 3550[RFC3550]. If the parameter is 5894 included in the Transport header of a SETUP request, the server 5895 MAY ignore it, and choose appropriate SSRCs for the stream. 5896 The server MAY set the ssrc parameter in the Transport header 5897 of the response. 5899 The parameters defined below MAY only be used if the media transport 5900 protocol if the lower-level transport is connection-oriented (such as 5901 TCP). However, these parameters MUST NOT be used when interleaving 5902 data over the RTSP control connection. 5904 setup: Clients use the setup parameter on the Transport line in a 5905 SETUP request, to indicate the roles it wishes to play in a TCP 5906 connection. This parameter is adapted from [RFC4145]. We 5907 discuss the use of this parameter in RTP/AVP/TCP non- 5908 interleaved transport in Appendix C.2.2; the discussion below 5909 is limited to syntactic issues. Clients may specify the 5910 following values for the setup parameter: ["active":] The 5911 client will initiate an outgoing connection. ["passive":] The 5912 client will accept an incoming connection. ["actpass":] The 5913 client is willing to accept an incoming connection or to 5914 initiate an outgoing connection. 5916 If a client does not specify a setup value, the "active" value 5917 is assumed. 5919 In response to a client SETUP request where the setup parameter 5920 is set to "active", a server's 2xx reply MUST assign the setup 5921 parameter to "passive" on the Transport header line. 5923 In response to a client SETUP request where the setup parameter 5924 is set to "passive", a server's 2xx reply MUST assign the setup 5925 parameter to "active" on the Transport header line. 5927 In response to a client SETUP request where the setup parameter 5928 is set to "actpass", a server's 2xx reply MUST assign the setup 5929 parameter to "active" or "passive" on the Transport header 5930 line. 5932 Note that the "holdconn" value for setup is not defined for 5933 RTSP use, and MUST NOT appear on a Transport line. 5935 connection: Clients use the setup parameter on the Transport line in 5936 a SETUP request, to indicate the SETUP request prefers the 5937 reuse of an existing connection between client and server (in 5938 which case the client sets the "connection" parameter to 5939 "existing"), or that the client requires the creation of a new 5940 connection between client and server (in which cast the client 5941 sets the "connection" parameter to "new"). Typically, clients 5942 use the "new" value for the first SETUP request for a URL, and 5943 "existing" for subsequent SETUP requests for a URL. 5945 If a client SETUP request assigns the "new" value to 5946 "connection", the server response MUST also assign the "new" 5947 value to "connection" on the Transport line. 5949 If a client SETUP request assigns the "existing" value to 5950 "connection", the server response MUST assign a value of 5951 "existing" or "new" to "connection" on the Transport line, at 5952 its discretion. 5954 The default value of "connection" is "existing", for all SETUP 5955 requests (initial and subsequent). 5957 The combination of transport protocol, profile and lower transport 5958 needs to be defined. A number of combinations are defined in the 5959 Appendix C. 5961 Below is a usage example, showing a client advertising the capability 5962 to handle multicast or unicast, preferring multicast. Since this is 5963 a unicast-only stream, the server responds with the proper transport 5964 parameters for unicast. 5966 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 5967 CSeq: 302 5968 Transport: RTP/AVP;multicast;mode="PLAY", 5969 RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ 5970 "192.0.2.5:3457";mode="PLAY" 5971 Accept-Ranges: NPT, SMPTE, UTC 5972 User-Agent: PhonyClient/1.2 5974 S->C: RTSP/2.0 200 OK 5975 CSeq: 302 5976 Date: Thu, 23 Jan 1997 15:35:06 GMT 5977 Session: 47112344 5978 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ 5979 "192.0.2.5:3457";src_addr="192.0.2.224:6256"/ 5980 "192.0.2.224:6257";mode="PLAY" 5981 Accept-Ranges: NPT 5983 16.52. Unsupported 5985 The Unsupported response-header field lists the features not 5986 supported by the server. In the case where the feature was specified 5987 via the Proxy-Require field (Section 16.35), if there is a proxy on 5988 the path between the client and the server, the proxy MUST send a 5989 response message with a status code of 551 (Option Not Supported). 5990 The request SHALL NOT be forwarded. 5992 See Section 16.42 for a usage example. 5994 16.53. User-Agent 5996 See [H14.43] for explanation, however the syntax is clarified due to 5997 an error in RFC 2616. A Client SHOULD include this header in all 5998 RTSP messages it sends. 6000 16.54. Vary 6002 See [H14.44]. 6004 16.55. Via 6006 See [H14.45]. 6008 16.56. WWW-Authenticate 6010 See [H14.47]. 6012 17. Proxies 6014 RTSP Proxies are RTSP agents that sit in between a client and a 6015 server. A proxy can take on both the role as a client and as server 6016 depending on what it tries to accomplish. Proxies are also 6017 introduced for several different reasons and the below are often 6018 combined. 6020 Caching Proxy: This type of proxy is used to reduce the workload on 6021 servers and connections. By caching a presentation, both 6022 description and media streams the proxy can serve a client 6023 content without requesting it from the server once it has been 6024 cached and hasn't become stale. See the caching Section 18. 6025 This type of proxy is expected to also understand RTSP end- 6026 point functionality, i.e. functionality identified in the 6027 Require header in addition to what Proxy-Require demands. 6029 Translator Proxy: This type of proxy is used to ensure that a RTSP 6030 client get access to servers and content on an external network 6031 or using content encodings not supported by the client. The 6032 proxy performs the necessary translation of addresses, 6033 protocols or encodings. This type of proxy is expected to also 6034 understand RTSP end-point functionality, i.e. functionality 6035 identified in the Require header in addition to what Proxy- 6036 Require demands. 6038 Access Proxy: This type of proxy is used to ensure that a RTSP 6039 client get access to servers on an external network. Thus this 6040 proxy is placed on the border between two domains, e.g. a 6041 private address space and the public internet. The proxy 6042 performs the necessary translation, usually addresses. This 6043 type of proxies are required to redirect the media to 6044 themselves or a controlled gateway that perform the translation 6045 before the media can reach the client. 6047 Security Proxy: This type of proxy is used to help facilitate 6048 security functions around RTSP. For example when having a 6049 firewalled network, the security proxy request that the 6050 necessary pinholes in the firewall is opened when a client in 6051 the protected network want to access media streams on the 6052 external side.This proxy can also limit the clients access to 6053 certain type of content. This proxy can perform its function 6054 without redirecting the media between the server and client. 6055 However, in deployements with private address spaces this proxy 6056 is likely to be combined with the access proxy. Anyway, the 6057 functionality of this proxy is usually closely tied into 6058 understand all aspects of how the media transport. 6060 Auditing Proxy: RTSP proxies can also provide network owners with a 6061 logging and audit point for RTSP sessions, e.g. for 6062 corporations that tracks their employees usage of the network. 6063 This type of proxy can perform its function without inserting 6064 itself or any other node in the media transport. This proxy 6065 type can also accept unknown methods as it doesn't interfere 6066 with the clients requests. 6068 All type of proxies can be used also when using secured communication 6069 with TLS as RTSP 2.0 allows the client to approve certificate chains 6070 used for connection establishment from a proxy, see Section 19.3.2. 6071 However that trust model may not be suitable for all type of 6072 deployment, and instead secured sessions do by-pass of the proxies. 6074 Access proxies SHOULD NOT be used in equipment like NATs and 6075 firewalls that aren't expected to be regularly maintained, like home 6076 or small office equipment. In these cases it is better to use the 6077 NAT traversal procedures defined for RTSP 2.0 6078 [I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is 6079 that any extensions of RTSP resulting in new media transport 6080 protocols or profiles, new parameters etc may fail in a proxy that 6081 isn't maintained. Thus resulting in blocking further development of 6082 RTSP and its usage. 6084 17.1. Proxies and Protocol Extensions 6086 The existence of proxies must always be considered when developing 6087 new RTSP extensions. Most type of proxies will need to implement any 6088 new method to operate correct in the presence of that extension. New 6089 headers will be possible to introduce without being blocked by 6090 proxies not yet updated. However, it is important to consider if 6091 this header and its function is required to be understood by the 6092 proxy or can be forwarded. If the header needs to be understood a 6093 feature-tag representing the functionality needs to be included in 6094 the Proxy-Require header. Below are guidelines for analysis if the 6095 header needs to be understood. The transport header and its 6096 parameters also shows that headers that are extensible and requires 6097 correct interpretation in the proxy also requires handling rules. 6099 When defining a new RTSP header it needs to be considered if RTSP 6100 proxies are required to understand them to achieve correct 6101 functionality. Determining this is not easy as the functionality for 6102 proxies are widely varied as can be understood from the above list of 6103 functionality. When evaluating this one can dived the functionality 6104 into three main categories: 6106 Media modifying: The caching and translator proxies are modifying 6107 the actual media and therefore needs to understand also request 6108 directed to the server that affects how the media is rendered. 6109 Thus this type of proxies needs to also understand the server side 6110 functionality. 6112 Transport modifying: The access and the security proxy both need to 6113 understand the how the transport is performed, either for opening 6114 pinholes or to translate the outer headers, e.g. IP and UDP. 6116 Non-modifying: The audit proxy is special in that it do not modify 6117 the messages in other ways than to insert the Via header. That 6118 makes it possible for this type to forward RTSP message that 6119 contains different type of unknown methods, headers or header 6120 parameters. 6122 Based on the above classification one should evaluate if ones 6123 functionality requires the Transport modifying type of proxies to 6124 understand it or not. 6126 18. Caching 6128 In HTTP, response-request pairs are cached. RTSP differs 6129 significantly in that respect. Responses are not cacheable, with the 6130 exception of the presentation description returned by DESCRIBE. 6131 (Since the responses for anything but DESCRIBE and GET_PARAMETER do 6132 not return any data, caching is not really an issue for these 6133 requests.) However, it is desirable for the continuous media data, 6134 typically delivered out-of-band with respect to RTSP, to be cached, 6135 as well as the session description. 6137 On receiving a SETUP or PLAY request, a proxy ascertains whether it 6138 has an up-to-date copy of the continuous media content and its 6139 description. It can determine whether the copy is up-to-date by 6140 issuing a SETUP or DESCRIBE request, respectively, and comparing the 6141 Last-Modified header with that of the cached copy. If the copy is 6142 not up-to-date, it modifies the SETUP transport parameters as 6143 appropriate and forwards the request to the origin server. 6144 Subsequent control commands such as PLAY or PAUSE then pass the proxy 6145 unmodified. The proxy delivers the continuous media data to the 6146 client, while possibly making a local copy for later reuse. The 6147 exact behavior allowed to the cache is given by the cache-response 6148 directives described in Section 16.10. A cache MUST answer any 6149 DESCRIBE requests if it is currently serving the stream to the 6150 requestor, as it is possible that low-level details of the stream 6151 description may have changed on the origin-server. 6153 Note that an RTSP cache, unlike the HTTP cache, is of the "cut- 6154 through" variety. Rather than retrieving the whole resource from the 6155 origin server, the cache simply copies the streaming data as it 6156 passes by on its way to the client. Thus, it does not introduce 6157 additional latency. 6159 To the client, an RTSP proxy cache appears like a regular media 6160 server, to the media origin server like a client. Just as an HTTP 6161 cache has to store the content type, content language, and so on for 6162 the objects it caches, a media cache has to store the presentation 6163 description. Typically, a cache eliminates all transport-references 6164 (that is, e.g. multicast information) from the presentation 6165 description, since these are independent of the data delivery from 6166 the cache to the client. Information on the encodings remains the 6167 same. If the cache is able to translate the cached media data, it 6168 would create a new presentation description with all the encoding 6169 possibilities it can offer. 6171 19. Security Framework 6173 The RTSP security framework consists of two high level components: 6174 the pure authentication mechanisms based on HTTP authentication, and 6175 the transport protection based on TLS, which is independent of RTSP. 6176 Because of the similarity in syntax and usage between RTSP servers 6177 and HTTP servers, the security for HTTP is re-used to a large extent. 6179 19.1. RTSP and HTTP Authentication 6181 RTSP and HTTP share common authentication schemes, and thus follow 6182 the same usage guidelines as specified in[RFC2617] and also in [H15]. 6183 Servers SHOULD implement both basic and digest [RFC2617] 6184 authentication. Client SHALL implement both basic and digest 6185 authentication [RFC2617] so that Server who requires the client to 6186 authenticate can trust that the capability is present. 6188 It should be stressed that using the HTTP authentication alone does 6189 not provide full control message security. Therefore, in 6190 environments requiring tighter security for the control messages, TLS 6191 SHOULD be used, see Section 19.2. 6193 19.2. RTSP over TLS 6195 RTSP SHALL follow the same guidelines with regards to TLS [RFC5246] 6196 usage as specified for HTTP, see [RFC2818]. RTSP over TLS is 6197 separated from unsecured RTSP both on URI level and port level. 6198 Instead of using the "rtsp" scheme identifier in the URI, the "rtsps" 6199 scheme identifier MUST be used to signal RTSP over TLS. If no port 6200 is given in a URI with the "rtsps" scheme, port 322 SHALL be used for 6201 TLS over TCP/IP. 6203 When a client tries to setup an insecure channel to the server (using 6204 the "rtsp" URI), and the policy for the resource requires a secure 6205 channel, the server SHALL redirect the client to the secure service 6206 by sending a 301 redirect response code together with the correct 6207 Location URI (using the "rtsps" scheme). A user or client MAY 6208 upgrade a non secured URI to a secured by changing the scheme from 6209 "rtsp" to "rtsps". A server implementing support for "rtsps" SHALL 6210 allow this. 6212 It should be noted that TLS allows for mutual authentication (when 6213 using both server and client certificates). Still, one of the more 6214 common way TLS is used is to only provide server side authentication 6215 (often to avoid client certificates). TLS is then used in addition 6216 to HTTP authentication, providing transport security and server 6217 authentication, while HTTP Authentication is used to authenticate the 6218 client. 6220 RTSP includes the possibility to keep a TCP session up between the 6221 client and server, throughout the RTSP session lifetime. It may be 6222 convenient to keep the TCP session, not only to save the extra setup 6223 time for TCP, but also the extra setup time for TLS (even if TLS uses 6224 the resume function, there will be almost two extra roundtrips). 6225 Still, when TLS is used, such behavior introduces extra active state 6226 in the server, not only for TCP and RTSP, but also for TLS. This may 6227 increase the vulnerability to DoS attacks. 6229 In addition to these recommendations, Section 19.3 gives further 6230 recommendations of TLS usage with proxies. 6232 19.3. Security and Proxies 6234 The nature of a proxy is often to act as a "man-in-the-middle", while 6235 security is often about preventing the existence of a "man-in-the- 6236 middle". This section provides clients with the possibility to use 6237 proxies even when applying secure transports (TLS) between the RTSP 6238 agents. The TLS proxy mechanism allows for server and proxy 6239 identification using certificates. However, the client can not be 6240 identified based on certificates. The client needs to select between 6241 using the procedure specified below or using a TLS connection 6242 directly (by-passing any proxies) to the server. The choice may be 6243 dependent on policies. 6245 There are basically two categories of proxies, the transparent 6246 proxies (of which the client is not aware) and the non-transparent 6247 proxies (of which the client is aware). An infrastructure based on 6248 proxies requires that the trust model is such that both client and 6249 servers can trust the proxies to handle the RTSP messages correctly. 6250 To be able to trust a proxy, the client and server also needs to be 6251 aware of the proxy. Hence, transparent proxies cannot generally be 6252 seen as trusted and will not work well with security (unless they 6253 work only at transport layer). In the rest of this section any 6254 reference to proxy will be to a non-transparent proxy, which inspects 6255 or manipulate the RTSP messages. 6257 HTTP Authentication is built on the assumption of proxies and can 6258 provide user-proxy authentication and proxy-proxy/server 6259 authentication in addition to the client-server authentication. 6261 When TLS is applied and a proxy is used, the client will connect to 6262 the proxy's address when connecting to any RTSP server. This implies 6263 that for TLS, the client will authenticate the proxy server and not 6264 the end server. Note that when the client checks the server 6265 certificate in TLS, it MUST check the proxy's identity (URI or 6266 possibly other known identity) against the proxy's identity as 6267 presented in the proxy's Certificate message. 6269 The problem is that for a proxy accepted by the client, the proxy 6270 needs to be provided information on which grounds it should accept 6271 the next-hop certificate. Both the proxy and the user may have rules 6272 for this, and the user have the possibility to select the desired 6273 behavior. To handle this case, the Accept-Credentials header (See 6274 Section 16.2) is used, where the client can force the proxy/proxies 6275 to relay back the chain of certificates used to authenticate any 6276 intermediate proxies as well as the server. Given the assumption 6277 that the proxies are viewed as trusted, it gives the user a 6278 possibility to enforce policies to each trusted proxy of whether it 6279 should accept the next entity in the chain. 6281 A proxy MUST use TLS for the next hop if the RTSP request includes a 6282 "rtsps" URI. TLS MAY be applied on intermediate links (e.g. between 6283 client and proxy, or between proxy and proxy), even if the resource 6284 and the end server does not require to use it. The proxy SHALL when 6285 initiating the next hop TLS connection use the incomming TLS 6286 connections CipherSuite list, only modified by removing any cipher 6287 suits that the proxy does not support. In case a proxy fails to 6288 establish a TLS connection due to cipher suite mismatch between proxy 6289 and next hop proxy or server, this is indicated using error code 472 6290 (Failure to establish secure connection). 6292 19.3.1. Accept-Credentials 6294 The Accept-Credentials header can be used by the client to distribute 6295 simple authorization policies to intermediate proxies. The client 6296 includes the Accept-Credentials header to dictate how the proxy 6297 treats the server/next proxy certificate. There are currently three 6298 methods defined: 6300 Any, which means that the proxy (or proxies) SHALL accept whatever 6301 certificate presented. This is of course not a recommended 6302 option to use, but may be useful in certain circumstances (such 6303 as testing). 6305 Proxy, which means that the proxy (or proxies) MUST use its own 6306 policies to validate the certificate and decide whether to 6307 accept it or not. This is convenient in cases where the user 6308 has a strong trust relation with the proxy. Reason why a 6309 strong trust relation may exist are; personal/company proxy, 6310 proxy has a out-of-band policy configuration mechanism. 6312 User, which means that the proxy (or proxies) MUST send credential 6313 information about the next hop to the client for authorization. 6314 The client can then decide whether the proxy should accept the 6315 certificate or not. See Section 19.3.2 for further details. 6317 If the Accept-Credentials header is not included in the RTSP request 6318 from the client, then the "Proxy" method SHALL be used as default. 6319 If an other method than the "Proxy" is to be used, then the Accept- 6320 Credentials header SHALL be included in all of the RTSP request from 6321 the client. This is because it cannot be assumed that the proxy 6322 always keeps the TLS state or the users previously preference between 6323 different RTSP messages (in particular if the time interval between 6324 the messages is long). 6326 With the "Any" and "Proxy" methods the proxy will apply the policy as 6327 defined for respectively method. If the policy do not accept the 6328 credentials of the next hop, the entity SHALL respond with a message 6329 using status code 471 (Connection Credentials not accepted). 6331 An RTSP request in the direction server to client MUST NOT include 6332 the Accept-Credential header. As for the non-secured communication, 6333 the possibility for these request depends on the presence of a client 6334 established connection. However if the server to client request is 6335 in relation to a session established over a TLS secured channel, if 6336 MUST be sent in a TLS secured connection. That secured connection 6337 MUST also be the one used by the last client to server request. If 6338 no such transport connection exist at the time when the server desire 6339 to send the request, it silently fails. 6341 Further policies MAY be defined and registered, but should be done so 6342 with caution. 6344 19.3.2. User approved TLS procedure 6346 For the "User" method each proxy MUST perform the the following 6347 procedure for each RTSP request: 6349 o Setup the TLS session to the next hop if not already present (i.e. 6350 run the TLS handshake, but do not send the RTSP request). 6352 o Extract the peer certificate chain for the TLS session. 6354 o Check if a matching identity and hash of the peer certificate is 6355 present in the Accept-Credentials header. If present, send the 6356 message to the next hop, and conclude these procedures. If not, 6357 go to the next step. 6359 o The proxy responds to the RTSP request with a 470 or 407 response 6360 code. The 407 response code MAY be used when the proxy requires 6361 both user and connection authorization from user or client. In 6362 this message the proxy SHALL include a Connection-Credentials 6363 header, see Section 16.12 with the next hop's identity and 6364 certificate. 6366 The client MUST upon receiving a 470 or 407 response with Connection- 6367 Credentials header take the decision on whether to accept the 6368 certificate or not (if it cannot do so, the user SHOULD be 6369 consulted). If the certificate is accepted, the client has to again 6370 send the RTSP request. In that request the client has to include the 6371 Accept-Credentials header including the hash over the DER encoded 6372 certificate for all trusted proxies in the chain. 6374 Example: 6376 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 6377 CSeq: 2 6378 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 6379 "192.0.2.5:4589" 6380 Accept-Ranges: NPT, SMPTE, UTC 6381 Accept-Credentials: User 6382 P->C: RTSP/2.0 470 Connection Authorization Required 6383 CSeq: 2 6384 Connection-Credentials: "rtsps://test.example.org"; 6385 MIIDNTCCAp... 6387 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 6388 CSeq: 2 6389 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 6390 "192.0.2.5:4589" 6391 Accept-Credentials: User "rtsps://test.example.org";sha-256; 6392 dPYD7txpoGTbAqZZQJ+vaeOkyH4= 6393 Accept-Ranges: NPT, SMPTE, UTC 6394 P->S: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 6395 CSeq: 2 6396 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 6397 "192.0.2.5:4589" 6398 Via: RTSP/2.0 proxy.example.org 6399 Accept-Credentials: User "rtsps://test.example.org";sha-256; 6400 dPYD7txpoGTbAqZZQJ+vaeOkyH4= 6401 Accept-Ranges: NPT, SMPTE, UTC 6403 One implication of this process is that the connection for secured 6404 RTSP messages may take significantly more round-trip times for the 6405 first message. An complete extra message exchange between the proxy 6406 connecting to the next hop and the client results because of the 6407 process for approval for each hop. However after the first message 6408 exchange the remaining message should not be delayed, if each message 6409 contains the chain of proxies that the requestor accepts. The 6410 procedure of including the credentials in each request rather than 6411 building state in each proxy, avoids the need for revocation 6412 procedures. 6414 20. Syntax 6416 The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF) 6417 as defined in RFC 5234 [RFC5234]. It uses the basic definitions 6418 present in RFC 5234. 6420 Please note that ABNF strings, e.g. "Accept", are case insensitive 6421 as specified in section 2.3 of RFC 5234. 6423 20.1. Base Syntax 6425 RTSP header field values can be folded onto multiple lines if the 6426 continuation line begins with a space or horizontal tab. All linear 6427 white space, including folding, has the same semantics as SP. A 6428 recipient MAY replace any linear white space with a single SP before 6429 interpreting the field value or forwarding the message downstream. 6430 This is intended to behave exactly as HTTP/1.1 as described in RFC 6431 2616 [RFC2616]. The SWS construct is used when linear white space is 6432 optional, generally between tokens and separators. 6434 To separate the header name from the rest of value, a colon is used, 6435 which, by the above rule, allows whitespace before, but no line 6436 break, and whitespace after, including a linebreak. The HCOLON 6437 defines this construct. 6439 OCTET = %x00-FF ; any 8-bit sequence of data 6440 CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127) 6441 UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z" 6442 LOALPHA = %x61-7A ;any US-ASCII lowercase letter "a".."z" 6443 ALPHA = UPALPHA / LOALPHA 6444 DIGIT = %x30-39 ; any US-ASCII digit "0".."9" 6445 CTL = %x00-1F / %x7F ; any US-ASCII control character 6446 ; (octets 0 - 31) and DEL (127) 6447 CR = %x0D ; US-ASCII CR, carriage return (13 6448 LF = %x0A ; US-ASCII LF, linefeed (10) 6449 SP = %x20 ; US-ASCII SP, space (32) 6450 HT = %x09 ; US-ASCII HT, horizontal-tab (9) 6451 DQ = %x22 ; US-ASCII double-quote mark (34) 6452 BACKSLASH = %x5C ; US-ASCII backslash (92) 6453 CRLF = CR LF 6454 LWS = [CRLF] 1*( SP / HT ) 6455 SWS = [LWS] ; sep whitespace 6456 HCOLON = *( SP / HT ) ":" SWS 6457 TEXT = %x20-7E / %x80-FF ; any OCTET except CTLs 6458 tspecials = "(" / ")" / "<" / ">" / "@" 6459 / "," / ";" / ":" / BACKSLASH / DQ 6460 / "/" / "[" / "]" / "?" / "=" 6461 / "{" / "}" / SP / HT 6462 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 6463 / %x41-5A / %x5E-7A / %x7C / %x7E) 6464 ; 1* 6465 quoted-string = ( DQ *qdtext DQ ) 6466 qdtext = %x20-21 / %x23-7E / %x80-FF ; any TEXT except <"> 6467 quoted-pair = BACKSLASH CHAR 6468 ctext = %x20-27 / %x2A-7E 6469 / %x80-FF ; any OCTET except CTLs, "(" and ")" 6470 generic-param = token [ EQUAL gen-value ] 6471 gen-value = token / host / quoted-string 6473 safe = "$" / "-" / "_" / "." / "+" 6474 extra = "!" / "*" / "'" / "(" / ")" / "," 6475 rtsp-extra = "!" / "*" / "'" / "(" / ")" 6477 HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 6478 / "a" / "b" / "c" / "d" / "e" / "f" 6479 LHEX = DIGIT / %x61-66 ;lowercase a-f 6480 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" 6482 unreserved = ALPHA / DIGIT / safe / extra 6483 rtsp-unreserved = ALPHA / DIGIT / safe / rtsp-extra 6485 base64 = *base64-unit [base64-pad] 6486 base64-unit = 4base64-char 6487 base64-pad = (2base64-char "==") / (3base64-char "=") 6488 base64-char = ALPHA / DIGIT / "+" / "/" 6489 SLASH = SWS "/" SWS ; slash 6490 EQUAL = SWS "=" SWS ; equal 6491 LPAREN = SWS "(" SWS ; left parenthesis 6492 RPAREN = SWS ")" SWS ; right parenthesis 6493 COMMA = SWS "," SWS ; comma 6494 SEMI = SWS ";" SWS ; semicolon 6495 COLON = SWS ":" SWS ; colon 6496 LDQUOT = SWS DQ ; open double quotation mark 6497 RDQUOT = DQ SWS ; close double quotation mark 6498 RAQUOT = ">" SWS ; right angle quote 6499 LAQUOT = SWS "<" ; left angle quote 6501 TEXT-UTF8char = %x21-7E / UTF8-NONASCII 6502 UTF8-NONASCII = %xC0-DF 1UTF8-CONT 6503 / %xE0-EF 2UTF8-CONT 6504 / %xF0-F7 3UTF8-CONT 6505 / %xF8-FB 4UTF8-CONT 6506 / %xFC-FD 5UTF8-CONT 6507 UTF8-CONT = %x80-BF 6509 FLOAT = ["-"] 1*39DIGIT ["." 1*46DIGIT] 6510 POS-FLOAT = 1*39DIGIT ["." 1*46DIGIT] 6512 20.2. RTSP Protocol Definition 6514 20.2.1. Generic Protocol elements 6515 RTSP-IRI = schemes ":" IRI-rest 6516 IRI-rest = ihier-part [ "?" iquery ] [ "#" ifragment ] 6517 ihier-part = "//" iauthority ipath-abempty 6518 RTSP-IRI-ref = RTSP-IRI / irelative-ref 6519 irelative-ref = irelative-part [ "?" iquery ] [ "#" ifragment ] 6520 irelative-part = "//" iauthority ipath-abempty 6521 / ipath-absolute 6522 / ipath-noscheme 6523 / ipath-empty 6525 iauthority = < As defined in RFC 3987> 6526 ipath = ipath-abempty ; begins with "/" or is empty 6527 / ipath-absolute ; begins with "/" but not "//" 6528 / ipath-noscheme ; begins with a non-colon segment 6529 / ipath-rootless ; begins with a segment 6530 / ipath-empty ; zero characters 6532 ipath-abempty = *( "/" isegment ) 6533 ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ] 6534 ipath-noscheme = isegment-nz-nc *( "/" isegment ) 6535 ipath-rootless = isegment-nz *( "/" isegment ) 6536 ipath-empty = 0 6538 isegment = *ipchar [";" *ipchar] 6539 isegment-nz = 1*ipchar [";" *ipchar] 6540 / ";" *ipchar 6541 isegment-nz-nc = (1*ipchar-nc [";" *ipchar-nc]) 6542 / ";" *ipchar-nc 6543 ; non-zero-length segment without any colon ":" 6545 ipchar = iunreserved / pct-encoded / sub-delims / ":" / "@" 6546 ipchar-nc = iunreserved / pct-encoded / sub-delims / "@" 6548 iquery = < As defined in RFC 3987> 6549 ifragment = < As defined in RFC 3987> 6550 iunreserved = < As defined in RFC 3987> 6551 pct-encoded = < As defined in RFC 3987> 6552 RTSP-URI = schemes ":" URI-rest 6553 RTSP-URI-Ref = RTSP-URI / RTSP-Relative 6554 schemes = "rtsp" / "rtsps" / scheme 6555 scheme = < As defined in RFC 3986> 6556 URI-rest = hier-part [ "?" query ] 6557 hier-part = "//" authority path-abempty 6559 RTSP-Relative = relative-part [ "?" query ] 6560 relative-part = "//" authority path-abempty 6561 / path-absolute 6562 / path-noscheme 6563 / path-empty 6565 authority = < As defined in RFC 3986> 6566 query = < As defined in RFC 3986> 6568 path = path-abempty ; begins with "/" or is empty 6569 / path-absolute ; begins with "/" but not "//" 6570 / path-noscheme ; begins with a non-colon segment 6571 / path-rootless ; begins with a segment 6572 / path-empty ; zero characters 6574 path-abempty = *( "/" segment ) 6575 path-absolute = "/" [ segment-nz *( "/" segment ) ] 6576 path-noscheme = segment-nz-nc *( "/" segment ) 6577 path-rootless = segment-nz *( "/" segment ) 6578 path-empty = 0 6580 segment = *pchar [";" *pchar] 6581 segment-nz = ( 1*pchar [";" *pchar]) / (";" *pchar) 6582 segment-nz-nc = ( 1*pchar-nc [";" *pchar-nc]) / (";" *pchar-nc) 6583 ; non-zero-length segment without any colon ":" 6585 pchar = unreserved / pct-encoded / sub-delims / ":" / "@" 6586 pchar-nc = unreserved / pct-encoded / sub-delims / "@" 6588 sub-delims = "!" / "$" / "&" / "'" / "(" / ")" 6589 / "*" / "+" / "," / "=" 6591 smpte-range = smpte-type "=" smpte-range-spec 6592 ; See section 3.4 6593 smpte-range-spec = ( smpte-time "-" [ smpte-time ] ) 6594 / ( "-" smpte-time ) 6595 smpte-type = "smpte" / "smpte-30-drop" 6596 / "smpte-25" / smpte-type-extension 6597 ; other timecodes may be added 6598 smpte-type-extension = token 6599 smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT 6600 [ ":" 1*2DIGIT [ "." 1*2DIGIT ] ] 6602 npt-range = "npt=" npt-range-spec 6603 npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time ) 6604 npt-time = "now" / npt-sec / npt-hhmmss 6605 npt-sec = 1*DIGIT [ "." *DIGIT ] 6606 npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] 6607 npt-hh = 1*DIGIT ; any positive number 6608 npt-mm = 1*2DIGIT ; 0-59 6609 npt-ss = 1*2DIGIT ; 0-59 6611 utc-range = "clock=" utc-range-spec 6612 utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time ) 6613 utc-time = utc-date "T" utc-clock "Z" 6614 utc-date = 8DIGIT 6615 utc-clock = 6DIGIT [ "." fraction ] 6616 fraction = 1*DIGIT 6618 feature-tag = token 6620 session-id = 1*256( ALPHA / DIGIT / safe ) 6622 extension-header = header-name HCOLON header-value 6623 header-name = token 6624 header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) 6626 20.2.2. Message Syntax 6627 RTSP-message = Request / Response ; RTSP/2.0 messages 6629 Request = Request-Line 6630 *((general-header 6631 / request-header 6632 / entity-header) CRLF) 6633 CRLF 6634 [ message-body ] 6636 Response = Status-Line 6637 *((general-header 6638 / response-header 6639 / entity-header) CRLF) 6640 CRLF 6641 [ message-body ] 6643 Request-Line = Method SP Request-URI SP RTSP-Version CRLF 6645 Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF 6646 Method = "DESCRIBE" 6647 / "GET_PARAMETER" 6648 / "OPTIONS" 6649 / "PAUSE" 6650 / "PLAY" 6651 / "PLAY_NOTIFY" 6652 / "REDIRECT" 6653 / "SETUP" 6654 / "SET_PARAMETER" 6655 / "TEARDOWN" 6656 / extension-method 6658 extension-method = token 6660 Request-URI = "*" / RTSP-URI 6661 RTSP-Version = "RTSP/" 1*DIGIT "." 1*DIGIT 6663 message-body = 1*OCTET 6665 Status-Code = "100" ; Continue 6666 / "200" ; OK 6667 / "300" ; Multiple Choices 6668 / "301" ; Moved Permanently 6669 / "302" ; Found 6670 / "303" ; See Other 6671 / "304" ; Not Modified 6672 / "305" ; Use Proxy 6673 / "400" ; Bad Request 6674 / "401" ; Unauthorized 6675 / "402" ; Payment Required 6676 / "403" ; Forbidden 6677 / "404" ; Not Found 6678 / "405" ; Method Not Allowed 6679 / "406" ; Not Acceptable 6680 / "407" ; Proxy Authentication Required 6681 / "408" ; Request Time-out 6682 / "410" ; Gone 6683 / "411" ; Length Required 6684 / "412" ; Precondition Failed 6685 / "413" ; Request Entity Too Large 6686 / "414" ; Request-URI Too Large 6687 / "415" ; Unsupported Media Type 6688 / "451" ; Parameter Not Understood 6689 / "452" ; reserved 6690 / "453" ; Not Enough Bandwidth 6691 / "454" ; Session Not Found 6692 / "455" ; Method Not Valid in This State 6693 / "456" ; Header Field Not Valid for Resource 6694 / "457" ; Invalid Range 6695 / "458" ; Parameter Is Read-Only 6696 / "459" ; Aggregate operation not allowed 6697 / "460" ; Only aggregate operation allowed 6698 / "461" ; Unsupported Transport 6699 / "462" ; Destination Unreachable 6700 / "463" ; Destination Prohibited 6701 / "464" ; Data Transport Not Ready Yet 6702 / "470" ; Connection Authorization Required 6703 / "471" ; Connection Credentials not accepted 6704 / "472" ; Failure to establish secure connection 6705 / "500" ; Internal Server Error 6706 / "501" ; Not Implemented 6707 / "502" ; Bad Gateway 6708 / "503" ; Service Unavailable 6709 / "504" ; Gateway Time-out 6710 / "505" ; RTSP Version not supported 6711 / "551" ; Option not supported 6712 / extension-code 6714 extension-code = 3DIGIT 6716 Reason-Phrase = *TEXT 6717 general-header = Cache-Control 6718 / Connection 6719 / CSeq 6720 / Date 6721 / Media-Properties 6722 / Media-Range 6723 / Pipelined-Requests 6724 / Proxy-Supported 6725 / Seek-Style 6726 / Supported 6727 / Timestamp 6728 / Via 6729 / extension-header 6731 request-header = Accept 6732 / Accept-Credentials 6733 / Accept-Encoding 6734 / Accept-Language 6735 / Authorization 6736 / Bandwidth 6737 / Blocksize 6738 / From 6739 / If-Match 6740 / If-Modified-Since 6741 / If-None-Match 6742 / Notify-Reason 6743 / Proxy-Require 6744 / Range 6745 / Referer 6746 / Request-Status 6747 / Require 6748 / Scale 6749 / Session 6750 / Speed 6751 / Supported 6752 / Transport 6753 / User-Agent 6754 / extension-header 6756 response-header = Accept-Credentials 6757 / Accept-Ranges 6758 / Connection-Credentials 6759 / ETag 6760 / Location 6761 / Proxy-Authenticate 6762 / Public 6763 / Range 6764 / Retry-After 6765 / RTP-Info 6766 / Scale 6767 / Session 6768 / Server 6769 / Speed 6770 / Transport 6771 / Unsupported 6772 / Vary 6773 / WWW-Authenticate 6774 / extension-header 6776 entity-header = Allow 6777 / Content-Base 6778 / Content-Encoding 6779 / Content-Language 6780 / Content-Length 6781 / Content-Location 6782 / Content-Type 6783 / Expires 6784 / Last-Modified 6785 / extension-header 6787 20.2.3. Header Syntax 6789 All header syntaxes not defined in this section are defined in 6790 section 14 of the HTTP 1.1 specification [RFC2616]. 6792 Accept = "Accept" HCOLON 6793 [ accept-range *(COMMA accept-range) ] 6794 accept-range = media-range *(SEMI accept-param) 6795 media-range = ( "*/*" 6796 / ( m-type SLASH "*" ) 6797 / ( m-type SLASH m-subtype ) 6798 ) *( SEMI m-parameter ) 6799 accept-param = ("q" EQUAL qvalue) / generic-param 6800 qvalue = ( "0" [ "." *3DIGIT ] ) 6801 / ( "1" [ "." *3("0") ] ) 6802 Accept-Credentials = "Accept-Credentials" HCOLON cred-decision 6803 cred-decision = ("User" [LWS cred-info]) 6804 / "Proxy" 6805 / "Any" 6806 / (token [LWS 1*TEXT]) ; For future extensions 6807 cred-info = cred-info-data *(COMMA cred-info-data) 6809 cred-info-data = DQ RTSP-URI DQ SEMI hash-alg SEMI base64 6810 hash-alg = "sha-256" / extension-alg 6811 extension-alg = token 6812 Accept-Encoding = "Accept-Encoding" HCOLON 6813 [ encoding *(COMMA encoding) ] 6814 encoding = codings *(SEMI accept-param) 6815 codings = content-coding / "*" 6816 content-coding = token 6817 Accept-Language = "Accept-Language" HCOLON 6818 [ language *(COMMA language) ] 6819 language = language-range *(SEMI accept-param) 6820 language-range = (1*8ALPHA *( "-" 1*8ALPHA)) / "*" 6821 Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges 6822 acceptable-ranges = (range-unit *(COMMA range-unit)) 6823 / "none" 6824 range-unit = "NPT" / "SMPTE" / "UTC" / extension-format 6825 extension-format = token 6826 Allow = "Allow" HCOLON [Method *(COMMA Method)] 6827 Authorization = "Authorization" HCOLON credentials 6828 credentials = ("Digest" LWS digest-response) 6829 / other-response 6830 digest-response = dig-resp *(COMMA dig-resp) 6831 dig-resp = username / realm / nonce / digest-uri 6832 / dresponse / algorithm / cnonce 6833 / opaque / message-qop 6834 / nonce-count / auth-param 6835 username = "username" EQUAL username-value 6836 username-value = quoted-string 6837 digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT 6838 digest-uri-value = Request-URI 6839 ; by HTTP/1.1 6840 message-qop = "qop" EQUAL qop-value 6841 cnonce = "cnonce" EQUAL cnonce-value 6842 cnonce-value = nonce-value 6843 nonce-count = "nc" EQUAL nc-value 6844 nc-value = 8LHEX 6845 dresponse = "response" EQUAL request-digest 6846 request-digest = LDQUOT 32LHEX RDQUOT 6847 auth-param = auth-param-name EQUAL 6848 ( token / quoted-string ) 6849 auth-param-name = token 6850 other-response = auth-scheme LWS auth-param 6851 *(COMMA auth-param) 6853 auth-scheme = token 6855 Bandwidth = "Bandwidth" HCOLON 1*DIGIT 6857 Blocksize = "Blocksize" HCOLON 1*DIGIT 6859 Cache-Control = "Cache-Control" HCOLON cache-directive 6860 *(COMMA cache-directive) 6861 cache-directive = cache-rqst-directive 6862 / cache-rspns-directive 6864 cache-rqst-directive = "no-cache" 6865 / "max-stale" [EQUAL delta-seconds] 6866 / "min-fresh" EQUAL delta-seconds 6867 / "only-if-cached" 6868 / cache-extension 6870 cache-rspns-directive = "public" 6871 / "private" 6872 / "no-cache" 6873 / "no-transform" 6874 / "must-revalidate" 6875 / "proxy-revalidate" 6876 / "max-age" EQUAL delta-seconds 6877 / cache-extension 6879 cache-extension = token [EQUAL (token / quoted-string)] 6880 delta-seconds = 1*DIGIT 6882 Connection-Credentials = "Connection-Credentials" HCOLON cred-chain 6883 cred-chain = DQ RTSP-URI DQ SEMI base64 6885 Connection = "Connection" HCOLON (connection-token) 6886 *(COMMA connection-token) 6887 connection-token = token 6889 Content-Base = "Content-Base" HCOLON RTSP-URI-Ref 6890 Content-Encoding = "Content-Encoding" HCOLON 6891 content-coding *(COMMA content-coding) 6892 Content-Language = "Content-Language" HCOLON 6893 language-tag *(COMMA language-tag) 6894 language-tag = primary-tag *( "-" subtag ) 6895 primary-tag = 1*8ALPHA 6896 subtag = 1*8ALPHA 6897 Content-Length = "Content-Length" HCOLON 1*DIGIT 6898 Content-Location = "Content-Location" HCOLON RTSP-URI-Ref 6899 Content-Type = ( "Content-Type" / "c" ) HCOLON media-type 6900 media-type = m-type SLASH m-subtype *(SEMI m-parameter) 6901 m-type = discrete-type / composite-type 6902 discrete-type = "text" / "image" / "audio" / "video" 6903 / "application" / extension-token 6904 composite-type = "message" / "multipart" / extension-token 6905 extension-token = ietf-token / x-token 6906 ietf-token = token 6907 x-token = "x-" token 6908 m-subtype = extension-token / iana-token 6909 iana-token = token 6910 m-parameter = m-attribute EQUAL m-value 6911 m-attribute = token 6912 m-value = token / quoted-string 6914 CSeq = "CSeq" HCOLON cseq-nr 6915 cseq-nr = 1*9DIGIT 6916 Date = "Date" HCOLON RTSP-date 6917 RTSP-date = rfc1123-date ; HTTP-date 6918 rfc1123-date = wkday "," SP date1 SP time SP "GMT" 6919 date1 = 2DIGIT SP month SP 4DIGIT 6920 ; day month year (e.g., 02 Jun 1982) 6921 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 6922 ; 00:00:00 - 23:59:59 6923 wkday = "Mon" / "Tue" / "Wed" 6924 / "Thu" / "Fri" / "Sat" / "Sun" 6925 month = "Jan" / "Feb" / "Mar" / "Apr" 6926 / "May" / "Jun" / "Jul" / "Aug" 6927 / "Sep" / "Oct" / "Nov" / "Dec" 6929 ETag = "ETag" HCOLON entity-tag 6930 Expires = "Expires" HCOLON RTSP-date 6931 From = "From" HCOLON from-spec 6932 from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) 6933 name-addr = [ display-name ] LAQUOT addr-spec RAQUOT 6934 addr-spec = RTSP-URI / absolute-URI 6935 absolute-URI = < As defined in RFC 3986> 6936 display-name = *(token LWS) / quoted-string 6937 from-param = tag-param / generic-param 6938 tag-param = "tag" EQUAL token 6939 If-Match = "If-Match" HCOLON ("*" / entity-tag-list) 6940 entity-tag-list = entity-tag *(COMMA entity-tag) 6941 entity-tag = [ weak ] opaque-tag 6942 weak = "W/" 6943 opaque-tag = quoted-string 6944 If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date 6945 If-None-Match = "If-None-Match" HCOLON ("*" / entity-tag-list) 6946 Last-Modified = "Last-Modified" HCOLON RTSP-date 6947 Location = "Location" HCOLON RTSP-URI 6948 Media-Properties = "Media-Properties" HCOLON media-prop-list 6949 media-prop-list = media-prop-value *(COMMA media-prop-value) 6950 media-prop-value = ("Random-Access" [EQUAL POS-FLOAT]) 6951 / "Begining-Only" 6952 / "No-Seeking" 6953 / "Unmutable" 6954 / "Dynamic" 6955 / "Time-Progressing" 6956 / "Unlimited" 6957 / ("Time-Limited" EQUAL utc-range-spec) 6958 / ("Time-Duration" EQUAL POS-FLOAT) 6959 / media-prop-ext 6960 media-prop-ext = token [EQUAL (1*rtsp-unreserved / quoted-string)] 6961 Media-Range = "Media-Range" HCOLON [ranges-list] 6962 Notify-Reason = "Notify-Reason" HCOLON Notify-Reas-val 6963 Notify-Reas-val = "end-of-stream" 6964 / "media-properties-update" 6965 / "scale-change" 6966 / Notify-Reason-extension 6967 Notify-Reason-extension = token 6968 Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id 6969 startup-id = 1*8DIGIT 6971 Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge-list 6972 challenge-list = challenge *(COMMA challenge) 6973 challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) 6974 / other-challenge 6975 other-challenge = auth-scheme LWS auth-param 6976 *(COMMA auth-param) 6977 digest-cln = realm / domain / nonce 6978 / opaque / stale / algorithm 6979 / qop-options / auth-param 6980 realm = "realm" EQUAL realm-value 6981 realm-value = quoted-string 6982 domain = "domain" EQUAL LDQUOT URI 6983 *(1*SP URI) RDQUOT 6984 URI = RTSP-URI / RTSP-URI-Ref 6985 nonce = "nonce" EQUAL nonce-value 6986 nonce-value = quoted-string 6987 opaque = "opaque" EQUAL quoted-string 6988 stale = "stale" EQUAL ( "true" / "false" ) 6989 algorithm = "algorithm" EQUAL ("MD5" / "MD5-sess" / token) 6990 qop-options = "qop" EQUAL LDQUOT qop-value 6991 *("," qop-value) RDQUOT 6992 qop-value = "auth" / "auth-int" / token 6993 Proxy-Require = "Proxy-Require" HCOLON feature-tag 6994 *(COMMA feature-tag) 6996 Proxy-Supported = "Proxy-Supported" HCOLON feature-tag 6997 *(COMMA feature-tag) 6999 Public = "Public" HCOLON Method *(COMMA Method) 7001 Range = "Range" HCOLON ranges-list [exec-time] 7002 ranges-list = ranges-spec *(COMMA ranges-spec) 7003 exec-time = SEMI "time" EQUAL utc-time 7004 ranges-spec = npt-range / utc-range / smpte-range 7005 / range-ext 7006 range-ext = extension-format "=" range-value 7007 range-value = 1*(rtsp-unreserved / quoted-string / ":" ) 7009 Referer = "Referer" HCOLON RTSP-URI-Ref 7010 Request-Status = "Request-Status" HCOLON status-info 7011 status-info = cseq-info LWS status-info LWS reason-info 7012 cseq-info = "cseq" EQUAL cseq-nr 7013 status-info = "status" EQUAL Status-Code 7014 reason-info = "reason" EQUAL DQ Reason-Phrase DQ 7015 Require = "Require" HCOLON feature-tag-list 7016 feature-tag-list = feature-tag *(COMMA feature-tag) 7017 RTP-Info = "RTP-Info" HCOLON rtsp-info-spec 7018 *(COMMA rtsp-info-spec) 7019 rtsp-info-spec = stream-url 1*ssrc-parameter 7020 stream-url = "url" EQUAL DQ RTSP-URI-Ref DQ 7021 ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON 7022 ri-parameter *(SEMI ri-parameter) 7023 ri-parameter = ("seq" EQUAL 1*DIGIT) 7024 / ("rtptime" EQUAL 1*DIGIT) 7025 / generic-param 7027 Retry-After = "Retry-After" HCOLON delta-seconds 7028 [ comment ] *( SEMI retry-param ) 7029 retry-param = ("duration" EQUAL delta-seconds) 7030 / generic-param 7032 Scale = "Scale" HCOLON ["-"] 1*DIGIT [ "." *DIGIT ] 7033 Seek-Style = "Seek-Style" HCOLON Seek-S-values 7034 Seek-S-values = "RAP" 7035 / "First-Prior" 7036 / "Next" 7037 / Seek-S-value-ext 7038 Seek-S-value-ext = token 7039 Speed = "Speed" HCOLON 1*DIGIT [ "." *DIGIT ] 7041 Server = "Server" HCOLON ( product / comment ) 7042 *(LWS (product / comment)) 7043 product = token [SLASH product-version] 7044 product-version = token 7045 comment = LPAREN *( ctext / quoted-pair) RPAREN 7047 Session = "Session" HCOLON session-id 7048 [ SEMI "timeout" EQUAL delta-seconds ] 7050 Supported = "Supported" HCOLON [feature-tag-list] 7052 Timestamp = "Timestamp" HCOLON timestamp-value LWS [delay] 7053 timestamp-value = *DIGIT [ "." *DIGIT ] 7054 delay = *DIGIT [ "." *DIGIT ] 7056 Transport = "Transport" HCOLON transport-spec 7057 *(COMMA transport-spec) 7058 transport-spec = transport-id *tr-parameter 7059 transport-id = trans-id-rtp / other-trans 7060 trans-id-rtp = "RTP/" profile ["/" lower-transport] 7061 ; no LWS is allowed inside transport-id 7062 other-trans = token *("/" token) 7064 profile = "AVP" / "SAVP" / "AVPF" / token 7065 lower-transport = "TCP" / "UDP" / token 7066 tr-parameter = (SEMI ( "unicast" / "multicast" )) 7067 / (SEMI "interleaved" EQUAL channel [ "-" channel ]) 7068 / (SEMI "ttl" EQUAL ttl) 7069 / (SEMI "layers" EQUAL 1*DIGIT) 7070 / (SEMI "ssrc" EQUAL ssrc *(SLASH ssrc)) 7071 / (SEMI "mode" EQUAL mode-spec) 7072 / (SEMI "dest_addr" EQUAL addr-list) 7073 / (SEMI "src_addr" EQUAL addr-list) 7074 / (SEMI trn-param-ext) 7075 / (SEMI "setup" EQUAL contrans-setup) 7076 / (SEMI "connection" EQUAL contrans-con) 7077 contrans-setup = "active" / "passive" / "actpass" 7078 contrans-con = "new" / "existing" 7079 trn-param-ext = par-name [EQUAL trn-par-value] 7080 par-name = token 7081 trn-par-value = *(rtsp-unreserved / quoted-string) 7082 ttl = 1*3DIGIT ; 0 to 255 7083 ssrc = 8HEX 7084 channel = 1*3DIGIT 7085 mode-spec = ( DQ mode *(COMMA mode) DQ ) 7086 mode = "PLAY" / token 7087 addr-list = quoted-addr *(SLASH quoted-addr) 7088 quoted-addr = DQ (host-port / extension-addr) DQ 7089 host-port = host [":" port] 7090 / ":" port 7091 extension-addr = 1*qdtext 7092 host = < As defined in RFC 3986> 7093 port = < As defined in RFC 3986> 7094 Unsupported = "Unsupported" HCOLON feature-tag-list 7096 User-Agent = "User-Agent" HCOLON ( product / comment ) 7097 0*(LWS (product / comment)) 7099 Vary = "Vary" HCOLON ( "*" / field-name-list) 7100 field-name-list = field-name *(COMMA field-name) 7101 field-name = token 7102 Via = "Via" HCOLON via-parm *(COMMA via-parm) 7103 via-parm = sent-protocol LWS sent-by *( SEMI via-params ) 7104 via-params = via-ttl / via-maddr 7105 / via-received / via-branch 7106 / via-extension 7107 via-ttl = "ttl" EQUAL ttl 7108 via-maddr = "maddr" EQUAL host 7109 via-received = "received" EQUAL (IPv4address / IPv6address) 7110 IPv4address = < As defined in RFC 3986> 7111 IPv6address = < As defined in RFC 3986> 7112 via-branch = "branch" EQUAL token 7113 via-extension = generic-param 7114 sent-protocol = protocol-name SLASH protocol-version 7115 SLASH transport-prot 7116 protocol-name = "RTSP" / token 7117 protocol-version = token 7118 transport-prot = "UDP" / "TCP" / "TLS" / other-transport 7119 other-transport = token 7120 sent-by = host [ COLON port ] 7122 WWW-Authenticate = "WWW-Authenticate" HCOLON challenge-list 7124 20.3. SDP extension Syntax 7126 This section defines in ABNF the SDP extensions defined for RTSP. 7127 See Appendix D for the definition of the extensions in text. 7129 control-attribute = "a=control:" *SP RTSP-URI 7131 a-range-def = "a=range:" ranges-spec CRLF 7133 a-etag-def = "a=etag:" entity-tag CRLF 7135 21. Security Considerations 7137 Because of the similarity in syntax and usage between RTSP servers 7138 and HTTP servers, the security considerations outlined in [H15] 7139 apply. Specifically, please note the following: 7141 Abuse of Server Log Information: RTSP and HTTP servers will 7142 presumably have similar logging mechanisms, and thus should be 7143 equally guarded in protecting the contents of those logs, thus 7144 protecting the privacy of the users of the servers. See 7145 [H15.1.1] for HTTP server recommendations regarding server 7146 logs. 7148 Transfer of Sensitive Information: There is no reason to believe 7149 that information transferred or controlled via RTSP may be any 7150 less sensitive than that normally transmitted via HTTP. 7151 Therefore, all of the precautions regarding the protection of 7152 data privacy and user privacy apply to implementors of RTSP 7153 clients, servers, and proxies. See [H15.1.2] for further 7154 details. 7156 Attacks Based On File and Path Names: Though RTSP URIs are opaque 7157 handles that do not necessarily have file system semantics, it 7158 is anticipated that many implementations will translate 7159 portions of the Request-URIs directly to file system calls. In 7160 such cases, file systems SHOULD follow the precautions outlined 7161 in [H15.5], such as checking for ".." in path components. 7163 Personal Information: RTSP clients are often privy to the same 7164 information that HTTP clients are (user name, location, etc.) 7165 and thus should be equally sensitive. See [H15.1] for further 7166 recommendations. 7168 Privacy Issues Connected to Accept Headers: Since may of the same 7169 "Accept" headers exist in RTSP as in HTTP, the same caveats 7170 outlined in [H15.1.4] with regards to their use should be 7171 followed. 7173 DNS Spoofing: Presumably, given the longer connection times 7174 typically associated to RTSP sessions relative to HTTP 7175 sessions, RTSP client DNS optimizations should be less 7176 prevalent. Nonetheless, the recommendations provided in 7177 [H15.3] are still relevant to any implementation which attempts 7178 to rely on a DNS-to-IP mapping to hold beyond a single use of 7179 the mapping. 7181 Location Headers and Spoofing: If a single server supports multiple 7182 organizations that do not trust each another, then it needs to 7183 check the values of Location and Content-Location header fields 7184 in responses that are generated under control of said 7185 organizations to make sure that they do not attempt to 7186 invalidate resources over which they have no authority. 7187 ([H15.4]) 7189 In addition to the recommendations in the current HTTP specification 7190 (RFC 2616 [RFC2616], as of this writing) and also of the previous 7191 RFC2068 [RFC2068], future HTTP specifications may provide additional 7192 guidance on security issues. 7194 The following are added considerations for RTSP implementations. 7196 Concentrated denial-of-service attack: The protocol offers the 7197 opportunity for a remote-controlled denial-of-service attack. 7198 See Section 21.1. 7200 Session hijacking: Since there is no or little relation between a 7201 transport layer connection and an RTSP session, it is possible 7202 for a malicious client to issue requests with random session 7203 identifiers which would affect unsuspecting clients. The 7204 server SHOULD use a large, random and non-sequential session 7205 identifier to minimize the possibility of this kind of attack. 7206 However, unless the RTSP signalling always are confedentiality 7207 protected, e.g. using TLS, an on-path attacker will be able to 7208 hijack a session. For real session security, client 7209 authentication needs to be performed. 7211 Authentication: Servers SHOULD implement both basic and digest 7212 [RFC2617] authentication. In environments requiring tighter 7213 security for the control messages, the transport layer 7214 mechanism TLS [RFC5246] SHOULD be used. 7216 Stream issues: RTSP only provides for stream control. Stream 7217 delivery issues are not covered in this section, nor in the 7218 rest of this draft. RTSP implementations will most likely rely 7219 on other protocols such as RTP, IP multicast, RSVP and IGMP, 7220 and should address security considerations brought up in those 7221 and other applicable specifications. 7223 Persistently suspicious behavior: RTSP servers SHOULD return error 7224 code 403 (Forbidden) upon receiving a single instance of 7225 behavior which is deemed a security risk. RTSP servers SHOULD 7226 also be aware of attempts to probe the server for weaknesses 7227 and entry points and MAY arbitrarily disconnect and ignore 7228 further requests clients which are deemed to be in violation of 7229 local security policy. 7231 Scope of Multicast: If RTSP is used to control the transmission of 7232 media onto a multicast network it is need to consider the scope 7233 that delivery has. RTSP supports the TTL Transport header 7234 parameter to indicate this scope. However such scope control 7235 is risk as it may be set to large and distribute media beyond 7236 the intended scope. 7238 TLS through proxies: If one uses the possibility to connect TLS in 7239 multiple legs (Section 19.3 one really needs to be aware of the 7240 trust model. That procedure requires full faith and trust in 7241 all proxies that one allows to connect through. They are man 7242 in the middle and has access to all that goes on over the TLS 7243 connection. Thus it is important to consider if that trust 7244 model is acceptable in the actual application. 7246 21.1. Remote denial of Service Attack 7248 The attacker may initiate traffic flows to one or more IP addresses 7249 by specifying them as the destination in SETUP requests. While the 7250 attacker's IP address may be known in this case, this is not always 7251 useful in prevention of more attacks or ascertaining the attackers 7252 identity. Thus, an RTSP server MUST only allow client-specified 7253 destinations for RTSP-initiated traffic flows if the server has 7254 ensured that the specified destination address accepts receiving 7255 media through different security mechanisms. Security mechanism that 7256 are acceptable in an increased generality are; verification of the 7257 client's identity, either against a database of known users using 7258 RTSP authentication mechanisms (preferably digest authentication or 7259 stronger); a list of addresses that accept to be media destinations, 7260 especially considering user identity; and media path based 7261 verification. 7263 The server SHOULD NOT allow the destination field to be set unless a 7264 mechanism exists in the system to authorize the request originator to 7265 direct streams to the recipient. It is preferred that this 7266 authorization be performed by the media recipient (destination) 7267 itself and the credentials passed along to the server. However, in 7268 certain cases, such as when recipient address is a multicast group, 7269 or when the recipient is unable to communicate with the server in an 7270 out-of-band manner, this may not be possible. In these cases server 7271 may chose another method such as a server-resident authorization list 7272 to ensure that the request originator has the proper credentials to 7273 request stream delivery to the recipient. 7275 One solution that performs the necessary verification of acceptance 7276 of media suitable for unicast based delivery is the ICE based NAT 7277 traversal method described in [I-D.ietf-mmusic-rtsp-nat]. By using 7278 random passwords and username the probability of unintended 7279 indication as a valid media destination is very low. If the server 7280 include in its STUN requests a cookie (consisting of random material) 7281 that is the destination echo back the solution is also safe against 7282 having a off-path attacker being able to spoof the STUN checks. 7283 Leaving this solution vulnerable only to on-path attackers that can 7284 see the STUN requests go to the target of attack. 7286 For delivery to multicast addresses there is need for another 7287 solution which is not specified here. 7289 22. IANA Considerations 7291 This section sets up a number of registries for RTSP 2.0 that should 7292 be maintained by IANA. For each registry there is a description on 7293 what it is required to contain, what specification is needed when 7294 adding a entry with IANA, and finally the entries that this document 7295 needs to register. See also the Section 2.3 "Extending RTSP". There 7296 is also an IANA registration of two SDP attributes. 7298 The sections describing how to register an item uses some of the 7299 requirements level described in RFC 5226 [RFC5226], namely "First 7300 Come, First Served", "Expert Review, "Specification Required", and 7301 "Standards Action". 7303 A registration request to IANA MUST contain the following 7304 information: 7306 o A name of the item to register according to the rules specified by 7307 the intended registry. 7309 o Indication of who has change control over the feature (for 7310 example, IETF, ISO, ITU-T, other international standardization 7311 bodies, a consortium, a particular company or group of companies, 7312 or an individual); 7314 o A reference to a further description, if available, for example 7315 (in decreasing order of preference) an RFC, a published standard, 7316 a published paper, a patent filing, a technical report, documented 7317 source code or a computer manual; 7319 o For proprietary features, contact information (postal and email 7320 address); 7322 22.1. Feature-tags 7324 22.1.1. Description 7326 When a client and server try to determine what part and functionality 7327 of the RTSP specification and any future extensions that its counter 7328 part implements there is need for a namespace. This registry 7329 contains named entries representing certain functionality. 7331 The usage of feature-tags is explained in Section 11 and 7332 Section 13.1. 7334 22.1.2. Registering New Feature-tags with IANA 7336 The registering of feature-tags is done on a first come, first served 7337 basis. 7339 The name of the feature MUST follow these rules: The name may be of 7340 any length, but SHOULD be no more than twenty characters long. The 7341 name MUST NOT contain any spaces, or control characters. The 7342 registration SHALL indicate if the feature-tag applies to clients, 7343 servers, or proxies only or any combinations of these. Any 7344 proprietary feature SHALL have as the first part of the name a vendor 7345 tag, which identifies the organization. 7347 22.1.3. Registered entries 7349 The following feature-tags are in this specification defined and 7350 hereby registered. The change control belongs to the IETF. 7352 play.basic: The minimal implementation for playback operations 7353 according to this specification. Applies for both clients, 7354 servers and proxies. 7356 play.scale: Support of scale operations for media playback. Applies 7357 only for servers. 7359 play.speed: Support of the speed functionality for playback. 7360 Applies only for servers. 7362 22.2. RTSP Methods 7364 22.2.1. Description 7366 What a method is, is described in section Section 13. Extending the 7367 protocol with new methods allow for totally new functionality. 7369 22.2.2. Registering New Methods with IANA 7371 A new method MUST be registered through an IETF Standards Action. 7372 The reason is that new methods may radically change the protocols 7373 behavior and purpose. 7375 A specification for a new RTSP method MUST consist of the following 7376 items: 7378 o A method name which follows the ABNF rules for methods. 7380 o A clear specification on what action and response a request with 7381 the method will result in. Which directions the method is used, 7382 C->S or S->C or both. How the use of headers, if any, modifies 7383 the behavior and effect of the method. 7385 o A list or table specifying which of the registered headers that 7386 are allowed to use with the method in request or/and response. 7388 o Describe how the method relates to network proxies. 7390 22.2.3. Registered Entries 7392 This specification, RFCXXXX, registers 10 methods: DESCRIBE, 7393 GET_PARAMETER, OPTIONS, PAUSE, PLAY, PLAY_NOTIFY REDIRECT, SETUP, 7394 SET_PARAMETER, and TEARDOWN. 7396 22.3. RTSP Status Codes 7398 22.3.1. Description 7400 A status code is the three digit numbers used to convey information 7401 in RTSP response messages, seeSection 8. The number space is limited 7402 and care should be taken not to fill the space. 7404 22.3.2. Registering New Status Codes with IANA 7406 A new status code can only be registered by an IETF Standards Action. 7407 A specification for a new status code MUST specify the following: 7409 o The requested number. 7411 o A description what the status code means and the expected behavior 7412 of the sender and receiver of the code. 7414 22.3.3. Registered Entries 7416 RFCXXX, registers the numbered status code defined in the ABNF entry 7417 "Status-Code" except "extension-code" in Section 20.2.2. 7419 22.4. RTSP Headers 7421 22.4.1. Description 7423 By specifying new headers a method(s) can be enhanced in many 7424 different ways. An unknown header will be ignored by the receiving 7425 entity. If the new header is vital for a certain functionality, a 7426 feature-tag for the functionality can be created and demanded to be 7427 used by the counter-part with the inclusion of a Require header 7428 carrying the feature-tag. 7430 22.4.2. Registering New Headers with IANA 7432 Registrations in the registry can be done following the Expert Review 7433 policy. A specification SHOULD be provided, preferable an IETF RFC 7434 or other Standards Developing Organization specification. The 7435 minimal information in a registration request is the header name and 7436 the contact information. 7438 The specification SHOULD contain the following information: 7440 o The name of the header. 7442 o An ABNF specification of the header syntax. 7444 o A list or table specifying when the header may be used, 7445 encompassing all methods, their request or response, the direction 7446 (C->S or S->C). 7448 o How the header is to be handled by proxies. 7450 o A description of the purpose of the header. 7452 22.4.3. Registered entries 7454 All headers specified in Section 16 in RFCXXXX are to be registered. 7456 Furthermore the following RTSP headers defined in other 7457 specifications are registered: 7459 o x-wap-profile defined in [3gpp-26234]. 7461 o x-wap-profile-diff defined in [3gpp-26234]. 7463 o x-wap-profile-warning defined in [3gpp-26234]. 7465 o x-predecbufsize defined in [3gpp-26234]. 7467 o x-initpredecbufperiod defined in [3gpp-26234]. 7469 o x-initpostdecbufperiod defined in [3gpp-26234]. 7471 o 3gpp-videopostdecbufsize defined in [3gpp-26234]. 7473 o 3GPP-Link-Char defined in [3gpp-26234]. 7475 o 3GPP-Adaptation defined in [3gpp-26234]. 7477 o 3GPP-QoE-Metrics defined in [3gpp-26234]. 7479 o 3GPP-QoE-Feedback defined in [3gpp-26234]. 7481 The use of "x-" is NOT RECOMMENDED but the above headers in the 7482 register list was defined prior to the clarification. 7484 22.5. Accept-Credentials 7486 The security framework's TLS connection mechanism has two 7487 registerable entities. 7489 22.5.1. Accept-Credentials policies 7491 In Section 19.3.1 three policies for how to handle certificates. 7492 Further policies may be defined and SHALL be registered with IANA 7493 using the following rules: 7495 o Registering requires an IETF Standards Action 7497 o A registration is required to name a contact person. 7499 o Name of the policy. 7501 o A describing text that explains how the policy works for handling 7502 the certificates. 7504 This specification registers the following values: 7506 Any 7508 Proxy 7510 User 7512 22.5.2. Accept-Credentials hash algorithms 7514 The Accept-Credentials header (See Section 16.2) allows for the usage 7515 of other algorithms for hashing the DER records of accepted entities. 7516 The registration of any future algorithm is expected to be extremely 7517 rare and could also be an interoperability problem. Therefore the 7518 bar for registering new algorithms is placed intentional high. 7520 Any registration of a new hash algorithm SHALL fulfill the following 7521 requirement: 7523 o Follow the IETF Standards Action policy. 7525 o A definition of the algorithm and its identifier meeting the 7526 "token" ABNF requirement. 7528 22.6. Cache-Control Cache Directive Extensions 7530 There exist a number of cache directives which can be sent in the 7531 Cache-Control header. A registry for this cache directives SHALL be 7532 defined with the following rules: 7534 o Registering requires an IETF Standards Action. 7536 o A registration is required to contain a contact person. 7538 o Name of the directive and a definition of the value, if any. 7540 o Specification if it is an request or response directive. 7542 o A describing text that explains how the cache directive is used 7543 for RTSP controlled media streams. 7545 This specification registers the following values: 7547 no-cache: 7549 public: 7551 private: 7553 no-transform: 7555 only-if-cached: 7557 max-stale: 7559 min-fresh: 7561 must-revalidate: 7563 proxy-revalidate: 7565 max-age: 7567 22.7. Media Properties 7568 22.7.1. Description 7570 The media streams being controlled by RTSP can have many different 7571 properties. The media properties required to cover the use cases 7572 that was in mind when writing the specification are defined. 7573 However, it can be expected that further inovation will result in new 7574 use cases or media streams with properties not covered by the one 7575 specified here. Thus new ones can be specified. As new media 7576 properties may need substantial amount of new definitions to 7577 correctly specify behavior for this property the bar is intended to 7578 be high. 7580 22.7.2. Registration Rules 7582 Registering new media property SHALL fulfill the following 7583 requirements 7585 o Follow the Specification Required policy and get the approval of 7586 the designated Expert. 7588 o Have a ABNF definition of the media property value name that meets 7589 "media-prop-ext" definition 7591 o A Contact Person for the Registration 7593 o Description of all changes to the behavior of RTSP protocol as 7594 result of these changes. 7596 22.7.3. Registered Values 7598 This specification registers the 9 values listed in Section 16.29. 7600 22.8. Notify-Reason header 7602 22.8.1. Description 7604 Notify-Reason values are the way to indicate why a notification was 7605 sent. It may also imply that certain headers shall or should be 7606 present required for the client to act upon the information the 7607 notification carries. New notification behaviors do need to be 7608 described to result in interoperable usage, thus specification are 7609 required. 7611 22.8.2. Registration Rules 7613 Registrations for new Notify-Reason value SHALL fulfill the following 7614 requirements 7615 o Follow the Specification Required policy and get the approval of 7616 the designated Expert. 7618 o Have a ABNF definition of the Notify reason value name that meets 7619 "Notify-Reason-extension" definition 7621 o A Contact Person for the Registration 7623 o Description of which headers shall be included in the request and 7624 response, when it should be sent, and any affect it has on the 7625 server client state. 7627 22.8.3. Registered Values 7629 This specification registers 3 values defined in the Notify-Reas-val 7630 ABNFSection 20.2.3: 7632 o end-of-stream 7634 o media-properties-update 7636 o scale-change 7638 22.9. Range header formats 7640 The Range header allows for different range formats. New ones may be 7641 registered, but moderation should be applied as it makes 7642 interoperability more difficult. A registration SHALL fulfill the 7643 following requirements: 7645 o Follow the Specification Required policy. 7647 o A ABNF definition of the range format that fulfils the "range-ext" 7648 definition. 7650 o A Contact person for the registration. 7652 o Rules for how one handles the range when using a negative Scale. 7654 22.10. RTP-Info header parameters 7656 22.10.1. Desctiption 7658 The RTP-Info header (Section 16.43) carries one or more parameter 7659 value pairs with information about a particular point in the RTP 7660 stream. RTP extensions or new usages may need new types of 7661 information. As RTP information that could be needed is likely to be 7662 generic enough and to maximize the interoperability registration 7663 requires specification required. 7665 22.10.2. Registration Rules 7667 Registrations for new Notify-Reason value SHALL fulfill the following 7668 requirements 7670 o Follow the Specification Required policy and get the approval of 7671 the designated Expert. 7673 o Have a ABNF definition that meets the "generic-param" definition 7675 o A Contact Person for the Registration 7677 22.10.3. Registered Values 7679 This specification registers 2 parameter value pairs: 7681 o seq 7683 o rtptime 7685 22.11. Seek-Style Policies 7687 22.11.1. Description 7689 New seek policies may be registered, however a large number of these 7690 will complicate implementation substantially. The impact of unknown 7691 policies is that the server will not honor the unknown and use the 7692 server default policy instead. 7694 22.11.2. Registration Rules 7696 Registrations of new Seek-Style polcies SHALL fulfill the following 7697 requirements 7699 o Follow the Specification Required policy. 7701 o Have a ABNF definition of the Seek-Style policy name that meets 7702 "Seek-S-value-ext" definition 7704 o A Contact Person for the Registration 7706 o Description of which headers shall be included in the request and 7707 response, when it should be sent, and any affect it has on the 7708 server client state. 7710 22.11.3. Registered Values 7712 This specification registers 3 values: 7714 o RAP 7716 o First-Prior 7718 o Next 7720 22.12. Transport Header Registries 7722 The transport header contains a number of parameters which have 7723 possibilities for future extensions. Therefore registries for these 7724 needs to be defined. 7726 22.12.1. Transport Protocol Specification 7728 A registry for the parameter transport-protocol specification SHALL 7729 be defined with the following rules: 7731 o Registering uses the policy of Specification Required. 7733 o A contact person or organization with address and email. 7735 o A value definition that are following the ABNF syntax definition. 7737 o A describing text that explains how the registered value are used 7738 in RTSP. 7740 This specification registers the following values: 7742 RTP/AVP: Use of the RTP[RFC3550] protocol for media transport in 7743 combination with the "RTP profile for audio and video 7744 conferences with minimal control"[RFC3551] over UDP. The usage 7745 is explained in RFC XXXX, appendix Appendix C.1. 7747 RTP/AVP/UDP: the same as RTP/AVP. 7749 RTP/AVPF: Use of the RTP[RFC3550] protocol for media transport in 7750 combination with the "Extended RTP Profile for RTCP-based 7751 Feedback (RTP/AVPF)" [RFC4585] over UDP. The usage is 7752 explained in RFC XXXX, appendix Appendix C.1. 7754 RTP/AVPF/UDP: the same as RTP/AVPF. 7756 RTP/SAVP: Use of the RTP[RFC3550] protocol for media transport in 7757 combination with the "The Secure Real-time Transport Protocol 7758 (SRTP)" [RFC3711] over UDP. The usage is explained in RFC 7759 XXXX, appendix Appendix C.1. 7761 RTP/SAVP/UDP: the same as RTP/SAVP. 7763 RTP/SAVPF: Use of the RTP[RFC3550] protocol for media transport in 7764 combination with the "[RFC5124] over UDP. The usage is 7765 explained in RFC XXXX, appendix Appendix C.1. 7767 RTP/SAVPF/UDP: the same as RTP/SAVPF. 7769 RTP/AVP/TCP: Use of the RTP[RFC3550] protocol for media transport in 7770 combination with the "RTP profile for audio and video 7771 conferences with minimal control"[RFC3551] over TCP. The usage 7772 is explained in RFC XXXX, appendix Appendix C.2.2. 7774 RTP/AVPF/TCP: Use of the RTP[RFC3550] protocol for media transport 7775 in combination with the "Extended RTP Profile for RTCP-based 7776 Feedback (RTP/AVPF)"[RFC4585] over TCP. The usage is explained 7777 in RFC XXXX, appendix Appendix C.2.2. 7779 RTP/SAVP/TCP: Use of the RTP[RFC3550] protocol for media transport 7780 in combination with the "The Secure Real-time Transport 7781 Protocol (SRTP)" [RFC3711] over TCP. The usage is explained in 7782 RFC XXXX, appendix Appendix C.2.2. 7784 RTP/SAVPF/TCP: Use of the RTP[RFC3550] protocol for media transport 7785 in combination with the "[RFC5124] over TCP. The usage is 7786 explained in RFC XXXX, appendix Appendix C.2.2. 7788 22.12.2. Transport modes 7790 A registry for the transport parameter mode SHALL be defined with the 7791 following rules: 7793 o Registering requires an IETF Standards Action. 7795 o A contact person or organization with address and email. 7797 o A value definition that are following the ABNF token definition. 7799 o A describing text that explains how the registered value are used 7800 in RTSP. 7802 This specification registers 1 value: 7804 PLAY: See RFC XXXX. 7806 22.12.3. Transport Parameters 7808 A registry for parameters that may be included in the Transport 7809 header SHALL be defined with the following rules: 7811 o Registering uses the Specification Required policy. 7813 o A value definition that are following the ABNF token definition. 7815 o A describing text that explains how the registered value are used 7816 in RTSP. 7818 This specification registers all the transport parameters defined in 7819 Section 16.51. 7821 22.13. URI Schemes 7823 This specification defines two URI schemes ("rtsp" and "rtsps") and 7824 reserves a third one ("rtspu"). Registrations are following RFC 7825 4395[RFC4395]. 7827 22.13.1. The rtsp URI Scheme 7829 URI scheme name: rtsp 7831 Status: Permanent 7833 URI scheme syntax: See Section 20.2.1 of RFC XXXX. 7835 URI scheme semantics: The rtsp scheme is used to indicate resources 7836 accessible through the usage of the Real-time Streaming 7837 Protocol (RTSP). RTSP allows different operations on the 7838 resource identified by the URI, but the primary purpose is the 7839 streaming delivery of the resource to a client. However the 7840 operations that are currently defined are: Describing the 7841 resource for the purpose of configuring the receiving entity 7842 (DESCRIBE), configuring the delivery method and its addressing 7843 (SETUP), controlling the delivery (PLAY and PAUSE), reading or 7844 setting of resource related parameters (SET_PARAMETER and 7845 GET_PARAMETER, and termination of the session context created 7846 (TEARDOWN). 7848 Encoding considerations: IRIs in this scheme are defined and needs 7849 to be encoded as RTSP URIs when used within the RTSP protocol. 7850 That encoding is done according to RFC 3987. 7852 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 7853 2326), RTSP 2.0 (RFC XXXX) 7855 Interoperability considerations: The change in URI syntax performed 7856 between RTSP 1.0 and 2.0 can create interoperability issues. 7858 Security considerations: All the security threats identified in 7859 Section 7 of RFC 3986 applies also to this scheme. They needs 7860 to be reviewed and considered in any implementation utilizing 7861 this scheme. 7863 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 7865 Author/Change controller: IETF 7867 References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX 7869 22.13.2. The rtsps URI Scheme 7871 URI scheme name: rtsps 7873 Status: Permanent 7875 URI scheme syntax: See Section 20.2.1 of RFC XXXX. 7877 URI scheme semantics: The rtsps scheme is used to indicate resources 7878 accessible through the usage of the Real-time Streaming 7879 Protocol (RTSP) over TLS. RTSP allows different operations on 7880 the resource identified by the URI, but the primary purpose is 7881 the streaming delivery of the resource to a client. However 7882 the operations that are currently defined are: Describing the 7883 resource for the purpose of configuring the receiving entity 7884 (DESCRIBE), configuring the delivery method and its addressing 7885 (SETUP), controlling the delivery (PLAY and PAUSE), reading or 7886 setting of resource related parameters (SET_PARAMETER and 7887 GET_PARAMETER, and termination of the session context created 7888 (TEARDOWN). 7890 Encoding considerations: IRIs in this scheme are defined and needs 7891 to be encoded as RTSP URIs when used within the RTSP protocol. 7892 That encoding is done according to RFC 3987. 7894 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 7895 2326), RTSP 2.0 (RFC XXXX) 7897 Interoperability considerations: The change in URI syntax performed 7898 between RTSP 1.0 and 2.0 can create interoperability issues. 7900 Security considerations: All the security threats identified in 7901 Section 7 of RFC 3986 applies also to this scheme. They needs 7902 to be reviewed and considered in any implementation utilizing 7903 this scheme. 7905 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 7907 Author/Change controller: IETF 7909 References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX 7911 22.13.3. The rtspu URI Scheme 7913 URI scheme name: rtspu 7915 Status: Permanent 7917 URI scheme syntax: See Section 3.2 of RFC 2326. 7919 URI scheme semantics: The rtspu scheme is used to indicate resources 7920 accessible through the usage of the Real-time Streaming 7921 Protocol (RTSP) over unrelaible datagram transport. RTSP 7922 allows different operations on the resource identified by the 7923 URI, but the primary purpose is the streaming delivery of the 7924 resource to a client. However the operations that are 7925 currently defined are: Describing the resource for the purpose 7926 of configuring the receiving entity (DESCRIBE), configuring the 7927 delivery method and its addressing (SETUP), controlling the 7928 delivery (PLAY and PAUSE), reading or setting of resource 7929 related parameters (SET_PARAMETER and GET_PARAMETER, and 7930 termination of the session context created (TEARDOWN). 7932 Encoding considerations: IRIs in this scheme are defined and needs 7933 to be encoded as RTSP URIs when used within the RTSP protocol. 7934 That encoding is done according to RFC 3987. 7936 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 7937 2326) 7939 Interoperability considerations: The definition of the transport 7940 mechanism of RTSP over UDP has interoperability issues. That 7941 makes the usage of this scheme problematic. 7943 Security considerations: All the security threats identified in 7944 Section 7 of RFC 3986 applies also to this scheme. They needs 7945 to be reviewed and considered in any implementation utilizing 7946 this scheme. 7948 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 7950 Author/Change controller: IETF 7952 References: RFC 2326, RFC 3986, RFC 3987 7954 22.14. SDP attributes 7956 This specification defines three SDP [RFC4566] attributes that it is 7957 requested that IANA register. 7959 SDP Attribute ("att-field"): 7961 Attribute name: range 7962 Long form: Media Range Attribute 7963 Type of name: att-field 7964 Type of attribute: Media and session level 7965 Subject to charset: No 7966 Purpose: RFC XXXX 7967 Reference: RFC XXXX 7968 Values: See ABNF definition. 7970 Attribute name: control 7971 Long form: RTSP control URI 7972 Type of name: att-field 7973 Type of attribute: Media and session level 7974 Subject to charset: No 7975 Purpose: RFC XXXX 7976 Reference: RFC XXXX 7977 Values: Absolute or Relative URIs. 7979 Attribute name: etag 7980 Long form: Entity Tag 7981 Type of name: att-field 7982 Type of attribute: Media and session level 7983 Subject to charset: No 7984 Purpose: RFC XXXX 7985 Reference: RFC XXXX 7986 Values: See ABNF definition 7988 22.15. Media Type Registration for text/parameters 7990 Type name: text 7992 Subtype name: parameters 7994 Required parameters: 7996 Optional parameters: 7998 Encoding considerations: 8000 Security considerations: This format may carry any type of 8001 parameters. Some can clear have security requirements, like 8002 privacy, confidentiality or integrity requirements. The format 8003 has no built in security protection. For the usage it was defined 8004 the transport can be protected between server and client using 8005 TLS. However, care must be take to consider if also the proxies 8006 are trusted with the parameters in case hop-by-hop security is 8007 used. If stored as file in file system the necessary precautions 8008 needs to be taken in relation to the parameters requirements 8009 including object security such as S/MIME [RFC3851]. 8011 Interoperability considerations: This media type was mentioned as a 8012 fictional example in RFC 2326 but was not formally specified. 8013 This have resulted in usage of this media type which may not match 8014 its formal definition. 8016 Published specification: RFC XXXX, Appendix E. 8018 Applications that use this media type: Applications that use RTSP 8019 and have additional parameters they like to read and set using the 8020 RTSP GET_PARAMETER and SET_PARAMETER methods. 8022 Additional information: 8024 Magic number(s): 8026 File extension(s): 8028 Macintosh file type code(s): 8030 Person & email address to contact for further information: Magnus 8031 Westerlund (magnus.westerlund@ericsson.com) 8033 Intended usage: Common 8035 Restrictions on usage: None 8037 Author: Magnus Westerlund (magnus.westerlund@ericsson.com) 8039 Change controller: IETF 8041 Addition Notes: 8043 23. References 8045 23.1. Normative References 8047 [3gpp-26234] 8048 Third Generation Partnership Project (3GPP), "Transparent 8049 end-to-end Packet-switched Streaming Service (PSS); 8050 Protocols and codecs; Technical Specification 26.234", 8051 December 2002. 8053 [FIPS-pub-180-2] 8054 National Institute of Standards and Technology (NIST), 8055 "Federal Information Processing Standards Publications 8056 (FIPS PUBS) 180-2: Secure Hash Standard", Augusti 2002. 8058 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 8059 August 1980. 8061 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 8062 RFC 793, September 1981. 8064 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 8065 Requirement Levels", BCP 14, RFC 2119, March 1997. 8067 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 8068 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 8069 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 8071 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 8072 Leach, P., Luotonen, A., and L. Stewart, "HTTP 8073 Authentication: Basic and Digest Access Authentication", 8074 RFC 2617, June 1999. 8076 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 8078 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 8079 Jacobson, "RTP: A Transport Protocol for Real-Time 8080 Applications", STD 64, RFC 3550, July 2003. 8082 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 8083 Video Conferences with Minimal Control", STD 65, RFC 3551, 8084 July 2003. 8086 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 8087 10646", STD 63, RFC 3629, November 2003. 8089 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 8090 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 8091 RFC 3711, March 2004. 8093 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 8094 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 8095 August 2004. 8097 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 8098 Extensions (S/MIME) Version 3.1 Message Specification", 8099 RFC 3851, July 2004. 8101 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 8102 Resource Identifier (URI): Generic Syntax", STD 66, 8103 RFC 3986, January 2005. 8105 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 8106 Identifiers (IRIs)", RFC 3987, January 2005. 8108 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 8109 Requirements for Security", BCP 106, RFC 4086, June 2005. 8111 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 8112 Architecture", RFC 4291, February 2006. 8114 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 8115 Registration Procedures for New URI Schemes", BCP 115, 8116 RFC 4395, February 2006. 8118 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 8119 Description Protocol", RFC 4566, July 2006. 8121 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 8122 Carrara, "Key Management Extensions for Session 8123 Description Protocol (SDP) and Real Time Streaming 8124 Protocol (RTSP)", RFC 4567, July 2006. 8126 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 8127 and RTP Control Protocol (RTCP) Packets over Connection- 8128 Oriented Transport", RFC 4571, July 2006. 8130 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 8131 "Extended RTP Profile for Real-time Transport Control 8132 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 8133 July 2006. 8135 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 8136 Encodings", RFC 4648, October 2006. 8138 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 8139 Real-time Transport Control Protocol (RTCP)-Based Feedback 8140 (RTP/SAVPF)", RFC 5124, February 2008. 8142 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 8143 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 8144 May 2008. 8146 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 8147 Specifications: ABNF", STD 68, RFC 5234, January 2008. 8149 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 8150 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 8152 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 8153 Housley, R., and W. Polk, "Internet X.509 Public Key 8154 Infrastructure Certificate and Certificate Revocation List 8155 (CRL) Profile", RFC 5280, May 2008. 8157 23.2. Informative References 8159 [I-D.ietf-mmusic-rtsp-nat] 8160 Goldberg, J., Westerlund, M., and T. Zeng, "An Network 8161 Address Translator (NAT) Traversal mechanism for media 8162 controlled by Real-Time Streaming Protocol (RTSP)", 8163 draft-ietf-mmusic-rtsp-nat-07 (work in progress), 8164 July 2008. 8166 [ISO.13818-1.2000] 8167 International Organization for Standardization, 8168 "Information technology - Generic coding of moving 8169 pictures and associated audio information: Systems", ISO/ 8170 IEC 13818-1:2000, December 2000. 8172 [ISO.13818-6.1995] 8173 International Organization for Standardization, 8174 "Information technology - Generic coding of moving 8175 pictures and associated audio information - part 6: 8176 Extension for digital storage media and control", 8177 ISO Draft Standard 13818-6, November 1995. 8179 [ISO.8601.2000] 8180 International Organization for Standardization, "Data 8181 elements and interchange formats - Information interchange 8182 - Representation of dates and times", ISO/IEC Standard 8183 8601, December 2000. 8185 [ITU.H323.1996] 8186 International Telecommunications Union, "Visual telephone 8187 systems and equipment for local area networks which 8188 provide a non-guaranteed quality of service", ITU- 8189 T Recommendation H.323, May 1996. 8191 [NOSSDAV-1997-1] 8192 Schulzrinne, H., "A comprehensive multimedia control 8193 architecture for the Internet", May 1997. 8195 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 8196 and Support", STD 3, RFC 1123, October 1989. 8198 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 8199 Specification, Implementation", RFC 1305, March 1992. 8201 [RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions 8202 Functional Specification", RFC 1644, July 1994. 8204 [RFC1961] McMahon, P., "GSS-API Authentication Method for SOCKS 8205 Version 5", RFC 1961, June 1996. 8207 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 8208 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 8209 RFC 2068, January 1997. 8211 [RFC2070] Yergeau, F., Nicol, G., Adams, G., and M. Duerst, 8212 "Internationalization of the Hypertext Markup Language", 8213 RFC 2070, January 1997. 8215 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 8216 Streaming Protocol (RTSP)", RFC 2326, April 1998. 8218 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 8219 Announcement Protocol", RFC 2974, October 2000. 8221 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 8222 A., Peterson, J., Sparks, R., Handley, M., and E. 8223 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 8224 June 2002. 8226 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 8227 Schulzrinne, "Grouping of Media Lines in the Session 8228 Description Protocol (SDP)", RFC 3388, December 2002. 8230 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 8231 the Session Description Protocol (SDP)", RFC 4145, 8232 September 2005. 8234 [Stevens98] 8235 Stevens, W., "Unix Networking Programming - Volume 1, 8236 second edition", 1998. 8238 [W3C.REC-PICS-labels] 8239 Miller, J., Krauskopf, T., Resnick, P., and W. Treese, 8240 "PICS label distribution label syntax and communication 8241 protocols", W3C REC-PICS-labels-961031. 8243 [W3C.REC-PICS-services] 8244 Miller, J., Resnick, P., and D. Singer, "Rating services 8245 and rating systems (and their machine readable 8246 descriptions)", W3C REC-PICS-services-961031, 8247 October 1996. 8249 Appendix A. Examples 8251 This section contains several different examples trying to illustrate 8252 possible ways of using RTSP. The examples can also help with the 8253 understanding of how functions of RTSP work. However remember that 8254 this is examples and the normative and syntax description in the 8255 other sections takes precedence. Please also note that many of the 8256 example contain syntax illegal line breaks to accommodate the 8257 formatting restriction that the RFC series impose. 8259 A.1. Media on Demand (Unicast) 8261 The is an example of media on demand streaming of a media stored in a 8262 container file. For purposes of this example, a container file is a 8263 storage entity in which multiple continuous media types pertaining to 8264 the same end-user presentation are present. In effect, the container 8265 file represents an RTSP presentation, with each of its components 8266 being RTSP controlled media streams. Container files are a widely 8267 used means to store such presentations. While the components are 8268 transported as independent streams, it is desirable to maintain a 8269 common context for those streams at the server end. 8271 This enables the server to keep a single storage handle open 8272 easily. It also allows treating all the streams equally in case 8273 of any prioritization of streams by the server. 8275 It is also possible that the presentation author may wish to prevent 8276 selective retrieval of the streams by the client in order to preserve 8277 the artistic effect of the combined media presentation. Similarly, 8278 in such a tightly bound presentation, it is desirable to be able to 8279 control all the streams via a single control message using an 8280 aggregate URI. 8282 The following is an example of using a single RTSP session to control 8283 multiple streams. It also illustrates the use of aggregate URIs. In 8284 a container file it is also desirable to not write any URI parts 8285 which is not kept, when the container is distributed, like the host 8286 and most of the path element. Therefore this example also uses the 8287 "*" and relative URI in the delivered SDP. 8289 Client C requests a presentation from media server M. The movie is 8290 stored in a container file. The client has obtained an RTSP URI to 8291 the container file. 8293 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 8294 CSeq: 1 8295 User-Agent: PhonyClient/1.2 8297 M->C: RTSP/2.0 200 OK 8298 CSeq: 1 8299 Server: PhonyServer/1.0 8300 Date: Thu, 23 Jan 1997 15:35:06 GMT 8301 Content-Type: application/sdp 8302 Content-Length: 271 8303 Content-Base: rtsp://example.com/twister.3gp/ 8304 Expires: 24 Jan 1997 15:35:06 GMT 8306 v=0 8307 o=- 2890844256 2890842807 IN IP4 192.0.2.5 8308 s=RTSP Session 8309 i=An Example of RTSP Session Usage 8310 e=adm@example.com 8311 c=IN IP4 0.0.0.0 8312 a=control: * 8313 a=range: npt=0-0:10:34.10 8314 t=0 0 8315 m=audio 0 RTP/AVP 0 8316 a=control: trackID=1 8317 m=video 0 RTP/AVP 26 8318 a=control: trackID=4 8320 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 8321 CSeq: 2 8322 User-Agent: PhonyClient/1.2 8323 Require: play.basic 8324 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" 8325 Accept-Ranges: NPT, SMPTE, UTC 8327 M->C: RTSP/2.0 200 OK 8328 CSeq: 2 8329 Server: PhonyServer/1.0 8330 Transport: RTP/AVP;unicast; ssrc=93CB001E; 8331 dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; 8332 src_addr="192.0.2.5:9000"/"192.0.2.5:9001" 8333 Session: 12345678 8334 Expires: 24 Jan 1997 15:35:12 GMT 8335 Date: 23 Jan 1997 15:35:12 GMT 8336 Accept-Ranges: NPT 8338 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 8339 CSeq: 3 8340 User-Agent: PhonyClient/1.2 8341 Require: play.basic 8342 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" 8343 Session: 12345678 8344 Accept-Ranges: NPT, SMPTE, UTC 8346 M->C: RTSP/2.0 200 OK 8347 CSeq: 3 8348 Server: PhonyServer/1.0 8349 Transport: RTP/AVP;unicast; ssrc=A813FC13; 8350 dest_addr="192.0.2.53:8002"/"192.0.2.53:8003"; 8351 src_addr="192.0.2.5:9002"/"192.0.2.5:9003"; 8353 Session: 12345678 8354 Expires: 24 Jan 1997 15:35:13 GMT 8355 Date: 23 Jan 1997 15:35:13 GMT 8356 Accept-Range: NPT 8358 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 8359 CSeq: 4 8360 User-Agent: PhonyClient/1.2 8361 Range: npt=0-10, npt=30- 8362 Session: 12345678 8364 M->C: RTSP/2.0 200 OK 8365 CSeq: 4 8366 Server: PhonyServer/1.0 8367 Date: 23 Jan 1997 15:35:14 GMT 8368 Session: 12345678 8369 Range: npt=0-10, npt=30-623.10 8370 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 8371 ssrc=0D12F123:seq=12345;rtptime=3450012, 8372 url="rtsp://example.com/twister.3gp/trackID=1" 8373 ssrc=4F312DD8:seq=54321;rtptime=2876889 8375 C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0 8376 CSeq: 5 8377 User-Agent: PhonyClient/1.2 8378 Session: 12345678 8380 M->C: RTSP/2.0 200 OK 8381 CSeq: 5 8382 Server: PhonyServer/1.0 8383 Date: 23 Jan 1997 15:36:01 GMT 8384 Session: 12345678 8385 Range: npt=34.57-623.10 8387 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 8388 CSeq: 6 8389 User-Agent: PhonyClient/1.2 8390 Range: npt=34.57-623.10 8391 Session: 12345678 8393 M->C: RTSP/2.0 200 OK 8394 CSeq: 6 8395 Server: PhonyServer/1.0 8396 Date: 23 Jan 1997 15:36:01 GMT 8397 Session: 12345678 8398 Range: npt=34.57-623.10 8399 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 8400 ssrc=0D12F123:seq=12555;rtptime=6330012, 8401 url="rtsp://example.com/twister.3gp/trackID=1" 8402 ssrc=4F312DD8:seq=55021;rtptime=3132889 8404 A.2. Media on Demand using Pipelining 8406 This example is basically the example above (Appendix A.1), but now 8407 utilizing pipelining to speed up the setup. It requires only two 8408 round trip times until the media starts flowing. First of all, the 8409 session description is retrieved to determine what media resources 8410 need to be setup. In the second step, one sends the necessary SETUP 8411 requests and the PLAY request to initiate media delivery. 8413 Client C requests a presentation from media server M. The movie is 8414 stored in a container file. The client has obtained an RTSP URI to 8415 the container file. 8417 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 8418 CSeq: 1 8419 User-Agent: PhonyClient/1.2 8421 M->C: RTSP/2.0 200 OK 8422 CSeq: 1 8423 Server: PhonyServer/1.0 8424 Date: Thu, 23 Jan 1997 15:35:06 GMT 8425 Content-Type: application/sdp 8426 Content-Length: 271 8427 Content-Base: rtsp://example.com/twister.3gp/ 8428 Expires: 24 Jan 1997 15:35:06 GMT 8430 v=0 8431 o=- 2890844256 2890842807 IN IP4 192.0.2.5 8432 s=RTSP Session 8433 i=An Example of RTSP Session Usage 8434 e=adm@example.com 8435 c=IN IP4 0.0.0.0 8436 a=control: * 8437 a=range: npt=0-0:10:34.10 8438 t=0 0 8439 m=audio 0 RTP/AVP 0 8440 a=control: trackID=1 8441 m=video 0 RTP/AVP 26 8442 a=control: trackID=4 8444 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 8445 CSeq: 2 8446 User-Agent: PhonyClient/1.2 8447 Require: play.basic 8448 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" 8449 Accept-Ranges: NPT, SMPTE, UTC 8450 Pipelined-Requests: 7654 8452 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 8453 CSeq: 3 8454 User-Agent: PhonyClient/1.2 8455 Require: play.basic 8456 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" 8457 Accept-Ranges: NPT, SMPTE, UTC 8458 Pipelined-Requests: 7654 8460 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 8461 CSeq: 4 8462 User-Agent: PhonyClient/1.2 8463 Range: npt=0-10, npt=30- 8464 Session: 12345678 8465 Pipelined-Requests: 7654 8467 M->C: RTSP/2.0 200 OK 8468 CSeq: 2 8469 Server: PhonyServer/1.0 8470 Transport: RTP/AVP;unicast; 8471 dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; 8472 src_addr="192.0.2.5:9000"/"192.0.2.5:9001"; 8473 ssrc=93CB001E 8474 Session: 12345678 8475 Expires: 24 Jan 1997 15:35:12 GMT 8476 Date: 23 Jan 1997 15:35:12 GMT 8477 Accept-Ranges: NPT 8478 Pipelined-Requests: 7654 8480 M->C: RTSP/2.0 200 OK 8481 CSeq: 3 8482 Server: PhonyServer/1.0 8483 Transport: RTP/AVP;unicast; 8484 dest_addr="192.0.2.53:8002"/"192.0.2.53:8003; 8485 src_addr="192.0.2.5:9002"/"192.0.2.5:9003"; 8486 ssrc=A813FC13 8487 Session: 12345678 8488 Expires: 24 Jan 1997 15:35:13 GMT 8489 Date: 23 Jan 1997 15:35:13 GMT 8490 Accept-Range: NPT 8491 Pipelined-Requests: 7654 8493 M->C: RTSP/2.0 200 OK 8494 CSeq: 4 8495 Server: PhonyServer/1.0 8496 Date: 23 Jan 1997 15:35:14 GMT 8497 Session: 12345678 8498 Range: npt=0-10, npt=30-623.10 8499 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 8500 ssrc=0D12F123:seq=12345;rtptime=3450012, 8501 url="rtsp://example.com/twister.3gp/trackID=1" 8502 ssrc=4F312DD8:seq=54321;rtptime=2876889 8503 Pipelined-Requests: 7654 8505 A.3. Media on Demand (Unicast) 8507 An alternative example of media on demand with a bit more tweaks is 8508 the following. Client C requests a movie distributed from two 8509 different media servers A (audio.example.com) and V ( 8510 video.example.com). The media description is stored on a web server 8511 W. The media description contains descriptions of the presentation 8512 and all its streams, including the codecs that are available, dynamic 8513 RTP payload types, the protocol stack, and content information such 8514 as language or copyright restrictions. It may also give an 8515 indication about the timeline of the movie. 8517 In this example, the client is only interested in the last part of 8518 the movie. 8520 C->W: GET /twister.sdp HTTP/1.1 8521 Host: www.example.com 8522 Accept: application/sdp 8524 W->C: HTTP/1.0 200 OK 8525 Date: Thu, 23 Jan 1997 15:35:06 GMT 8526 Content-Type: application/sdp 8527 Content-Length: 278 8528 Expires: 23 Jan 1998 15:35:06 GMT 8530 v=0 8531 o=- 2890844526 2890842807 IN IP4 192.0.2.5 8532 s=RTSP Session 8533 e=adm@example.com 8534 c=IN IP4 0.0.0.0 8535 a=range:npt=0-1:49:34 8536 t=0 0 8537 m=audio 0 RTP/AVP 0 8538 a=control:rtsp://audio.example.com/twister/audio.en 8539 m=video 0 RTP/AVP 31 8540 a=control:rtsp://video.example.com/twister/video 8542 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0 8543 CSeq: 1 8544 User-Agent: PhonyClient/1.2 8545 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057", 8546 RTP/AVP/TCP;unicast;interleaved=0-1 8547 Accept-Ranges: NPT, SMPTE, UTC 8549 A->C: RTSP/2.0 200 OK 8550 CSeq: 1 8551 Session: 12345678 8552 Transport: RTP/AVP/UDP;unicast; 8553 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; 8554 src_addr="192.0.2.5:5000"/"192.0.2.5:5001" 8555 Date: 23 Jan 1997 15:35:12 GMT 8556 Server: PhonyServer/1.0 8557 Expires: 24 Jan 1997 15:35:12 GMT 8558 Cache-Control: public 8559 Accept-Ranges: NPT, SMPTE 8561 C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0 8562 CSeq: 1 8563 User-Agent: PhonyClient/1.2 8564 Transport: RTP/AVP/UDP;unicast; 8565 dest_addr="192.0.2.53:3058"/"192.0.2.53:3059", 8566 RTP/AVP/TCP;unicast;interleaved=0-1 8567 Accept-Ranges: NPT, SMPTE, UTC 8569 V->C: RTSP/2.0 200 OK 8570 CSeq: 1 8571 Session: 23456789 8572 Transport: RTP/AVP/UDP;unicast; 8573 dest_addr="192.0.2.53:3058"/"192.0.2.53:3059"; 8574 src_addr="192.0.2.5:5002"/"192.0.2.5:5003" 8575 Date: 23 Jan 1997 15:35:12 GMT 8576 Server: PhonyServer/1.0 8577 Cache-Control: public 8578 Expires: 24 Jan 1997 15:35:12 GMT 8579 Accept-Ranges: NPT, SMPTE 8581 C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0 8582 CSeq: 2 8583 User-Agent: PhonyClient/1.2 8584 Session: 23456789 8585 Range: smpte=0:10:00- 8587 V->C: RTSP/2.0 200 OK 8588 CSeq: 2 8589 Session: 23456789 8590 Range: smpte=0:10:00-1:49:23 8591 RTP-Info: url="rtsp://video.example.com/twister/video" 8592 ssrc=A17E189D:seq=12312232;rtptime=78712811 8593 Server: PhonyServer/2.0 8594 Date: 23 Jan 1997 15:35:13 GMT 8596 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0 8597 CSeq: 2 8598 User-Agent: PhonyClient/1.2 8599 Session: 12345678 8600 Range: smpte=0:10:00- 8602 A->C: RTSP/2.0 200 OK 8603 CSeq: 2 8604 Session: 12345678 8605 Range: smpte=0:10:00-1:49:23 8606 RTP-Info: url="rtsp://audio.example.com/twister/audio.en" 8607 ssrc=3D124F01:seq=876655;rtptime=1032181 8608 Server: PhonyServer/1.0 8609 Date: 23 Jan 1997 15:35:13 GMT 8611 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0 8612 CSeq: 3 8613 User-Agent: PhonyClient/1.2 8614 Session: 12345678 8616 A->C: RTSP/2.0 200 OK 8617 CSeq: 3 8618 Server: PhonyServer/1.0 8619 Date: 23 Jan 1997 15:36:52 GMT 8621 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0 8622 CSeq: 3 8623 User-Agent: PhonyClient/1.2 8624 Session: 23456789 8626 V->C: RTSP/2.0 200 OK 8627 CSeq: 3 8628 Server: PhonyServer/2.0 8629 Date: 23 Jan 1997 15:36:52 GMT 8631 Even though the audio and video track are on two different servers, 8632 may start at slightly different times, and may drift with respect to 8633 each other, the client can perform initial synchronize of the two 8634 media using RTP-Info and Range received in the PLAY responses. If 8635 the two servers are time synchronized the RTCP packets can also be 8636 used to maintain synchronization. 8638 A.4. Single Stream Container Files 8640 Some RTSP servers may treat all files as though they are "container 8641 files", yet other servers may not support such a concept. Because of 8642 this, clients needs to use the rules set forth in the session 8643 description for Request-URIs, rather than assuming that a consistent 8644 URI may always be used throughout. Below are an example of how a 8645 multi-stream server might expect a single-stream file to be served: 8647 C->S: DESCRIBE rtsp://foo.com/test.wav RTSP/2.0 8648 Accept: application/x-rtsp-mh, application/sdp 8649 CSeq: 1 8650 User-Agent: PhonyClient/1.2 8652 S->C: RTSP/2.0 200 OK 8653 CSeq: 1 8654 Content-base: rtsp://foo.com/test.wav/ 8655 Content-type: application/sdp 8656 Content-length: 163 8657 Server: PhonyServer/1.0 8658 Date: Thu, 23 Jan 1997 15:35:06 GMT 8659 Expires: 23 Jan 1997 17:00:00 GMT 8661 v=0 8662 o=- 872653257 872653257 IN IP4 192.0.2.5 8663 s=mu-law wave file 8664 i=audio test 8665 c=IN IP4 0.0.0.0 8666 t=0 0 8667 a=control: * 8668 m=audio 0 RTP/AVP 0 8669 a=control:streamid=0 8671 C->S: SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/2.0 8672 Transport: RTP/AVP/UDP;unicast; 8673 dest_addr=":6970"/":6971";mode="PLAY" 8674 CSeq: 2 8675 User-Agent: PhonyClient/1.2 8676 Accept-Ranges: NPT, SMPTE, UTC 8678 S->C: RTSP/2.0 200 OK 8679 Transport: RTP/AVP/UDP;unicast; 8680 dest_addr="192.0.2.53:6970"/"192.0.2.53:6971"; 8681 src_addr="192.0.2.5:6970"/"192.0.2.5:6971"; 8682 mode="PLAY";ssrc=EAB98712 8683 CSeq: 2 8684 Session: 2034820394 8685 Expires: 23 Jan 1997 16:00:00 GMT 8686 Server: PhonyServer/1.0 8687 Date: 23 Jan 1997 15:35:07 GMT 8688 Accept-Ranges: NPT 8690 C->S: PLAY rtsp://foo.com/test.wav/ RTSP/2.0 8691 CSeq: 3 8692 User-Agent: PhonyClient/1.2 8693 Session: 2034820394 8695 S->C: RTSP/2.0 200 OK 8696 CSeq: 3 8697 Server: PhonyServer/1.0 8698 Date: 23 Jan 1997 15:35:08 GMT 8699 Session: 2034820394 8700 Range: npt=0-600 8701 RTP-Info: url="rtsp://foo.com/test.wav/streamid=0" 8702 ssrc=0D12F123:seq=981888;rtptime=3781123 8704 Note the different URI in the SETUP command, and then the switch back 8705 to the aggregate URI in the PLAY command. This makes complete sense 8706 when there are multiple streams with aggregate control, but is less 8707 than intuitive in the special case where the number of streams is 8708 one. However the server has declared that the aggregated control URI 8709 in the SDP and therefore this is legal. 8711 In this case, it is also required that servers accept implementations 8712 that use the non-aggregated interpretation and use the individual 8713 media URI, like this: 8715 C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0 8716 CSeq: 3 8717 User-Agent: PhonyClient/1.2 8719 A.5. Live Media Presentation Using Multicast 8721 The media server M chooses the multicast address and port. Here, it 8722 is assumed that the web server only contains a pointer to the full 8723 description, while the media server M maintains the full description. 8725 C->W: GET /sessions.html HTTP/1.1 8726 Host: www.example.com 8728 W->C: HTTP/1.1 200 OK 8729 Content-Type: text/html 8731 8732 ... 8733 8735 ... 8736 8738 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0 8739 CSeq: 1 8740 Supported: play.basic, play.scale 8741 User-Agent: PhonyClient/1.2 8743 M->C: RTSP/2.0 200 OK 8744 CSeq: 1 8745 Content-Type: application/sdp 8746 Content-Length: 183 8747 Server: PhonyServer/1.0 8748 Date: Thu, 23 Jan 1997 15:35:06 GMT 8749 Supported: play.basic 8751 v=0 8752 o=- 2890844526 2890842807 IN IP4 192.0.2.5 8753 s=RTSP Session 8754 t=0 0 8755 m=audio 3456 RTP/AVP 0 8756 c=IN IP4 224.2.0.1/16 8757 a=control: rtsp://live.example.com/concert/audio 8758 a=range:npt=0- 8760 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0 8761 CSeq: 2 8762 Transport: RTP/AVP;multicast 8763 Accept-Ranges: NPT, SMPTE, UTC 8764 User-Agent: PhonyClient/1.2 8766 M->C: RTSP/2.0 200 OK 8767 CSeq: 2 8768 Server: PhonyServer/1.0 8769 Date: Thu, 23 Jan 1997 15:35:06 GMT 8770 Transport: RTP/AVP;multicast; 8771 dest_addr="224.2.0.1:3456"/"224.2.0.1:3457";ttl=16 8772 Session: 0456804596 8773 Accept-Ranges: NPT, UTC 8775 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0 8776 CSeq: 3 8777 Session: 0456804596 8778 User-Agent: PhonyClient/1.2 8780 M->C: RTSP/2.0 200 OK 8781 CSeq: 3 8782 Server: PhonyServer/1.0 8783 Date: 23 Jan 1997 15:35:07 GMT 8784 Session: 0456804596 8785 Range:npt=1256- 8786 RTP-Info: url="rtsp://live.example.com/concert/audio" 8787 ssrc=0D12F123:seq=1473; rtptime=80000 8789 A.6. Capability Negotiation 8791 This examples illustrate how the client and server determines their 8792 capability to support a special feature, in this case "play.scale". 8793 The server, through the clients request and the included Supported 8794 header, learns the client supports RTSP 2.0, and also supports the 8795 playback time scaling feature of RTSP. The server's response 8796 contains the following feature related information to the client; it 8797 supports the basic playback (play.basic), the extended functionality 8798 of time scaling of content (play.scale), and one "example.com" 8799 proprietary feature (com.example.flight). The client also learns the 8800 methods supported (Public header) by the server for the indicated 8801 resource. 8803 C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0 8804 CSeq: 1 8805 Supported: play.basic, play.scale 8806 User-Agent: PhonyClient/1.2 8808 S->C: RTSP/2.0 200 OK 8809 CSeq: 1 8810 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 8811 Server: PhonyServer/2.0 8812 Supported: play.basic, play.scale, com.example.flight 8814 When the client sends its SETUP request it tells the server that it 8815 is requires support of the play.scale feature for this session by 8816 including the Require header. 8818 C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0 8819 CSeq: 3 8820 User-Agent: PhonyClient/1.2 8821 Transport: RTP/AVP/UDP;unicast; 8822 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057", 8823 RTP/AVP/TCP;unicast;interleaved=0-1 8824 Require: play.scale 8825 Accept-Ranges: NPT, SMPTE, UTC 8826 User-Agent: PhonyClient/1.2 8828 S->C: RTSP/2.0 200 OK 8829 CSeq: 3 8830 Session: 12345678 8831 Transport: RTP/AVP/UDP;unicast; 8832 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; 8833 src_addr="192.0.2.5:5000"/"192.0.2.5:5001" 8834 Server: PhonyServer/2.0 8835 Accept-Ranges: NPT, SMPTE 8837 Appendix B. RTSP Protocol State Machine 8839 The RTSP session state machine describes the behavior of the protocol 8840 from RTSP session initialization through RTSP session termination. 8842 The State machine is defined on a per session basis which is uniquely 8843 identified by the RTSP session identifier. The session may contain 8844 one or more media streams depending on state. If a single media 8845 stream is part of the session it is in non-aggregated control. If 8846 two or more is part of the session it is in aggregated control. 8848 The below state machine is a normative description of the protocols 8849 behavior. However, in case of ambiguity with the earlier parts of 8850 this specification, the description in the earlier parts SHALL take 8851 precedence. 8853 B.1. States 8855 The state machine contains three states, described below. For each 8856 state there exist a table which shows which requests and events that 8857 is allowed and if they will result in a state change. 8859 Init: Initial state no session exist. 8861 Ready: Session is ready to start playing. 8863 Play: Session is playing, i.e. sending media stream data in the 8864 direction S->C. 8866 B.2. State variables 8868 This representation of the state machine needs more than its state to 8869 work. A small number of variables are also needed and is explained 8870 below. 8872 NRM: The number of media streams part of this session. 8874 RP: Resume point, the point in the presentation time line at which 8875 a request to continue will resume from. A time format for the 8876 variable is not mandated. 8878 B.3. Abbreviations 8880 To make the state tables more compact a number of abbreviations are 8881 used, which are explained below. 8883 IFI: IF Implemented. 8885 md: Media 8887 PP: Pause Point, the point in the presentation time line at which 8888 the presentation was paused. 8890 Prs: Presentation, the complete multimedia presentation. 8892 RedP: Redirect Point, the point in the presentation time line at 8893 which a REDIRECT was specified to occur. 8895 SES: Session. 8897 B.4. State Tables 8899 This section contains a table for each state. The table contains all 8900 the requests and events that this state is allowed to act on. The 8901 events which is method names are, unless noted, requests with the 8902 given method in the direction client to server (C->S). In some cases 8903 there exist one or more requisite. The response column tells what 8904 type of response actions should be performed. Possible actions that 8905 is requested for an event includes: response codes, e.g. 200, headers 8906 that MUST be included in the response, setting of state variables, or 8907 setting of other session related parameters. The new state column 8908 tells which state the state machine changes to. 8910 The response to valid request meeting the requisites is normally a 8911 2xx (SUCCESS) unless other noted in the response column. The 8912 exceptions needs to be given a response according to the response 8913 column. If the request does not meet the requisite, is erroneous or 8914 some other type of error occur the appropriate response code MUST be 8915 sent. If the response code is a 4xx the session state is unchanged. 8916 A response code of 3rr will result in that the session is ended and 8917 its state is changed to Init. A response code of 304 results in no 8918 state change. However there exist restrictions to when a 3rr 8919 response may be used. A 5xx response SHALL NOT result in any change 8920 of the session state, except if the error is not possible to recover 8921 from. A unrecoverable error SHALL result the ending of the session. 8922 As it in the general case can't be determined if it was a 8923 unrecoverable error or not the client will be required to test. In 8924 the case that the next request after a 5xx is responded with 454 8925 (Session Not Found) the client knows that the session has ended. 8927 The server will timeout the session after the period of time 8928 specified in the SETUP response, if no activity from the client is 8929 detected. Therefore there exist a timeout event for all states 8930 except Init. 8932 In the case that NRM = 1 the presentation URI is equal to the media 8933 URI or a specified presentation URI. For NRM > 1 the presentation 8934 URI MUST be other than any of the medias that are part of the 8935 session. This applies to all states. 8937 +---------------+-----------------+---------------------------------+ 8938 | Event | Prerequisite | Response | 8939 +---------------+-----------------+---------------------------------+ 8940 | DESCRIBE | Needs REDIRECT | 3rr, Redirect | 8941 | | | | 8942 | DESCRIBE | | 200, Session description | 8943 | | | | 8944 | OPTIONS | Session ID | 200, Reset session timeout | 8945 | | | timer | 8946 | | | | 8947 | OPTIONS | | 200 | 8948 | | | | 8949 | SET_PARAMETER | Valid parameter | 200, change value of parameter | 8950 | | | | 8951 | GET_PARAMETER | Valid parameter | 200, return value of parameter | 8952 +---------------+-----------------+---------------------------------+ 8954 Table 13: None state-machine changing events 8956 The methods in Table 13 do not have any effect on the state machine 8957 or the state variables. However some methods do change other session 8958 related parameters, for example SET_PARAMETER which will set the 8959 parameter(s) specified in its body. Also all of these methods that 8960 allows Session header will also update the keep-alive timer for the 8961 session. 8963 +------------------+----------------+-----------+-------------------+ 8964 | Action | Requisite | New State | Response | 8965 +------------------+----------------+-----------+-------------------+ 8966 | SETUP | | Ready | NRM=1, RP=0.0 | 8967 | | | | | 8968 | SETUP | Needs Redirect | Init | 3rr Redirect | 8969 | | | | | 8970 | S -> C: REDIRECT | No Session hdr | Init | Terminate all SES | 8971 +------------------+----------------+-----------+-------------------+ 8973 Table 14: State: Init 8975 The initial state of the state machine, see Table 14 can only be left 8976 by processing a correct SETUP request. As seen in the table the two 8977 state variables are also set by a correct request. This table also 8978 shows that a correct SETUP can in some cases be redirected to another 8979 URI and/or server by a 3rr response. 8981 +--------------+-----------------+-----------+----------------------+ 8982 | Action | Requisite | New State | Response | 8983 +--------------+-----------------+-----------+----------------------+ 8984 | SETUP | New URI | Ready | NRM +=1 | 8985 | | | | | 8986 | SETUP | URI Setup prior | Ready | Change transport | 8987 | | | | param | 8988 | | | | | 8989 | TEARDOWN | Prs URI, | Init | No session hdr, NRM | 8990 | | | | = 0 | 8991 | | | | | 8992 | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, NRM | 8993 | | | | = 0 | 8994 | | | | | 8995 | TEARDOWN | md URI,NRM>1 | Ready | Session hdr, NRM -= | 8996 | | | | 1 | 8997 | | | | | 8998 | PLAY | Prs URI, No | Play | Play from RP | 8999 | | range | | | 9000 | | | | | 9001 | PLAY | Prs URI, Range | Play | According to range | 9002 | | | | | 9003 | PAUSE | Prs URI | Ready | Return PP | 9004 | | | | | 9005 | SC:REDIRECT | Range hdr | Ready | Set RedP | 9006 | | | | | 9007 | SC:REDIRECT | no range hdr | Init | Session is removed | 9008 | | | | | 9009 | Timeout | | Init | | 9010 | | | | | 9011 | RedP reached | | Init | TEARDOWN of session | 9012 +--------------+-----------------+-----------+----------------------+ 9014 Table 15: State: Ready 9016 In the Ready state, see Table 15, some of the actions are depending 9017 on the number of media streams (NRM) in the session, i.e. aggregated 9018 or non-aggregated control. A setup request in the ready state can 9019 either add one more media stream to the session or if the media 9020 stream (same URI) already is part of the session change the transport 9021 parameters. TEARDOWN is depending on both the Request-URI and the 9022 number of media stream within the session. If the Request-URI is the 9023 presentations URI the whole session is torn down. If a media URI is 9024 used in the TEARDOWN request and more than one media exist in the 9025 session, the session will remain and a session header MUST be 9026 returned in the response. If only a single media stream remains in 9027 the session when performing a TEARDOWN with a media URI the session 9028 is removed. The number of media streams remaining after tearing down 9029 a media stream determines the new state. 9031 +--------------+-----------------+-----------+----------------------+ 9032 | Action | Requisite | New State | Response | 9033 +--------------+-----------------+-----------+----------------------+ 9034 | PAUSE | PrsURI | Ready | Set RP to present | 9035 | | | | point | 9036 | | | | | 9037 | PP reached | | Ready | RP = PP | 9038 | | | | | 9039 | End of media | All media | Play | Set RP = End of | 9040 | | | | media | 9041 | | | | | 9042 | End of range | | Play | Set RP = End of | 9043 | | | | range | 9044 | | | | | 9045 | PLAY | Prs URI, No | Play | Play from present | 9046 | | range | | point | 9047 | | | | | 9048 | PLAY | Prs URI, Range | Play | According to range | 9049 | | | | | 9050 | PLAY_NOTIFY | | Play | 200 | 9051 | | | | | 9052 | SETUP | New URI | Play | 455 | 9053 | | | | | 9054 | SETUP | Setuped URI | Play | 455 | 9055 | | | | | 9056 | SETUP | Setuped URI, | Play | Change transport | 9057 | | IFI | | param. | 9058 | | | | | 9059 | TEARDOWN | Prs URI | Init | No session hdr | 9060 | | | | | 9061 | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, | 9062 | | | | NRM=0 | 9063 | | | | | 9064 | TEARDOWN | md URI | Play | 455 | 9065 | | | | | 9066 | SC:REDIRECT | Range hdr | Play | Set RedP | 9067 | | | | | 9068 | SC:REDIRECT | no range hdr | Init | Session is removed | 9069 | | | | | 9070 | RedP reached | | Init | TEARDOWN of session | 9071 | | | | | 9072 | Timeout | | Init | Stop Media playout | 9073 +--------------+-----------------+-----------+----------------------+ 9075 Table 16: State: Play 9077 The Play state table, see Table 16, is the largest. The table 9078 contains an number of requests that has presentation URI as a 9079 prerequisite on the Request-URI, this is due to the exclusion of non- 9080 aggregated stream control in sessions with more than one media 9081 stream. 9083 To avoid inconsistencies between the client and server, automatic 9084 state transitions are avoided. This can be seen at for example "End 9085 of media" event when all media has finished playing, the session 9086 still remain in Play state. An explicit PAUSE request MUST be sent 9087 to change the state to Ready. It may appear that there exist an 9088 automatic transitions in "RedP reached" and "PP reached", however 9089 they are requested and acknowledge before they take place. The time 9090 at which the transition will happen is known by looking at the range 9091 header. If the client sends request close in time to these 9092 transitions it needs to be prepared for getting error message as the 9093 state may or may not have changed. 9095 Appendix C. Media Transport Alternatives 9097 This section defines how certain combinations of protocols, profiles 9098 and lower transports are used. This includes the usage of the 9099 Transport header's source and destination address parameters 9100 "src_addr" and "dest_addr". 9102 C.1. RTP 9104 This section defines the interaction of RTSP with respect to the RTP 9105 protocol [RFC3550]. It also defines any necessary media transport 9106 signalling with regards to RTP. 9108 The available RTP profiles and lower layer transports are described 9109 below along with rules on signalling the available combinations. 9111 C.1.1. AVP 9113 The usage of the "RTP Profile for Audio and Video Conferences with 9114 Minimal Control" [RFC3551] when using RTP for media transport over 9115 different lower layer transport protocols is defined below in regards 9116 to RTSP. 9118 One such case is defined within this document, the use of embedded 9119 (interleaved) binary data as defined in Section 14. The usage of 9120 this method is indicated by include the "interleaved" parameter. 9122 When using embedded binary data the "src_addr" and "dest_addr" SHALL 9123 NOT be used. This addressing and multiplexing is used as defined 9124 with use of channel numbers and the interleaved parameter. 9126 C.1.2. AVP/UDP 9128 This part describes sending of RTP [RFC3550] over lower transport 9129 layer UDP [RFC0768] according to the profile "RTP Profile for Audio 9130 and Video Conferences with Minimal Control" defined in RFC 3551 9131 [RFC3551]. This profiles requires one or two uni- or bi-directional 9132 UDP flows per media stream. The first UDP flow is for RTP and the 9133 second is for RTCP. Embedding of RTP data with the RTSP messages, in 9134 accordance with Section 14, SHOULD NOT be performed when RTSP 9135 messages are transported over unreliable transport protocols, like 9136 UDP [RFC0768]. 9138 The RTP/UDP and RTCP/UDP flows can be established using the Transport 9139 header's "src_addr", and "dest_addr" parameters. 9141 In RTSP PLAY mode, the transmission of RTP packets from client to 9142 server is unspecified. The behavior in regards to such RTP packets 9143 MAY be defined in future. 9145 The "src_addr" and "dest_addr" parameters are used in the following 9146 way for media playback, i.e. Mode=PLAY: 9148 o The "src_addr" and "dest_addr" parameters MUST contain either 1 or 9149 2 address specifications. 9151 o Each address specification for RTP/AVP/UDP or RTP/AVP/TCP MUST 9152 contain either: 9154 * both an address and a port number, or 9156 * a port number without an address. 9158 o The first address and port pair given in either of the parameters 9159 applies to the RTP stream. The second address and port pair if 9160 present applies to the RTCP stream. 9162 o The RTP/UDP packets from the server to the client SHALL be sent to 9163 the address and port given by first address and port pair of the 9164 "dest_addr" parameter. 9166 o The RTCP/UDP packets from the server to the client SHALL be sent 9167 to the address and port given by the second address and port pair 9168 of the "dest_addr" parameter. If no second pair is specified RTCP 9169 SHALL NOT be sent. 9171 o The RTCP/UDP packets from the client to the server SHALL be sent 9172 to the address and port given by the second address and port pair 9173 of the "src_addr" parameter. If no second pair is given RTCP 9174 SHALL NOT be sent. 9176 o The RTP/UDP packets from the client to the server SHALL be sent to 9177 the address and port given by the first address and port pair of 9178 the "src_addr" parameter. 9180 o RTP and RTCP Packets SHOULD be sent from the corresponding 9181 receiver port, i.e. RTCP packets from server should be sent from 9182 the "src_addr" parameters second address port pair. 9184 C.1.3. AVPF/UDP 9186 The RTP profile "Extended RTP Profile for RTCP-based Feedback (RTP/ 9187 AVPF)"[RFC4585] MAY be used as RTP profiles in session using RTP. 9188 All that is defined for AVP SHALL also apply for AVPF. 9190 The usage of AVPF is indicated by the media initialization protocol 9191 used. In the case of SDP it is indicated by media lines (m=) 9192 containing the profile RTP/AVPF. That SDP MAY also contain further 9193 AVPF related SDP attributes configuring the AVPF session regarding 9194 reporting interval and feedback messages that shall be used that 9195 SHALL be followed. 9197 C.1.4. SAVP/UDP 9199 The RTP profile "The Secure Real-time Transport Protocol (SRTP)" 9200 [RFC3711] is an RTP profile (SAVP) that MAY be used in RTSP sessions 9201 using RTP. All that is defined for AVP SHALL also apply for SAVP. 9203 The usage of SRTP requires that a security association is 9204 established. The RECOMMENDED mechanism for establishing that 9205 security association is to use MIKEY with RTSP as defined in RFC 4567 9206 [RFC4567]. 9208 C.1.5. SAVPF/UDP 9210 The RTP profile "Extended Secure RTP Profile for RTCP-based Feedback 9211 (RTP/SAVPF)" [RFC5124] is an RTP profile (SAVPF) that MAY be used in 9212 RTSP sessions using RTP. All that is defined for AVP SHALL also 9213 apply for SAVPF. 9215 The usage of SRTP requires that a security association is 9216 established. The RECOMMENDED mechanism for establishing that 9217 security association is to use MIKEY[RFC3830] with RTSP as defined in 9218 RFC 4567 [RFC4567]. 9220 C.1.6. RTCP usage with RTSP 9222 RTCP has several usages when RTP is used for media transport as 9223 explained below. Due to that RTCP SHALL be supported if an RTSP 9224 agent handles RTP. 9226 C.1.6.1. Media synchronization 9228 RTCP provides media synchronization and clock drift compensation. 9229 The first is available from RTP-Info header to accomplish the initial 9230 synchronization. But to be able to handle any clockdrift between the 9231 media streams, RTCP is needed. 9233 C.1.6.2. RTSP Session keep-alive 9235 RTCP traffic from the RTSP client to the RTSP server SHALL function 9236 as keep-alive. Which requires an RTSP server supporting RTP to use 9237 the received RTCP packets as indications that the client desires the 9238 related RTSP session to be kept alive. 9240 C.1.6.3. Bit-rate adapation 9242 RTCP Receiver reports and any additional feedback from the client 9243 SHALL be used adapt the bit-rate used over the transport for all 9244 cases when RTP is sent over UDP. A RTP sender without reserved 9245 resources SHALL NOT use more than its fair share of the available 9246 resources. This can be determined by comparing on short to medium 9247 term (some seconds) the used bit-rate and adapt it so that the RTP 9248 sender sends at a bit-rate comparable to what a TCP sender would 9249 achieve on average over the same path. 9251 C.2. RTP over TCP 9253 Transport of RTP over TCP can be done in two ways, over independent 9254 TCP connections using RFC 4571 [RFC4571] or interleaved in the RTSP 9255 control connection. In both cases the protocol SHALL be "rtp" and 9256 the lower layer SHALL be TCP. The profile may be any of the above 9257 specified ones; AVP, AVPF, SAVP or SAVPF. 9259 C.2.1. Interleaved RTP over TCP 9261 The use of embedded (interleaved) binary data transported on the RTSP 9262 connection is possible as specified in Section 14. When using this 9263 declared combination of interleaved binary data the RTSP messages 9264 MUST be transported over TCP. TLS may or may not be used. 9266 One should however consider that this will result that all media 9267 streams go through any proxy. Using independent TCP connections can 9268 avoid that issue. 9270 C.2.2. RTP over independent TCP 9272 In this Appendix, we describe the sending of RTP [RFC3550] over lower 9273 transport layer TCP [RFC0793] according to "Framing Real-time 9274 Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over 9275 Connection-Oriented Transport" [RFC4571]. This Appendix adapts the 9276 guidelines for using RTP over TCP within SIP/SDP [RFC4145] to work 9277 with RTSP. 9279 A client codes the support of RTP over independent TCP by specifying 9280 an RTP/AVP/TCP transport option without an interleaved parameter in 9281 the Transport line of a SETUP request. This transport option MUST 9282 include the "unicast" parameter. 9284 If the client wishes to use RTP with RTCP, two ports (or two address/ 9285 port pairs) are specified by the dest_addr parameter. If the client 9286 wishes to use RTP without RTCP, one port (or one address/port pair) 9287 is specified by the dest_addr parameter. Ordering rules of dest_addr 9288 ports follow the rules for RTP/AVP/UDP. 9290 If the client wishes to play the active role in initiating the TCP 9291 connection, it MAY set the "setup" parameter (See Section 16.51) on 9292 the Transport line to be "active", or it MAY omit the setup 9293 parameter, as active is the default. If the client signals the 9294 active role, the ports for all dest_addr values MUST be set to 9 (the 9295 discard port). 9297 If the client wishes to play the passive role in TCP connection 9298 initiation, it MUST set the "setup" parameter on the Transport line 9299 to be "passive". If the client is able to assume the active or the 9300 passive role, it MUST set the "setup" parameter on the Transport line 9301 to be "actpass". In either case, the dest_addr port value for RTP 9302 MUST be set to the TCP port number on which the client is expecting 9303 to receive the RTP stream connection, and the dest_addr port value 9304 for RTCP MUST be set to the TCP port number on which the client is 9305 expecting to receive the RTCP stream connection. 9307 If upon receipt of a non-interleaved RTP/AVP/TCP SETUP request, a 9308 server decides to accept this requested option, the 2xx reply MUST 9309 contain a Transport option that specifies RTP/AVP/TCP (without using 9310 the interleaved parameter, and with using the unicast parameter). 9311 The dest_addr parameter value MUST be echoed from the parameter value 9312 in the client request unless the destination address (only port) was 9313 not provided in which can the server MAY include the source address 9314 of the RTSP TCP connection with the port number unchanged. 9316 In addition, the server reply MUST set the setup parameter on the 9317 Transport line, to indicate the role the server will play in the 9318 connection setup. Permissible values are "active" (if a client set 9319 "setup" to "passive" or "actpass") and "passive" (if a client set 9320 "setup" to "active" or "actpass"). 9322 If a server sets "setup" to "passive", the "src_addr" in the reply 9323 MUST indicate the ports the server is willing to receive an RTP 9324 connection and (if the client requested an RTCP connection by 9325 specifying two dest_addr ports or address/port pairs) and RTCP 9326 connection. If a server sets "setup" to "active", the ports 9327 specified in "src_addr" MUST be set to 9. The server MAY use the 9328 "ssrc" parameter, following the guidance in Section 16.51. Port 9329 ordering for src_addr follows the rules for RTP/AVP/UDP. 9331 For cases when servers have a public IP-address it is RECOMMENDED 9332 that the server take the passive role and the client the active role. 9333 This help in cases when the client is behind a NAT. 9335 After sending (receiving) a 2xx reply for a SETUP method for a non- 9336 interleaved RTP/AVP/TCP media stream, the active party SHOULD 9337 initiate the TCP connection as soon as possible. The client SHALL 9338 NOT send a PLAY request prior to the establishment of all the TCP 9339 connections negotiated using SETUP for the session. In case the 9340 server receives a PLAY request in a session that has not yet 9341 established all the TCP connections, it SHALL respond using the 464 9342 "Data Transport Not Ready Yet" (Section 15.4.16) error code. 9344 Once the PLAY request for a media resource transported over non- 9345 interleaved RTP/AVP/TCP occurs, media begins to flow from server to 9346 client over the RTP TCP connection, and RTCP packets flow 9347 bidirectionally over the RTCP TCP connection. As in the RTP/UDP 9348 case, client to server traffic on the TCP port is unspecified by this 9349 memo. The packets that travel on these connections SHALL be framed 9350 using the protocol defined in [RFC4571], not by the framing defined 9351 for interleaving RTP over the RTSP control connection defined in 9352 Section 14. 9354 A successful PAUSE request for a media being transported over RTP/ 9355 AVP/TCP pauses the flow of packets over the connections, without 9356 closing the connections. A successful TEARDOWN request signals that 9357 the TCP connections for RTP and RTCP are to be closed as soon as 9358 possible. 9360 Subsequent SETUP requests on an already-SETUP RTP/AVP/TCP URI may be 9361 ambiguous in the following way: does the client wish to open up new 9362 TCP RTP and RTCP connections for the URI, or does the client wish to 9363 continue using the existing TCP RTP and RTCP connections? The client 9364 SHOULD use the "connection" parameter (defined in Section 16.51) on 9365 the Transport line to make its intention clear in the regard (by 9366 setting "connection" to "new" if new connections are needed, and by 9367 setting "connection" to "existing" if the existing connections are to 9368 be used). After a 2xx reply for a SETUP request for a new 9369 connection, parties should close the pre-existing connections, after 9370 waiting a suitable period for any stray RTP or RTCP packets to 9371 arrive. 9373 Below, we rewrite part of the example media on demand example shown 9374 in Appendix A.1 to use RTP/AVP/TCP non-interleaved: 9376 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 9377 CSeq: 1 9378 User-Agent: PhonyClient/1.2 9380 M->C: RTSP/2.0 200 OK 9381 CSeq: 1 9382 Server: PhonyServer/1.0 9383 Date: Thu, 23 Jan 1997 15:35:06 GMT 9384 Content-Type: application/sdp 9385 Content-Length: 227 9386 Content-Base: rtsp://example.com/twister.3gp/ 9387 Expires: 24 Jan 1997 15:35:06 GMT 9389 v=0 9390 o=- 2890844256 2890842807 IN IP4 192.0.2.5 9391 s=RTSP Session 9392 i=An Example of RTSP Session Usage 9393 e=adm@example.com 9394 c=IN IP4 0.0.0.0 9395 a=control: * 9396 a=range: npt=0-0:10:34.10 9397 t=0 0 9398 m=audio 0 RTP/AVP 0 9399 a=control: trackID=1 9401 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 9402 CSeq: 2 9403 User-Agent: PhonyClient/1.2 9404 Require: play.basic 9405 Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9" 9406 setup=active;connection=new 9408 Accept-Ranges: NPT, SMPTE, UTC 9410 M->C: RTSP/2.0 200 OK 9411 CSeq: 2 9412 Server: PhonyServer/1.0 9413 Transport: RTP/AVP/TCP;unicast; 9414 dest_addr=":9"/":9"; 9415 src_addr="192.0.2.5:9000"/"192.0.2.5:9001" 9416 setup=passive;connection=new;ssrc=93CB001E 9417 Session: 12345678 9418 Expires: 24 Jan 1997 15:35:12 GMT 9419 Date: 23 Jan 1997 15:35:12 GMT 9420 Accept-Ranges: NPT 9422 C->M: TCP Connection Establishment 9424 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 9425 CSeq: 4 9426 User-Agent: PhonyClient/1.2 9427 Range: npt=0-10, npt=30- 9428 Session: 12345678 9430 M->C: RTSP/2.0 200 OK 9431 CSeq: 4 9432 Server: PhonyServer/1.0 9433 Date: 23 Jan 1997 15:35:14 GMT 9434 Session: 12345678 9435 Range: npt=0-10, npt=30-623.10 9436 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1" 9437 ssrc=4F312DD8:seq=54321;rtptime=2876889 9439 C.2.3. Handling Media Clock Time Jumps in the RTP Media Layer 9441 RTSP allows media clients to control selected, non-contiguous 9442 sections of media presentations, rendering those streams with an RTP 9443 media layer[RFC3550]. Such control allows jumps to be created in 9444 media clock (e.g. NPT) timeline of the RTSP session. The simple 9445 case of jumps in media clock time is caused by multiple ranges in the 9446 range specifier of a PLAY request. This allows the media layer 9447 rendering the RTP stream without being affected by jumps in media 9448 clock time. The RTP timestamps for the next media segment is set so 9449 that they become continuous with the previous media segment in the 9450 request. The RTP sequence number for the first packet in the new 9451 segment will be the next following the last packet in the previous 9452 segment, i.e. monotonically increasing. The goal is to allow the 9453 media rendering layer to work without interruption or reconfiguration 9454 across the jumps in media clock. This should be possible in all 9455 cases of multiple ranges in a PLAY request for media that has random- 9456 access properties. It is also possible when one PLAY request 9457 replaces another ongoing for media with random-access properties. In 9458 both cases care to align frames or similar media dependent structures 9459 are need but likely possible. 9461 In cases where jumps in media clock time are a result of RTSP 9462 signalling operations arriving during or after an PLAY operation, the 9463 processing delay or request timing can result in that media becomes 9464 non-continuous. The server becomes unable to send the media so that 9465 it arrive timely and still carry timestamps to make the media stream 9466 continuous. In these cases the server will produce RTP streams where 9467 there are gaps in the RTP timeline for the media. In such cases, if 9468 the media has frame structure, aligning the timestamp for the next 9469 frame with the previous structure reduces the burden to render this 9470 media. The gap should represent the time the server hasn't been 9471 serving media, e.g. the time between the end of the media stream or a 9472 PAUSE request and the new PLAY request. In these cases the RTP 9473 sequence number would normally be monotonically increasing across the 9474 gap. 9476 For RTSP sessions with media that lacks random access properties, 9477 like live streams, any media clock jump is commonly result of 9478 correspondingly long pause of delivery. The RTP timestamp will have 9479 increased in direct proportion to the duration of the paused 9480 delivery. Not also that in this case the RTP sequence number should 9481 be the next packet number. If not, the RTCP packet loss reporting 9482 will indicate as loss all packets not received between the point of 9483 pausing and later resuming. This may trigger congestion avoidance 9484 mechanisms. 9486 The goal when handling jumps in media clock time is that the provided 9487 stream is continuous without gaps in RTP timestamp or sequence 9488 number. However, when delivery has been halted for some reason the 9489 RTP timestamp when resuming SHALL represent the duration the delivery 9490 was halted. RTP sequence number MUST be the next number. A client 9491 can not rely on that a server will align when resuming playing even 9492 if it is RECOMMENDED. The RTP-Info header will provide information 9493 if this have occurred or not. 9495 We cannot assume that the RTSP client can communicate with the RTP 9496 media agent, as the two may be independent processes. If the RTP 9497 timestamp shows the same gap as the NPT, the media agent will 9498 assume that there is a pause in the presentation. If the jump in 9499 NPT is large enough, the RTP timestamp may roll over and the media 9500 agent may believe later packets to be duplicates of packets just 9501 played out. Having the RTP timestamp jump will also affect the 9502 RTCP measurements based on this. 9504 As an example, assume a RTP timestamp frequency of 8000 Hz, a 9505 packetization interval of 100 ms and an initial sequence number and 9506 timestamp of zero. 9508 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 9509 CSeq: 4 9510 Session: abcdefg 9511 Range: npt=10-15 9512 User-Agent: PhonyClient/1.2 9514 S->C: RTSP/2.0 200 OK 9515 CSeq: 4 9516 Session: abcdefg 9517 Range: npt=10-15 9518 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 9519 ssrc=0D12F123:seq=0;rtptime=0 9521 The ensuing RTP data stream is depicted below: 9523 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 9524 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 9525 . . . 9526 S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s 9528 Immediately after the end of the play range, the client follows up 9529 with a request to PLAY from a new NPT. 9531 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 9532 CSeq: 5 9533 Session: abcdefg 9534 Range: npt=18-20 9535 User-Agent: PhonyClient/1.2 9537 S->C: RTSP/2.0 200 OK 9538 CSeq: 5 9539 Session: abcdefg 9540 Range: npt=18-20 9541 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 9542 ssrc=0D12F123:seq=50;rtptime=40100 9544 The ensuing RTP data stream is depicted below: 9546 S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s 9547 S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s 9548 . . . 9549 S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s 9551 In this example, first, NPT 10 through 15 is played, then the client 9552 request the server to skip ahead and play NPT 18 through 20. The 9553 first segment is presented as RTP packets with sequence numbers 0 9554 through 49 and timestamp 0 through 39,200. The second segment 9555 consists of RTP packets with sequence number 50 through 69, with 9556 timestamps 40,100 through 55,200. While there is a gap in the NPT, 9557 there is no gap in the sequence number space of the RTP data stream. 9559 The RTP timestamp gap is present in the above example due to the time 9560 it takes to perform the second play request, in this case 12.5 ms 9561 (100/8000). To avoid this gap in playback due to the time it takes 9562 to perform RTSP requests, a PLAY request with multiple ranges needs 9563 to be specified. That would result in the following example: 9565 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 9566 CSeq: 4 9567 Session: abcdefg 9568 Range: npt=10-15;npt=18-20 9569 User-Agent: PhonyClient/1.2 9571 S->C: RTSP/2.0 200 OK 9572 CSeq: 4 9573 Session: abcdefg 9574 Range: npt=10-15 9575 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 9576 ssrc=0D12F123:seq=0;rtptime=0 9578 The ensuing RTP data stream is depicted below: 9580 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 9581 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 9582 . . . 9583 S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s 9584 S -> C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s 9585 S -> C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s 9586 . . . 9587 S -> C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s 9589 C.2.4. Handling RTP Timestamps after PAUSE 9591 During a PAUSE / PLAY interaction in an RTSP session, the duration of 9592 time for which the RTP transmission was halted MUST be reflected in 9593 the RTP timestamp of each RTP stream. The duration can be calculated 9594 for each RTP stream as the time elapsed from when the last RTP packet 9595 was sent before the PAUSE request was received and when the first RTP 9596 packet was sent after the subsequent PLAY request was received. The 9597 duration includes all latency incurred and processing time required 9598 to complete the request. 9600 The RTP RFC [RFC3550] states that: The RTP timestamp for each 9601 unit[packet] would be related to the wallclock time at which the 9602 unit becomes current on the virtual presentation timeline. 9604 In order to satisfy the requirements of [RFC3550], the RTP 9605 timestamp space needs to increase continuously with real time. 9606 While this is not optimal for stored media, it is required for RTP 9607 and RTCP to function as intended. Using a continuous RTP 9608 timestamp space allows the same timestamp model for both stored 9609 and live media and allows better opportunity to integrate both 9610 types of media under a single control. 9612 As an example, assume a clock frequency of 8000 Hz, a packetization 9613 interval of 100 ms and an initial sequence number and timestamp of 9614 zero. 9616 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 9617 CSeq: 4 9618 Session: abcdefg 9619 Range: npt=10-15 9620 User-Agent: PhonyClient/1.2 9622 S->C: RTSP/2.0 200 OK 9623 CSeq: 4 9624 Session: abcdefg 9625 Range: npt=10-15 9626 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 9627 ssrc=0D12F123:seq=0;rtptime=0 9629 The ensuing RTP data stream is depicted below: 9631 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 9632 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 9633 S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s 9634 S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s 9636 The client then sends a PAUSE request: 9638 C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0 9639 CSeq: 5 9640 Session: abdcdefg 9641 User-Agent: PhonyClient/1.2 9643 S->C: RTSP/2.0 200 OK 9644 CSeq: 5 9645 Session: abcdefg 9646 Range: npt=10.4-15 9648 20 seconds elapse and then the client sends a PLAY request. In 9649 addition the server requires 15 ms to process the request: 9651 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 9652 CSeq: 6 9653 Session: abcdefg 9654 User-Agent: PhonyClient/1.2 9656 S->C: RTSP/2.0 200 OK 9657 CSeq: 6 9658 Session: abcdefg 9659 Range: npt=10.4-15 9660 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 9661 ssrc=0D12F123:seq=4;rtptime=164400 9663 The ensuing RTP data stream is depicted below: 9665 S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s 9666 S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s 9667 S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s 9669 First, NPT 10 through 10.3 is played, then a PAUSE is received by the 9670 server. After 20 seconds a PLAY is received by the server which take 9671 15ms to process. The duration of time for which the session was 9672 paused is reflected in the RTP timestamp of the RTP packets sent 9673 after this PLAY request. 9675 A client can use the RTSP range header and RTP-Info header to map NPT 9676 time of a presentation with the RTP timestamp. 9678 Note: In RFC 2326 [RFC2326], this matter was not clearly defined and 9679 was misunderstood commonly. However for RTSP 2.0 it is expected that 9680 this will be handled correctly and no exception handling will be 9681 required. 9683 C.2.5. RTSP / RTP Integration 9685 For certain datatypes, tight integration between the RTSP layer and 9686 the RTP layer will be necessary. This by no means precludes the 9687 above restrictions. Combined RTSP/RTP media clients should use the 9688 RTP-Info field to determine whether incoming RTP packets were sent 9689 before or after a seek or before or after a PAUSE. 9691 C.2.6. Scaling with RTP 9693 For scaling (see Section 16.44), RTP timestamps should correspond to 9694 the playback timing. For example, when playing video recorded at 30 9695 frames/second at a scale of two and speed (Section 16.46) of one, the 9696 server would drop every second frame to maintain and deliver video 9697 packets with the normal timestamp spacing of 3,000 per frame, but NPT 9698 would increase by 1/15 second for each video frame. 9700 Note: The above scaling puts requirements on the media codec or a 9701 media stream to support it. For example motion JPEG or other non- 9702 predictive video coding can easier handle the above example. 9704 C.2.7. Maintaining NPT synchronization with RTP timestamps 9706 The client can maintain a correct display of NPT (Normal Play Time) 9707 by noting the RTP timestamp value of the first packet arriving after 9708 repositioning. The sequence parameter of the RTP-Info 9709 (Section 16.43) header provides the first sequence number of the next 9710 segment. 9712 C.2.8. Continuous Audio 9714 For continuous audio, the server SHOULD set the RTP marker bit at the 9715 beginning of serving a new PLAY request or at jumps in timeline. 9716 This allows the client to perform playout delay adaptation. 9718 C.2.9. Multiple Sources in an RTP Session 9720 Note that more than one SSRC MAY be sent in the media stream. If it 9721 happens all sources are expected to be rendered simultaneously. 9723 C.2.10. Usage of SSRCs and the RTCP BYE Message During an RTSP Session 9725 The RTCP BYE message indicates the end of use of a given SSRC. If 9726 all sources leave an RTP session, it can, in most cases, be assumed 9727 to have ended. Therefore, a client or server SHALL NOT send a RTCP 9728 BYE message until it has finished using a SSRC. A server SHOULD keep 9729 using a SSRC until the RTP session is terminated. Prolonging the use 9730 of a SSRC allows the established synchronization context associated 9731 with that SSRC to be used to synchronize subsequent PLAY requests 9732 even if the PLAY response is late. 9734 An SSRC collision with the SSRC that transmits media does also have 9735 consequences, as it will force the media sender to change its SSRC in 9736 accordance with the RTP specification[RFC3550]. This will result in 9737 a loss of synchronization context, and require any receiver to wait 9738 for RTCP sender reports for all media requiring synchronization 9739 before being able to play out synchronized. Due to these reasons a 9740 client joining a session should take care to not select the same SSRC 9741 as the server. Any SSRC signalled in the Transport header SHOULD be 9742 avoided. A client detecting a collision prior to sending any RTP or 9743 RTCP messages can also select a new SSRC. 9745 C.3. Future Additions 9747 It is the intention that any future protocol or profile regarding 9748 both for media delivery and lower transport should be easy to add to 9749 RTSP. This section provides the necessary steps that needs to be 9750 meet. 9752 The following things needs to be considered when adding a new 9753 protocol of profile for use with RTSP: 9755 o The protocol or profile needs to define a name tag representing 9756 it. This tag is required to be a ABNF "token" to be possible to 9757 use in the Transport header specification. 9759 o The useful combinations of protocol, profiles and lower layer 9760 transport for this extension needs to be defined. For each 9761 combination declare the necessary parameters to use in the 9762 Transport header. 9764 o For new media protocols the interaction with RTSP needs to be 9765 addressed. One important factor will be the media 9766 synchronization. May need new headers similar to RTP info to 9767 carry information. 9769 o Discuss congestion control for media, especially if transport 9770 without built in congestion control is used. 9772 See the IANA section (Section 22) for information how to register new 9773 attributes. 9775 Appendix D. Use of SDP for RTSP Session Descriptions 9777 The Session Description Protocol (SDP, [RFC4566]) may be used to 9778 describe streams or presentations in RTSP. This description is 9779 typically returned in reply to a DESCRIBE request on an URI from a 9780 server to a client, or received via HTTP from a server to a client. 9782 This appendix describes how an SDP file determines the operation of 9783 an RTSP session. SDP as is provides no mechanism by which a client 9784 can distinguish, without human guidance, between several media 9785 streams to be rendered simultaneously and a set of alternatives 9786 (e.g., two audio streams spoken in different languages). However the 9787 SDP extension "Grouping of Media Lines in the Session Description 9788 Protocol (SDP)" [RFC3388] may provide such functionality depending on 9789 need. Also future grouping semantics may in the future be developed. 9791 D.1. Definitions 9793 The terms "session-level", "media-level" and other key/attribute 9794 names and values used in this appendix are to be used as defined in 9795 SDP (RFC 4566 [RFC4566]): 9797 D.1.1. Control URI 9799 The "a=control:" attribute is used to convey the control URI. This 9800 attribute is used both for the session and media descriptions. If 9801 used for individual media, it indicates the URI to be used for 9802 controlling that particular media stream. If found at the session 9803 level, the attribute indicates the URI for aggregate control 9804 (presentation URI). The session level URI SHALL be different from 9805 any media level URI. The presence of a session level control 9806 attribute SHALL be interpreted as support for aggregated control. 9807 The control attribute SHALL be present on media level unless the 9808 presentation only contains a single media stream, in which case the 9809 attribute MAY only be present on the session level. 9811 ABNF for the attribute is defined in Section 20.3. 9813 Example: 9814 a=control:rtsp://example.com/foo 9816 This attribute MAY contain either relative or absolute URIs, 9817 following the rules and conventions set out in RFC 3986 [RFC3986]. 9818 Implementations SHALL look for a base URI in the following order: 9820 1. the RTSP Content-Base field; 9821 2. the RTSP Content-Location field; 9823 3. the RTSP Request-URI. 9825 If this attribute contains only an asterisk (*), then the URI SHALL 9826 be treated as if it were an empty embedded URI, and thus inherit the 9827 entire base URI. 9829 Note, RFC 2326 was very unclear on the processing of relative URI 9830 and several RTSP 1.0 implementations at the point of publishing 9831 this document did not perform RFC 3986 processing to determine the 9832 resulting URI, instead simple concatenation is common. To avoid 9833 this issue completely it is recommended to use absolute URI in the 9834 SDP. 9836 The URI handling for SDPs from container files need special 9837 consideration. For example lets assume that a container file has the 9838 URI: "rtsp://example.com/container.mp4". Lets further assume this 9839 URI is the base URI, and that there is a absolute media level URI: 9840 "rtsp://example.com/container.mp4/trackID=2". A relative media level 9841 URI that resolves in accordance with RFC 3986 [RFC3986] to the above 9842 given media URI is: "container.mp4/trackID=2". It is usually not 9843 desirable to need to include in or modify the SDP stored within the 9844 container file with the server local name of the container file. To 9845 avoid this, one can modify the base URI used to include a trailing 9846 slash, e.g. "rtsp://example.com/container.mp4/". In this case the 9847 relative URI for the media will only need to be: "trackID=2". 9848 However this will also mean that using "*" in the SDP will result in 9849 control URI including the trailing slash, i.e. 9850 "rtsp://example.com/container.mp4/". 9852 Note: The usage of TrackID in the above is not an standardized 9853 form, but one example out of several similar strings such as 9854 TrackID, Track_ID, StreamID that is used by different server 9855 vendors to indicate a particular piece of media inside a container 9856 file. 9858 D.1.2. Media Streams 9860 The "m=" field is used to enumerate the streams. It is expected that 9861 all the specified streams will be rendered with appropriate 9862 synchronization. If the session is over multicast, the port number 9863 indicated SHOULD be used for reception. The client MAY try to 9864 override the destination port, through the Transport header. The 9865 servers MAY allow this, the response will indicate if allowed or not. 9866 If the session is unicast, the port number is the ones RECOMMENDED by 9867 the server to the client, about which receiver ports to use; the 9868 client MUST still include its receiver ports in its SETUP request. 9870 The client MAY ignore this recommendation. If the server has no 9871 preference, it SHOULD set the port number value to zero. 9873 The "m=" lines contain information about what transport protocol, 9874 profile, and possibly lower-layer is to be used for the media stream. 9875 The combination of transport, profile and lower layer, like RTP/AVP/ 9876 UDP needs to be defined for how to be used with RTSP. The currently 9877 defined combinations are defined in Appendix C, further combinations 9878 MAY be specified. 9880 Usage of grouping of media lines [RFC3388] to determine which media 9881 lines should or should not be included in a RTSP session is 9882 unspecified. 9884 Example: 9885 m=audio 0 RTP/AVP 31 9887 D.1.3. Payload Type(s) 9889 The payload type(s) are specified in the "m=" line. In case the 9890 payload type is a static payload type from RFC 3551 [RFC3551], no 9891 other information may be required. In case it is a dynamic payload 9892 type, the media attribute "rtpmap" is used to specify what the media 9893 is. The "encoding name" within the "rtpmap" attribute may be one of 9894 those specified in RFC 3551 (Sections 5 and 6), or an MIME type 9895 registered with IANA, or an experimental encoding as specified in SDP 9896 (RFC 4566 [RFC4566]). Codec-specific parameters are not specified in 9897 this field, but rather in the "fmtp" attribute described below. 9899 D.1.4. Format-Specific Parameters 9901 Format-specific parameters are conveyed using the "fmtp" media 9902 attribute. The syntax of the "fmtp" attribute is specific to the 9903 encoding(s) that the attribute refers to. Note that some of the 9904 format specific parameters may be specified outside of the fmtp 9905 parameters, like for example the "ptime" attribute for most audio 9906 encodings. 9908 D.1.5. Directionality of media stream 9910 The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly" 9911 provides instructions on which direction the media streams flow 9912 within a session. When using RTSP the SDP can be delivered to a 9913 client using either RTSP DESCRIBE or a number of RTSP external 9914 methods, like HTTP, FTP, and email. Based on this the SDP applies to 9915 how the RTSP client will see the complete session. Thus for media 9916 streams delivered from the RTSP server to the client would be given 9917 the "a=recvonly" attribute. 9919 The direction attributes are not commonly used in SDPs for RTSP, but 9920 may occur. "a=recvonly" in a SDP provided to the RTSP client SHALL 9921 indicate that media delivery will only occur in the direction from 9922 the RTSP server to the client. In SDP provided to the RTSP client 9923 that lacks any of the directionality attributes (a=recvonly, 9924 a=sendonly, a=sendrecv) SHALL behave as if the "a=recvonly" attribute 9925 was received. Note that this overrules the normal default rule 9926 defined in SDP[RFC4566]. The usage of "a=sendonly" or "a=sendrecv" 9927 is not defined, nor is the interpretation of SDP by other entities 9928 than the RTSP client. 9930 D.1.6. Range of Presentation 9932 The "a=range" attribute defines the total time range of the stored 9933 session or an individual media. Non-seekable live sessions can be 9934 indicated, while the length of live sessions can be deduced from the 9935 "t" and "r" SDP parameters. 9937 The attribute is both a session and a media level attribute. For 9938 presentations that contains media streams of the same durations, the 9939 range attribute SHOULD only be used at session-level. In case of 9940 different length the range attribute MUST be given at media level for 9941 all media, and SHOULD NOT be given at session level. If the 9942 attribute is present at both media level and session level the media 9943 level values SHALL be used. 9945 Note: Usually one will specify the same length for all media, even if 9946 there isn't media available for the full duration on all media. 9947 However that requires that the server accepts PLAY requests within 9948 that range. 9950 Servers SHALL take care to provide RTSP Range (see Section 16.38) 9951 values that are consistent with what is presented in the SDP for the 9952 content. There are no reason for non dynamic content, like media 9953 clips provided on demand to have inconsistent values. Inconsistent 9954 values between the SDP and the actual values for the content handled 9955 by the server is likely to generate some failure, like 457 "Invalid 9956 Range", in case the client uses PLAY requests with a Range header. 9957 In case the content is dynamic in length and it is infeasible to 9958 provide a correct value in the SDP the server is recommended to 9959 describe this as non-seekable content (see below). The server MAY 9960 override that property in the response to a PLAY request using the 9961 correct values in the Range header. 9963 The unit is specified first, followed by the value range. The units 9964 and their values are as defined in Section 4.4, Section 4.5 and 9965 Section 4.6 and MAY be extended with further formats. Any open ended 9966 range (start-), i.e. without stop range, is of unspecified duration 9967 and SHALL be considered as non-seekable content unless this property 9968 is overridden. Multiple instances carrying different clock formats 9969 MAY be included at either session or media level. 9971 ABNF for the attribute is defined in Section 20.3. 9973 Examples: 9974 a=range:npt=0-34.4368 9975 a=range:clock=19971113T211503Z-19971113T220300Z 9976 Non seekable stream of unknown duration: 9977 a=range:npt=0- 9979 D.1.7. Time of Availability 9981 The "t=" field MUST contain suitable values for the start and stop 9982 times for both aggregate and non-aggregate stream control. The 9983 server SHOULD indicate a stop time value for which it guarantees the 9984 description to be valid, and a start time that is equal to or before 9985 the time at which the DESCRIBE request was received. It MAY also 9986 indicate start and stop times of 0, meaning that the session is 9987 always available. 9989 For sessions that are of live type, i.e. specific start time, unknown 9990 stop time, likely unseekable, the "t=" and "r=" field SHOULD be used 9991 to indicate the start time of the event. The stop time SHOULD be 9992 given so that the live event will have ended at that time, while 9993 still not be unnecessary long into the future. 9995 D.1.8. Connection Information 9997 In SDP, the "c=" field contains the destination address for the media 9998 stream. For on-demand unicast streams and some multicast streams, 9999 the destination address MAY be specified by the client via the SETUP 10000 request, thus overriding any specified address. To identify streams 10001 without a fixed destination address, where the client is required to 10002 specify a destination address, the "c=" field SHOULD be set to a null 10003 value. For addresses of type "IP4", this value SHALL be "0.0.0.0", 10004 and for type "IP6", this value SHALL be "0:0:0:0:0:0:0:0", i.e. the 10005 unspecified address according to RFC 4291 [RFC4291]. 10007 D.1.9. Entity Tag 10009 The optional "a=etag" attribute identifies a version of the session 10010 description. It is opaque to the client. SETUP requests may include 10011 this identifier in the If-Match field (see Section 16.24) to only 10012 allow session establishment if this attribute value still corresponds 10013 to that of the current description. The attribute value is opaque 10014 and may contain any character allowed within SDP attribute values. 10016 ABNF for the attribute is defined in Section 20.3. 10018 Example: 10019 a=etag:"158bb3e7c7fd62ce67f12b533f06b83a" 10021 One could argue that the "o=" field provides identical 10022 functionality. However, it does so in a manner that would put 10023 constraints on servers that need to support multiple session 10024 description types other than SDP for the same piece of media 10025 content. 10027 D.2. Aggregate Control Not Available 10029 If a presentation does not support aggregate control no session level 10030 "a=control:" attribute is specified. For a SDP with multiple media 10031 sections specified, each section will have its own control URI 10032 specified via the "a=control:" attribute. 10034 Example: 10035 v=0 10036 o=- 2890844256 2890842807 IN IP4 192.0.2.56 10037 s=I came from a web page 10038 e=adm@example.com 10039 c=IN IP4 0.0.0.0 10040 t=0 0 10041 m=video 8002 RTP/AVP 31 10042 a=control:rtsp://audio.com/movie.aud 10043 m=audio 8004 RTP/AVP 3 10044 a=control:rtsp://video.com/movie.vid 10046 Note that the position of the control URI in the description implies 10047 that the client establishes separate RTSP control sessions to the 10048 servers audio.com and video.com. 10050 It is recommended that an SDP file contains the complete media 10051 initialization information even if it is delivered to the media 10052 client through non-RTSP means. This is necessary as there is no 10053 mechanism to indicate that the client should request more detailed 10054 media stream information via DESCRIBE. 10056 D.3. Aggregate Control Available 10058 In this scenario, the server has multiple streams that can be 10059 controlled as a whole. In this case, there are both a media-level 10060 "a=control:" attributes, which are used to specify the stream URIs, 10061 and a session-level "a=control:" attribute which is used as the 10062 Request-URI for aggregate control. If the media-level URI is 10063 relative, it is resolved to absolute URIs according to Appendix D.1.1 10064 above. 10066 Example: 10067 C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0 10068 CSeq: 1 10069 User-Agent: PhonyClient/1.2 10071 M->C: RTSP/2.0 200 OK 10072 CSeq: 1 10073 Date: Thu, 23 Jan 1997 15:35:06 GMT 10074 Content-Type: application/sdp 10075 Content-Base: rtsp://example.com/movie/ 10076 Content-Length: 227 10078 v=0 10079 o=- 2890844256 2890842807 IN IP4 192.0.2.211 10080 s=I contain 10081 i= 10082 e=adm@example.com 10083 c=IN IP4 0.0.0.0 10084 a=control:* 10085 t=0 0 10086 m=video 8002 RTP/AVP 31 10087 a=control:trackID=1 10088 m=audio 8004 RTP/AVP 3 10089 a=control:trackID=2 10091 In this example, the client is required to establish a single RTSP 10092 session to the server, and uses the URIs 10093 rtsp://example.com/movie/trackID=1 and 10094 rtsp://example.com/movie/trackID=2 to set up the video and audio 10095 streams, respectively. The URI rtsp://example.com/movie/, which is 10096 resolved from the "*", controls the whole presentation (movie). 10098 A client is not required to issues SETUP requests for all streams 10099 within an aggregate object. Servers should allow the client to ask 10100 for only a subset of the streams. 10102 D.4. RTSP external SDP delivery 10104 There are some considerations that needs to be made when the session 10105 description is delivered to client outside of RTSP, for example in 10106 HTTP or email. 10108 First of all the SDP needs to contain absolute URIs, relative will in 10109 most cases not work as the delivery will not correctly forward the 10110 base URI. And as SDP might be temporarily stored on file system 10111 before being loaded into an RTSP capable client, thus if possible to 10112 transport the base URI it still would need to be merged into the 10113 file. 10115 The writing of the SDP session availability information, i.e. "t=" 10116 and "r=", needs to be carefully considered. When the SDP is fetched 10117 by the DESCRIBE method, the probability that it is valid is very 10118 high. However the same are much less certain for SDPs distributed 10119 using other methods. Therefore the publisher of the SDP should take 10120 care to follow the recommendations about availability in the SDP 10121 specification [RFC4566]. 10123 Appendix E. Text format for Parameters 10125 A resource of type "text/parameters" consists of either 1) a list of 10126 parameters (for a query) or 2) a list of parameters and associated 10127 values (for an response or setting of the parameter). Each entry of 10128 the list is a single line of text. Parameters are separated from 10129 values by a colon. The parameter name SHALL only use US-ASCII 10130 visable characters while the values are UTF-8 text strings. The 10131 media type registration template is in Section 22.15. 10133 There exist a potential interoperability issue for this format. It 10134 was named in RFC 2326 but never defined, even if used in examples 10135 that hint at the syntax. This format matches the purpose and its 10136 syntax supports the examples provided. However, it goes further by 10137 allowing UTF-8 in the vaue part, thus usage of UTF-8 strings may not 10138 be supported. However, as individual parameters are not defined, the 10139 using application anyway needs to have out-of-band agreement or using 10140 feature-tag to determine if the end-point supports the parameters. 10142 The ABNF [RFC5234] grammar for "text/parameters" content is: 10144 file = *((parameter / parameter-value) CRLF) 10145 parameter = 1*visible-except-colon 10146 parameter-value = parameter *WSP ":" value 10147 visible-except-colon = %x21-39 / %x3B-7E ; VCHAR - ":" 10148 value = *(TEXT-UTF8char / WSP) 10149 TEXT-UTF8char = %x21-7E / UTF8-NONASCII 10150 UTF8-NONASCII = %xC0-DF 1UTF8-CONT 10151 / %xE0-EF 2UTF8-CONT 10152 / %xF0-F7 3UTF8-CONT 10153 / %xF8-FB 4UTF8-CONT 10154 / %xFC-FD 5UTF8-CONT 10155 UTF8-CONT = %x80-BF 10156 WSP = ; Space or HTAB 10157 VCHAR = 10158 CRLF = 10160 Appendix F. Requirements for Unreliable Transport of RTSP 10162 This section provides anyone intending to define how to transport of 10163 RTSP messages over a unreliable transport protocol with some 10164 information learned by the attempt in RFC 2326 [RFC2326]. RFC 2326 10165 define both an URI scheme and some basic functionality for transport 10166 of RTSP messages over UDP, however it was not sufficient for reliable 10167 usage and successful interoperability. 10169 The RTSP scheme defined for unreliable transport of RTSP messages was 10170 "rtspu". It has been reserved by this specification as at least one 10171 commercial implementation exist, thus avoiding any collisions in the 10172 name space. 10174 The following considerations should exist for operation of RTSP over 10175 an unreliable transport protocol: 10177 o Request shall be acknowledged by the receiver. If there is no 10178 acknowledgement, the sender may resend the same message after a 10179 timeout of one round-trip time (RTT). Any retransmissions due to 10180 lack of acknowledgement must carry the same sequence number as the 10181 original request. 10183 o The round-trip time can be estimated as in TCP (RFC 1123) 10184 [RFC1123], with an initial round-trip value of 500 ms. An 10185 implementation may cache the last RTT measurement as the initial 10186 value for future connections. 10188 o If RTSP is used over a small-RTT LAN, standard procedures for 10189 optimizing initial TCP round trip estimates, such as those used in 10190 T/TCP (RFC 1644) [RFC1644], can be beneficial. 10192 o The Timestamp header (Section 16.50) is used to avoid the 10193 retransmission ambiguity problem [Stevens98]. 10195 o The registered default port for RTSP over UDP for the server is 10196 554. 10198 o RTSP messages can be carried over any lower-layer transport 10199 protocol that is 8-bit clean. 10201 o RTSP messages are vulnerable to bit errors and should not be 10202 subjected to them. 10204 o Source authentication, or at least validation that RTSP messages 10205 comes from the same entity becomes extremely important, as session 10206 hijacking may be substantially easier for RTSP message transport 10207 using an unreliable protocol like UDP than for TCP. 10209 There exist two RTSP headers thats primarily are intended for being 10210 used by the unreliable handling of RTSP messages and which will be 10211 maintained: 10213 o [CSeq] See Section 16.19 10215 o [Timestamp] See Section 16.50 10217 Appendix G. Backwards Compatibility Considerations 10219 This section contains notes on issues about backwards compatibility 10220 with clients or servers being implemented according to RFC 2326 10221 [RFC2326]. Note that there exist no requirement to implement RTSP 10222 1.0, in fact we recommend against it as it is difficult to do in an 10223 interoperable way. 10225 A server implementing RTSP/2.0 MUST include a RTSP-Version of 10226 RTSP/2.0 in all responses to requests containing RTSP-Version 10227 RTSP/2.0. If a server receives a RTSP/1.0 request, it MAY respond 10228 with a RTSP/1.0 response if it chooses to support RFC 2326. If the 10229 server chooses not to support RFC 2326, it SHALL respond with a 505 10230 (RTSP Version not supported) status code. A server MUST NOT respond 10231 to a RTSP-Version RTSP/1.0 request with a RTSP-Version RTSP/2.0 10232 response. 10234 Clients implementing RTSP/2.0 MAY use an OPTIONS request with a RTSP- 10235 Version of 2.0 to determine whether a server supports RTSP/2.0. If 10236 the server responds with either a RTSP-Version of 1.0 or a status 10237 code of 505 (RTSP Version not supported), the client will have to use 10238 RTSP/1.0 requests if it chooses to support RFC 2326. 10240 G.1. Play Request in Play mode 10242 The behavior in the server when a Play is received in Play mode has 10243 changed (Section 13.4). In RFC 2326, the new PLAY request would be 10244 queued until the current Play completed. Any new PLAY request now 10245 take effect immediately replacing the previous request. 10247 G.2. Using Persistent Connections 10249 Some server implementations of RFC 2326 maintain a one-to-one 10250 relationship between a connection and an RTSP session. Such 10251 implementations require clients to use a persistent connection to 10252 communicate with the server and when a client closes its connection, 10253 the server may remove the RTSP session. This is worth noting if a 10254 RTSP 2.0 client also supporting 1.0 connects to a 1.0 server. 10256 Appendix H. Open Issues 10258 Open issues are filed and tracked in the bug and feature trackers at 10259 http://rtspspec.sourceforge.net. Open issues are discussed on MMUSIC 10260 list. 10262 Appendix I. Changes 10264 Compared to RTSP 1.0 (RFC 2326), the below changes has been made when 10265 defining RTSP 2.0. Note that this list does not reflect minor 10266 changes in wording or correction of typographical errors. 10268 o The section on minimal implementation was deleted without 10269 substitution. 10271 o The Transport header has been changed in the following way: 10273 * The ABNF has been changed to define that extensions are 10274 possible, and that unknown extension parameters are to be 10275 ignored. 10277 * To prevent backwards compatibility issues, any extension or new 10278 parameter requires the usage of a feature-tag combined with the 10279 Require header. 10281 * Syntax unclarities with the Mode parameter has been resolved. 10283 * Syntax error with ";" for multicast and unicast has been 10284 resolved. 10286 * Two new addressing parameters has been defined, src_addr and 10287 dest_addr. These replaces the parameters "port", 10288 "client_port", "server_port", "destination", "source". 10290 * Support for IPv6 explicit addresses in all address fields has 10291 been included. 10293 * To handle URI definitions that contain ";" or "," a quoted URI 10294 format has been introduced and is required. 10296 * Defined IANA registries for the transport headers parameters, 10297 transport-protocol, profile, lower-transport, and mode. 10299 * The transport headers interleaved parameter's text was made 10300 more strict and use formal requirements levels. It was also 10301 clarified that the interleaved channels are symmetric and that 10302 it is the server that sets the channel numbers. 10304 * It has been clarified that the client can't request of the 10305 server to use a certain RTP SSRC, using a request with the 10306 transport parameter SSRC. 10308 * Syntax definition for SSRC has been clarified to require 8HEX. 10309 It has also been extend to allow multiple values for clients 10310 supporting this version. 10312 * Clarified the text on the transport headers "dest_addr" 10313 parameters regarding what security precautions the server is 10314 required to perform. 10316 o The Range formats has been changed in the following way: 10318 * The NPT format has been given a initial NPT identifier that 10319 must now be used. 10321 * All formats now support initial open ended formats of type 10322 "npt=-10". 10324 o RTSP message handling has been changed in the following way: 10326 * RTSP messages now uses URIs rather then URLs. 10328 * It has been clarified that a 4xx message due to missing CSeq 10329 header shall be returned without a CSeq header. 10331 * Rules for how to handle timing out RTSP messages has been 10332 added. 10334 * Extended Pipelining rules allowing for quick session startup. 10336 o The HTTP references has been updated to RFC 2616 and RFC 2617. 10337 This has resulted in that the Public, and the Content-Base header 10338 needed to be defined in the RTSP specification. Known effects on 10339 RTSP due to HTTP clarifications: 10341 * Content-Encoding header can include encoding of type 10342 "identity". 10344 o The state machine section has completely been rewritten. It 10345 includes now more details and are also more clear about the model 10346 used. 10348 o A IANA section has been included with contains a number of 10349 registries and their rules. This will allow us to use IANA to 10350 keep track of RTSP extensions. 10352 o Than transport of RTSP messages has seen the following changes: 10354 * The use of UDP for RTSP message transport has been deprecated 10355 due to missing interest and to broken specification. 10357 * The rules for how TCP connections is to be handled has been 10358 clarified. Now it is made clear that servers should not close 10359 the TCP connection unless they have been unused for significant 10360 time. 10362 * Strong recommendations why server and clients should use 10363 persistent connections has also been added. 10365 * There is now a requirement on the servers to handle non- 10366 persistent connections as this provides fault tolerance. 10368 * Added wording on the usage of Connection:Close for RTSP. 10370 * specified usage of TLS for RTSP messages, including a scheme to 10371 approve a proxies TLS connection to the next hop. 10373 o The following header related changes have been made: 10375 * Accept-Ranges response header is added. This header clarifies 10376 which range formats that can be used for a resource. 10378 * Changed the Range header to allow multiple ranges for creating 10379 editing list. 10381 * Fixed the missing definitions for the Cache-Control header. 10382 Also added to the syntax definition the missing delta-seconds 10383 for max-stale and min-fresh parameters. 10385 * Put requirement on CSeq header that the value is increased by 10386 one for each new RTSP request. A Recommendation to start at 1 10387 has also been added. 10389 * Added requirement that the Date header must be used for all 10390 messages with entity and the Server should always include it. 10392 * Removed possibility of using Range header with Scale header to 10393 indicate when it is to be activated, since it can't work as 10394 defined. Also added rule that lack of Scale header in response 10395 indicates lack of support for the header. Feature-tags for 10396 scaled playback has been defined. 10398 * The Speed header must now be responded to indicate support and 10399 the actual speed going to be used. A feature-tag is defined. 10400 Notes on congestion control was also added. 10402 * The Supported header was borrowed from SIP to help with the 10403 feature negotiation in RTSP. 10405 * Clarified that the Timestamp header can be used to resolve 10406 retransmission ambiguities. 10408 * The Session header text has been expanded with a explanation on 10409 keep alive and which methods to use. SET_PARAMETER is now 10410 recommended to use if only keep-alive within RTSP is desired. 10412 * It has been clarified how the Range header formats is used to 10413 indicate pause points in the PAUSE response. 10415 * Clarified that RTP-Info URIs that are relative, uses the 10416 Request-URI as base URI. Also clarified that used URI must be 10417 that one that was used in the SETUP request. They are now also 10418 required to be quoted. The header also expresses the SSRC for 10419 the provided RTP timestamp and sequence number values. 10421 * Added text that requires the Range to always be present in PLAY 10422 responses. Clarified what should be sent in case of live 10423 streams. 10425 * The headers table has been updated using a structured borrowed 10426 from SIP. Those tables carries much more information and 10427 should provide a good overview of the available headers. 10429 * It has been is clarified that any message with a message body 10430 is required to have a Content-Length header. This was the case 10431 in RFC 2326 but could be misinterpreted. 10433 * To resolve functionality around ETag. The ETag and If-None- 10434 Match header has been added from HTTP with necessary 10435 clarification in regards to RTSP operation. 10437 * Imported the Public header from HTTP RFC 2068 [RFC2068] since 10438 it has been removed from HTTP due to lack of use. Public is 10439 used quite frequently in RTSP. 10441 * Clarified rules for populating the Public header so that it is 10442 an intersection of the capabilities of all the RTSP agents in a 10443 chain. 10445 * Added the Media-Range header for listing the current 10446 availability of the media range. 10448 * Added the Notify-Reason header for giving the reason when 10449 sending PLAY_NOTIFY requests. 10451 o The Protocol Syntax has been changed in the following way: 10453 * All BNF definitions are updated according to the rules defined 10454 in RFC 5234 [RFC5234] and has been gathered in a separate 10455 Section 20. 10457 * The BNF for the User-Agent and Server headers has been 10458 corrected so now only the description is in the HTTP 10459 specification. 10461 * Some definitions in the introduction regarding the RTSP session 10462 has been changed. 10464 * The protocol has been made fully IPv6 capable. Certain of the 10465 functionality, like using explicit IPv6 addresses in fields 10466 requires that the protocol support this updated specification. 10468 * Added a fragment part to the RTSP URI. This seem to be 10469 indicated by the note below the definition however it was not 10470 part of the BNF. 10472 * The CHAR rule has been changed to exclude NULL. 10474 o The Status codes has been changed in the following way: 10476 * The use of status code 303 "See Other" has been deprecated as 10477 it does not make sense to use in RTSP. 10479 * When sending response 451 and 458 the response body should 10480 contain the offending parameters. 10482 * Clarification on when a 3rr redirect status code can be 10483 received has been added. This includes receiving 3rr as a 10484 result of request within a established session. This provides 10485 clarification to a previous unspecified behavior. 10487 * Removed the 201 (Created) and 250 (Low On Storage Space) status 10488 codes as they are only relevant to recording, which is 10489 deprecated. 10491 o The following functionality has been deprecated from the protocol: 10493 * The use of Queued Play. 10495 * The use of PLAY method for keep-alive in play state. 10497 * The RECORD and ANNOUNCE methods and all related functionality. 10498 Some of the syntax has been removed. 10500 * The possibility to use timed execution of methods with the time 10501 parameter in the Range header. 10503 * The description on how rtspu works is not part of the core 10504 specification and will require external description. Only that 10505 it exist is defined here and some requirements for the the 10506 transport is provided. 10508 o The following changes has been made in relation to methods: 10510 * The OPTIONS method has been clarified with regards to the use 10511 of the Public and Allow headers. 10513 * The RECORD and ANNOUNCE methods are removed as they are lacking 10514 implementation and not considered necessary in the core 10515 specification. Any work on these methods should be done as a 10516 extension document to RTSP. 10518 * Added text clarifying the usage of SET_PARAMETER for keep-alive 10519 and usage without any body. 10521 * PLAY method is now allowed to be pipelined with the pipelining 10522 of one or more SETUP requests following the initial that 10523 generates the session for aggregated control. 10525 o Wrote a new section about how to setup different media transport 10526 alternatives and their profiles, and lower layer protocols. This 10527 resulted that the appendix on RTP interaction was moved there 10528 instead in the part describing RTP. The section also includes 10529 guidelines what to think of when writing usage guidelines for new 10530 protocols and profiles. 10532 o Setup and usage of independent TCP connections for transport of 10533 RTP has been specified. 10535 o Added a new section describing the available mechanisms to 10536 determine if functionality is supported, called "Capability 10537 Handling". Renamed option-tags to feature-tags. 10539 o Added a contributors section with people who have contributed 10540 actual text to the specification. 10542 o Added a section Use Cases that describes the major use cases for 10543 RTSP. 10545 o Clarified the usage of a=range and how to indicate live content 10546 that are not seekable with this header. 10548 o Text specifying the special behavior of PLAY for live content. 10550 o Added a new method PLAY_NOTIFY. This method is used by the RTSP 10551 server to asynchronously notify clients about session changes. 10553 Appendix J. Acknowledgements 10555 This memorandum defines RTSP version 2.0 which is a revision of the 10556 Proposed Standard RTSP version 1.0 which is defined in [RFC2326]. 10557 The authors of this RFC are Henning Schulzrinne, Anup Rao, and Robert 10558 Lanphier. 10560 Both RTSP version 1.0 and RTSP versio 2.0 borrow format and 10561 descriptions from HTTP/1.1. 10563 This document has benefited greatly from the comments of all those 10564 participating in the MMUSIC-WG. In addition to those already 10565 mentioned, the following individuals have contributed to this 10566 specification: 10568 Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning, 10569 Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari, 10570 Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V. 10571 Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt, 10572 John K. Ho, Go Hori, Philipp Hoschka, Anne Jones, Anders Klemets, 10573 Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Thomas 10574 Marshall, Rob McCool, David Oran, Joerg Ott, Maria Papadopouli, Sujal 10575 Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Igor Plotnikov, 10576 Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff Smith, 10577 Alexander Sokolsky, Dale Stammen, John Francis Stracke, Maureen 10578 Chesire, David Walker, Geetha Srikantan, Stephan Wenger, Pekka Pessi, 10579 Jae-Hwan Kim, Holger Schmidt, Stephen Farrell, Xavier Marjou, Joe 10580 Pallas and Mela Martti. 10582 J.1. Contributors 10584 The following people have made written contributions that were 10585 included in the specification: 10587 o Tom Marshall contributed text on the usage of 3rr status codes. 10589 o Thomas Zheng contributed text on the usage of the Range in PLAY 10590 responses. 10592 o Sean Sheedy contributed text on the timeout behavior of RTSP 10593 messages and connections, and the 463 status code. 10595 o Fredrik Lindholm contributed text about the RTSP security 10596 framework. 10598 o John Lazzaro contributed the text for RTP over Independent TCP. 10600 o Aravind Narasimhan contributed by rewriting Media Transport 10601 Alternatives (Appendix C) and editorial improvements on a number 10602 of places in the specification. 10604 Appendix K. RFC Editor Consideration 10606 Please replace RFC XXXX with the RFC number this specification 10607 recieves. 10609 Authors' Addresses 10611 Henning Schulzrinne 10612 Columbia University 10613 1214 Amsterdam Avenue 10614 New York, NY 10027 10615 USA 10617 Email: schulzrinne@cs.columbia.edu 10619 Anup Rao 10620 Cisco 10621 USA 10623 Email: anrao@cisco.com 10625 Rob Lanphier 10626 Seattle, WA 10627 USA 10629 Email: robla@robla.net 10631 Magnus Westerlund 10632 Ericsson AB 10633 Faeroegatan 6 10634 STOCKHOLM, SE-164 80 10635 SWEDEN 10637 Email: magnus.westerlund@ericsson.com 10639 Martin Stiemerling 10640 NEC Laboratories Europe, NEC Europe Ltd. 10641 Kurfuersten-Anlage 36 10642 Heidelberg 69115 10643 Germany 10645 Phone: +49 (0) 6221 4342 113 10646 Email: stiemerling@nw.neclab.eu 10648 Full Copyright Statement 10650 Copyright (C) The IETF Trust (2008). 10652 This document is subject to the rights, licenses and restrictions 10653 contained in BCP 78, and except as set forth therein, the authors 10654 retain all their rights. 10656 This document and the information contained herein are provided on an 10657 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 10658 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 10659 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 10660 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 10661 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 10662 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 10664 Intellectual Property 10666 The IETF takes no position regarding the validity or scope of any 10667 Intellectual Property Rights or other rights that might be claimed to 10668 pertain to the implementation or use of the technology described in 10669 this document or the extent to which any license under such rights 10670 might or might not be available; nor does it represent that it has 10671 made any independent effort to identify any such rights. Information 10672 on the procedures with respect to rights in RFC documents can be 10673 found in BCP 78 and BCP 79. 10675 Copies of IPR disclosures made to the IETF Secretariat and any 10676 assurances of licenses to be made available, or the result of an 10677 attempt made to obtain a general license or permission for the use of 10678 such proprietary rights by implementers or users of this 10679 specification can be obtained from the IETF on-line IPR repository at 10680 http://www.ietf.org/ipr. 10682 The IETF invites any interested party to bring to its attention any 10683 copyrights, patents or patent applications, or other proprietary 10684 rights that may cover technology that may be required to implement 10685 this standard. Please address the information to the IETF at 10686 ietf-ipr@ietf.org.