idnits 2.17.1 draft-ietf-mmusic-rfc2326bis-15.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 24. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 9290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 9301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 9308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 9314. 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 non-RFC2606-compliant FQDNs in the document. == There are 3 instances 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 == 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Unless requested otherwise by the Speed parameter, the data rate SHOULD not be changed. Implementation of scale changes depends on the server and media type. For video, a server may, for example, deliver only key frames or selected key frames. For audio, it may time-scale the audio while preserving pitch or, less desirably, deliver fragments of audio. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: The response to valid request meeting the requisites is normally a 2xx (SUCCESS) unless other noted in the response column. The exceptions needs to be given a response according to the response column. If the request does not meet the requisite, is erroneous or some other type of error occur the appropriate response code MUST be sent. If the response code is a 4xx the session state is unchanged. A response code of 3rr will result in that the session is ended and its state is changed to Init. A response code of 304 results in no state change. However there exist restrictions to when a 3rr response may be used. A 5xx response SHALL not result in any change of the session state, except if the error is not possible to recover from. A unrecoverable error SHALL result the ending of the session. As it in the general case can't be determined if it was a unrecoverable error or not the client will be required to test. In the case that the next request after a 5xx is responded with 454 (Session Not Found) the client knows that the session has ended. -- 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 (June 25, 2007) is 6143 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'H6' is mentioned on line 1502, but not defined == Missing Reference: 'H10' is mentioned on line 3057, but not defined == Missing Reference: 'H15' is mentioned on line 6474, but not defined == Missing Reference: 'CSeq' is mentioned on line 8763, but not defined == Missing Reference: 'Timestamp' is mentioned on line 8765, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '3gpp-26234' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-pub-180-1' == Outdated reference: A later version (-12) exists of draft-ietf-avt-profile-savpf-09 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2068 (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** 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 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3548 (Obsoleted by RFC 4648) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4395 (Obsoleted by RFC 7595) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-22) exists of draft-ietf-mmusic-rtsp-nat-04 -- 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 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: 14 errors (**), 0 flaws (~~), 13 warnings (==), 16 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: December 27, 2007 Cisco 6 R. Lanphier 7 Real Networks 8 M. Westerlund 9 Ericsson AB 10 A. Narasimhan 11 Overture Computing Corp. 12 M. Stiemerling (Ed.) 13 NEC 14 June 25, 2007 16 Real Time Streaming Protocol 2.0 (RTSP) 17 draft-ietf-mmusic-rfc2326bis-15.txt 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on December 27, 2007. 44 Copyright Notice 46 Copyright (C) The IETF Trust (2007). 48 Abstract 50 This memorandum defines RTSP version 2.0 which is a revision of the 51 Proposed Standard RTSP version 1.0 which is defined in RFC 2326. 53 The Real Time Streaming Protocol, or RTSP, is an application-level 54 protocol for control over the delivery of data with real-time 55 properties. RTSP provides an extensible framework to enable 56 controlled, on-demand delivery of real-time data, such as audio and 57 video. Sources of data can include both live data feeds and stored 58 clips. This protocol is intended to control multiple data delivery 59 sessions, provide a means for choosing delivery channels such as UDP, 60 multicast UDP and TCP, and provide a means for choosing delivery 61 mechanisms based upon RTP (RFC 3550). 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 66 1.1. RTSP Specification Update . . . . . . . . . . . . . . . 8 67 1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . 8 68 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 10 69 1.3.1. RFC Editor Consideration . . . . . . . . . . . . . . 10 70 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . 10 71 1.5. Protocol Properties . . . . . . . . . . . . . . . . . . 14 72 1.6. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 15 73 1.7. Overall Operation . . . . . . . . . . . . . . . . . . . 16 74 1.8. RTSP States . . . . . . . . . . . . . . . . . . . . . . 17 75 1.9. Relationship with Other Protocols . . . . . . . . . . . 18 76 2. RTSP Use Cases . . . . . . . . . . . . . . . . . . . . . . . 19 77 2.1. On-demand Playback of Stored Content . . . . . . . . . . 19 78 2.2. Unicast distribution of Live Content . . . . . . . . . . 20 79 2.3. On-demand Playback using Multicast . . . . . . . . . . . 21 80 2.4. Inviting an RTSP server into a conference . . . . . . . 21 81 2.5. Live Content using Multicast . . . . . . . . . . . . . . 22 82 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 24 83 3.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 24 84 3.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 24 85 3.3. Session Identifiers . . . . . . . . . . . . . . . . . . 26 86 3.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . 26 87 3.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 26 88 3.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . 27 89 3.7. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 27 90 3.8. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 28 91 4. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 29 92 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 29 93 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 29 94 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 29 95 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 29 96 5. General Header Fields . . . . . . . . . . . . . . . . . . . . 31 97 6. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 98 6.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 32 99 6.2. Request Header Fields . . . . . . . . . . . . . . . . . 34 100 7. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 36 101 7.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 36 102 7.1.1. Status Code and Reason Phrase . . . . . . . . . . . 36 103 7.2. Response Header Fields . . . . . . . . . . . . . . . . . 39 104 8. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 105 8.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 42 106 8.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 43 107 9. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 44 108 9.1. Reliability and Acknowledgements . . . . . . . . . . . . 44 109 9.2. Using Connections . . . . . . . . . . . . . . . . . . . 45 110 9.3. Closing Connections . . . . . . . . . . . . . . . . . . 46 111 9.4. Timing Out Connections and RTSP Messages . . . . . . . . 47 112 9.5. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 47 113 10. Capability Handling . . . . . . . . . . . . . . . . . . . . . 48 114 11. Method Definitions . . . . . . . . . . . . . . . . . . . . . 50 115 11.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 51 116 11.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 52 117 11.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 54 118 11.3.1. Changing Transport Parameters . . . . . . . . . . . 56 119 11.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 57 120 11.5. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 62 121 11.6. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 65 122 11.7. GETPARAMETER . . . . . . . . . . . . . . . . . . . . . . 66 123 11.8. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 67 124 11.9. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 68 125 12. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 71 126 13. Status Code Definitions . . . . . . . . . . . . . . . . . . . 73 127 13.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 73 128 13.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 73 129 13.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 73 130 13.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 73 131 13.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 74 132 13.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 74 133 13.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 74 134 13.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 74 135 13.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 74 136 13.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 75 137 13.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 75 138 13.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 75 139 13.4.2. 405 Method Not Allowed . . . . . . . . . . . . . . . 75 140 13.4.3. 451 Parameter Not Understood . . . . . . . . . . . . 75 141 13.4.4. 452 reserved . . . . . . . . . . . . . . . . . . . . 75 142 13.4.5. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 76 143 13.4.6. 454 Session Not Found . . . . . . . . . . . . . . . 76 144 13.4.7. 455 Method Not Valid in This State . . . . . . . . . 76 145 13.4.8. 456 Header Field Not Valid for Resource . . . . . . 76 146 13.4.9. 457 Invalid Range . . . . . . . . . . . . . . . . . 76 147 13.4.10. 458 Parameter Is Read-Only . . . . . . . . . . . . . 76 148 13.4.11. 459 Aggregate Operation Not Allowed . . . . . . . . 76 149 13.4.12. 460 Only Aggregate Operation Allowed . . . . . . . . 76 150 13.4.13. 461 Unsupported Transport . . . . . . . . . . . . . 77 151 13.4.14. 462 Destination Unreachable . . . . . . . . . . . . 77 152 13.4.15. 463 Destination Prohibited . . . . . . . . . . . . . 77 153 13.4.16. 464 Data Transport Not Ready Yet . . . . . . . . . . 77 154 13.4.17. 470 Connection Authorization Required . . . . . . . 77 155 13.4.18. 471 Connection Credentials not accepted . . . . . . 77 156 13.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 78 157 13.5.1. 551 Option not supported . . . . . . . . . . . . . . 78 158 14. Header Field Definitions . . . . . . . . . . . . . . . . . . 79 159 14.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 88 160 14.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 88 161 14.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 89 162 14.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 89 163 14.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 89 164 14.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 89 165 14.7. Authorization . . . . . . . . . . . . . . . . . . . . . 90 166 14.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 90 167 14.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 90 168 14.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 90 169 14.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 93 170 14.12. Connection-Credentials . . . . . . . . . . . . . . . . . 93 171 14.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 93 172 14.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 93 173 14.15. Content-Language . . . . . . . . . . . . . . . . . . . . 93 174 14.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 94 175 14.17. Content-Location . . . . . . . . . . . . . . . . . . . . 94 176 14.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 94 177 14.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 94 178 14.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 94 179 14.21. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 95 180 14.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 95 181 14.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 96 182 14.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 96 183 14.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 97 184 14.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 97 185 14.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 97 186 14.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 97 187 14.29. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 97 188 14.30. Proxy-Authorization . . . . . . . . . . . . . . . . . . 97 189 14.31. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 97 190 14.32. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 98 191 14.33. Public . . . . . . . . . . . . . . . . . . . . . . . . . 99 192 14.34. Range . . . . . . . . . . . . . . . . . . . . . . . . . 100 193 14.35. Referer . . . . . . . . . . . . . . . . . . . . . . . . 101 194 14.36. Retry-After . . . . . . . . . . . . . . . . . . . . . . 101 195 14.37. Require . . . . . . . . . . . . . . . . . . . . . . . . 101 196 14.38. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 102 197 14.39. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 104 198 14.40. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 105 199 14.41. Server . . . . . . . . . . . . . . . . . . . . . . . . . 106 200 14.42. Session . . . . . . . . . . . . . . . . . . . . . . . . 106 201 14.43. Supported . . . . . . . . . . . . . . . . . . . . . . . 107 202 14.44. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 108 203 14.45. Transport . . . . . . . . . . . . . . . . . . . . . . . 108 204 14.46. Unsupported . . . . . . . . . . . . . . . . . . . . . . 114 205 14.47. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 114 206 14.48. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 114 207 14.49. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 114 208 14.50. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 114 209 15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 210 16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 211 17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 118 212 17.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 118 213 17.2. Media on Demand (Unicast) . . . . . . . . . . . . . . . 121 214 17.3. Single Stream Container Files . . . . . . . . . . . . . 123 215 17.4. Live Media Presentation Using Multicast . . . . . . . . 125 216 17.5. Capability Negotiation . . . . . . . . . . . . . . . . . 126 217 18. Security Framework . . . . . . . . . . . . . . . . . . . . . 128 218 18.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 128 219 18.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 128 220 18.3. Security and Proxies . . . . . . . . . . . . . . . . . . 129 221 18.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 130 222 18.3.2. User approved TLS procedure . . . . . . . . . . . . 131 223 19. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 224 19.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 133 225 19.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 135 226 19.2.1. Generic Protocol elements . . . . . . . . . . . . . 135 227 19.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 138 228 19.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 142 229 19.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 149 230 20. Security Considerations . . . . . . . . . . . . . . . . . . . 150 231 20.1. Remote denial of Service Attack . . . . . . . . . . . . 152 232 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 154 233 21.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 154 234 21.1.1. Description . . . . . . . . . . . . . . . . . . . . 154 235 21.1.2. Registering New Feature-tags with IANA . . . . . . . 155 236 21.1.3. Registered entries . . . . . . . . . . . . . . . . . 155 237 21.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 155 238 21.2.1. Description . . . . . . . . . . . . . . . . . . . . 155 239 21.2.2. Registering New Methods with IANA . . . . . . . . . 155 240 21.2.3. Registered Entries . . . . . . . . . . . . . . . . . 156 241 21.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 156 242 21.3.1. Description . . . . . . . . . . . . . . . . . . . . 156 243 21.3.2. Registering New Status Codes with IANA . . . . . . . 156 244 21.3.3. Registered Entries . . . . . . . . . . . . . . . . . 156 245 21.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 156 246 21.4.1. Description . . . . . . . . . . . . . . . . . . . . 156 247 21.4.2. Registering New Headers with IANA . . . . . . . . . 157 248 21.4.3. Registered entries . . . . . . . . . . . . . . . . . 157 249 21.5. Transport Header Registries . . . . . . . . . . . . . . 158 250 21.5.1. Transport Protocol Specification . . . . . . . . . . 158 251 21.5.2. Transport modes . . . . . . . . . . . . . . . . . . 159 252 21.5.3. Transport Parameters . . . . . . . . . . . . . . . . 160 253 21.6. Cache Directive Extensions . . . . . . . . . . . . . . . 160 254 21.7. Accept-Credentials . . . . . . . . . . . . . . . . . . . 161 255 21.7.1. Accept-Credentials policies . . . . . . . . . . . . 161 256 21.7.2. Accept-Credentials hash algorithms . . . . . . . . . 161 257 21.8. Range header formats . . . . . . . . . . . . . . . . . . 162 258 21.9. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 162 259 21.9.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 162 260 21.9.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 163 261 21.9.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 164 262 21.10. SDP attributes . . . . . . . . . . . . . . . . . . . . . 165 263 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 166 264 22.1. Normative References . . . . . . . . . . . . . . . . . . 166 265 22.2. Informative References . . . . . . . . . . . . . . . . . 168 266 Appendix A. RTSP Protocol State Machine . . . . . . . . . . . . 170 267 A.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 170 268 A.2. State variables . . . . . . . . . . . . . . . . . . . . 170 269 A.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 170 270 A.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 171 271 Appendix B. Media Transport Alternatives . . . . . . . . . . . . 176 272 B.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 176 273 B.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 176 274 B.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 176 275 B.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 177 276 B.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 178 277 B.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 178 278 B.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 178 279 B.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 178 280 B.2.2. RTP over independent TCP . . . . . . . . . . . . . . 179 281 B.2.3. Handling NPT Jumps in the RTP Media Layer . . . . . 182 282 B.2.4. Handling RTP Timestamps after PAUSE . . . . . . . . 184 283 B.2.5. RTSP / RTP Integration . . . . . . . . . . . . . . . 186 284 B.2.6. Scaling with RTP . . . . . . . . . . . . . . . . . . 186 285 B.2.7. Maintaining NPT synchronization with RTP 286 timestamps . . . . . . . . . . . . . . . . . . . . . 187 288 B.2.8. Continuous Audio . . . . . . . . . . . . . . . . . . 187 289 B.2.9. Multiple Sources in an RTP Session . . . . . . . . . 187 290 B.2.10. Usage of SSRCs and the RTCP BYE Message During an 291 RTSP Session . . . . . . . . . . . . . . . . . . . . 187 292 B.3. Future Additions . . . . . . . . . . . . . . . . . . . . 187 293 Appendix C. Use of SDP for RTSP Session Descriptions . . . . . . 189 294 C.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 189 295 C.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 189 296 C.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 190 297 C.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 191 298 C.1.4. Format-Specific Parameters . . . . . . . . . . . . . 191 299 C.1.5. Directionality of media stream . . . . . . . . . . . 191 300 C.1.6. Range of Presentation . . . . . . . . . . . . . . . 192 301 C.1.7. Time of Availability . . . . . . . . . . . . . . . . 193 302 C.1.8. Connection Information . . . . . . . . . . . . . . . 193 303 C.1.9. Entity Tag . . . . . . . . . . . . . . . . . . . . . 193 304 C.2. Aggregate Control Not Available . . . . . . . . . . . . 194 305 C.3. Aggregate Control Available . . . . . . . . . . . . . . 195 306 C.4. RTSP external SDP delivery . . . . . . . . . . . . . . . 196 307 Appendix D. Minimal RTSP Implementation . . . . . . . . . . . . 197 308 D.1. Minimal Core Implementation . . . . . . . . . . . . . . 197 309 D.2. Recommended Core Implementation . . . . . . . . . . . . 197 310 D.3. The Basic Playback Feature Support . . . . . . . . . . . 198 311 D.3.1. Client . . . . . . . . . . . . . . . . . . . . . . . 198 312 D.3.2. Server . . . . . . . . . . . . . . . . . . . . . . . 198 313 D.3.3. Proxy . . . . . . . . . . . . . . . . . . . . . . . 199 314 D.4. Secure Transport . . . . . . . . . . . . . . . . . . . . 199 315 Appendix E. Requirements for Unreliable Transport of RTSP . . . 200 316 Appendix F. Backwards Compatibility Considerations . . . . . . . 202 317 F.1. Play Request in Play mode . . . . . . . . . . . . . . . 202 318 F.2. Using Persistent Connections . . . . . . . . . . . . . . 202 319 Appendix G. Open Issues . . . . . . . . . . . . . . . . . . . . 203 320 Appendix H. Changes . . . . . . . . . . . . . . . . . . . . . . 205 321 H.1. Changes needing to be updated . . . . . . . . . . . . . 210 322 Appendix I. Contributors . . . . . . . . . . . . . . . . . . . . 211 323 Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 212 324 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 213 325 Intellectual Property and Copyright Statements . . . . . . . . . 215 327 1. Introduction 329 1.1. RTSP Specification Update 331 This memorandum specifies RTSP 2.0 which is an update of RTSP 1.0, a 332 proposed standard defined in [RFC2326]. The goal of this version is 333 to correct the many flaws that have been identified in RTSP 1.0 since 334 its publication. The corrections are such that backwards 335 compatibility was impossible. Thus a new version was deemed the most 336 appropriate solution to get a more functional protocol. There are no 337 plans to revise RTSP 1.0. Appendix H catalogs the changes of this 338 version in relation to RTSP 1.0. 340 RTSP 2.0 has reduced functionality compared to RTSP 1.0 and aims at 341 specifying the RTSP core, functionality and rules for extensions, and 342 basic interaction with the media delivery protocol RTP [RFC3550]. 344 Any other functionality would be need to be published as extension 345 documents. This specification provides rules for such extensions and 346 defines registries to avoid naming collisions. 348 1.2. Purpose 350 The Real-Time Streaming Protocol (RTSP) establishes and controls one 351 or several time-synchronized streams of continuous media such as 352 audio and video. Put simply, RTSP acts as a "network remote control" 353 for multimedia servers. 355 There is no notion of an RTSP connection in the protocol. Instead, 356 an RTSP server maintains a session labeled by an identifier to 357 associate groups of media streams and their states. An RTSP session 358 is not tied to a transport-level connection such as a TCP connection. 359 During a session, a client may open and close multiple reliable 360 transport connections to the server to issue RTSP requests for that 361 session. 363 This memorandum describes the use of RTSP over a reliable connection 364 based transport level protocol such as TCP. RTSP may be implemented 365 over an unreliable connectionless transport protocol such as UDP. 366 While nothing in RTSP precludes this, additional definition of this 367 problem area needs to be handled as an extension to the core 368 specification. 370 The mechanisms of RTSP's operation over UDP were left out of this 371 spec. because they were poorly defined in [RFC2326] and the 372 tradeoff in size and complexity of this memorandum for a small 373 gain in a limited problem space was not deemed justifiable. 375 The set of streams to be controlled in an RTSP session is defined by 376 a presentation description. This memorandum does not define a format 377 for the presentation description. However appendix C describes how 378 SDP [RFC4566] is used for this purpose. The streams controlled by 379 RTSP may use RTP [RFC3550] for their data transport, but the 380 operation of RTSP does not depend on the transport mechanism used to 381 carry continuous media. RTSP is intentionally similar in syntax and 382 operation to HTTP/1.1 [RFC2616] so that extension mechanisms to HTTP 383 can in most cases also be applied to RTSP. However, RTSP differs in 384 a number of important aspects from HTTP: 386 * RTSP introduces a number of new methods and has a different 387 protocol identifier. 389 * RTSP has the notion of a session built into the protocol. 391 * An RTSP server needs to maintain state in almost all cases, as 392 opposed to the stateless nature of HTTP. 394 * Both an RTSP server and client can issue requests. 396 * Data is usually carried out-of-band by a different protocol. 397 Session descriptions returned in a DESCRIBE response (see 398 Section 11.2) and interleaving of RTP with RTSP over TCP are 399 exceptions to this rule (see Section 12). 401 * RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 402 8859-1, consistent with HTML internationalization efforts 403 [RFC2070]. 405 * The Request-URI always contains the absolute URI. Because of 406 backward compatibility with a historical blunder, HTTP/1.1 407 [RFC2616] carries only the absolute path in the request and 408 puts the host name in a separate header field. 409 This makes "virtual hosting" easier, where a single host with 410 one IP address hosts several document trees. 412 The protocol supports the following operations: 414 Retrieval of media from media server: The client can either request 415 a presentation description via RTSP DESCRIBE, HTTP or some 416 other method. If the presentation is being multicast, the 417 presentation description contains the multicast addresses and 418 ports to be used for the continuous media. If the presentation 419 is to be sent only to the client via unicast, the client 420 provides the destination. 422 Invitation of a media server to a conference: A media server can be 423 "invited" to join an existing conference to play back media 424 into the presentation. This mode is useful, for example, in 425 distributed teaching applications. Several parties in the 426 conference may take turns "pushing the remote control buttons". 427 Note: This functionality will require RTSP external application 428 level functionality. 430 RTSP requests may be handled by proxies, tunnels and caches as in 431 HTTP/1.1 [RFC2616]. 433 1.3. Notational Conventions 435 Since many of the definitions and syntax are identical to HTTP/1.1, 436 this specification only points to the section where they are defined 437 rather than copying it. For brevity, [HX.Y] is to be taken to refer 438 to Section X.Y of the current HTTP/1.1 specification ([RFC2616]). 440 All the mechanisms specified in this document are described in both 441 prose and the Augmented Backus-Naur form (ABNF) described in detail 442 in [RFC4234]. 444 Indented and smaller-type paragraphs are used to provide informative 445 background and motivation. This is intended to give readers who were 446 not involved with the formulation of the specification an 447 understanding of why things are the way they are in RTSP. 449 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 450 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 451 document are to be interpreted as described in [RFC2119]. 453 The word, "unspecified" is used to indicate functionality or features 454 that are not defined in this specification. Such functionality 455 cannot be used in a standardized manner without further definition in 456 an extension specification to RTSP. 458 1.3.1. RFC Editor Consideration 460 Please replace RFC XXXX with the RFC number this specification 461 recieves. 463 Please replace RFC YYYY with the RFC number that SAVPF 464 [I-D.ietf-avt-profile-savpf] receives. 466 1.4. Terminology 468 Some of the terminology has been adopted from HTTP/1.1 [RFC2616]. 469 Terms not listed here are defined as in HTTP/1.1. 471 Aggregate control: The concept of controlling multiple streams using 472 a single timeline, generally maintained by the server. A client, 473 for example, uses aggregate control when it issues a single play 474 or pause message to simultaneously control both the audio and 475 video in a movie. A session which is under aggregate control is 476 referred to as an aggregated session. 478 Aggregate control URI: The URI used in an RTSP request to refer to 479 and control an aggregated session. It normally, but not always, 480 corresponds to the presentation URI specified in the session 481 description. See Section 11.3 for more information. 483 Conference: A multiparty, multimedia presentation, where "multi" 484 implies greater than or equal to one. 486 Client: The client requests media service from the media server. 488 Connection: A transport layer virtual circuit established between 489 two programs for the purpose of communication. 491 Container file: A file which may contain multiple media streams 492 which often constitutes a presentation when played together. The 493 concept of a container file is not embedded in the protocol. 494 However, RTSP servers may offer aggregate control on the media 495 streams within these files. 497 Continuous media: Data where there is a timing relationship between 498 source and sink; that is, the sink needs to reproduce the timing 499 relationship that existed at the source. The most common examples 500 of continuous media are audio and motion video. Continuous media 501 can be real-time (interactive or conversational), where there is a 502 "tight" timing relationship between source and sink, or streaming 503 (playback), where the relationship is less strict. 505 Entity: The information transferred as the payload of a request or 506 response. An entity consists of meta-information in the form of 507 entity-header fields and content in the form of an entity-body, as 508 described in Section 8. 510 Feature-tag: A tag representing a certain set of functionality, i.e. 511 a feature. 513 IRI: Internationalized Resource Identifier, is the same as an URI, 514 with the exception that it allows characters from the whole 515 Universal Character Set (Unicode/ISO 10646), rather than the US- 516 ASCII only. See [RFC3987] for more information. 518 Live: Normally used to describe a presentation or session with media 519 coming from an ongoing event. This generally results in the 520 session having an unbound or only loosely defined duration, and 521 sometimes no seek operations are possible. 523 Media initialization: Datatype/codec specific initialization. This 524 includes such things as clock rates, color tables, etc. Any 525 transport-independent information which is required by a client 526 for playback of a media stream occurs in the media initialization 527 phase of stream setup. 529 Media parameter: Parameter specific to a media type that may be 530 changed before or during stream playback. 532 Media server: The server providing playback services for one or more 533 media streams. Different media streams within a presentation may 534 originate from different media servers. A media server may reside 535 on the same host or on a different host from which the 536 presentation is invoked. 538 Media server indirection: Redirection of a media client to a 539 different media server. 541 (Media) stream: A single media instance, e.g., an audio stream or a 542 video stream as well as a single whiteboard or shared application 543 group. When using RTP, a stream consists of all RTP and RTCP 544 packets created by a source within an RTP session. 546 Message: The basic unit of RTSP communication, consisting of a 547 structured sequence of octets matching the syntax defined in 548 Section 19 and transmitted over a connection or a connectionless 549 transport. 551 Non-Aggregated Control: Control of a single media stream. This is 552 only possible in RTSP sessions with a single media. 554 Participant: Member of a conference. A participant may be a 555 machine, e.g., a playback server. 557 Presentation: A set of one or more streams presented to the client 558 as a complete media feed and described by a presentation 559 description as defined below. Presentations with more than one 560 media stream are often handled in RTSP under aggregate control. 562 Presentation description: A presentation description contains 563 information about one or more media streams within a presentation, 564 such as the set of encodings, network addresses and information 565 about the content. Other IETF protocols such as SDP ([RFC4566]) 566 use the term "session" for a presentation. The presentation 567 description may take several different formats, including but not 568 limited to the session description protocol format, SDP. 570 Response: An RTSP response. If an HTTP response is meant, that is 571 indicated explicitly. 573 Request: An RTSP request. If an HTTP request is meant, that is 574 indicated explicitly. 576 Request-URI: The URI used in a request to indicate the resource on 577 which the request is to be performed. 579 RTSP agent: Refers to either an RTSP client, an RTSP server, or an 580 RTSP Proxy. In this specification, there are many capabilities 581 that are common to these three entities such as the capability to 582 send requests or receive responses. This term will be used when 583 describing functionality that is applicable to all three of these 584 entities. 586 RTSP session: A stateful abstraction upon which the main control 587 methods of RTSP operate. An RTSP session is a server entity; it 588 is created, maintained and destroyed by the server. It is 589 established by an RTSP server upon the completion of a successful 590 SETUP request (when a 200 OK response is sent) and is labelled 591 with a session identifier at that time. The session exists until 592 timed out by the server or explicitly removed by a TEARDOWN 593 request. An RTSP session is a stateful entity; an RTSP server 594 maintains an explicit session state machine (see Appendix A) where 595 most state transitions are triggered by client requests. The 596 existence of a session implies the existence of state about the 597 session's media streams and their respective transport mechanisms. 598 A given session can have one or more media streams associated with 599 it. An RTSP server uses the session to aggregate control over 600 multiple media streams. 602 Transport initialization: The negotiation of transport information 603 (e.g., port numbers, transport protocols) between the client and 604 the server. 606 URI: Universal Resource Identifier, see [RFC3986]. The URIs used in 607 RTSP are generally URLs as they give a location for the resource. 608 As URLs are a subset of URIs, they will be referred to as URIs to 609 cover also the cases when an RTSP URI would not be an URL. 611 URL: Universal Resource Locator, is an URI which identifies the 612 resource through its primary access mechanism, rather than 613 identifying the resource by name or by some other attribute(s) of 614 that resource. 616 1.5. Protocol Properties 618 RTSP has the following properties: 620 Extendable: New methods and parameters can be easily added to RTSP. 622 Easy to parse: RTSP can be parsed by standard HTTP or MIME parsers. 624 Secure: RTSP re-uses web security mechanisms, either at the 625 transport level (TLS, [RFC4346]) or within the protocol itself. 626 All HTTP authentication mechanisms such as basic ([RFC2616]) and 627 digest authentication ([RFC2617]) are directly applicable. 629 Transport-independent: RTSP does not preclude the use of unreliable 630 datagram protocol (UDP) ([RFC0768]) as it would be possible to 631 implement application-level reliability. The use of a 632 connectionless datagram protocol such as UDP requires additional 633 definition that may be provided as extensions to the core RTSP 634 specification. The reliable stream protocol TCP ([RFC0793]) and 635 the secured reliable stream protocol TLS over TCP [RFC4346] are 636 the currently defined transport protocols for RTSP messages. 638 Media-delivery protocol independent: The operation of RTSP does not 639 depend on the transport mechanism used to carry continuous media. 640 While most real-time media will use RTP as a transport protocol, 641 RTSP does not preclude the use of other protocols such as MPEG-2 642 [ISO.13818-1.2000]. The use of other protocols requires 643 additional definition that may be provided as extensions to the 644 core RTSP specification. 646 Multi-server capable: Each media stream within a presentation can 647 reside on a different server. The client automatically 648 establishes several concurrent control sessions with the different 649 media servers. Media synchronization in those cases is performed 650 at the transport level. 652 Separation of stream control and conference initiation: Stream 653 control is divorced from inviting a media server to a conference. 654 In particular, SIP [RFC3261] or H.323 [ITU.H323.1996] may be used 655 to invite a server to a conference; however, the exact procedures 656 are unspecified. 658 Suitable for professional applications: RTSP supports frame- level 659 accuracy through SMPTE time stamps to allow remote digital 660 editing. 662 Presentation description neutral: The protocol does not impose a 663 particular presentation description or metafile format and can 664 convey the type of format to be used. However, the presentation 665 description is required to contain at least one RTSP URI. 667 Proxy and firewall friendly: The protocol should be readily handled 668 by both application and transport-layer (SOCKS [RFC1961]) 669 firewalls. A firewall may need to understand the SETUP method to 670 open a "hole" for the media stream. 672 HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so that 673 the existing infrastructure can be reused. This infrastructure 674 includes PICS (Platform for Internet Content Selection 675 [W3C.REC-PICS-services] [W3C.REC-PICS-labels]) for associating 676 labels with content. However, RTSP does not just add methods to 677 HTTP since controlling continuous media requires server state in 678 most cases. 680 Appropriate server control: If a client can start a stream, it needs 681 to be able to stop a stream. Servers should not start streaming 682 to clients in such a way that clients cannot stop the stream. 684 Transport negotiation: The client can negotiate the transport method 685 prior to actually needing to process a continuous media stream. 687 1.6. Extending RTSP 689 Since not all media servers have the same functionality, media 690 servers by necessity will support different sets of requests. For 691 example: 693 o A server may not be capable of seeking (absolute positioning) if 694 it is to support live events only. 696 o Some servers may not support setting stream parameters and thus 697 not support GET_PARAMETER and SET_PARAMETER. 699 o Some server may support an RTSP extension. 701 It is up to the creators of presentation descriptions not to ask the 702 impossible of a server. This situation is similar in HTTP/1.1 703 [RFC2616], where the methods described in [H19.5] are not likely to 704 be supported across all servers. 706 RTSP can be extended in three ways, listed here in order of the 707 magnitude of changes supported: 709 o Existing methods can be extended with new parameters, e.g. 710 headers, as long as these parameters can be safely ignored by the 711 recipient. If the client needs negative acknowledgement when a 712 method extension is not supported, a tag corresponding to the 713 extension may be added in the field of the Require or Proxy- 714 Require headers (see Section 14.31). 716 o New methods can be added. If the recipient of the message does 717 not understand the request, it MUST respond with error code 501 718 (Not Implemented) so that the sender can avoid using this method 719 again. A client may also use the OPTIONS method to inquire about 720 methods supported by the server. The server MUST list the methods 721 it supports using the Public response header. 723 o A new version of the protocol can be defined, allowing almost all 724 aspects (except the position of the protocol version number) to 725 change. A new version of the protocol MUST be registered through 726 an IETF standard track document. 728 The basic capability discovery mechanism can be used to both discover 729 support for a certain feature and to ensure that a feature is 730 available when performing a request. For detailed explanation of 731 this see Section 10. 733 1.7. Overall Operation 735 Each presentation and media stream is identified by an RTSP URI. The 736 overall presentation and the properties of the media the presentation 737 is composed of are defined by a presentation description file, the 738 format of which is outside the scope of this specification. The 739 presentation description file may be obtained by the client using 740 HTTP or other means such as email and may not necessarily be stored 741 on the media server. 743 For the purposes of this specification, a presentation description is 744 assumed to describe one or more presentations, each of which 745 maintains a common time axis. For simplicity of exposition and 746 without loss of generality, it is assumed that the presentation 747 description contains exactly one such presentation. A presentation 748 may contain several media streams. 750 The presentation description file contains a description of the media 751 streams making up the presentation, including their encodings, 752 language, and other parameters that enable the client to choose the 753 most appropriate combination of media. In this presentation 754 description, each media stream that is individually controllable by 755 RTSP is identified by an RTSP URI, which points to the media server 756 handling that particular media stream and names the stream stored on 757 that server. Several media streams can be located on different 758 servers; for example, audio and video streams can be split across 759 servers for load sharing. The description also enumerates which 760 transport methods the server is capable of. 762 Besides the media parameters, the network destination address and 763 port need to be determined. Several modes of operation can be 764 distinguished: 766 Unicast: The media is transmitted to the source of the RTSP request 767 or the requested destination, with the port number chosen by the 768 client. Alternatively, the media is transmitted on the same 769 reliable stream as RTSP. 771 Multicast, server chooses address: The media server picks the 772 multicast address and port. This is the typical case for a live 773 or near-media-on-demand transmission. 775 Multicast, client chooses address: If the server is to participate 776 in an existing multicast conference, the multicast address, port 777 and encryption key are given by the conference description, 778 established by means outside the scope of this specification, for 779 example by a SIP created conference. 781 1.8. RTSP States 783 RTSP controls a stream which may be sent via a separate protocol, 784 independent of the control channel. For example, RTSP control may be 785 transported on a TCP connection while the media data is conveyed via 786 UDP. Thus, data delivery continues even if no RTSP requests are 787 received by the media server. Also, during its lifetime a single 788 media stream may be controlled by RTSP requests issued sequentially 789 on different TCP connections. Therefore, the server needs to 790 maintain "session state" to be able to correlate RTSP requests with a 791 stream. The state transitions are described in Appendix A. 793 Many methods in RTSP do not contribute to state. However, the 794 following play a central role in defining the allocation and usage of 795 stream resources on the server: SETUP, PLAY, PAUSE, REDIRECT, and 796 TEARDOWN. 798 SETUP: Causes the server to allocate resources for a stream and 799 create an RTSP session. 801 PLAY: Starts data transmission on a stream allocated via SETUP. 803 PAUSE: Temporarily halts a stream without freeing server resources. 805 REDIRECT: Indicates that the session should be moved to a new server 806 or location 808 TEARDOWN: Frees resources associated with the stream. The RTSP 809 session ceases to exist on the server. 811 RTSP methods that contribute to state use the Session header field 812 (Section 14.43) to identify the RTSP session whose state is being 813 manipulated. The server generates session identifiers in response to 814 SETUP requests (Section 11.3). 816 1.9. Relationship with Other Protocols 818 RTSP has some overlap in functionality with HTTP. It also may 819 interact with HTTP in that the initial contact with streaming content 820 will often be made through a web page. The current protocol 821 specification aims to allow different hand-off points between a web 822 server and the media server implementing RTSP. For example, the 823 presentation description can be retrieved using HTTP or RTSP, which 824 reduces round trips in web-browser-based scenarios, yet also allows 825 for stand alone RTSP servers and clients which do not rely on HTTP at 826 all. However, RTSP differs fundamentally from HTTP in that most data 827 delivery takes place out-of-band in a different protocol. HTTP is an 828 asymmetric protocol where the client issues requests and the server 829 responds. In RTSP, both the media client and media server can issue 830 requests. RTSP requests are also stateful; they may set parameters 831 and continue to control a media stream long after the request has 832 been acknowledged. 834 Re-using HTTP functionality has advantages in at least two areas, 835 namely security and proxies. The requirements are very similar, so 836 having the ability to adopt HTTP work on caches, proxies and 837 authentication is valuable. 839 RTSP assumes the existence of a presentation description format that 840 can express both static and temporal properties of a presentation 841 containing several media streams. Session Description Protocol (SDP) 842 [RFC4566] is generally the format of choice; however, RTSP is not 843 bound to it. For data delivery, most real-time media will use RTP as 844 a transport protocol. While RTSP works well with RTP, it is not tied 845 to RTP. 847 2. RTSP Use Cases 849 This section describes the most important and considered use cases 850 for RTSP. They are listed in descending order of importance in 851 regards to ensuring that all necessary functionality is present. 852 This specification only fully supports usage of the two first. Also 853 in these first two cases, there are special cases or exceptions that 854 are not supported without extensions, e.g. the redirection of media 855 to another address than the controlling entity. 857 2.1. On-demand Playback of Stored Content 859 An RTSP capable server stores content suitable for being streamed to 860 a client. A client desiring playback of any of the stored content 861 uses RTSP to set up the media transport required to deliver the 862 desired content. RTSP is then used to initiate, halt and manipulate 863 the actual transmission (playout) of the content. RTSP is also 864 required to provide necessary description and synchronization 865 information for the content. 867 The above high level description can be broken down into a number of 868 functions that RTSP needs to be capable of. 870 Presentation Description: Provide initialization information about 871 the presentation (content); for example, which media codecs are 872 needed for the content. Other information that is important 873 includes the number of media stream the presentation contains, 874 the transport protocols used for the media streams, and 875 identifiers for these media streams. This information is 876 required before setup of the content is possible and to 877 determine if the client is even capable of using the content. 879 This information need not be sent using RTSP; other external 880 protocols can be used to transmit the transport presentation 881 descriptions. Two good examples are the use of HTTP [RFC2616] 882 or email to fetch or receive presentation descriptions like SDP 883 [RFC4566] 885 Setup: Set up some or all of the media streams in a presentation. 886 The setup itself consist of selecting the protocol for media 887 transport and the necessary parameters for the protocol, like 888 addresses and ports. 890 Control of Transmission: After the necessary media streams have been 891 established the client can request the server to start 892 transmitting the content. The client must be allowed to start 893 or stop the transmission of the content at arbitrary times. 894 The client must also be able to start the transmission at any 895 point in the timeline of the presentation. 897 Synchronization: For media transport protocols like RTP [RFC3550] it 898 might be beneficial to carry synchronization information within 899 RTSP. This may be due to either the lack of inter-media 900 synchronization within the protocol itself, or the potential 901 delay before the synchronization is established (which is the 902 case for RTP when using RTCP). 904 Termination: Terminate the established contexts. 906 For this use case there are a number of assumptions about how it 907 works. These are: 909 On-Demand content: The content is stored at the server and can be 910 accessed at any time during a time period when it is intended 911 to be available. 913 Independent sessions: A server is capable of serving a number of 914 clients simultaneously, including from the same piece of 915 content at different points in that presentations time-line. 917 Unicast Transport: Content for each individual client is transmitted 918 to them using unicast traffic. 920 It is also possible to redirect the media traffic to a different 921 destination than that of the entity controlling the traffic. 922 However, allowing this without appropriate mechanisms for checking 923 that the destination approves of this allows for distributed denial 924 of service attacks (DDoS). 926 2.2. Unicast distribution of Live Content 928 This use cases is similar to the above on-demand content case (see 929 Section 2.1) the difference is the nature of the content itself. 930 Live content is continuously distributed as it becomes available from 931 a source; i.e., the main difference from on-demand is that one starts 932 distributing content before the end of it has become available to the 933 server. 935 In many cases the consumer of live content is only interested in 936 consuming what is actually happens "now"; i.e., very similar to 937 broadcast TV. However in this case it is assumed that there exist no 938 broadcast or multicast channel to the users, and instead the server 939 functions as a distribution node, sending the same content to 940 multiple receivers, using unicast traffic between server and client. 941 This unicast traffic and the transport parameters are individually 942 negotiated for each receiving client. 944 Another aspect of live content is that it often has a very limited 945 time of availability, as it is only is available for the duration of 946 the event the content covers. An example of such a live content 947 could be a music concert which lasts 2 hour and starts at a 948 predetermined time. Thus there is need to announce when and for how 949 long the live content is available. 951 2.3. On-demand Playback using Multicast 953 It is possible to use RTSP to request that media be delivered to a 954 multicast group. The entity setting up the session (the controller) 955 will then control when and what media is delivered to the group. 956 This use case has some potential for denial of service attacks by 957 flooding a multicast group. Therefore, a mechanism is needed to 958 indicate that the group actually accepts the traffic from the RTSP 959 server. 961 An open issue in this use case is how one ensures that all receivers 962 listening to the multicast or broadcast receives the session 963 presentation configuring the receivers. 965 2.4. Inviting an RTSP server into a conference 967 If one has an established conference or group session, it is possible 968 to have an RTSP server distribute media to the whole group. 969 Transmission to the group is simplest when controlled by a single 970 participant or leader of the conference. Shared control might be 971 possible, but would require further investigation and possibly 972 extensions. 974 This use case assumes that there exists either multicast or a 975 conference focus that redistribute media to all participants. 977 This use case is intended to be able to handle the following 978 scenario: A conference leader or participant (hereafter called the 979 controller) has some pre-stored content on an RTSP server that he 980 wants to share with the group. The controller sets up an RTSP 981 session at the streaming server for this content and retrieves the 982 session description for the content. The destination for the media 983 content is set to the shared multicast group or conference focus. 984 When desired by the controller, he/she can start and stop the 985 transmission of the media to the conference group. 987 There are several issues with this use case that are not solved by 988 this core specification for RTSP: 990 Denial of service: To avoid an RTSP server from being an unknowing 991 participant in a denial of service attack the server needs to 992 be able to verify the destination's acceptance of the media. 993 Such a mechanism to verify the approval of received media does 994 not yet exist; instead, only policies can be used, which can be 995 made to work in controlled environments. 997 Distributing the presentation description to all participants in the 998 group: To enable a media receiver to correctly decode the content 999 the media configuration information needs to be distributed 1000 reliably to all participants. This will most likely require 1001 support from an external protocol. 1003 Passing control of the session: If it is desired to pass control of 1004 the RTSP session between the participants, some support will be 1005 required by an external protocol to exchange state information 1006 and possibly floor control of who is controlling the RTSP 1007 session. 1009 If there interest in this use case, further work is required on the 1010 necessary extensions. 1012 2.5. Live Content using Multicast 1014 This use case in its simplest form does not require any use of RTSP 1015 at all; this is what multicast conferences being announced with SAP 1016 and SDP are intended to handle. However in use cases where more 1017 advanced features like access control to the multicast session are 1018 desired, RTSP could be used for session establishment. 1020 A client desiring to join a live multicasted media session with 1021 cryptographic (encryption) access control could use RTSP in the 1022 following way. The source of the session announces the session and 1023 gives all interested an RTSP URI. The client connects to the server 1024 and requests the presentation description, allowing configuration for 1025 reception of the media. In this step it is possible for the client 1026 to use secured transport and any desired level of authentication; for 1027 example, for billing or access control. An RTSP link also allows for 1028 load balancing between multiple servers. 1030 If these were the only goals, they could be achieved by simply using 1031 HTTP. However, for cases where the sender likes to keep track of 1032 each individual receiver of a session, and possibly use the session 1033 as a side channel for distributing key-updates or other information 1034 on a per-receiver basis, and the full set of receivers is not know 1035 prior to the session start, the state establishment that RTSP 1036 provides can be beneficial. In this case a client would establish an 1037 RTSP session to the multicast group. The RTSP server will not 1038 transmit any media, but instead will point to the multicast group. 1039 The client and server will be able to keep the session alive for as 1040 long as the receiver participates in the session thus enabling, for 1041 example, the server to push updates to the client. 1043 This use case will most likely not be able to be implemented without 1044 some extensions to the server-to-client push mechanism. Here a 1045 method like ANNOUNCE (see [RFC2326]) might be suitable; however, it 1046 will require a RTSP extension to revive the method. 1048 3. Protocol Parameters 1050 3.1. RTSP Version 1052 HTTP specification section [H3.1] applies, with "HTTP" replaced by 1053 "RTSP". This specification defines version 2.0 of RTSP. 1055 3.2. RTSP IRI and URI 1057 RTSP 2.0 defines and registers three URI schemas "rtsp", "rtsps" and 1058 "rtspu". The usage of the last, "rtspu", is unspecified in RTSP 2.0, 1059 and is defined here to register and reserve the URI scheme that is 1060 defined in RTSP 1.0. The "rtspu" scheme indicates transport of the 1061 RTSP messages over unreliable transport (UDP). The syntax of "rtsp" 1062 and "rtsps" URIs has been changed from RTSP 1.0. 1064 This specification also defines the format of the RTSP IRI [RFC3987] 1065 that can be used as RTSP resource identifiers and locators, in web 1066 pages, user interfaces, on paper, etc. However, the RTSP request 1067 message format only allows usage of the absolute URI format. The 1068 RTSP IRI format SHALL use the rules and transformation for IRIs 1069 defined in [RFC3987]. This way RTSP 2.0 URIs for request can be 1070 produced from an RTSP IRI. 1072 The RTSP IRI and URI are both syntax restricted compared to the 1073 generic syntax defined in [RFC3986] and RFC [RFC3987]: 1075 o An absolute URI requires the authority part; i.e., a host identity 1076 must be provided. 1078 o Parameters in the path element are prefixed with the reserved 1079 separator ";". 1081 The RTSP URI and IRI is case sensitive, with the exception of those 1082 parts that [RFC3986] and [RFC3987] defines as case-insensitive; for 1083 example, the scheme and host part. 1085 The fragment identifier is used as defined in sections 3.5 and 4.3 of 1086 [RFC3986], i.e. the fragment is to be stripped from the URI by the 1087 requestor and not included in the request. The user agent also needs 1088 to interpret the value of the fragment based on the media type the 1089 request relates to; i.e., the media type indicated in Content-Type 1090 header in the response to DESCRIBE. 1092 The syntax of any URI query string is unspecified and responder 1093 (usually the server) specific. The query is, from the requestor's 1094 perspective, an opaque string and needs to be handled as such. 1096 The URI scheme "rtsp" requires that commands are issued via a 1097 reliable protocol (within the Internet, TCP), while the scheme 1098 "rtsps" identifies a reliable transport using secure transport (TLS 1099 [RFC4346], see Section (Section 18). 1101 For the scheme "rtsp", if no port number is provided in the authority 1102 part of the URI port number 554 SHALL be used. For the scheme 1103 "rtsps", the TCP port 322 is registered and SHALL be assumed. 1105 A presentation or a stream is identified by a textual media 1106 identifier, using the character set and escape conventions of URIs 1107 (RFC 3986 [RFC3986]). URIs may refer to a stream or an aggregate of 1108 streams; i.e., a presentation. Accordingly, requests described in 1109 Section (Section 11) can apply to either the whole presentation or an 1110 individual stream within the presentation. Note that some request 1111 methods can only be applied to streams, not presentations, and vice 1112 versa. 1114 For example, the RTSP URI: 1116 rtsp://media.example.com:554/twister/audiotrack 1118 may identify the audio stream within the presentation "twister", 1119 which can be controlled via RTSP requests issued over a TCP 1120 connection to port 554 of host media.example.com. 1122 Also, the RTSP URI: 1124 rtsp://media.example.com:554/twister 1126 identifies the presentation "twister", which may be composed of audio 1127 and video streams, but could also be something else like a random 1128 media redirector. 1130 This does not imply a standard way to reference streams in URIs. 1131 The presentation description defines the hierarchical 1132 relationships in the presentation and the URIs for the individual 1133 streams. A presentation description may name a stream "a.mov" and 1134 the whole presentation "b.mov". 1136 The path components of the RTSP URI are opaque to the client and do 1137 not imply any particular file system structure for the server. 1139 This decoupling also allows presentation descriptions to be used 1140 with non-RTSP media control protocols simply by replacing the 1141 scheme in the URI. 1143 3.3. Session Identifiers 1145 Session identifiers are strings of any arbitrary length. A session 1146 identifier MUST be chosen randomly and MUST be at least eight 1147 characters long to make guessing it more difficult. (See 1148 Section 20.) 1150 3.4. SMPTE Relative Timestamps 1152 A SMPTE relative timestamp expresses time relative to the start of 1153 the clip. Relative timestamps are expressed as SMPTE time codes for 1154 frame-level access accuracy. The time code has the format 1156 hours:minutes:seconds:frames.subframes, 1158 with the origin at the start of the clip. The default smpte format 1159 is "SMPTE 30 drop" format, with frame rate is 29.97 frames per 1160 second. Other SMPTE codes MAY be supported (such as "SMPTE 25") 1161 through the use of alternative use of "smpte-type". For SMPTE 30, 1162 the "frames" field in the time value can assume the values 0 through 1163 29. The difference between 30 and 29.97 frames per second is handled 1164 by dropping the first two frame indices (values 00 and 01) of every 1165 minute, except every tenth minute. If the frame and the subframe 1166 values are zero, they may be omitted. Subframes are measured in one- 1167 hundredth of a frame. 1169 Examples: 1171 smpte=10:12:33:20- 1172 smpte=10:07:33- 1173 smpte=10:07:00-10:07:33:05.01 1174 smpte-25=10:07:00-10:07:33:05.01 1176 3.5. Normal Play Time 1178 Normal play time (NPT) indicates the stream absolute position 1179 relative to the beginning of the presentation, not to be confused 1180 with the Network Time Protocol (NTP) [RFC1305]. The timestamp 1181 consists of a decimal fraction. The part left of the decimal may be 1182 expressed in either seconds or hours, minutes, and seconds. The part 1183 right of the decimal point measures fractions of a second. 1185 The beginning of a presentation corresponds to 0.0 seconds. Negative 1186 values are not defined. The special constant "now" is defined as the 1187 current instant of a live event. It MAY only be used for live 1188 events, and SHALL NOT be used for on-demand (i.e., non-live) content. 1190 NPT is defined as in DSM-CC [ISO.13818-6.1995]: "Intuitively, NPT is 1191 the clock the viewer associates with a program. It is often 1192 digitally displayed on a VCR. NPT advances normally when in normal 1193 play mode (scale = 1), advances at a faster rate when in fast scan 1194 forward (high positive scale ratio), decrements when in scan reverse 1195 (high negative scale ratio) and is fixed in pause mode. NPT is 1196 (logically) equivalent to SMPTE time codes." 1198 Examples: 1200 npt=123.45-125 1201 npt=12:05:35.3- 1202 npt=now- 1204 The syntax conforms to ISO 8601 [ISO.8601.2000]. The npt-sec 1205 notation is optimized for automatic generation, the npt-hhmmss 1206 notation for consumption by human readers. The "now" constant 1207 allows clients to request to receive the live feed rather than the 1208 stored or time-delayed version. This is needed since neither 1209 absolute time nor zero time are appropriate for this case. 1211 3.6. Absolute Time 1213 Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps, 1214 using UTC (GMT). Fractions of a second may be indicated. 1216 Example for November 8, 1996 at 14h37 and 20 and a quarter seconds 1217 UTC: 1219 19961108T143720.25Z 1221 3.7. Feature-tags 1223 Feature-tags are unique identifiers used to designate features in 1224 RTSP. These tags are used in Require ( (Section 14.37)), Proxy- 1225 Require (Section 14.31), Proxy-Supported ( (Section 14.32)), 1226 Unsupported ( (Section 14.46)), and header fields. 1228 A feature-tag definition MUST indicate which combination of clients, 1229 servers or proxies they applies too. 1231 The creator of a new RTSP feature-tag should either prefix the 1232 feature-tag with a reverse domain name (e.g., 1233 "com.example.mynewfeature" is an apt name for a feature whose 1234 inventor can be reached at "example.com"), or register the new 1235 feature-tag with the Internet Assigned Numbers Authority (IANA) (see 1236 IANA Section 21). 1238 The usage of feature-tags is further described in Section 10 that 1239 deals with capability handling. 1241 3.8. Entity Tags 1243 Entity tags are opaque strings that are used to compare two entities 1244 from the same resource, for example in caches or to optimize setup 1245 after a redirect. Further explanation is present in [H3.11]. For an 1246 explanation of how to compare entity tags see [H13.3]. Entity tags 1247 can be carried in the ETag header (see Section 14.21) or in SDP (see 1248 Appendix C.1.9). 1250 Entity tags are used in RTSP to make some methods conditional. The 1251 methods are made conditional through the inclusion of headers, see 1252 Section 14.24 and Section 14.26. Note that RTSP entity tags apply to 1253 the complete presentation; i.e., both the session description and the 1254 individual media streams. Thus entity tags can be used to verify at 1255 setup time after a redirect that the same session description applies 1256 to the media at the new location using the If-Match header. 1258 4. RTSP Message 1260 RTSP is a text-based protocol and uses the ISO 10646 character set in 1261 UTF-8 encoding (RFC 3629 [RFC3629]). Lines SHALL be terminated by 1262 CRLF. 1264 Text-based protocols make it easier to add optional parameters in 1265 a self-describing manner. Since the number of parameters and the 1266 frequency of commands is low, processing efficiency is not a 1267 concern. Text-based protocols, if done carefully, also allow easy 1268 implementation of research prototypes in scripting languages such 1269 as Tcl, Visual Basic and Perl. 1271 The ISO 10646 character set avoids tricky character set switching, 1272 but is invisible to the application as long as US-ASCII is being 1273 used. This is also the encoding used for RTCP [RFC3550]. ISO 8859-1 1274 translates directly into Unicode with a high-order octet of zero. 1275 ISO 8859-1 characters with the most-significant bit set are 1276 represented as 1100001x 10xxxxxx. (See RFC 3629 [RFC3629]) 1278 Requests contain methods, the object the method is operating upon and 1279 parameters to further describe the method. Methods are idempotent 1280 unless otherwise noted. Methods are also designed to require little 1281 or no state maintenance at the media server. 1283 4.1. Message Types 1285 See [H4.1]. 1287 4.2. Message Headers 1289 See [H4.2]. 1291 4.3. Message Body 1293 See [H4.3]. 1295 Unlike HTTP, the presence of a message-body in either a request or a 1296 response MUST be signaled by the inclusion of a Content-Length header 1297 field (see Section 14.16). 1299 4.4. Message Length 1301 When a message body is included with a message, the length of that 1302 body is determined by one of the following (in order of precedence): 1304 1. Any response message which MUST NOT include a message body (such 1305 as the 1xx, 204, and 304 responses) is always terminated by the 1306 first empty line after the header fields, regardless of the 1307 entity-header fields present in the message. (Note: An empty 1308 line is a line with nothing preceding the CRLF.) 1310 2. If a Content-Length header field (Section 14.16) is present, its 1311 value in bytes represents the length of the message-body. If 1312 this header field is not present, a value of zero is assumed. 1314 Unlike an HTTP message, an RTSP message MUST contain a Content-Length 1315 header field whenever it contains a message body. Note that RTSP 1316 does not support the HTTP/1.1 "chunked" transfer coding (see 1317 [H3.6.1]). 1319 Given the moderate length of presentation descriptions returned, 1320 the server should always be able to determine its length, even if 1321 it is generated dynamically, making the chunked transfer encoding 1322 unnecessary. 1324 5. General Header Fields 1326 See [H4.5], except that the Pragma, Trailer, Transfer-Encoding, 1327 Upgrade, and Warning headers are not defined. RTSP further defines 1328 the CSeq, Proxy-Supported and Timestamp headers. The general headers 1329 are listed in Table 1: 1331 +-----------------+--------------------+ 1332 | Header Name | Defined in Section | 1333 +-----------------+--------------------+ 1334 | Cache-Control | Section 14.10 | 1335 | | | 1336 | Connection | Section 14.11 | 1337 | | | 1338 | CSeq | Section 14.19 | 1339 | | | 1340 | Date | Section 14.20 | 1341 | | | 1342 | Proxy-Supported | Section 14.32 | 1343 | | | 1344 | Supported | Section 14.43 | 1345 | | | 1346 | Timestamp | Section 14.44 | 1347 | | | 1348 | Via | Section 14.49 | 1349 +-----------------+--------------------+ 1351 Table 1: The general headers used in RTSP 1353 6. Request 1355 A request message uses the format outlined below regardless of the 1356 direction of a request, client to server or server to client: 1358 o Request line, containing the method to be applied to the resource, 1359 the identifier of the resource, and the protocol version in use; 1361 o Zero or more Header lines, that can be of the following types: 1362 general (Section 5), request (Section 6.2), or entity 1363 (Section 8.1); 1365 o One empty line (CRLF) to indicate the end of the header section; 1367 o Optionally a message body (entity), consisting of one or more 1368 lines. The length of the message body in bytes is indicated by 1369 the Content-Length entity header. 1371 6.1. Request Line 1373 The request line provides the key information about the request: what 1374 method, on what resources and using which RTSP version. The methods 1375 that are defined by this specification are listed in Table 2. 1377 +---------------+--------------------+ 1378 | Method | Defined in Section | 1379 +---------------+--------------------+ 1380 | DESCRIBE | Section 11.2 | 1381 | | | 1382 | GET_PARAMETER | Section 11.7 | 1383 | | | 1384 | OPTIONS | Section 11.1 | 1385 | | | 1386 | PAUSE | Section 11.5 | 1387 | | | 1388 | PLAY | Section 11.4 | 1389 | | | 1390 | REDIRECT | Section 11.9 | 1391 | | | 1392 | SETUP | Section 11.3 | 1393 | | | 1394 | SET_PARAMETER | Section 11.8 | 1395 | | | 1396 | TEARDOWN | Section 11.6 | 1397 +---------------+--------------------+ 1399 Table 2: The RTSP Methods 1401 The syntax of the RTSP request line is the following: 1403 CRLF 1405 Note: This syntax cannot be freely changed in future versions of 1406 RTSP. This line needs to remain parsable by older RTSP 1407 implementations since it indicates the RTSP version of the message. 1409 In contrast to HTTP/1.1 [RFC2616], RTSP requests identify the 1410 resource through an absolute RTSP URI (scheme, host, and port) (see 1411 Section 3.2) rather than just the absolute path. 1413 HTTP/1.1 requires servers to understand the absolute URI, but 1414 clients are supposed to use the Host request header. This is 1415 purely needed for backward-compatibility with HTTP/1.0 servers, a 1416 consideration that does not apply to RTSP. 1418 An asterisk "*" can be used instead of an absolute URI in the 1419 Request-URI part to indicate that the request does not apply to a 1420 particular resource, but to the server or proxy itself, and is only 1421 allowed when the request method does not necessarily apply to a 1422 resource. 1424 For example: 1426 OPTIONS * RTSP/2.0 1428 An OPTIONS in this form will determine the capabilities of the server 1429 or the proxy that first receives the request. If the capability of 1430 the specific server needs to be determined, without regard to the 1431 capability of an intervening proxy, the server should be addressed 1432 explicitly with an absolute URI that contains the server's address. 1434 For example: 1436 OPTIONS rtsp://example.com RTSP/2.0 1438 6.2. Request Header Fields 1440 The RTSP headers in Table Table 3 can be included in a request, as 1441 request headers, to modify the specifics of the request. Some of 1442 these headers may also be used in the response to a request, as 1443 response headers, to modify the specifics of a response 1444 (Section 7.2). 1446 +--------------------+--------------------+ 1447 | Header | Defined in Section | 1448 +--------------------+--------------------+ 1449 | Accept | Section 14.1 | 1450 | | | 1451 | Accept-Credentials | Section 14.2 | 1452 | | | 1453 | Accept-Encoding | Section 14.3 | 1454 | | | 1455 | Accept-Language | Section 14.4 | 1456 | | | 1457 | Authorization | Section 14.7 | 1458 | | | 1459 | Bandwidth | Section 14.8 | 1460 | | | 1461 | Blocksize | Section 14.9 | 1462 | | | 1463 | From | Section 14.23 | 1464 | | | 1465 | If-Match | Section 14.24 | 1466 | | | 1467 | If-Modified-Since | Section 14.25 | 1468 | | | 1469 | If-None-Match | Section 14.26 | 1470 | | | 1471 | Proxy-Require | Section 14.31 | 1472 | | | 1473 | Range | Section 14.34 | 1474 | Referer | Section 14.35 | 1475 | | | 1476 | Require | Section 14.37 | 1477 | | | 1478 | Scale | Section 14.39 | 1479 | | | 1480 | Session | Section 14.42 | 1481 | | | 1482 | Speed | Section 14.40 | 1483 | | | 1484 | Supported | Section 14.43 | 1485 | | | 1486 | Transport | Section 14.45 | 1487 | | | 1488 | User-Agent | Section 14.47 | 1489 +--------------------+--------------------+ 1491 Table 3: The RTSP request headers 1493 Detailed headers definition are provided in Section 14. 1495 New request headers may be defined. If the receiver of the request 1496 is required to understand the request header, the request MUST 1497 include a corresponding feature tag in a Require or Proxy-Require 1498 header to ensure the correct processing of the header. 1500 7. Response 1502 [H6] applies except that HTTP-Version is replaced by RTSP-Version. 1503 Also, RTSP defines additional status codes and does not define some 1504 of the HTTP codes. The valid response codes and the methods they can 1505 be used with are listed in Table 4. 1507 After receiving and interpreting a request message, the recipient 1508 responds with an RTSP response message. 1510 7.1. Status-Line 1512 The first line of a Response message is the Status-Line, consisting 1513 of the protocol version followed by a numeric status code and the 1514 textual phrase associated with the status code, with each element 1515 separated by SP characters. No CR or LF is allowed except in the 1516 final CRLF sequence. 1518 SP SP CRLF 1520 7.1.1. Status Code and Reason Phrase 1522 The Status-Code element is a 3-digit integer result code of the 1523 attempt to understand and satisfy the request. These codes are fully 1524 defined in Section 13. The Reason-Phrase is intended to give a short 1525 textual description of the Status-Code. The Status-Code is intended 1526 for use by automata and the Reason-Phrase is intended for the human 1527 user. The client is not required to examine or display the Reason- 1528 Phrase. 1530 The first digit of the Status-Code defines the class of response. 1531 The last two digits do not have any categorization role. There are 5 1532 values for the first digit: 1534 1xx: Informational - Request received, continuing process 1536 2xx: Success - The action was successfully received, understood, and 1537 accepted 1539 3rr: Redirection - Further action needs to be taken in order to 1540 complete the request 1542 4xx: Client Error - The request contains bad syntax or cannot be 1543 fulfilled 1545 5xx: Server Error - The server failed to fulfill an apparently valid 1546 request 1548 The individual values of the numeric status codes defined for 1549 RTSP/2.0, and an example set of corresponding Reason-Phrases, are 1550 presented in Table 4. The reason phrases listed here are only 1551 recommended; they may be replaced by local equivalents without 1552 affecting the protocol. Note that RTSP adopts most HTTP/1.1 1553 [RFC2616] status codes and adds RTSP-specific status codes starting 1554 at x50 to avoid conflicts with newly defined HTTP status codes. 1556 RTSP status codes are extensible. RTSP applications are not required 1557 to understand the meaning of all registered status codes, though such 1558 understanding is obviously desirable. However, applications MUST 1559 understand the class of any status code, as indicated by the first 1560 digit, and treat any unrecognized response as being equivalent to the 1561 x00 status code of that class, with the exception that an 1562 unrecognized response MUST NOT be cached. For example, if an 1563 unrecognized status code of 431 is received by the client, it can 1564 safely assume that there was something wrong with its request and 1565 treat the response as if it had received a 400 status code. In such 1566 cases, user agents SHOULD present to the user the entity returned 1567 with the response, since that entity is likely to include human- 1568 readable information which will explain the unusual status. 1570 +------+-------------------------------------+-----------------+ 1571 | Code | Reason | Method | 1572 +------+-------------------------------------+-----------------+ 1573 | 100 | Continue | all | 1574 | | | | 1575 | | | | 1576 | 200 | OK | all | 1577 | | | | 1578 | | | | 1579 | 300 | Multiple Choices | all | 1580 | | | | 1581 | 301 | Multiple Choices | all | 1582 | | | | 1583 | 301 | Moved Permanently | all | 1584 | | | | 1585 | 302 | Found | all | 1586 | | | | 1587 | 303 | See Other | all | 1588 | | | | 1589 | 305 | Use Proxy | all | 1590 | | | | 1591 | | | | 1592 | 400 | Bad Request | all | 1593 | 401 | Unauthorized | all | 1594 | | | | 1595 | 402 | Payment Required | all | 1596 | | | | 1597 | 403 | Forbidden | all | 1598 | | | | 1599 | 404 | Not Found | all | 1600 | | | | 1601 | 405 | Method Not Allowed | all | 1602 | | | | 1603 | 406 | Not Acceptable | all | 1604 | | | | 1605 | 407 | Proxy Authentication Required | all | 1606 | | | | 1607 | 408 | Request Timeout | all | 1608 | | | | 1609 | 410 | Gone | all | 1610 | | | | 1611 | 411 | Length Required | all | 1612 | | | | 1613 | 412 | Precondition Failed | DESCRIBE, SETUP | 1614 | | | | 1615 | 413 | Request Entity Too Large | all | 1616 | | | | 1617 | 414 | Request-URI Too Long | all | 1618 | | | | 1619 | 415 | Unsupported Media Type | all | 1620 | | | | 1621 | 451 | Parameter Not Understood | SET_PARAMETER | 1622 | | | | 1623 | 452 | reserved | n/a | 1624 | | | | 1625 | 453 | Not Enough Bandwidth | SETUP | 1626 | | | | 1627 | 454 | Session Not Found | all | 1628 | | | | 1629 | 455 | Method Not Valid In This State | all | 1630 | | | | 1631 | 456 | Header Field Not Valid | all | 1632 | | | | 1633 | 457 | Invalid Range | PLAY, PAUSE | 1634 | | | | 1635 | 458 | Parameter Is Read-Only | SET_PARAMETER | 1636 | | | | 1637 | 459 | Aggregate Operation Not Allowed | all | 1638 | | | | 1639 | 460 | Only Aggregate Operation Allowed | all | 1640 | | | | 1641 | 461 | Unsupported Transport | all | 1642 | | | | 1643 | 462 | Destination Unreachable | all | 1644 | | | | 1645 | 463 | Destination Prohibited | SETUP | 1646 | | | | 1647 | 464 | Data Transport Not Ready Yet | PLAY | 1648 | | | | 1649 | 470 | Connection Authorization Required | all | 1650 | | | | 1651 | 471 | Connection Credentials not accepted | all | 1652 | | | | 1653 | | | | 1654 | 500 | Internal Server Error | all | 1655 | | | | 1656 | 501 | Not Implemented | all | 1657 | | | | 1658 | 502 | Bad Gateway | all | 1659 | | | | 1660 | 503 | Service Unavailable | all | 1661 | | | | 1662 | 504 | Gateway Timeout | all | 1663 | | | | 1664 | 505 | RTSP Version Not Supported | all | 1665 | | | | 1666 | 551 | Option not support | all | 1667 +------+-------------------------------------+-----------------+ 1669 Table 4: Status codes and their usage with RTSP methods 1671 7.2. Response Header Fields 1673 The response-header fields allow the request recipient to pass 1674 additional information about the response which cannot be placed in 1675 the Status-Line. These header fields give information about the 1676 server and about further access to the resource identified by the 1677 Request-URI. All headers currently classified as response headers 1678 are listed in Table 5. 1680 +------------------------+--------------------+ 1681 | Header | Defined in Section | 1682 +------------------------+--------------------+ 1683 | Accept-Credentials | Section 14.2 | 1684 | | | 1685 | Accept-Ranges | Section 14.5 | 1686 | | | 1687 | Connection-Credentials | Section 14.12 | 1688 | | | 1689 | ETag | Section 14.21 | 1690 | | | 1691 | Location | Section 14.28 | 1692 | | | 1693 | Proxy-Authenticate | Section 14.29 | 1694 | | | 1695 | Public | Section 14.33 | 1696 | | | 1697 | Range | Section 14.34 | 1698 | | | 1699 | Retry-After | Section 14.36 | 1700 | | | 1701 | RTP-Info | Section 14.38 | 1702 | | | 1703 | Scale | Section 14.39 | 1704 | | | 1705 | Session | Section 14.42 | 1706 | | | 1707 | Server | Section 14.41 | 1708 | | | 1709 | Speed | Section 14.40 | 1710 | | | 1711 | Transport | Section 14.45 | 1712 | | | 1713 | Unsupported | Section 14.46 | 1714 | | | 1715 | Vary | Section 14.48 | 1716 | | | 1717 | WWW-Authenticate | Section 14.50 | 1718 +------------------------+--------------------+ 1720 Table 5: The RTSP response headers 1722 Response-header field names can be extended reliably only in 1723 combination with a change in the protocol version. However the usage 1724 of feature-tags in the request allows the responding party to learn 1725 the capability of the receiver of the response. New or experimental 1726 header fields MAY be given the semantics of response-header fields if 1727 all parties in the communication recognize them to be response-header 1728 fields. Unrecognized header fields in responses are treated as 1729 entity-header fields. 1731 8. Entity 1733 Request and Response messages MAY transfer an entity if not otherwise 1734 restricted by the request method or response status code. An entity 1735 consists of entity-header fields and an entity-body, although some 1736 responses will only include the entity-headers. 1738 The SETPARAMETER and GETPARAMETER request and response, and DESCRIBE 1739 response MAY have an entity. All 4xx and 5xx responses MAY also have 1740 an entity. 1742 In this section, both sender and recipient refer to either the client 1743 or the server, depending on who sends and who receives the entity. 1745 8.1. Entity Header Fields 1747 Entity-header fields define meta-information about the entity-body 1748 or, if no body is present, about the resource identified by the 1749 request. The entity header fields are listed in Table 6. 1751 +------------------+--------------------+ 1752 | Header | Defined in Section | 1753 +------------------+--------------------+ 1754 | Allow | Section 14.6 | 1755 | | | 1756 | Content-Base | Section 14.13 | 1757 | | | 1758 | Content-Encoding | Section 14.14 | 1759 | | | 1760 | Content-Language | Section 14.15 | 1761 | | | 1762 | Content-Length | Section 14.16 | 1763 | | | 1764 | Content-Location | Section 14.17 | 1765 | | | 1766 | Content-Type | Section 14.18 | 1767 | | | 1768 | Expires | Section 14.22 | 1769 | | | 1770 | Last-Modified | Section 14.27 | 1771 +------------------+--------------------+ 1773 Table 6: The RTSP entity headers 1775 The extension-header mechanism allows additional entity-header fields 1776 to be defined without changing the protocol, but these fields cannot 1777 be assumed to be recognizable by the recipient. Unrecognized header 1778 fields SHOULD be ignored by the recipient and forwarded by proxies. 1780 8.2. Entity Body 1782 See [H7.2] with the addition that an RTSP message with an entity body 1783 MUST include the Content-Type and Content-Length headers. 1785 9. Connections 1787 RTSP requests can be transmitted using the two different connection 1788 scenarios listed below: 1790 o persistent - a transport connection is used for several request/ 1791 response transactions; 1793 o transient - a transport connection is used for a single request/ 1794 response transaction. 1796 RFC 2326 attempted to specify an optional mechanism for transmitting 1797 RTSP messages in connectionless mode over a transport protocol such 1798 as UDP. However, it was not specified in sufficient detail to allow 1799 for interoperable implementations. In an attempt to reduce 1800 complexity and scope, and due to lack of interest, RTSP 2.0 does not 1801 attempt to define a mechanism for supporting RTSP over UDP or other 1802 connectionless transport protocols. A side-effect of this is that 1803 RTSP requests SHALL NOT be sent to multicast groups since no 1804 connection can be established with a specific receiver in multicast 1805 environments. 1807 Certain RTSP headers, such as the CSeq header Section 14.19), which 1808 may appear to be relevant only to connectionless transport scenarios 1809 are still retained and must be implemented according to the 1810 specification. In the case of CSeq, it is quite useful for matching 1811 responses to requests if the requests are pipelined (see 1812 Section 9.2). It is also useful in proxies for keeping track of the 1813 different requests when aggregating several client requests on a 1814 single TCP connection. 1816 9.1. Reliability and Acknowledgements 1818 When RTSP messages are transmitted using reliable transport 1819 protocols, they MUST NOT be retransmitted at the RTSP protocol level. 1820 Instead, the implementation must rely on the underlying transport to 1821 provide reliability. The RTSP implementation may use any indication 1822 of reception acknowledgement of the message from the underlying 1823 transport protocols to optimize the RTSP behavior. 1825 If both the underlying reliable transport such as TCP and the RTSP 1826 application retransmit requests, each packet loss or message loss 1827 may result in two retransmissions. The receiver typically cannot 1828 take advantage of the application-layer retransmission since the 1829 transport stack will not deliver the application-layer 1830 retransmission before the first attempt has reached the receiver. 1831 If the packet loss is caused by congestion, multiple 1832 retransmissions at different layers will exacerbate the 1833 congestion. 1835 Lack of acknowledgement of an RTSP request should be handled within 1836 the constraints of the connection timeout considerations described 1837 below (Section 9.4). 1839 9.2. Using Connections 1841 A TCP transport can be used for both persistent connections (for 1842 several message exchanges) and transient connections (for a single 1843 message exchange). Implementations of this specification MUST 1844 support RTSP over TCP. The scheme of the RTSP URI (Section 3.2) 1845 indicates the default port that the server will listen on. 1847 A server MUST handle both persistent and transient connections. 1849 Transient connections facilitate mechanisms for fault tolerance. 1850 They also allow for application layer mobility. A server and 1851 client pair that support transient connections can survive the 1852 loss of a TCP connection; e.g., due to a NAT timeout. When the 1853 client has discovered that the TCP connection has been lost, it 1854 can set up a new one when there is need to communicate again. 1856 A persistent connection MAY be used for all transactions between the 1857 server and client, including messages for multiple RTSP sessions. 1858 However a persistent connection MAY also be closed after a few 1859 message exchanges. For example, a client may use a persistent 1860 connection for the initial SETUP and PLAY message exchanges in a 1861 session and then close the connection. Later, when the client wishes 1862 to send a new request, such as a PAUSE for the session, a new 1863 connection would be opened. This connection may either be transient 1864 or persistent. 1866 An RTSP agent SHOULD NOT have more than one connection to the server 1867 at any given point. If a client or proxy handles multiple RTSP 1868 sessions on the same server, it SHOULD use only one connection for 1869 managing those sessions. 1871 This saves connection resources on the server. It also reduces 1872 complexity by and enabling the server to maintain less state about 1873 its sessions and connections. 1875 Unlike HTTP, RTSP allows a server to send requests to a client. 1876 However, this can be supported only if a client establishes a 1877 persistent connection with the server. In cases where a persistent 1878 connection does not exist between a server and its client, due to the 1879 lack of a signalling channel the server may be forced to drop an RTSP 1880 session without notifying the client. An example of such a case is 1881 when the server desires to send a REDIRECT request for an RTSP 1882 session to the client but is not able to do so because it cannot 1883 reach the client. 1885 Without a persistent connection between the client and the server, 1886 the media server has no reliable way of reaching the client. 1887 Also, this is the only way that requests from a server to its 1888 client are likely to traverse firewalls. 1890 In light of the above, it is RECOMMENDED that clients use persistent 1891 connections whenever possible. A client that supports persistent 1892 connections MAY "pipeline" its requests (i.e., send multiple requests 1893 without waiting for each response). A server MUST send its responses 1894 to those requests in the order that the requests were received. 1896 9.3. Closing Connections 1898 The client MAY close a connection at any point when no outstanding 1899 request/response transactions exist for any RTSP session being 1900 managed through the connection. The server, however, SHOULD NOT 1901 close a connection until all RTSP sessions being managed through the 1902 connection have been timed out (Section 14.42). A server SHOULD NOT 1903 close a connection immediately after responding to a session-level 1904 TEARDOWN request for the last RTSP session being controlled through 1905 the connection. Instead, it should wait for a reasonable amount of 1906 time for the client to receive the TEARDOWN response, take 1907 appropriate action, and initiate the connection closing. The server 1908 SHOULD wait at least 10 seconds after sending the TEARDOWN response 1909 before closing the connection. 1911 This is to ensure that the client has time to issue a SETUP for a 1912 new session on the existing connection after having torn the last 1913 one down. 10 seconds should give the client ample opportunity get 1914 its message to the server. 1916 A server SHOULD NOT close the connection directly as a result of 1917 responding to a request with an error code. 1919 Certain error responses such as "460 Only Aggregate Operation 1920 Allowed" (Section 13.4.12) are used for negotiating capabilities 1921 of a server with respect to content or other factors. In such 1922 cases, it is inefficient for the server to close a connection on 1923 an error response. Also, such behavior would prevent 1924 implementation of advanced/special types of requests or result in 1925 extra overhead for the client when testing for new features. On 1926 the flip side, keeping connections open after sending an error 1927 response poses a Denial of Service security risk (Section 20). 1929 If a server initiates a connection close while the client is 1930 attempting to send a new request, the client will have to close its 1931 current connection, establish a new connection and send its request 1932 over the new connection. 1934 An RTSP message should not be terminated by closing the connection. 1935 Such a message MAY be considered to be incomplete by the receiver and 1936 discarded. An RTSP message is properly terminated as defined in 1937 Section Section 4. 1939 9.4. Timing Out Connections and RTSP Messages 1941 Receivers of a request (responder) SHOULD respond to requests in a 1942 timely manner even when a reliable transport such as TCP is used. 1943 Similarly, the sender of a request (requestor) SHOULD wait for a 1944 sufficient time for a response before concluding that the responder 1945 will not be acting upon its request. 1947 A responder SHOULD respond to all requests within 5 seconds. If the 1948 responder recognizes that processing of a request will take longer 1949 than 5 seconds, it SHOULD send a 100 (Continue) response as soon as 1950 possible. It SHOULD continue sending a 100 response every 5 seconds 1951 thereafter until it is ready to send the final response to the 1952 requestor. After sending a 100 response, the receiver MUST send a 1953 final response indicating the success or failure of the request. 1955 A requestor SHOULD wait at least 10 seconds for a response before 1956 concluding that the responder will not be responding to its request. 1957 After receiving a 100 response, the requestor SHOULD continue waiting 1958 for further responses. If more than 10 seconds elapses without 1959 receiving any response, the requestor MAY assume that the responder 1960 is unresponsive and abort the connection. 1962 A requestor SHOULD wait longer than 10 seconds for a response if it 1963 is experiencing significant transport delays on its connection to the 1964 responder. The requestor is capable of determining the RTT of the 1965 request/response cycle using the Timestamp header (Section 14.44) in 1966 any RTSP request. 1968 9.5. Use of IPv6 1970 Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP 1971 2.0 has been updated for explicit IPv6 support. Implementations of 1972 RTSP 2.0 MUST understand literal IPv6 addresses in URIs and headers. 1974 10. Capability Handling 1976 This section describes the capability handling mechanism available in 1977 RTSP which allows RTSP to be extended. Extensions to this version of 1978 the protocol are basically done in two ways. First, new headers can 1979 be added. Secondly, new methods can be added. The capability 1980 handling mechanism is designed to handle both cases. 1982 When a method is added, the involved parties can use the OPTIONS 1983 method to discover wether it is supported. This is done by issuing a 1984 OPTIONS request to the other party. Depending on the URI it will 1985 either apply in regards to a certain media resource, the whole server 1986 in general, or simply the next hop. The OPTIONS response MUST 1987 contain a Public header which declares all methods supported for the 1988 indicated resource. 1990 It is not necessary to use OPTIONS to discover support of a method, 1991 the client could simply try the method. If the receiver of the 1992 request does not support the method it will respond with an error 1993 code indicating the the method is either not implemented (501) or 1994 does not apply for the resource (405). The choice between the two 1995 discovery methods depends on the requirements of the service. 1997 Feature-Tags are defined to handle functionality additions that are 1998 not new methods. Each feature-tag represents a certain block of 1999 functionality. The amount of functionality that a feature-tag 2000 represents can vary significantly. A feature-tag can for example 2001 represent the functionality a single RTSP header provides. Another 2002 feature-tag can represent much more functionality, such as the 2003 "play.basic" feature-tag which represents the minimal playback 2004 implementation. 2006 Feature-tags are used to determine wether the client, server or proxy 2007 supports the functionality that is necessary to achieve the desired 2008 service. To determine support of a feature-tag, several different 2009 headers can be used, each explained below: 2011 Supported: The supported header is used to determine the complete 2012 set of functionality that both client and server have. The 2013 intended usage is to determine before one needs to use a 2014 functionality that it is supported. It can be used in any 2015 method, however OPTIONS is the most suitable one as it at the 2016 same time determines all methods that are implemented. When 2017 sending a request the requestor declares all its capabilities 2018 by including all supported feature-tags. This results in that 2019 the receiver learns the requestors feature support. The 2020 receiver then includes its set of features in the response. 2022 Proxy-Supported: The Proxy-Supported header is used similar to the 2023 Supported header, but instead of giving the supported 2024 functionality of the client or server it provides both the 2025 requestor and the responder a view of what functionality the 2026 proxy chain between the two supports. Proxies are required to 2027 add this header whenever the Supported header is present, but 2028 proxies may independently of the requestor add it. 2030 Require: The Require header can be included in any request where the 2031 end-point, i.e. the client or server, is required to understand 2032 the feature to correctly perform the request. This can, for 2033 example, be a SETUP request where the server is required to 2034 understand a certain parameter to be able to set up the media 2035 delivery correctly. Ignoring this parameter would not have the 2036 desired effect and is not acceptable. Therefore the end-point 2037 receiving a request containing a Require MUST negatively 2038 acknowledge any feature that it does not understand and not 2039 perform the request. The response in cases where features are 2040 not supported are 551 (Option Not Supported). Also the 2041 features that are not supported are given in the Unsupported 2042 header in the response. 2044 Proxy-Require: This method has the same purpose and workings as 2045 Require except that it only applies to proxies and not the end- 2046 point. Features that needs to be supported by both proxies and 2047 end-point needs to be included in both the Require and Proxy- 2048 Require header. 2050 Unsupported: This header is used in a 551 error response, to 2051 indicate which feature(s) that was not supported. Such a 2052 response is only the result of the usage of the Require and/or 2053 Proxy-Require header where one or more feature where not 2054 supported. This information allows the requestor to make the 2055 best of situations as it knows which features are not 2056 supported. 2058 11. Method Definitions 2060 The method indicates what is to be performed on the resource 2061 identified by the Request-URI. The method name is case-sensitive. 2062 New methods may be defined in the future. Method names SHALL NOT 2063 start with a $ character (decimal 24) and MUST be a token as defined 2064 by the ABNF [RFC4234] in the syntax chapter Section 19. The methods 2065 are summarized in Table 7. 2067 +--------------+-----------+--------+---------------+---------------+ 2068 | method | direction | object | Server req. | Client req. | 2069 +--------------+-----------+--------+---------------+---------------+ 2070 | DESCRIBE | C -> S | P,S | recommended | recommended | 2071 | | | | | | 2072 | GETPARAMETER | C -> S | P,S | optional | optional | 2073 | | | | | | 2074 | | S -> C | | | | 2075 | | | | | | 2076 | OPTIONS | C -> S | P,S | R=Req, Sd=Opt | Sd=Req, R=Opt | 2077 | | | | | | 2078 | | S -> C | | | | 2079 | | | | | | 2080 | PAUSE | C -> S | P,S | required | required | 2081 | | | | | | 2082 | PLAY | C -> S | P,S | required | required | 2083 | | | | | | 2084 | REDIRECT | S -> C | P,S | optional | required | 2085 | | | | | | 2086 | SETUP | C -> S | S | required | required | 2087 | | | | | | 2088 | SETPARAMETER | C -> S | P,S | required | optional | 2089 | | | | | | 2090 | | S -> C | | | | 2091 | | | | | | 2092 | TEARDOWN | C -> S | P,S | required | required | 2093 +--------------+-----------+--------+---------------+---------------+ 2095 Table 7: Overview of RTSP methods, their direction, and what objects 2096 (P: presentation, S: stream) they operate on. Legend: R=Respond, 2097 Sd=Send, Opt: Optional, Req: Required 2099 Note on Table 7: GETPARAMETER is recommended, but not required. 2100 For example, a fully functional server can be built to deliver 2101 media without any parameters. SETPARAMETER is required however 2102 due to its usage for keep-alive. PAUSE is now required due to 2103 that it is the only way of getting out of the state machines play 2104 state without terminating the whole session. 2106 If an RTSP agent does not support a particular method, it MUST return 2107 501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD 2108 NOT try this method again for the given agent / resource combination. 2110 11.1. OPTIONS 2112 The semantics of the RTSP OPTIONS method is equivalent to that of the 2113 HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is 2114 bi-directional, in that a client can request it to a server and vice 2115 versa. A client MUST implement the capability to send an OPTIONS 2116 request and a server or a proxy MUST implement the capability to 2117 respond to an OPTIONS request. The client, server or proxy MAY also 2118 implement the converse of their required capability. 2120 An OPTIONS request may be issued at any time. Such a request does 2121 not modify the session state. However, it may prolong the session 2122 lifespan (see below). The URI in an OPTIONS request determines the 2123 scope of the request and the corresponding response. If the Request- 2124 URI refers to a specific media resource on a given host, the scope is 2125 limited to the set of methods supported for that media resource by 2126 the indicated RTSP agent. A Request-URI with only the host address 2127 limits the scope to the specified RTSP agent's general capabilities 2128 without regard to any specific media. If the Request-URI is an 2129 asterisk ("*"), the scope is limited to the general capabilities of 2130 the next hop (i.e. the RTSP agent in direct communication with the 2131 request sender). 2133 Regardless of scope of the request, the Public header MUST always be 2134 included in the OPTIONS response listing the methods that are 2135 supported by the responding RTSP agent. In addition, if the scope of 2136 the request is limited to a media resource, the Allow header MUST be 2137 included in the response to enumerate the set of methods that are 2138 allowed for that resource unless the set of methods completely 2139 matches the set in the Public header. If the given resource is not 2140 available, the RTSP agent SHOULD return an appropriate response code 2141 such as 3rr or 4xx. The Supported header MAY be included in the 2142 request to query the set of features that are supported by the 2143 responding RTSP agent. 2145 The OPTIONS method can be used to keep an RTSP session alive. 2146 However, it is not the preferred means of session keep-alive 2147 signalling, see Section 14.42. An OPTIONS request intended for 2148 keeping alive an RTSP session MUST include the Session header with 2149 the associated session ID. Such a request SHOULD also use the media 2150 or the aggregated control URI as the Request-URI. 2152 Example: 2154 C->S: OPTIONS * RTSP/2.0 2155 CSeq: 1 2156 User-Agent: PhonyClient/1.2 2157 Require: 2158 Proxy-Require: gzipped-messages 2159 Supported: play.basic 2161 S->C: RTSP/2.0 200 OK 2162 CSeq: 1 2163 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE 2164 Supported: play.basic, implicit-play, gzipped-messages 2165 Server: PhonyServer/1.1 2167 Note that some of the feature-tags in Require and Proxy-Require are 2168 fictional features. 2170 11.2. DESCRIBE 2172 The DESCRIBE method is used to retrieve the description of a 2173 presentation or media object from a server. The Request-URI of the 2174 DESCRIBE request identifies the media resource of interest. The 2175 client MAY include the Accept header in the request to list the 2176 description formats that it understands. The server SHALL respond 2177 with a description of the requested resource and return the 2178 description in the entity of the response. The DESCRIBE reply- 2179 response pair constitutes the media initialization phase of RTSP. 2181 Example: 2183 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 2184 CSeq: 312 2185 User-Agent: PhonyClient 1.2 2186 Accept: application/sdp, application/example 2188 S->C: RTSP/2.0 200 OK 2189 CSeq: 312 2190 Date: 23 Jan 1997 15:35:06 GMT 2191 Server: PhonyServer 1.1 2192 Content-Type: application/sdp 2193 Content-Length: 367 2195 v=0 2196 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46 2197 s=SDP Seminar 2198 i=A Seminar on the session description protocol 2199 u=http://www.example.com/lectures/sdp.ps 2200 e=seminar@example.com (Seminar Management) 2201 c=IN IP4 224.2.17.12/127 2202 t=2873397496 2873404696 2203 a=recvonly 2204 m=audio 3456 RTP/AVP 0 2205 m=video 2232 RTP/AVP 31 2206 m=application 32416 UDP WB 2207 a=orient:portrait 2209 The DESCRIBE response SHOULD contain all media initialization 2210 information for the resource(s) that it describes. Servers SHOULD 2211 NOT use the DESCRIBE response as a means of media indirection by 2212 having the description point at another server, instead usage of 3rr 2213 responses are recommended. 2215 By forcing a DESCRIBE response to contain all media initialization 2216 for the set of streams that it describes, and discouraging the use 2217 of DESCRIBE for media indirection, any looping problems can be 2218 avoided that might have resulted from other approaches. 2220 Media initialization is a requirement for any RTSP-based system, but 2221 the RTSP specification does not dictate that this is required to be 2222 done via the DESCRIBE method. There are three ways that an RTSP 2223 client may receive initialization information: 2225 o via an RTSP DESCRIBE request 2227 o via some other protocol (HTTP, email attachment, etc.) 2229 o via some form of a user interface 2230 If a client obtains a valid description from an alternate source, the 2231 client MAY use this description for initialization purposes without 2232 issuing a DESCRIBE request for the same media. 2234 It is RECOMMENDED that minimal servers support the DESCRIBE method, 2235 and highly recommended that minimal clients support the ability to 2236 act as "helper applications" that accept a media initialization file 2237 from a user interface, and/or other means that are appropriate to the 2238 operating environment of the clients. 2240 11.3. SETUP 2242 The SETUP request for an URI specifies the transport mechanism to be 2243 used for the streamed media. The SETUP method may be used in three 2244 different cases; Create an RTSP session, add a media to a session, 2245 and change the transport parameters of already set up media stream. 2246 When in PLAY state, using SETUP to create or add media to a session 2247 when in PLAY state is unspecified. Otherwise SETUP can be used in 2248 all three states; INIT, and READY, for both purposes and in PLAY to 2249 change the transport parameters. 2251 The Transport header, see Section 14.45, specifies the transport 2252 parameters acceptable to the client for data transmission; the 2253 response will contain the transport parameters selected by the 2254 server. This allows the client to enumerate in priority order the 2255 transport mechanisms and parameters acceptable to it, while the 2256 server can select the most appropriate. It is expected that the 2257 session description format used will enable the client to select a 2258 limited number possible configurations that are offered to the server 2259 to choose from. All transport related parameters shall be included 2260 in the Transport header, the use of other headers for this purpose is 2261 discouraged due to middle boxes such as firewalls, or NATs. 2263 For the benefit of any intervening firewalls, a client SHALL indicate 2264 the known transport parameters, even if it has no influence over 2265 these parameters, for example, where the server advertises a fixed 2266 multicast address as destination. 2268 Since SETUP includes all transport initialization information, 2269 firewalls and other intermediate network devices (which need this 2270 information) are spared the more arduous task of parsing the 2271 DESCRIBE response, which has been reserved for media 2272 initialization. 2274 The client SHALL include the Accept-Ranges header in the request 2275 indicating all supported unit formats in the Range header. This 2276 allows the server to know which format it may use in future session 2277 related responses, such as PLAY response without any range in the 2278 request. If the client does not support a time format necessary for 2279 the presentation the server SHALL respond using 456 (Header Field Not 2280 Valid for Resource) and include the Accept-Ranges header with the 2281 range unit formats supported for the resource. 2283 In a SETUP response the server SHALL include the Accept-Ranges header 2284 (see Section 14.5) to indicate which time formats that are acceptable 2285 to use for this media resource. 2287 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 2288 CSeq: 302 2289 Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589", 2290 RTP/AVP/TCP;unicast;interleaved=0-1 2292 S->C: RTSP/2.0 200 OK 2293 CSeq: 302 2294 Date: 23 Jan 1997 15:35:06 GMT 2295 Server: PhonyServer 1.1 2296 Session: 47112344;timeout=60 2297 Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589"; 2298 src_addr="192.0.2.241:6256"/"192.0.2.241:6257"; 2299 ssrc=2A3F93ED 2300 Accept-Ranges: NPT 2302 In the above example the client wants to create an RTSP session 2303 containing the media resource "rtsp://example.com/foo/bar/baz.rm". 2304 The transport parameters acceptable to the client is either RTP/AVP/ 2305 UDP (UDP per default) to be received on client port 4588 and 4589 or 2306 RTP/AVP interleaved on the RTSP control channel. The server selects 2307 the RTP/AVP/UDP transport and adds the ports it will send and 2308 received RTP and RTCP from, and the RTP SSRC that will be used by the 2309 server. 2311 The server MUST generate a session identifier in response to a 2312 successful SETUP request, unless a SETUP request to a server includes 2313 a session identifier, in which case the server MUST bundle this setup 2314 request into the existing session (aggregated session) or return 2315 error 459 (Aggregate Operation Not Allowed) (see Section 13.4.11). 2316 An Aggregate control URI MUST be used to control an aggregated 2317 session. This URI MUST be different from the stream control URIs of 2318 the individual media streams included in the aggregate. The 2319 Aggregate control URI is to be specified by the session description 2320 if the server supports aggregated control and aggregated control is 2321 desired for the session. However even if aggregated control is 2322 offered the client MAY chose to not set up the session in aggregated 2323 control. If an Aggregate control URI is not specified in the session 2324 description, it is normally an indication that non-aggregated control 2325 should be used. The SETUP of media streams in an aggregate which has 2326 not been given an aggregated control URI is unspecified. 2328 While the session ID sometimes has enough information for 2329 aggregate control of a session, the Aggregate control URI is still 2330 important for some methods such as SETPARAMETER where the control 2331 URI enables the resource in question to be easily identified. The 2332 Aggregate control URI is also useful for proxies, enabling them to 2333 route the request to the appropriate server, and for logging, 2334 where it is useful to note the actual resource that a request was 2335 operating on. 2337 A session will exist until it is either removed by a TEARDOWN request 2338 or is timed-out by the server. The server MAY remove a session that 2339 has not demonstrated liveness signs from the client(s) within a 2340 certain timeout period. The default timeout value is 60 seconds; the 2341 server MAY set this to a different value and indicate so in the 2342 timeout field of the Session header in the SETUP response. For 2343 further discussion see Section 14.42. Signs of liveness for an RTSP 2344 session are: 2346 o Any RTSP request from a client(s) which includes a Session header 2347 with that session's ID. 2349 o If RTP is used as a transport for the underlying media streams, an 2350 RTCP sender or receiver report from the client(s) for any of the 2351 media streams in that RTSP session. RTCP Sender Reports may for 2352 example be received in sessions where the server is invited into a 2353 conference session and is as valid for keep-alive. 2355 If a SETUP request on a session fails for any reason, the session 2356 state, as well as transport and other parameters for associated 2357 streams SHALL remain unchanged from their values as if the SETUP 2358 request had never been received by the server. 2360 11.3.1. Changing Transport Parameters 2362 A client MAY issue a SETUP request for a stream that is already set 2363 up or playing in the session to change transport parameters, which a 2364 server MAY allow. If it does not allow changing of parameters, it 2365 MUST respond with error 455 (Method Not Valid In This State). 2366 Reasons to support changing transport parameters, is to allow for 2367 application layer mobility and flexibility to utilize the best 2368 available transport as it becomes available. If a client receives a 2369 455 when trying to change transport parameters while the server is in 2370 play state, it MAY try to put the server in ready state using PAUSE, 2371 before issuing the SETUP request again. If also that fails the 2372 changing of transport parameters will require that the client 2373 performs a TEARDOWN of the affected media and then setting it up 2374 again. In aggregated session avoiding tearing down all the media at 2375 the same time will avoid the creation of a new session. 2377 All transport parameters MAY be changed. However the primary usage 2378 expected is to either change transport protocol completely, like 2379 switching from Interleaved TCP mode to UDP or vise versa or change 2380 delivery address. 2382 In a SETUP response for a request to change the transport parameters 2383 while in Play state, the server SHALL include the Range to indicate 2384 from what point the new transport parameters are used. Further, if 2385 RTP is used for delivery, the server SHALL also include the RTP-Info 2386 header to indicate from what timestamp and RTP sequence number the 2387 change has taken place. If both RTP-Info and Range is included in 2388 the response the "rtp_time" parameter and range MUST be for the 2389 corresponding time, i.e. be used in the same way as for PLAY to 2390 ensure the correct synchronization information is available. 2392 If the transport parameters change while in PLAY state results in a 2393 change of synchronization related information, for example changing 2394 RTP SSRC, the server MUST provide in the SETUP response the necessary 2395 synchronization information. However the server is RECOMMENDED to 2396 avoid changing the synchronization information if possible. 2398 11.4. PLAY 2400 The PLAY method tells the server to start sending data via the 2401 mechanism specified in SETUP. PLAY requests are valid when the 2402 session is in READY or PLAY states. A PLAY request MUST include a 2403 Session header to indicate which session the request applies to. 2405 For aggregated sessions where the initial SETUP request (creating a 2406 session) is followed by one or more additional SETUP request, a PLAY 2407 request MAY be pipelined after those additional SETUP requests 2408 without awaiting their responses. This can procedure can reduce the 2409 delay from start of session establishment until media play-out has 2410 started with one round trip time. However an client needs to be 2411 aware that using this procedure will result in the playout of the 2412 server state established at the time of processing the PLAY, i.e. 2413 after the processing of all the requests prior to the PLAY request in 2414 the pipeline. This may not be the intended one due to failure of any 2415 of the prior requests. However a client easily determine this based 2416 on the responses from those requests. In case of failure the client 2417 can halt the media playout using PAUSE and try to establish the 2418 intended state again before issuing another PLAY request. 2420 In an aggregated session the PLAY request MUST contain an aggregated 2421 control URI. A server SHALL responde with error 460 (Only Aggregate 2422 Operation Allowed) if the client PLAY Request-URI is for one of the 2423 media. The media in an aggregate SHALL be played in sync. If a 2424 client want individual control of the media it needs to use separate 2425 RTSP sessions for each media. 2427 The PLAY request SHALL position the normal play time to the beginning 2428 of the range specified by the Range header and delivers stream data 2429 until the end of the range if given, else to the end of the media is 2430 reached. To allow for precise composition multiple ranges MAY be 2431 specified in one PLAY Request. The range values are valid if all 2432 given ranges are part of any media within the aggregate. If a given 2433 range value points outside of the media, the response SHALL be the 2434 457 (Invalid Range) error code. 2436 The below example will first play seconds 10 through 15, then, 2437 immediately following, seconds 20 to 25, and finally seconds 30 2438 through the end. 2440 C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0 2441 CSeq: 835 2442 Session: 12345678 2443 Range: npt=10-15, npt=20-25, npt=30- 2445 See the description of the PAUSE request for further examples. 2447 A PLAY request without a Range header is legal. It SHALL start 2448 playing a stream from the beginning (npt=0-) unless the stream has 2449 been paused or is currently playing. If a stream has been paused via 2450 PAUSE, stream delivery resumes at the pause point. If a stream is 2451 currently playing, the new PLAY begins at the current stream 2452 position. The stream SHALL play until the end of the media. 2454 The Range header MUST NOT contain a time parameter. The usage of 2455 time in PLAY method has been deprecated. If a request with time 2456 parameter is received the server SHOULD respond with a 457 (Invalid 2457 Range) to indicate that the time parameter is not supported. 2459 Server MUST include a "Range" header in any PLAY response. The 2460 response MUST use the same format as the request's range header 2461 contained. If no Range header was in the request, the NPT time 2462 format SHOULD be used unless the client showed support for an other 2463 format more appropriate. Also for a session with live media streams 2464 the Range header MUST indicate a valid time. It is RECOMMENDED that 2465 normal play time is used, either the "now" indicator, for example 2466 "npt=now-", or the time since session start as an open interval, e.g. 2467 "npt=96.23-". An absolute time value (clock) for the corresponding 2468 time MAY be given, i.e. "clock=20030213T143205Z-". The UTC clock 2469 format SHOULD only be used if client has shown support for it. 2471 For an on-demand stream, the server MUST reply with the actual range 2472 that will be played back, i.e. for which duration any media (having 2473 content at this time) is delivered. This may differ from the 2474 requested range if alignment of the requested range to valid frame 2475 boundaries is required for the media source. Note that some media 2476 streams in an aggregate may need to be delivered from even earlier 2477 points. Also, some media format have a very long duration per 2478 individual data unit, therefore it might be necessary for the client 2479 to parse the data unit, and select where to start. 2481 Example: Single audio stream (MIDI) 2483 C->S: PLAY rtsp://example.com/audio RTSP/2.0 2484 CSeq: 836 2485 Session: 12345678 2486 Range: npt=7.05- 2488 S->C: RTSP/2.0 200 OK 2489 CSeq: 836 2490 Date: 23 Jan 1997 15:35:06 GMT 2491 Server: PhonyServer 1.0 2492 Range: npt=3.52- 2493 RTP-Info:url="rtsp://example.com/audio" 2494 ssrc=0D12F123:seq=14783;rtptime=2345962545 2496 S->C: RTP Packet TS=2345962545 => NPT=3.52 2497 Duration: 4.15 seconds 2499 In this example the client receives the first media packet that 2500 stretches all the way up and past the requested playtime. Thus, it 2501 is the client's decision if to render to the user the time between 2502 3.52 and 7.05, or to skip it. In most cases it is probably most 2503 suitable to not render that time period. 2505 For live media sources it might be impossible to specify from which 2506 point in time all media streams carrying active content can actually 2507 be delivered. Therefore a server MAY specify a start time (or now-) 2508 in the range header, for which not all media will be available from. 2510 If no range is specified in the request, the start position SHALL 2511 still be returned in the reply. If the medias that are part of an 2512 aggregate has different lengths, the PLAY request SHALL be performed 2513 as long as the given range is valid for any media, for example the 2514 longest media. Media will be sent whenever it is available for the 2515 given play-out point. 2517 A PLAY response MAY include a header(s) carrying synchronization 2518 information. As the information necessary is dependent on the media 2519 transport format, further rules specifying the header and its usage 2520 is needed. For RTP the RTP-Info header is specified, see 2521 Section 14.38. 2523 After playing the desired range, the presentation does NOT transition 2524 to the READY state, media delivery simply stops. A PAUSE request 2525 MUST be issued before the stream enters the READY state. A PLAY 2526 request while the stream is still in the PLAYING state is legal, and 2527 can be issued without an intervening PAUSE request. Such a request 2528 SHALL replace the current PLAY action with the new one requested, 2529 i.e. being handle the same as the request was received in ready 2530 state. In the case the first time range in Range header has a open 2531 start time (-endtime), the server SHALL continue to play from where 2532 it currently was until the specified end point. This is useful to 2533 change ongoing playback to play another sequence, or end at another 2534 point than in the previous request. 2536 A client desiring to play the media from the beginning MUST send a 2537 PLAY request with a Range header pointing at the beginning, e.g. 2538 npt=0-. If a PLAY request is received without a Range header when 2539 media delivery has stopped at the end, the server SHOULD respond with 2540 a 457 "Invalid Range" error response. In that response the current 2541 pause point in a Range header SHALL be included. 2543 The following example plays the whole presentation starting at SMPTE 2544 time code 0:10:20 until the end of the clip. Note: The RTP-Info 2545 headers has been broken into several lines to fit the page. 2547 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0 2548 CSeq: 833 2549 Session: 12345678 2550 Range: smpte=0:10:20- 2552 S->C: RTSP/2.0 200 OK 2553 CSeq: 833 2554 Date: 23 Jan 1997 15:35:06 GMT 2555 Server: PhonyServer 1.0 2556 Range: smpte=0:10:22-0:15:45 2557 RTP-Info:url="rtsp://example.com/twister.en" 2558 ssrc=0D12F123:seq=14783;rtptime=2345962545 2560 For playing back a recording of a live presentation, it may be 2561 desirable to use clock units: 2563 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0 2564 CSeq: 835 2565 Session: 12345678 2566 Range: clock=19961108T142300Z-19961108T143520Z 2568 S->C: RTSP/2.0 200 OK 2569 CSeq: 835 2570 Date: 23 Jan 1997 15:35:06 GMT 2571 Server:PhonyServer 1.0 2572 Range: clock=19961108T142300Z-19961108T143520Z 2573 RTP-Info:url="rtsp://example.com/meeting.en" 2574 ssrc=0D12F123:seq=53745;rtptime=484589019 2576 All range specifiers in this specification allow for ranges with 2577 unspecified begin times (e.g. "npt=-30"). When used in a PLAY 2578 request, the server treats this as a request to start/resume playback 2579 from the current pause point, ending at the end time specified in the 2580 Range header. If the pause point is located later than the given end 2581 value, a 457 (Invalid Range) response SHALL be given. 2583 The possibility to replace a current PLAY request with a new one 2584 replaces two RTSP 1.0 functions: 2586 o The queued play functionality described in RFC 2326 [RFC2326] is 2587 removed and multiple ranges can be used to achieve a similar 2588 functionality. 2590 o The use of PLAY for keep-alive signaling, i.e. PLAY request 2591 without a range header in PLAY state, has also been deprecated. 2592 Instead a client can use, SETPARAMETER (recommended) or OPTIONS 2593 (allowed) for keep alive. 2595 An example of using PLAY request to change the behavior, if a server 2596 has received requests to play ranges 10 to 15 and then 13 to 20 (that 2597 is, overlapping ranges), a PLAY request 4 seconds after the first 2598 would take effect while the server plays the first range. Thus 2599 changing the behavior to continue to play to 25 seconds, i.e. the 2600 played range equal play with range: npt=10-25. If the second PLAY 2601 request would arrive after the second range in the first range was 2602 playing, then the equivalent request would be play with range:npt=10- 2603 15,npt=13-25. 2605 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 2606 CSeq: 834 2607 Session: 12345678 2608 Range: npt=10-15, npt=13-20 2610 S->C: RTSP/2.0 200 OK 2611 CSeq: 834 2612 Date: 23 Jan 1997 15:35:06 GMT 2613 Server: PhonyServer 1.0 2614 Range: npt=10-15, npt=13-20 2615 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 2616 ssrc=0D12F123:seq=5712;rtptime=934207921, 2617 url="rtsp://example.com/fizzle/videotrack" 2618 ssrc=789DAF12:seq=57654;rtptime=2792482193 2619 Session: 12345678 2621 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 2622 CSeq: 835 2623 Session: 12345678 2624 Range: npt=-25 2626 S->C: RTSP/2.0 200 OK 2627 CSeq: 835 2628 Date: 23 Jan 1997 15:35:09 GMT 2629 Server: PhonyServer 1.0 2630 Range: npt=14-15, npt=13-25 2631 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 2632 ssrc=0D12F123:seq=5712;rtptime=934239921, 2633 url="rtsp://example.com/fizzle/videotrack" 2634 ssrc=789DAF12:seq=57654;rtptime=2792842193 2635 Session: 12345678 2637 11.5. PAUSE 2639 The PAUSE request causes the stream delivery to immediately be 2640 interrupted (halted). A PAUSE request MUST be done with the 2641 aggregated control URI for aggregated sessions, resulting in all 2642 media being halted, or the media URI for non-aggregated sessions. 2643 Any attempt to do muting of a single media with an PAUSE request in 2644 an aggregated session SHALL be responded with error 460 (Only 2645 Aggregate Operation Allowed). After resuming playback, 2646 synchronization of the tracks MUST be maintained. Any server 2647 resources are kept, though servers MAY close the session and free 2648 resources after being paused for the duration specified with the 2649 timeout parameter of the Session header in the SETUP message. 2651 Example: 2653 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 2654 CSeq: 834 2655 Session: 12345678 2657 S->C: RTSP/2.0 200 OK 2658 CSeq: 834 2659 Date: 23 Jan 1997 15:35:06 GMT 2660 Range: npt=45.76- 2662 The PAUSE request causes stream delivery to be interrupted 2663 immediately on receipt of the message and the pause point is set to 2664 the current point in the presentation. That pause point in the media 2665 stream needs to be maintained. A subsequent PLAY request without 2666 Range header SHALL resume from the pause point and play until media 2667 end. 2669 The pause point after any PAUSE request SHALL be returned to the 2670 client by adding a Range header with what remains unplayed of the 2671 PLAY request's ranges, i.e. including all the remaining ranges part 2672 of multiple range specification. If one desires to resume playing a 2673 ranged request, one simply includes the Range header from the PAUSE 2674 response. 2676 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 2677 CSeq: 834 2678 Session: 12345678 2679 Range: npt=10-30 2681 S->C: RTSP/2.0 200 OK 2682 CSeq: 834 2683 Date: 23 Jan 1997 15:35:06 GMT 2684 Server: PhonyServer 1.0 2685 Range: npt=10-30 2686 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 2687 ssrc=0D12F123:seq=5712;rtptime=934207921, 2688 url="rtsp://example.com/fizzle/videotrack" 2689 ssrc=4FAD8726:seq=57654;rtptime=2792482193 2690 Session: 12345678 2692 after 11 seconds, i.e. at 21 seconds into the presentation: 2693 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 2694 CSeq: 835 2695 Session: 12345678 2697 S->C: RTSP/2.0 200 OK 2698 CSeq: 835 2699 Date: 23 Jan 1997 15:35:09 GMT 2700 Server: PhonyServer 1.0 2701 Range: npt=21-30 2702 Session: 12345678 2704 If a client issues a PAUSE request and the server acknowledges and 2705 enters the READY state, the proper server response, if the player 2706 issues another PAUSE, is still 200 OK. The 200 OK response MUST 2707 include the Range header with the current pause point. See examples 2708 below: 2710 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 2711 CSeq: 834 2712 Session: 12345678 2714 S->C: RTSP/2.0 200 OK 2715 CSeq: 834 2716 Session: 12345678 2717 Date: 23 Jan 1997 15:35:06 GMT 2718 Range: npt=45.76-98.36 2720 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 2721 CSeq: 835 2722 Session: 12345678 2724 S->C: RTSP/2.0 200 OK 2725 CSeq: 835 2726 Session: 12345678 2727 Date: 23 Jan 1997 15:35:07 GMT 2728 Range: npt=45.76-98.36 2730 11.6. TEARDOWN 2732 The TEARDOWN client to server request stops the stream delivery for 2733 the given URI, freeing the resources associated with it. A TEARDOWN 2734 request MAY be performed on either an aggregated or a media control 2735 URI. However some restrictions apply depending on the current state. 2736 The TEARDOWN request SHALL contain a Session header indicating what 2737 session the request applies to. 2739 A TEARDOWN using the aggregated control URI or the media URI in a 2740 session under non-aggregated control (single media session) MAY be 2741 done in any state (Ready, and Play). A successful request SHALL 2742 result in that media delivery is immediately halted and the session 2743 state is destroyed. This SHALL be indicated through the lack of a 2744 Session header in the response. 2746 A TEARDOWN using a media URI in an aggregated session MAY only be 2747 done in Ready state. Such a request only removes the indicated media 2748 stream and associated resources from the session. This may result in 2749 that a session returns to non-aggregated control, due to that it only 2750 contains a single media after the requests completion. A session 2751 that will exist after the processing of the TEARDOWN request SHALL in 2752 the response to that TEARDOWN request contain a Session header. Thus 2753 the presence of the Session header indicates to the receiver of the 2754 response if the session is still existing or has been removed. 2756 Example: 2758 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0 2759 CSeq: 892 2760 Session: 12345678 2762 S->C: RTSP/2.0 200 OK 2763 CSeq: 892 2764 Server: PhonyServer 1.0 2766 11.7. GETPARAMETER 2768 The GETPARAMETER request retrieves the value of a parameter or 2769 parameters for a presentation or stream specified in the URI. If the 2770 Session header is present in a request, the value of a parameter MUST 2771 be retrieved in the specified session context. The content of the 2772 reply and response is left to the implementation. 2774 The method MAY also be used without a body (entity). If the this 2775 request is successful, i.e. a 200 OK response is received, then the 2776 keep-alive timer has been updated. Any non-required header present 2777 in such a request may or may not been processed. To allow a client 2778 to determine if any such header has been processed, it is necessary 2779 to use a feature-tag and the Require header. Due to this reason it 2780 is RECOMMENDED that any parameters to be retrieved are sent in the 2781 body, rather than using any header. 2783 Example: 2785 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 2786 CSeq: 431 2787 Content-Type: text/parameters 2788 Session: 12345678 2789 Content-Length: 26 2791 packets_received 2792 jitter 2794 C->S: RTSP/2.0 200 OK 2795 CSeq: 431 2796 Content-Length: 38 2797 Content-Type: text/parameters 2799 packets_received: 10 2800 jitter: 0.3838 2802 The "text/parameters" section is only an example type for a body 2803 carrying parameters. 2805 11.8. SET_PARAMETER 2807 This method requests to set the value of a parameter or a set of 2808 parameters for a presentation or stream specified by the URI. The 2809 method MAY also be used without a body (entity). It is the 2810 RECOMMENDED method to use in request sent for the sole purpose of 2811 updating the keep-alive timer. If this request is successful, i.e. a 2812 200 OK response is received, then the keep-alive timer has been 2813 updated. Any non-required header present in such a request may or 2814 may not been processed. To allow a client to determine if any such 2815 header has been processed, it is necessary to use a feature tag and 2816 the Require header. Due to this reason it is RECOMMENDED that any 2817 parameters are sent in the body, rather than using any header. 2819 A request is RECOMMENDED to only contain a single parameter to allow 2820 the client to determine why a particular request failed. If the 2821 request contains several parameters, the server MUST only act on the 2822 request if all of the parameters can be set successfully. A server 2823 MUST allow a parameter to be set repeatedly to the same value, but it 2824 MAY disallow changing parameter values. If the receiver of the 2825 request does not understand or cannot locate a parameter, error 451 2826 (Parameter Not Understood) SHALL be used. In the case a parameter is 2827 not allowed to change, the error code is 458 (Parameter Is Read- 2828 Only). The response body SHOULD contain only the parameters that 2829 have errors. Otherwise no body SHALL be returned. 2831 Note: transport parameters for the media stream MUST only be set with 2832 the SETUP command. 2834 Restricting setting transport parameters to SETUP is for the 2835 benefit of firewalls. 2837 The parameters are split in a fine-grained fashion so that there 2838 can be more meaningful error indications. However, it may make 2839 sense to allow the setting of several parameters if an atomic 2840 setting is desirable. Imagine device control where the client 2841 does not want the camera to pan unless it can also tilt to the 2842 right angle at the same time. 2844 Example: 2846 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 2847 CSeq: 421 2848 Content-length: 20 2849 Content-type: text/parameters 2851 barparam: barstuff 2853 S->C: RTSP/2.0 451 Parameter Not Understood 2854 CSeq: 421 2855 Content-length: 10 2856 Content-type: text/parameters 2858 barparam: barstuff 2860 The "text/parameters" section is only an example type for 2861 parameters. This method is intentionally loosely defined with the 2862 intention that the reply content and response content will be 2863 defined by the one desiring to use this mechanism. 2865 11.9. REDIRECT 2867 The REDIRECT method is issued by a server to inform a client that it 2868 required to connect to another server location to access the resource 2869 indicated by the Request-URI. The presence of the Session header in 2870 a REDIRECT request indicates the scope of the request, and determines 2871 the specific semantics of the request. 2873 A REDIRECT request with a Session header has end-to-end (i.e. server 2874 to client) scope and applies only to the given session. Any 2875 intervening proxies SHOULDNOT disconnect the control channel while 2876 there are other remaining end-to-end sessions. The OPTIONAL Location 2877 header, if included in such a request, SHALL contain a complete 2878 absolute URI pointing to the resource to which the client SHOULD 2879 reconnect. Specifically, the Location SHALL NOT contain just the 2880 host and port. A client may receive a REDIRECT request with a 2881 Session header, if and only if, an end-to-end session has been 2882 established. 2884 A client may receive a REDIRECT request without a Session header at 2885 any time when it has communication or a connection established with a 2886 server. The scope of such a request is limited to the next-hop (i.e. 2887 the RTSP agent in direct communication with the server) and applies, 2888 as well, to the control connection between the next-hop RTSP agent 2889 and the server. A REDIRECT request without a Session header 2890 indicates that all sessions and pending requests being managed via 2891 the control connection MUST be redirected. The OPTIONAL Location 2892 header, if included in such a request, SHOULD contain an absolute URI 2893 with only the host address and the OPTIONAL port number of the server 2894 to which the RTSP agent SHOULD reconnect. Any intervening proxies 2895 SHOULD do all of the following in the order listed: 2897 1. respond to the REDIRECT request 2899 2. disconnect the control channel from the requesting server 2901 3. connect to the server at the given host address 2903 4. pass the REDIRECT request to each applicable client (typically 2904 those clients with an active session or an unanswered request) 2906 Note: The proxy is responsible for accepting REDIRECT responses 2907 from its clients; these responses MUST NOT be passed on to either 2908 the original server or the redirected server. 2910 The lack of a Location header in any REDIRECT request is indicative 2911 of the server no longer being able to fulfill the current request and 2912 having no alternatives for the client to continue with its normal 2913 operation. It is akin to a server initiated TEARDOWN that applies 2914 both to sessions as well as the general connection associated with 2915 that client. 2917 When the Range header is not included in a REDIRECT request, the 2918 client SHOULD perform the redirection immediately and return a 2919 response to the server. The server can consider the session as 2920 terminated and can free any associated state after it receives the 2921 successful (2xx) response. The server MAY close the signalling 2922 connection upon receiving the response and the client SHOULD close 2923 the signalling connection after sending the 2xx response. The 2924 exception to this is when the client has several sessions on the 2925 server being managed by the given signalling connection. In this 2926 case, the client SHOULD close the connection when it has received and 2927 responded to REDIRECT requests for all the sessions managed by the 2928 signalling connection. 2930 If the OPTIONAL Range header is included in a REDIRECT request, it 2931 indicates when the redirection takes effect. The range value MUST be 2932 an open ended single value, e.g. npt=59-, indicating the play out 2933 time when redirection SHALL occur. Alternatively, a range with a 2934 time= parameter indicates the wall clock time by when the redirection 2935 MUST take place. When the time= parameter is present in the range, 2936 any range value MUST be ignored even though it MUST be syntactically 2937 correct. To allow a client to determine that redirect time without 2938 being time synchronized with the server, the server SHALL include a 2939 Date header in the request. When the indicated redirect point is 2940 reached, a client MUST issue a TEARDOWN request and SHOULD close the 2941 signalling connection after receiving a 2xx response. The normal 2942 connection considerations apply for the server. 2944 The differentiation of REDIRECT requests with and without range 2945 headers is to allow for clear and explicit state handling. As the 2946 state in the server needs to be kept until the point of 2947 redirection, the handling becomes more clear if the client is 2948 required to TEARDOWN the session at the redirect point. 2950 If the REDIRECT request times out following the rules in Section 9.4 2951 the server MAY terminate the session or transport connection that 2952 would be redirected by the request. This is a safeguard against 2953 misbehaving clients that refuses to respond to a REDIRECT request. 2954 That should not provide any benefit. 2956 After a REDIRECT request has been processed, a client that wants to 2957 continue to send or receive media for the resource identified by the 2958 Request-URI will have to establish a new session with the designated 2959 host. If the URI given in the Location header is a valid resource 2960 URI, a client SHOULD issue a DESCRIBE request for the URI. 2962 Note: The media resource indicated by the \header {Location header 2963 can be identical, slightly different or totally different. This 2964 is the reason why a new DESCRIBE request SHOULD be issued. 2966 If the Location header contains only a host address, the client MAY 2967 assume that the media on the new server is identical to the media on 2968 the old server, i.e. all media configuration information from the old 2969 session is still valid except for the host address. However the 2970 usage of conditional SETUP using ETag identifiers are RECOMMENDED to 2971 verify the assumption. 2973 This example request redirects traffic for this session to the new 2974 server at the given absolute time: 2976 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0 2977 CSeq: 732 2978 Location: rtsp://s2.example.com:8001 2979 Range: npt=0- ;time=19960213T143205Z 2980 Session: uZ3ci0K+Ld-M 2982 C->S: RTSP/2.0 200 OK 2983 CSeq: 732 2985 12. Embedded (Interleaved) Binary Data 2987 In order to fulfill certain requirements on the network side, e.g. in 2988 conjunction with network address translators that block RTP traffic 2989 over UDP, it may be necessary to interleave RTSP messages and media 2990 stream data. This interleaving should generally be avoided unless 2991 necessary since it complicates client and server operation and 2992 imposes additional overhead. Also head of line blocking may cause 2993 problems. Interleaved binary data SHOULD only be used if RTSP is 2994 carried over TCP. 2996 Stream data such as RTP packets is encapsulated by an ASCII dollar 2997 sign (24 decimal), followed by a one-byte channel identifier, 2998 followed by the length of the encapsulated binary data as a binary, 2999 two-byte integer in network byte order. The stream data follows 3000 immediately afterwards, without a CRLF, but including the upper-layer 3001 protocol headers. Each $ block SHALL contain exactly one upper-layer 3002 protocol data unit, e.g., one RTP packet. 3004 0 1 2 3 3005 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 3006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3007 | "$" = 24 | Channel ID | Length in bytes | 3008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3009 : Length number of bytes of binary data : 3010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3012 The channel identifier is defined in the Transport header with the 3013 interleaved parameter (Section 14.45). 3015 When the transport choice is RTP, RTCP messages are also interleaved 3016 by the server over the TCP connection. The usage of RTCP messages is 3017 indicated by including a range containing a second channel in the 3018 interleaved parameter of the Transport header, see Section 14.45. If 3019 RTCP is used, packets SHALL be sent on the first available channel 3020 higher than the RTP channel. The channels are bi-directional and 3021 therefore RTCP traffic are sent on the second channel in both 3022 directions. 3024 RTCP is sometime needed for synchronization when two or more 3025 streams are interleaved in such a fashion. Also, this provides a 3026 convenient way to tunnel RTP/RTCP packets through the TCP control 3027 connection when required by the network configuration and transfer 3028 them onto UDP when possible. 3030 C->S: SETUP rtsp://example.com/bar.file RTSP/2.0 3031 CSeq: 2 3032 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 3034 S->C: RTSP/2.0 200 OK 3035 CSeq: 2 3036 Date: 05 Jun 1997 18:57:18 GMT 3037 Transport: RTP/AVP/TCP;unicast;interleaved=5-6 3038 Session: 12345678 3040 C->S: PLAY rtsp://example.com/bar.file RTSP/2.0 3041 CSeq: 3 3042 Session: 12345678 3044 S->C: RTSP/2.0 200 OK 3045 CSeq: 3 3046 Session: 12345678 3047 Date: 05 Jun 1997 18:59:15 GMT 3048 RTP-Info: url="rtsp://example.com/bar.file" 3049 ssrc=0D12F123:seq=232433;rtptime=972948234 3051 S->C: $005{2 byte length}{"length" bytes data, w/RTP header} 3052 S->C: $005{2 byte length}{"length" bytes data, w/RTP header} 3053 S->C: $006{2 byte length}{"length" bytes RTCP packet} 3055 13. Status Code Definitions 3057 Where applicable, HTTP status [H10] codes are reused. Status codes 3058 that have the same meaning are not repeated here. See Table 4 for a 3059 listing of which status codes may be returned by which requests. All 3060 error messages, 4xx and 5xx MAY return a body containing further 3061 information about the error. 3063 13.1. Success 1xx 3065 13.1.1. 100 Continue 3067 See, [H10.1.1]. 3069 13.2. Success 2xx 3071 13.3. Redirection 3xx 3073 The notation "3rr" indicates response codes from 300 to 399 inclusive 3074 which are meant for redirection. The response code 304 is excluded 3075 from this set, as it is not used for redirection. 3077 See [H10.3] for definition of status code 300 to 305. However 3078 comments are given for some to how they apply to RTSP. 3080 Within RTSP, redirection may be used for load balancing or 3081 redirecting stream requests to a server topologically closer to the 3082 client. Mechanisms to determine topological proximity are beyond the 3083 scope of this specification. 3085 A 3rr code MAY be used to respond to any request. It is RECOMMENDED 3086 that they are used if necessary before a session is established, i.e. 3087 in response to DESCRIBE or SETUP. However in cases where a server is 3088 not able to send a REDIRECT request to the client, the server MAY 3089 need to resort to using 3rr responses to inform a client with a 3090 established session about the need for redirecting the session. If 3091 an 3rr response is received for an request in relation to a 3092 established session, the client SHOULD send a TEARDOWN request for 3093 the session, and MAY reestablish the session using the resource 3094 indicated by the Location. 3096 If the the Location header is used in a response it SHALL contain an 3097 absolute URI pointing out the media resource the client is redirected 3098 to, the URI SHALL NOT only contain the host name. 3100 13.3.1. 300 Multiple Choices 3102 See [H10.3.1]. 3104 13.3.2. 301 Moved Permanently 3106 The request resource are moved permanently and resides now at the URI 3107 given by the location header. The user client SHOULD redirect 3108 automatically to the given URI. This response MUST NOT contain a 3109 message-body. The Location header MUST be included in the response. 3111 13.3.3. 302 Found 3113 The requested resource resides temporarily at the URI given by the 3114 Location header. The Location header MUST be included in the 3115 response. This response is intended to be used for many types of 3116 temporary redirects; e.g., load balancing. It is RECOMMENDED that 3117 the server set the reason phrase to something more meaningful than 3118 "Found" in these cases. The user client SHOULD redirect 3119 automatically to the given URI. This response MUST NOT contain a 3120 message-body. 3122 This example shows a client being redirected to a different server: 3124 C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0 3125 CSeq: 2 3126 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 3128 C->S: RTSP/2.0 302 Try Other Server 3129 CSeq: 2 3130 Location: rtsp://s2.example.com:8001/fizzle/foo 3132 13.3.4. 303 See Other 3134 This status code SHALL NOT be used in RTSP. However as it was 3135 allowed to use in RTSP 1.0 (RFC 2326). 3137 13.3.5. 304 Not Modified 3139 If the client has performed a conditional DESCRIBE or SETUP (see 3140 Section 14.25) and the requested resource has not been modified, the 3141 server SHOULD send a 304 response. This response MUST NOT contain a 3142 message-body. 3144 The response MUST include the following header fields: 3146 o Date 3147 o ETag and/or Content-Location, if the header(s) would have been 3148 sent in a 200 response to the same request. 3150 o Expires, Cache-Control, and/or Vary, if the field-value might 3151 differ from that sent in any previous response for the same 3152 variant. 3154 This response is independent for the DESCRIBE and SETUP requests. 3155 That is, a 304 response to DESCRIBE does NOT imply that the resource 3156 content is unchanged (only the session description) and a 304 3157 response to SETUP does NOT imply that the resource description is 3158 unchanged. The ETag and If-Match headers may be used to link the 3159 DESCRIBE and SETUP in this manner. 3161 13.3.6. 305 Use Proxy 3163 See [H10.3.6]. 3165 13.4. Client Error 4xx 3167 13.4.1. 400 Bad Request 3169 The request could not be understood by the server due to malformed 3170 syntax. The client SHOULDNOT repeat the request without 3171 modifications [H10.4.1]. If the request does not have a CSeq header, 3172 the server MUST NOT include a CSeq in the response. 3174 13.4.2. 405 Method Not Allowed 3176 The method specified in the request is not allowed for the resource 3177 identified by the Request-URI. The response MUST include an Allow 3178 header containing a list of valid methods for the requested resource. 3179 This status code is also to be used if a request attempts to use a 3180 method not indicated during SETUP, e.g., if a RECORD request is 3181 issued even though the mode parameter in the Transport header only 3182 specified PLAY. 3184 13.4.3. 451 Parameter Not Understood 3186 The recipient of the request does not support one or more parameters 3187 contained in the request. When returning this error message the 3188 sender SHOULD return a entity body containing the offending 3189 parameter(s). 3191 13.4.4. 452 reserved 3193 This error code was removed from RFC 2326 [RFC2326] and is obsolete. 3195 13.4.5. 453 Not Enough Bandwidth 3197 The request was refused because there was insufficient bandwidth. 3198 This may, for example, be the result of a resource reservation 3199 failure. 3201 13.4.6. 454 Session Not Found 3203 The RTSP session identifier in the Session header is missing, 3204 invalid, or has timed out. 3206 13.4.7. 455 Method Not Valid in This State 3208 The client or server cannot process this request in its current 3209 state. The response SHALL contain an Allow header to make error 3210 recovery possible. 3212 13.4.8. 456 Header Field Not Valid for Resource 3214 The server could not act on a required request header. For example, 3215 if PLAY contains the Range header field but the stream does not allow 3216 seeking. This error message may also be used for specifying when the 3217 time format in Range is impossible for the resource. In that case 3218 the Accept-Ranges header SHALL be returned to inform the client of 3219 which format(s) that are allowed. 3221 13.4.9. 457 Invalid Range 3223 The Range value given is out of bounds, e.g., beyond the end of the 3224 presentation. 3226 13.4.10. 458 Parameter Is Read-Only 3228 The parameter to be set by SET_PARAMETER can be read but not 3229 modified. When returning this error message the sender SHOULD return 3230 a entity body containing the offending parameter(s). 3232 13.4.11. 459 Aggregate Operation Not Allowed 3234 The requested method may not be applied on the URI in question since 3235 it is an aggregate (presentation) URI. The method may be applied on 3236 a media URI. 3238 13.4.12. 460 Only Aggregate Operation Allowed 3240 The requested method may not be applied on the URI in question since 3241 it is not an aggregate control (presentation) URI. The method may be 3242 applied on the aggregate control URI. 3244 13.4.13. 461 Unsupported Transport 3246 The Transport field did not contain a supported transport 3247 specification. 3249 13.4.14. 462 Destination Unreachable 3251 The data transmission channel could not be established because the 3252 client address could not be reached. This error will most likely be 3253 the result of a client attempt to place an invalid dest_addr 3254 parameter in the Transport field. 3256 13.4.15. 463 Destination Prohibited 3258 The data transmission channel was not established because the server 3259 prohibited access to the client address. This error is most likely 3260 the result of a client attempt to redirect media traffic to another 3261 destination with a dest_addr parameter in the Transport header. 3263 13.4.16. 464 Data Transport Not Ready Yet 3265 The data transmission channel to the media destination is not yet 3266 ready for carrying data. However the responding entity still expects 3267 that the data transmission channel will be established at this point 3268 in time. Note however that this may result in a permanent failure 3269 like 462 "Destination Unreachable". 3271 An example when this error may occur is in the case a client sends a 3272 PLAY request to a server prior to ensuring that the TCP connections 3273 negotiated for carrying media data was successful established (In 3274 violation of this specification). The server would use this error 3275 code to indicate that the requested action could not be performed due 3276 to the failure of completing the connection establishment. 3278 13.4.17. 470 Connection Authorization Required 3280 The secured connection attempt need user or client authorization 3281 before proceeding. The next hops certificate is included in this 3282 response in the Accept-Credentials header. 3284 13.4.18. 471 Connection Credentials not accepted 3286 When performing a secure connection over multiple connections, a 3287 intermediary has refused to connect to the next hop and carry out the 3288 request due to unacceptable credentials for the used policy. 3290 13.5. Server Error 5xx 3292 13.5.1. 551 Option not supported 3294 A feature-tag given in the Require or the Proxy-Require fields was 3295 not supported. The Unsupported header SHALL be returned stating the 3296 feature for which there is no support. 3298 14. Header Field Definitions 3300 +--------------+----------------+--------+---------+------+ 3301 | method | direction | object | acronym | Body | 3302 +--------------+----------------+--------+---------+------+ 3303 | DESCRIBE | C -> S | P,S | DES | r | 3304 | | | | | | 3305 | GETPARAMETER | C -> S, S -> C | P,S | GPR | R,r | 3306 | | | | | | 3307 | OPTIONS | C -> S | P,S | OPT | | 3308 | | | | | | 3309 | | S -> C | | | | 3310 | | | | | | 3311 | PAUSE | C -> S | P,S | PSE | | 3312 | | | | | | 3313 | PLAY | C -> S | P,S | PLY | | 3314 | | | | | | 3315 | REDIRECT | S -> C | P,S | RDR | | 3316 | | | | | | 3317 | SETUP | C -> S | S | STP | | 3318 | | | | | | 3319 | SETPARAMETER | C -> S, S -> C | P,S | SPR | R,r | 3320 | | | | | | 3321 | TEARDOWN | C -> S | P,S | TRD | | 3322 +--------------+----------------+--------+---------+------+ 3324 Table 8: Overview of RTSP methods, their direction, and what objects 3325 (P: presentation, S: stream) they operate on. Body notes if a method 3326 is allowed to carry body and in which direction, R = Request, 3327 r=response. Note: It is allowed for all error messages 4xx and 5xx to 3328 have a body 3330 The general syntax for header fields is covered in Section 3331 Section 4.2 This section lists the full set of header fields along 3332 with notes on meaning, and usage. The syntax definition for header 3333 fields are present in section Section 19.2.3. Throughout this 3334 section, we use [HX.Y] to refer to Section X.Y of the current 3335 HTTP/1.1 specification RFC 2616 [RFC2616]. Examples of each header 3336 field are given. 3338 Information about header fields in relation to methods and proxy 3339 processing is summarized in Table 9, Table 10, Table 11, and 3340 Table 12. 3342 The "where" column describes the request and response types in which 3343 the header field can be used. Values in this column are: 3345 R: header field may only appear in requests; 3347 r: header field may only appear in responses; 3349 2xx, 4xx, etc.: A numerical value or range indicates response codes 3350 with which the header field can be used; 3352 c: header field is copied from the request to the response. 3354 An empty entry in the "where" column indicates that the header field 3355 may be present in both requests and responses. 3357 The "proxy" column describes the operations a proxy may perform on a 3358 header field. An empty proxy column indicates that the proxy SHALL 3359 NOT do any changes to that header, all allowed operations are 3360 explicitly stated: 3362 a: A proxy can add or concatenate the header field if not present. 3364 m: A proxy can modify an existing header field value. 3366 d: A proxy can delete a header field value. 3368 r: A proxy needs to be able to read the header field, and thus 3369 this header field cannot be encrypted. 3371 The rest of the columns relate to the presence of a header field in a 3372 method. The method names when abbreviated, are according to table 3373 XXX {tab:methods2: 3375 c: Conditional; requirements on the header field depend on the 3376 context of the message. 3378 m: The header field is mandatory. 3380 m*: The header field SHOULD be sent, but clients/servers need to be 3381 prepared to receive messages without that header field. 3383 o: The header field is optional. 3385 *: The header field is SHALL be present if the message body is not 3386 empty. See Section 14.16, Section 14.18 and Section 4.3 for 3387 details. 3389 -: The header field is not applicable. 3391 "Optional" means that a Client/Server MAY include the header field in 3392 a request or response. The Client/Server behavior when receiving 3393 such headers varies, for some it may ignore the header field, in 3394 other case it is request to process the header. This is regulated by 3395 the method and header descriptions. Example of such headers that 3396 require processing are the Require and Proxy-Require header fields 3397 discussed in Section 14.37 and Section 14.31. A "mandatory" header 3398 field MUST be present in a request, and MUST be understood by the 3399 Client/Server receiving the request. A mandatory response header 3400 field MUST be present in the response, and the header field MUST be 3401 understood by the Client/Server processing the response. "Not 3402 applicable" means that the header field MUST NOT be present in a 3403 request. If one is placed in a request by mistake, it MUST be 3404 ignored by the Client/Server receiving the request. Similarly, a 3405 header field labeled "not applicable" for a response means that the 3406 Client/Server MUST NOT place the header field in the response, and 3407 the Client/Server MUST ignore the header field in the response. 3409 An RTSP agent SHALL ignore extension headers that are not understood. 3411 The From and Location header fields contain an URI. If the URI 3412 contains a comma, or semicolon, the URI MUST be enclosed in double 3413 quotas ("). Any URI parameters are contained within these quotas. 3414 If the URI is not enclosed in double quotas, any semicolon- delimited 3415 parameters are header-parameters, not URI parameters. 3417 +----------------+------+-----+-----+-----+------+-----+------+-----+ 3418 | Header | Wher | Pro | DES | OPT | SETU | PLA | PAUS | TRD | 3419 | | e | xy | | | P | Y | E | | 3420 +----------------+------+-----+-----+-----+------+-----+------+-----+ 3421 | Accept | R | | o | - | - | - | - | - | 3422 | | | | | | | | | | 3423 | Accept-Credent | R | r | o | o | o | o | o | o | 3424 | ials | | | | | | | | | 3425 | | | | | | | | | | 3426 | Accept-Encodin | R | r | o | - | - | - | - | - | 3427 | g | | | | | | | | | 3428 | | | | | | | | | | 3429 | Accept-Languag | R | r | o | - | - | - | - | - | 3430 | e | | | | | | | | | 3431 | | | | | | | | | | 3432 | Accept-Ranges | R | r | - | - | m | - | - | - | 3433 | | | | | | | | | | 3434 | Accept-Ranges | r | r | - | - | o | - | - | - | 3435 | | | | | | | | | | 3436 | Accept-Ranges | 456 | r | - | - | - | o | - | - | 3437 | | | | | | | | | | 3438 | Allow | r | am | c | c | c | - | - | - | 3439 | | | | | | | | | | 3440 | Allow | 405 | am | m | m | m | m | m | m | 3441 | Authorization | R | | o | o | o | o | o | o | 3442 | | | | | | | | | | 3443 | Bandwidth | R | | o | o | o | o | - | - | 3444 | | | | | | | | | | 3445 | Blocksize | R | | o | - | o | o | - | - | 3446 | | | | | | | | | | 3447 | Cache-Control | | r | o | - | o | - | - | - | 3448 | | | | | | | | | | 3449 | Connection | | | o | o | o | o | o | o | 3450 | | | | | | | | | | 3451 | Connection-Cre | 470, | ar | o | o | o | o | o | o | 3452 | dentials | 407 | | | | | | | | 3453 | | | | | | | | | | 3454 | Content-Base | r | | o | - | - | - | - | - | 3455 | | | | | | | | | | 3456 | Content-Base | 4xx, | | o | o | o | o | o | o | 3457 | | 5xx | | | | | | | | 3458 | | | | | | | | | | 3459 | Content-Encodi | R | r | - | - | - | - | - | - | 3460 | ng | | | | | | | | | 3461 | | | | | | | | | | 3462 | Content-Encodi | r | r | o | - | - | - | - | - | 3463 | ng | | | | | | | | | 3464 | | | | | | | | | | 3465 | Content-Encodi | 4xx, | r | o | o | o | o | o | o | 3466 | ng | 5xx | | | | | | | | 3467 | | | | | | | | | | 3468 | Content-Langua | R | r | - | - | - | - | - | - | 3469 | ge | | | | | | | | | 3470 | | | | | | | | | | 3471 | Content-Langua | r | r | o | - | - | - | - | - | 3472 | ge | | | | | | | | | 3473 | | | | | | | | | | 3474 | Content-Langua | 4xx, | r | o | o | o | o | o | o | 3475 | ge | 5xx | | | | | | | | 3476 | | | | | | | | | | 3477 | Content-Length | r | r | * | - | - | - | - | - | 3478 | | | | | | | | | | 3479 | Content-Length | 4xx, | r | * | * | * | * | * | * | 3480 | | 5xx | | | | | | | | 3481 | | | | | | | | | | 3482 | Content-Locati | r | | o | - | - | - | - | - | 3483 | on | | | | | | | | | 3484 | | | | | | | | | | 3485 | Content-Locati | 4xx, | | o | o | o | o | o | o | 3486 | on | 5xx | | | | | | | | 3487 | | | | | | | | | | 3488 | Content-Type | r | | * | - | - | - | - | - | 3489 | Content-Type | 4xx, | | * | * | * | * | * | * | 3490 | | 5xx | | | | | | | | 3491 | | | | | | | | | | 3492 | CSeq | Rc | rm | m | m | m | m | m | m | 3493 | | | | | | | | | | 3494 | Date | | am | o | o | o | o | o | o | 3495 | | | | | | | | | | 3496 | ETag | r | r | o | - | o | - | - | - | 3497 | | | | | | | | | | 3498 | Expires | r | r | o | - | - | - | - | - | 3499 | | | | | | | | | | 3500 | From | R | r | o | o | o | o | o | o | 3501 | | | | | | | | | | 3502 | If-Match | R | r | - | - | o | - | - | - | 3503 | | | | | | | | | | 3504 | If-Modified-Si | R | r | o | - | o | - | - | - | 3505 | nce | | | | | | | | | 3506 | | | | | | | | | | 3507 | If-None-Match | R | r | o | - | - | - | - | - | 3508 | | | | | | | | | | 3509 | Last-Modified | r | r | o | - | - | - | - | - | 3510 | | | | | | | | | | 3511 | Location | 3rr | | o | o | o | o | o | o | 3512 +----------------+------+-----+-----+-----+------+-----+------+-----+ 3514 Table 9: Overview of RTSP header fields (A-L) related to methods 3515 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 3517 +------------+-------+------+----+-----+-------+------+-------+-----+ 3518 | Header | Where | Prox | DE | OPT | SETUP | PLAY | PAUSE | TRD | 3519 | | | y | S | | | | | | 3520 +------------+-------+------+----+-----+-------+------+-------+-----+ 3521 | Proxy- | 407 | amr | m | m | m | m | m | m | 3522 | Authentica | | | | | | | | | 3523 | te | | | | | | | | | 3524 | | | | | | | | | | 3525 | Proxy- | R | rd | o | o | o | o | o | o | 3526 | Authorizat | | | | | | | | | 3527 | ion | | | | | | | | | 3528 | | | | | | | | | | 3529 | Proxy- | R | ar | o | o | o | o | o | o | 3530 | Require | | | | | | | | | 3531 | | | | | | | | | | 3532 | Proxy- | r | r | c | c | c | c | c | c | 3533 | Require | | | | | | | | | 3534 | | | | | | | | | | 3535 | Proxy- | R | amr | c | c | c | c | c | c | 3536 | Supported | | | | | | | | | 3537 | Proxy- | r | | c | c | c | c | c | c | 3538 | Supported | | | | | | | | | 3539 | | | | | | | | | | 3540 | Public | r | admr | - | m | - | - | - | - | 3541 | | | | | | | | | | 3542 | Public | 501 | admr | m | m | m | m | m | m | 3543 | | | | | | | | | | 3544 | Range | R | | - | - | - | o | - | - | 3545 | | | | | | | | | | 3546 | Range | r | | - | - | c | m | m | - | 3547 | | | | | | | | | | 3548 | Referer | R | | o | o | o | o | o | o | 3549 | | | | | | | | | | 3550 | Require | R | | o | o | o | o | o | o | 3551 | | | | | | | | | | 3552 | Retry-Afte | 3rr,5 | | o | o | o | - | - | - | 3553 | r | 03 | | | | | | | | 3554 | | | | | | | | | | 3555 | RTP-Info | r | | - | - | o | c | - | - | 3556 | | | | | | | | | | 3557 | Scale | | | - | - | - | o | - | - | 3558 | | | | | | | | | | 3559 | Session | R | r | - | o | o | m | m | m | 3560 | | | | | | | | | | 3561 | Session | r | r | - | c | m | m | m | o | 3562 | | | | | | | | | | 3563 | Server | R | r | - | o | - | - | - | - | 3564 | | | | | | | | | | 3565 | Server | r | r | o | o | o | o | o | o | 3566 | | | | | | | | | | 3567 | Speed | | | - | - | - | o | - | - | 3568 | | | | | | | | | | 3569 | Supported | R | amr | o | o | o | o | o | o | 3570 | | | | | | | | | | 3571 | Supported | r | amr | c | c | c | c | c | c | 3572 | | | | | | | | | | 3573 | Timestamp | R | admr | o | o | o | o | o | o | 3574 | | | | | | | | | | 3575 | Timestamp | c | admr | m | m | m | m | m | m | 3576 | | | | | | | | | | 3577 | Transport | | amr | - | - | m | - | - | - | 3578 | | | | | | | | | | 3579 | Unsupporte | r | | c | c | c | c | c | c | 3580 | d | | | | | | | | | 3581 | | | | | | | | | | 3582 | User-Agent | R | | m* | m* | m* | m* | m* | m* | 3583 | | | | | | | | | | 3584 | Vary | r | | c | c | c | c | c | c | 3585 | Via | R | amr | o | o | o | o | o | o | 3586 | | | | | | | | | | 3587 | Via | c | dr | m | m | m | m | m | m | 3588 | | | | | | | | | | 3589 | WWW- | 401 | | m | m | m | m | m | m | 3590 | Authentica | | | | | | | | | 3591 | te | | | | | | | | | 3592 +------------+-------+------+----+-----+-------+------+-------+-----+ 3594 Table 10: Overview of RTSP header fields (P-W) related to methods 3595 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 3597 +------------------------+---------+-------+-----+-----+-----+ 3598 | Header | Where | Proxy | GPR | SPR | RDR | 3599 +------------------------+---------+-------+-----+-----+-----+ 3600 | Accept-Credentials | R | r | o | o | o | 3601 | | | | | | | 3602 | Allow | 405 | amr | m | m | m | 3603 | | | | | | | 3604 | Authorization | R | | o | o | o | 3605 | | | | | | | 3606 | Bandwidth | R | | - | o | - | 3607 | | | | | | | 3608 | Blocksize | R | | - | o | - | 3609 | | | | | | | 3610 | Connection | | | o | o | o | 3611 | | | | | | | 3612 | Connection-Credentials | 470,407 | ar | o | o | o | 3613 | | | | | | | 3614 | Content-Base | R | | o | o | - | 3615 | | | | | | | 3616 | Content-Base | r | | o | o | - | 3617 | | | | | | | 3618 | Content-Base | 4xx,5xx | | o | o | o | 3619 | | | | | | | 3620 | Content-Encoding | R | r | o | o | - | 3621 | | | | | | | 3622 | Content-Encoding | r | r | o | o | - | 3623 | | | | | | | 3624 | Content-Encoding | 4xx,5xx | r | o | o | o | 3625 | | | | | | | 3626 | Content-Language | R | r | o | o | - | 3627 | | | | | | | 3628 | Content-Language | r | r | o | o | - | 3629 | | | | | | | 3630 | Content-Language | 4xx,5xx | r | o | o | o | 3631 | | | | | | | 3632 | Content-Length | R | r | * | * | - | 3633 | Content-Length | r | r | * | * | - | 3634 | | | | | | | 3635 | Content-Length | 4xx,5xx | r | * | * | * | 3636 | | | | | | | 3637 | Content-Location | R | | o | o | - | 3638 | | | | | | | 3639 | Content-Location | r | | o | o | - | 3640 | | | | | | | 3641 | Content-Location | 4xx,5xx | | o | o | o | 3642 | | | | | | | 3643 | Content-Type | R | | * | * | - | 3644 | | | | | | | 3645 | Content-Type | r | | * | * | - | 3646 | | | | | | | 3647 | Content-Type | 4xx | | * | * | * | 3648 | | | | | | | 3649 | CSeq | R,c | mr | m | m | m | 3650 | | | | | | | 3651 | Date | R | a | o | o | m | 3652 | | | | | | | 3653 | Date | r | am | o | o | o | 3654 | | | | | | | 3655 | From | R | r | o | o | o | 3656 | | | | | | | 3657 | Last-Modified | R | r | - | - | - | 3658 | | | | | | | 3659 | Last-Modified | r | r | o | - | - | 3660 | | | | | | | 3661 | Location | 3rr | | o | o | o | 3662 | | | | | | | 3663 | Location | R | | - | - | m | 3664 | | | | | | | 3665 | Proxy-Authenticate | 407 | amr | m | m | m | 3666 | | | | | | | 3667 | Proxy-Authorization | R | rd | o | o | o | 3668 | | | | | | | 3669 | Proxy-Require | R | ar | o | o | o | 3670 | | | | | | | 3671 | Proxy-Require | r | r | c | c | c | 3672 | | | | | | | 3673 | Proxy-Supported | R | amr | c | c | c | 3674 | | | | | | | 3675 | Proxy-Supported | r | | c | c | c | 3676 | | | | | | | 3677 | Public | 501 | admr | m | m | m | 3678 +------------------------+---------+-------+-----+-----+-----+ 3680 Table 11: Overview of RTSP header fields (A-P) related to methods 3681 GETPARAMETER, SETPARAMETER, and REDIRECT. 3683 +------------------+---------+-------+-----+-----+-----+ 3684 | Header | Where | Proxy | GPR | SPR | RDR | 3685 +------------------+---------+-------+-----+-----+-----+ 3686 | Range | R | | - | - | o | 3687 | | | | | | | 3688 | Referer | R | | o | o | o | 3689 | | | | | | | 3690 | Require | R | r | o | o | o | 3691 | | | | | | | 3692 | Retry-After | 3rr,503 | | o | o | - | 3693 | | | | | | | 3694 | Scale | | | - | - | - | 3695 | | | | | | | 3696 | Session | R | r | o | o | o | 3697 | | | | | | | 3698 | Session | r | r | c | c | o | 3699 | | | | | | | 3700 | Server | R | r | o | o | o | 3701 | | | | | | | 3702 | Server | r | r | o | o | - | 3703 | | | | | | | 3704 | Supported | R | adrm | o | o | o | 3705 | | | | | | | 3706 | Supported | r | adrm | c | c | c | 3707 | | | | | | | 3708 | Timestamp | R | adrm | o | o | o | 3709 | | | | | | | 3710 | Timestamp | c | adrm | m | m | m | 3711 | | | | | | | 3712 | Unsupported | r | arm | c | c | c | 3713 | | | | | | | 3714 | User-Agent | R | r | m* | m* | - | 3715 | | | | | | | 3716 | User-Agent | r | r | - | - | m* | 3717 | | | | | | | 3718 | Vary | r | | c | c | - | 3719 | | | | | | | 3720 | Via | R | amr | o | o | o | 3721 | | | | | | | 3722 | Via | c | dr | m | m | m | 3723 | | | | | | | 3724 | WWW-Authenticate | 401 | | m | m | m | 3725 +------------------+---------+-------+-----+-----+-----+ 3727 Table 12: Overview of RTSP header fields (R-W) related to methods 3728 GETPARAMETER, SETPARAMETER, and REDIRECT. 3730 14.1. Accept 3732 The Accept request-header field can be used to specify certain 3733 presentation description content types which are acceptable for the 3734 response. 3736 See [H14.1] for syntax. 3738 Example of use: 3740 Accept: application/example q=1.0, application/sdp 3742 14.2. Accept-Credentials 3744 The Accept-Credentials header is a request header used to indicate to 3745 any trusted intermediary how to handle further secured connections to 3746 proxies or servers. See Section Section 18 for the usage of this 3747 header. It SHALL NOT be included in server to client requests. 3749 In a request the header SHALL contain the method (User, Proxy, or 3750 Any) for approving credentials selected by the requestor. The method 3751 SHALL NOT be changed by any proxy. If the method is "User" the 3752 header contains zero or more of credentials that the client accept. 3753 The header may contain zero credentials in the first RTSP request to 3754 a RTSP server when using the "User" method. This as the client has 3755 not yet received any credentials to accept. Each credential SHALL 3756 consist of one URI identifying the proxy or server, the hash 3757 algorithm identifier, and the hash over that entity's DER encoded 3758 certificate [RFC3280]"/> in Base64. All RTSP clients and proxies 3759 SHALL implement the SHA-1[FIPS-pub-180-1] algorithm for computation 3760 of the hash of the DER encoded certificate. The SHA-1 algorithm is 3761 identified by the token "sha-1". 3763 The intention with allowing for other hash algorithms is to enable 3764 the future retirement of algorithms that are not implemented 3765 somewhere else than here. Thus the definition of future algorithms 3766 for this purpose is intended to be extremely limited. 3768 Example: 3770 Accept-Credentials:User, 3771 "rtsps://proxy2.example.com/";sha-1;exaIl9VMbQMOFGClx5rXnPJKVNI=, 3772 "rtsps://server.example.com/";sha-1;lurbjj5khhB0NhIuOXtt4bBRH1M= 3774 14.3. Accept-Encoding 3776 See [H14.3]. 3778 14.4. Accept-Language 3780 See [H14.4]. Note that the language specified applies to the 3781 presentation description and any reason phrases, not the media 3782 content. 3784 14.5. Accept-Ranges 3786 The Accept-Ranges request and response-header field allows indication 3787 of the format supported in the Range header. The client SHALL 3788 include the header in SETUP requests to indicate which formats it 3789 support to receive in PLAY and PAUSE responses, and REDIRECT 3790 requests. The server SHALL include the header in SETUP and 456 error 3791 responses to indicate the formats supported for the resource 3792 indicated by the request URI. 3794 Accept-Ranges: NPT, SMPTE 3796 This header has the same syntax as [H14.5] and the syntax is defined 3797 in Section 19.2.3. However, new range-units are defined. 3799 14.6. Allow 3801 The Allow entity-header field lists the methods supported by the 3802 resource identified by the Request-URI. The purpose of this field is 3803 to strictly inform the recipient of valid methods associated with the 3804 resource. An Allow header field MUST be present in a 405 (Method Not 3805 Allowed) response. See [H14.7] for syntax definition. The Allow 3806 header MUST also be present in all OPTIONS responses where the 3807 content of the header will not include exactly the same methods as 3808 listed in the Public header. 3810 The Allow SHALL also be included in SETUP and DESCRIBE responses, if 3811 the methods allowed for the resource is different than the minimal 3812 implementation set. 3814 Example of use: 3816 Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE 3818 14.7. Authorization 3820 See [H14.8]. 3822 14.8. Bandwidth 3824 The Bandwidth request-header field describes the estimated bandwidth 3825 available to the client, expressed as a positive integer and measured 3826 in bits per second. The bandwidth available to the client may change 3827 during an RTSP session, e.g., due to mobility, congestion, etc. 3829 Example: 3831 Bandwidth: 62360 3833 14.9. Blocksize 3835 The Blocksize request-header field is sent from the client to the 3836 media server asking the server for a particular media packet size. 3837 This packet size does not include lower-layer headers such as IP, 3838 UDP, or RTP. The server is free to use a blocksize which is lower 3839 than the one requested. The server MAY truncate this packet size to 3840 the closest multiple of the minimum, media-specific block size, or 3841 override it with the media-specific size if necessary. The block 3842 size MUST be a positive decimal number, measured in octets. The 3843 server only returns an error (4xx) if the value is syntactically 3844 invalid. 3846 14.10. Cache-Control 3848 The Cache-Control general-header field is used to specify directives 3849 that MUST be obeyed by all caching mechanisms along the request/ 3850 response chain. 3852 Cache directives MUST be passed through by a proxy or gateway 3853 application, regardless of their significance to that application, 3854 since the directives may be applicable to all recipients along the 3855 request/response chain. It is not possible to specify a cache- 3856 directive for a specific cache. 3858 Cache-Control should only be specified in a SETUP request and its 3859 response. Note: Cache-Control does em not govern the caching of 3860 responses as for HTTP, instead it applies to the media stream 3861 identified by the SETUP request. The RTSP requests are generally not 3862 cacheable, for further information see section Section 16. Below is 3863 the description of the cache directives that can be included in the 3864 Cache-Control header. 3866 no-cache: Indicates that the media stream MUST NOT be cached 3867 anywhere. This allows an origin server to prevent caching even 3868 by caches that have been configured to return stale responses 3869 to client requests. 3871 public: Indicates that the media stream is cacheable by any cache. 3873 private: Indicates that the media stream is intended for a single 3874 user and MUST NOT be cached by a shared cache. A private (non- 3875 shared) cache may cache the media streams. 3877 no-transform: An intermediate cache (proxy) may find it useful to 3878 convert the media type of a certain stream. A proxy might, for 3879 example, convert between video formats to save cache space or 3880 to reduce the amount of traffic on a slow link. Serious 3881 operational problems may occur, however, when these 3882 transformations have been applied to streams intended for 3883 certain kinds of applications. For example, applications for 3884 medical imaging, scientific data analysis and those using end- 3885 to-end authentication all depend on receiving a stream that is 3886 bit-for-bit identical to the original media stream. Therefore, 3887 if a response includes the no-transform directive, an 3888 intermediate cache or proxy MUST NOT change the encoding of the 3889 stream. Unlike HTTP, RTSP does not provide for partial 3890 transformation at this point, e.g., allowing translation into a 3891 different language. 3893 only-if-cached: In some cases, such as times of extremely poor 3894 network connectivity, a client may want a cache to return only 3895 those media streams that it currently has stored, and not to 3896 receive these from the origin server. To do this, the client 3897 may include the only-if-cached directive in a request. If it 3898 receives this directive, a cache SHOULD either respond using a 3899 cached media stream that is consistent with the other 3900 constraints of the request, or respond with a 504 (Gateway 3901 Timeout) status. However, if a group of caches is being 3902 operated as a unified system with good internal connectivity, 3903 such a request MAY be forwarded within that group of caches. 3905 max-stale: Indicates that the client is willing to accept a media 3906 stream that has exceeded its expiration time. If max-stale is 3907 assigned a value, then the client is willing to accept a 3908 response that has exceeded its expiration time by no more than 3909 the specified number of seconds. If no value is assigned to 3910 max-stale, then the client is willing to accept a stale 3911 response of any age. 3913 min-fresh: Indicates that the client is willing to accept a media 3914 stream whose freshness lifetime is no less than its current age 3915 plus the specified time in seconds. That is, the client wants 3916 a response that will still be fresh for at least the specified 3917 number of seconds. 3919 must-revalidate: When the must-revalidate directive is present in a 3920 SETUP response received by a cache, that cache MUST NOT use the 3921 entry after it becomes stale to respond to a subsequent request 3922 without first revalidating it with the origin server. That is, 3923 the cache is required to do an end-to-end revalidation every 3924 time, if, based solely on the origin server's Expires, the 3925 cached response is stale.) 3927 proxy-revalidate: The proxy-revalidate directive has the same 3928 meaning as the must-revalidate directive, except that it does 3929 not apply to non-shared user agent caches. It can be used on a 3930 response to an authenticated request to permit the user's cache 3931 to store and later return the response without needing to 3932 revalidate it (since it has already been authenticated once by 3933 that user), while still requiring proxies that service many 3934 users to revalidate each time (in order to make sure that each 3935 user has been authenticated). Note that such authenticated 3936 responses also need the public cache control directive in order 3937 to allow them to be cached at all. 3939 max-age: When an intermediate cache is forced, by means of a max- 3940 age=0 directive, to revalidate its own cache entry, and the 3941 client has supplied its own validator in the request, the 3942 supplied validator might differ from the validator currently 3943 stored with the cache entry. In this case, the cache MAY use 3944 either validator in making its own request without affecting 3945 semantic transparency. 3947 However, the choice of validator might affect performance. The best 3948 approach is for the intermediate cache to use its own validator when 3949 making its request. If the server replies with 304 (Not Modified), 3950 then the cache can return its now validated copy to the client with a 3951 200 (OK) response. If the server replies with a new entity and cache 3952 validator, however, the intermediate cache can compare the returned 3953 validator with the one provided in the client's request, using the 3954 strong comparison function. If the client's validator is equal to 3955 the origin server's, then the intermediate cache simply returns 304 3956 (Not Modified). Otherwise, it returns the new entity with a 200 (OK) 3957 response. 3959 14.11. Connection 3961 See [H14.10]. The use of the connection option "close" in RTSP 3962 messages SHOULD be limited to error messages when the server is 3963 unable to recover and therefore see it necessary to close the 3964 connection. The reason is that the client has the choice of 3965 continuing using a connection indefinitely, as long as it sends valid 3966 messages. 3968 14.12. Connection-Credentials 3970 The Connection-Credentials response header is used to carry the 3971 credentials of any next hop that need to be approved by the 3972 requestor. It SHALL only be used in server to client responses. 3974 The Connection-Credentials header in an RTSP response SHALL, if 3975 included, contain the credentials information of the next hop that an 3976 intermediary needs to securely connect to. The credential MUST 3977 include the URI of the next proxy or server and the DER encoded 3978 X.509v3[RFC3280] certificate in base64 [RFC3548]. 3980 Example: 3982 Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC... 3984 14.13. Content-Base 3986 The Content-Base entity-header field may be used to specify the base 3987 URI for resolving relative URIs within the entity. 3989 Content-Base: rtsp://media.example.com/movie/twister 3991 If no Content-Base field is present, the base URI of an entity is 3992 defined either by its Content-Location (if that Content-Location URI 3993 is an absolute URI) or the URI used to initiate the request, in that 3994 order of precedence. Note, however, that the base URI of the 3995 contents within the entity-body may be redefined within that entity- 3996 body. 3998 14.14. Content-Encoding 4000 See [H14.11]. 4002 14.15. Content-Language 4004 See [H14.12]. 4006 14.16. Content-Length 4008 The Content-Length general-header field contains the length of the 4009 body (entity) of the message (i.e. after the double CRLF following 4010 the last header). Unlike HTTP, it MUST be included in all messages 4011 that carry body beyond the header portion of the message. If it is 4012 missing, a default value of zero is assumed. It is interpreted 4013 according to [H14.13]. 4015 14.17. Content-Location 4017 See [H14.14]. 4019 14.18. Content-Type 4021 See [H14.17]. Note that the content types suitable for RTSP are 4022 likely to be restricted in practice to presentation descriptions and 4023 parameter-value types. 4025 14.19. CSeq 4027 The CSeq general-header field specifies the sequence number for an 4028 RTSP request-response pair. This field MUST be present in all 4029 requests and responses. For every RTSP request containing the given 4030 sequence number, the corresponding response will have the same 4031 number. Any retransmitted request MUST contain the same sequence 4032 number as the original (i.e. the sequence number is em not 4033 incremented for retransmissions of the same request). For each new 4034 RTSP request the CSeq value SHALL be incremented by one. The initial 4035 sequence number MAY be any number, however it is RECOMMENDED to start 4036 at 0. Each sequence number series is unique between each requester 4037 and responder, i.e. the client has one series for its request to a 4038 server and the server has another when sending request to the client. 4039 Each requester and responder is identified with its network address. 4041 Proxies that aggregate several sessions on the same transport will 4042 regularly need to renumber the CSeq header field in requests and 4043 responses to fulfill the rules for the header. 4045 Example: 4047 CSeq: 239 4049 14.20. Date 4051 See [H14.18]. An RTSP message containing a body MUST include a Date 4052 header if the sending host has a clock. Servers SHOULD include a 4053 Date header in all other RTSP messages. 4055 14.21. ETag 4057 The ETag response header MAY be included in DESCRIBE or SETUP 4058 responses. The entity tags (Section 3.8) returned in a DESCRIBE 4059 response, and the one in SETUP refers to the presentation, i.e. both 4060 the returned session description and the media stream. This allows 4061 for verification that one has the right session description to a 4062 media resource at the time of the SETUP request. However it has the 4063 disadvantage that a change in any of the parts results in 4064 invalidation of all the parts. 4066 If the ETag is provided both inside the entity, e.g. within the 4067 "a=etag" attribute in SDP, and in the response message, then both 4068 tags SHALL be identical. It is RECOMMENDED that the ETag is 4069 primarily given in the RTSP response message, to ensure that caches 4070 can use the ETag without requiring content inspection. However for 4071 session descriptions that are distributed outside of RTSP, for 4072 example using HTTP, etc. it will be necessary to include the entity 4073 tag in the session description as specified in Appendix C.1.9. 4075 SETUP and DESCRIBE requests can be made conditional upon the ETag 4076 using the headers If-Match (Section Section 14.24) and If-None-Match 4077 ( Section 14.26). 4079 14.22. Expires 4081 The Expires entity-header field gives a date and time after which the 4082 description or media-stream should be considered stale. The 4083 interpretation depends on the method: 4085 DESCRIBE response: The Expires header indicates a date and time 4086 after which the presentation description (body) SHOULD be 4087 considered stale. 4089 SETUP response: The Expires header indicate a date and time after 4090 which the media stream SHOULD be considered stale. 4092 A stale cache entry may not normally be returned by a cache (either a 4093 proxy cache or an user agent cache) unless it is first validated with 4094 the origin server (or with an intermediate cache that has a fresh 4095 copy of the entity). See Section 16 for further discussion of the 4096 expiration model. 4098 The presence of an Expires field does not imply that the original 4099 resource will change or cease to exist at, before, or after that 4100 time. 4102 The format is an absolute date and time as defined by HTTP-date in 4104 [H3.3]; it MUST be in RFC1123-date format: 4106 An example of its use is 4108 Expires: Thu, 01 Dec 1994 16:00:00 GMT 4110 RTSP/2.0 clients and caches MUST treat other invalid date formats, 4111 especially including the value "0", as having occurred in the past 4112 (i.e., already expired). 4114 To mark a response as "already expired," an origin server should use 4115 an Expires date that is equal to the Date header value. To mark a 4116 response as "never expires," an origin server SHOULD use an Expires 4117 date approximately one year from the time the response is sent. 4118 RTSP/2.0 servers SHOULDNOT send Expires dates more than one year in 4119 the future. 4121 The presence of an Expires header field with a date value of some 4122 time in the future on a media stream that otherwise would by default 4123 be non-cacheable indicates that the media stream is cacheable, unless 4124 indicated otherwise by a Cache-Control header field (Section 4125 Section 14.10). 4127 14.23. From 4129 See [H14.22]. 4131 14.24. If-Match 4133 See [H14.24]. 4135 The If-Match request-header field is especially useful for ensuring 4136 the integrity of the presentation description, in both the case where 4137 it is fetched via means external to RTSP (such as HTTP), or in the 4138 case where the server implementation is guaranteeing the integrity of 4139 the description between the time of the DESCRIBE message and the 4140 SETUP message. By including the ETag given in or with the session 4141 description in a SETUP request, the client ensures that resources set 4142 up are matching the description. A SETUP request for which the ETag 4143 validation check fails, SHALL responde using 412 (Precondition 4144 Failed). 4146 This validation check is also very useful if a session has been 4147 redirected from one server to another. 4149 14.25. If-Modified-Since 4151 The If-Modified-Since request-header field is used with the DESCRIBE 4152 and SETUP methods to make them conditional. If the requested variant 4153 has not been modified since the time specified in this field, a 4154 description will not be returned from the server (DESCRIBE) or a 4155 stream will not be set up (SETUP). Instead, a 304 (Not Modified) 4156 response SHALL be returned without any message-body. 4158 An example of the field is: 4160 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 4162 14.26. If-None-Match 4164 See [H14.26]. 4166 This request header can be used with one or several entity tags to 4167 make DESCRIBE requests conditional. A new session description is 4168 retrieved only if another entity than the ones already available 4169 would be included. If the entity available for delivery is matching 4170 the one the client already has, then a 304 (Not Modified) response is 4171 given. 4173 14.27. Last-Modified 4175 The Last-Modified entity-header field indicates the date and time at 4176 which the origin server believes the presentation description or 4177 media stream was last modified. See [H14.29]. For the methods 4178 DESCRIBE, the header field indicates the last modification date and 4179 time of the description, for SETUP that of the media stream. 4181 14.28. Location 4183 See [H14.30]. 4185 14.29. Proxy-Authenticate 4187 See [H14.33]. 4189 14.30. Proxy-Authorization 4191 See [H14.34]. 4193 14.31. Proxy-Require 4195 The Proxy-Require request-header field is used to indicate proxy- 4196 sensitive features that MUST be supported by the proxy. Any Proxy- 4197 Require header features that are not supported by the proxy MUST be 4198 negatively acknowledged by the proxy to the client using the 4199 Unsupported header. The proxy SHALL use the 551 (Option Not 4200 Supported) status code in the response. Any feature-tag included in 4201 the Proxy-Require does not apply to the end-point (server or client). 4202 To ensure that a feature is supported by both proxies and servers the 4203 tag needs to be included in also a Require header. 4205 See SectionSection 14.37 for more details on the mechanics of this 4206 message and a usage example. 4208 Example of use: 4210 Proxy-Require: play.basic 4212 14.32. Proxy-Supported 4214 The Proxy-Supported header field enumerates all the extensions 4215 supported by the proxy using feature-tags. The header carries the 4216 intersection of extensions supported by the forwarding proxies. The 4217 Proxy-Supported header MAY be included in any request by a proxy. It 4218 SHALL be added by any proxy if the Supported header is present in a 4219 request. When present in a request, the receiver MUST in the 4220 response copy the received Proxy-Supported header. 4222 The Proxy-Supported header field contains a list of feature-tags 4223 applicable to proxies, as described in SectionSection 3.7. The list 4224 are the intersection of all feature-tags understood by the proxies. 4225 To achieve an intersection, the proxy adding the Proxy-Supported 4226 header includes all proxy feature-tags it understands. Any proxy 4227 receiving a request with the header, checks the list and removes any 4228 feature-tag it do not support. A Proxy-Supported header present in 4229 the response SHALL NOT be touched by the proxies. 4231 Example: 4233 C->P1: OPTIONS rtsp://example.com/ RTSP/2.0 4234 Supported: foo, bar, blech 4236 P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0 4237 Supported: foo, bar, blech 4238 Proxy-Supported: proxy-foo, proxy-bar, proxy-blech 4239 Via: 2.0 prox1.example.com 4241 P2->S: OPTIONS rtsp://example.com/ RTSP/2.0 4242 Supported: foo, bar, blech 4243 Proxy-Supported: proxy-foo, proxy-blech 4244 Via: 2.0 prox1.example.com, 2.0 prox2.example.com 4246 S->C: RTSP/2.0 200 OK 4247 Supported: foo, bar, baz 4248 Proxy-Supported: proxy-foo, proxy-blech 4249 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 4250 Via: 2.0 prox1.example.com, 2.0 prox2.example.com 4252 14.33. Public 4254 The Public response header field lists the set of methods supported 4255 by the response sender. This header applies to the general 4256 capabilities of the sender and its only purpose is to indicate the 4257 sender's capabilities to the recipient. The methods listed may or 4258 may not be applicable to the Request-URI; the Allow header field 4259 (section 14.7) MAY be used to indicate methods allowed for a 4260 particular URI. 4262 Example of use: 4264 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 4266 In the event that there are proxies between the sender and the 4267 recipient of a response, each intervening proxy MUST modify the 4268 Public header field to remove any methods that are not supported via 4269 that proxy. The resulting Public header field will contain an 4270 intersection of the sender's methods and the methods allowed through 4271 by the intervening proxies. 4273 In general proxies should allow all methods to transparently pass 4274 through from the sending RTSP agent to the receiving RTSP agent, 4275 but there may be cases where this is not desirable for a given 4276 proxy. Modification of the Public response header field by the 4277 intervening proxies ensures that the request sender gets an 4278 accurate response indicating the methods that can be used on the 4279 target agent via the proxy chain. 4281 14.34. Range 4283 The Range header specifies a time range in PLAY ( Section 11.4), 4284 PAUSE (Section 11.5), SETUP (Section 11.3), and REDIRECT ( 4285 Section 11.9) requests and responses. 4287 The range can be specified in a number of units. This specification 4288 defines smpte (SectionSection 3.4), npt (SectionSection 3.5), and 4289 clock (SectionSection 3.6) range units. While byte ranges [H14.35.1] 4290 and other extended units MAY be used, their behavior is unspecified 4291 since they are not normally meaningful in RTSP. Servers supporting 4292 the Range header MUST understand the NPT range format and SHOULD 4293 understand the SMPTE range format. If the Range header is sent in a 4294 time format that is not understood, the recipient SHOULD return 456 4295 (Header Field Not Valid for Resource) and include an Accept-Ranges 4296 header indicating the supported time formats for the given resource. 4298 The Range header MAY contain a time parameter in UTC, specifying the 4299 time at which the operation is to be made effective. This 4300 functionality SHALL be used only with the REDIRECT method. 4302 Ranges are half-open intervals, including the first point, but 4303 excluding the second point. In other words, a range of A-B starts 4304 exactly at time A, but stops just before B. Only the start time of a 4305 media unit such as a video or audio frame is relevant. For example, 4306 assume that video frames are generated every 40 ms. A range of 10.0- 4307 10.1 would include a video frame starting at 10.0 or later time and 4308 would include a video frame starting at 10.08, even though it lasted 4309 beyond the interval. A range of 10.0-10.08, on the other hand, would 4310 exclude the frame at 10.08. 4312 Example: 4314 Range: clock=19960213T143205Z-;time=19970123T143720Z 4316 The notation is similar to that used for the HTTP/1.1 [RFC2616] 4317 byte-range header. It allows clients to select an excerpt from 4318 the media object, and to play from a given point to the end as 4319 well as from the current location to a given point. 4321 By default, range intervals increase, where the second point is 4322 larger than the first point. 4324 Example: 4326 Range: npt=10-15 4328 However, range intervals can also decrease if the Scale header (see 4329 sectionSection 14.39) indicates a negative scale value. For example, 4330 this would be the case when a playback in reverse is desired. 4332 Example: 4334 Scale: -1 4335 Range: npt=15-10 4337 Decreasing ranges are still half open intervals as described above. 4338 Thus, for range A-B, A is closed and B is open. In the above 4339 example, 15 is closed and 10 is open. An exception to this rule is 4340 the case when B=0 in a decreasing range. In this case, the range is 4341 closed on both ends, as otherwise there would be no way to reach 0 on 4342 a reverse playback for formats that have such a notion, like NPT and 4343 SMPTE. 4345 Example: 4347 Scale: -1 4348 Range: npt=15-0 4350 In this range both 15 and 0 are closed. 4352 A decreasing range interval without a corresponding negative Scale 4353 header is not valid. 4355 14.35. Referer 4357 See [H14.36]. The URI refers to that of the presentation 4358 description, typically retrieved via HTTP. 4360 14.36. Retry-After 4362 See [H14.37]. 4364 14.37. Require 4366 The Require request-header field is used by clients or servers to 4367 ensure that the other end-point supports features that are required 4368 in respect to this request. It can also be used to query if the 4369 other end-point supports certain features, however the use of the 4370 Supported (SectionSection 14.43) is much more effective in this 4371 purpose. The server MUST respond to this header by using the 4372 Unsupported header to negatively acknowledge those feature-tags which 4373 are NOT supported. The response SHALL use the error code 551 (Option 4374 Not Supported). This header does not apply to proxies, for the same 4375 functionality in respect to proxies see, header Proxy-Require 4376 (Section Section 14.31). 4378 This is to make sure that the client-server interaction will 4379 proceed without delay when all features are understood by both 4380 sides, and only slow down if features are not understood (as in 4381 the example below). For a well-matched client-server pair, the 4382 interaction proceeds quickly, saving a round-trip often required 4383 by negotiation mechanisms. In addition, it also removes state 4384 ambiguity when the client requires features that the server does 4385 not understand. 4387 Example: 4389 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/2.0 4390 CSeq: 302 4391 Require: funky-feature 4392 Funky-Parameter: funkystuff 4394 S->C: RTSP/2.0 551 Option not supported 4395 CSeq: 302 4396 Unsupported: funky-feature 4398 In this example, "funky-feature" is the feature-tag which indicates 4399 to the client that the fictional Funky-Parameter field is required. 4400 The relationship between "funky-feature" and Funky-Parameter is not 4401 communicated via the RTSP exchange, since that relationship is an 4402 immutable property of "funky-feature" and thus should not be 4403 transmitted with every exchange. 4405 Proxies and other intermediary devices SHALL ignore this header. If 4406 a particular extension requires that intermediate devices support it, 4407 the extension should be tagged in the Proxy-Require field instead 4408 (see SectionSection 14.31). 4410 14.38. RTP-Info 4412 The RTP-Info response-header field is used to set RTP-specific 4413 parameters in the PLAY response. For streams using RTP as transport 4414 protocol the RTP-Info header SHOULD be part of a 200 response to 4415 PLAY. 4417 The exclusion of the RTP-Info in a PLAY response for RTP 4418 transported media will result in that a client needs to 4419 synchronize the media streams using RTCP. This may have negative 4420 impact as the RTCP can be lost, and does not need to be 4421 particulary timely in their arrival. Also functionality as 4422 informing the client from which packet a seek has occurred is 4423 affected. 4425 The RTP-Info MAY also be included in SETUP responses to provide 4426 synchronization information when changing transport parameters, see 4427 Section 11.3. 4429 The header can carry the following parameters: 4431 url: Indicates the stream URI which for which the following RTP 4432 parameters correspond, this URI MUST be the same used in the 4433 SETUP request for this media stream. Any relative URI SHALL 4434 use the Request-URI as base URI. This parameter SHALL be 4435 present. 4437 ssrc: The Synchronization source (SSRC) that the RTP timestamp and 4438 sequence number provide applies to. This parameter SHALL be 4439 present. 4441 seq: Indicates the sequence number of the first packet of the stream 4442 that is direct result of the request. This allows clients to 4443 gracefully deal with packets when seeking. The client uses 4444 this value to differentiate packets that originated before the 4445 seek from packets that originated after the seek. Note that a 4446 client may not receive the packet with the expressed sequence 4447 number, and instead packets with a higher sequence number, due 4448 to packet loss or reordering. This parameter is RECOMMENDED to 4449 be present. 4451 rtptime: SHALL indicate the RTP timestamp value corresponding to the 4452 start time value in the Range response header, or if not 4453 explicitly given the implied start point. The client uses this 4454 value to calculate the mapping of RTP time to NPT or other 4455 media timescale. This parameter SHOULD be present to ensure 4456 inter-media synchronization is achieved. There exist no 4457 requirement that any received RTP packet will have the same RTP 4458 timestamp value as the one in the parameter used to establish 4459 synchronization. 4461 A mapping from RTP timestamps to NTP timestamps (wall clock) is 4462 available via RTCP. However, this information is not sufficient 4463 to generate a mapping from RTP timestamps to media clock time 4464 (NPT, etc.). Furthermore, in order to ensure that this 4465 information is available at the necessary time (immediately at 4466 startup or after a seek), and that it is delivered reliably, this 4467 mapping is placed in the RTSP control channel. 4469 In order to compensate for drift for long, uninterrupted 4470 presentations, RTSP clients should additionally map NPT to NTP, 4471 using initial RTCP sender reports to do the mapping, and later 4472 reports to check drift against the mapping. 4474 Example: 4476 Range:npt=3.25-15 4477 RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102; 4478 rtptime=12345678,url="rtsp://example.com/foo/video" 4479 ssrc=9A9DE123:seq=30211;rtptime=29567112 4481 Lets assume that audio uses a 16kHz RTP timestamp clock and Video 4482 a 90kHz RTP timestamp clock. Then the media synchronization is 4483 depicted in the following way. 4485 NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6 4486 Audio PA A 4487 Video V PV 4489 X: NPT time value = 3.25, from Range header. 4490 A: RTP timestamp value for Audio from RTP-Info header (12345678). 4491 V: RTP timestamp value for Video from RTP-Info header (29567112). 4492 PA: RTP audio packet carrying an RTP timestamp of 12344878. Which 4493 corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2 4494 PV: RTP video packet carrying an RTP timestamp of 29573412. Which 4495 corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32 4497 14.39. Scale 4499 A scale value of 1 indicates normal play at the normal forward 4500 viewing rate. If not 1, the value corresponds to the rate with 4501 respect to normal viewing rate. For example, a ratio of 2 indicates 4502 twice the normal viewing rate ("fast forward") and a ratio of 0.5 4503 indicates half the normal viewing rate. In other words, a ratio of 2 4504 has normal play time increase at twice the wallclock rate. For every 4505 second of elapsed (wallclock) time, 2 seconds of content will be 4506 delivered. A negative value indicates reverse direction. For 4507 certain media transports this may require certain considerations to 4508 work consistent, see section Appendix B.1 for description on how RTP 4509 handles this. 4511 Unless requested otherwise by the Speed parameter, the data rate 4512 SHOULD not be changed. Implementation of scale changes depends on 4513 the server and media type. For video, a server may, for example, 4514 deliver only key frames or selected key frames. For audio, it may 4515 time-scale the audio while preserving pitch or, less desirably, 4516 deliver fragments of audio. 4518 The server should try to approximate the viewing rate, but may 4519 restrict the range of scale values that it supports. The response 4520 MUST contain the actual scale value chosen by the server. 4522 If the server does not implement the possibility to scale, it will 4523 not return a Scale header. A server supporting Scale operations for 4524 PLAY SHALL indicate this with the use of the "play.scale" feature- 4525 tags. 4527 When indicating a negative scale for a reverse playback, the Range 4528 header MUST indicate a decreasing range as described in 4529 sectionSection 14.34. 4531 Example of playing in reverse at 3.5 times normal rate: 4533 Scale: -3.5 4534 Range: npt=15-10 4536 14.40. Speed 4538 The Speed request-header field requests the server to deliver data to 4539 the client at a particular speed, contingent on the server's ability 4540 and desire to serve the media stream at the given speed. 4541 Implementation by the server is OPTIONAL. The default is the bit 4542 rate of the stream. 4544 The parameter value is expressed as a decimal ratio, e.g., a value of 4545 2.0 indicates that data is to be delivered twice as fast as normal. 4546 A speed of zero is invalid. All speeds may not be possible to 4547 support. Therefore the actual used speed MUST be included in the 4548 response. The lack of a response header is indication of lack of 4549 support from the server of this functionality. Support of the speed 4550 functionality are indicated by the "play.speed" feature\-tag. 4552 Example: 4554 Speed: 2.5 4556 Use of this field changes the bandwidth used for data delivery. It 4557 is meant for use in specific circumstances where preview of the 4558 presentation at a higher or lower rate is necessary. Implementors 4559 should keep in mind that bandwidth for the session may be negotiated 4560 beforehand (by means other than RTSP), and therefore re-negotiation 4561 may be necessary. When data is delivered over UDP, it is highly 4562 recommended that means such as RTCP be used to track packet loss 4563 rates. If the data transport is performed over non-dedicated best- 4564 effort networks the sender is required to perform congestion control 4565 of the stream(s). This can result in that the communicated speed is 4566 impossible to maintain. 4568 14.41. Server 4570 See [H14.38], however the header syntax is corrected in section 4571 Section 19.2.3. 4573 14.42. Session 4575 The Session request-header and response-header field identifies an 4576 RTSP session. An RTSP session is created by the server as a result 4577 of a successful SETUP request and in the response the session 4578 identifier is given to the client. The RTSP session exist until 4579 destroyed by a TEARDOWN or timed out by the server. 4581 The session identifier is chosen by the server (see 4582 SectionSection 3.3) and MUST be returned in the SETUP response. Once 4583 a client receives a session identifier, it SHALL be included in any 4584 request related to that session. This means that the Session header 4585 MUST be included in a request using the following methods: PLAY, 4586 PAUSE, and TEARDOWN, and MAY be included in SETUP, OPTIONS, 4587 SETPARAMETER, GETPARAMETER, and REDIRECT, and SHALL NOT be included 4588 in DESCRIBE. In an RTSP response the session header SHALL be 4589 included in methods, SETUP, PLAY, and PAUSE, and MAY be included in 4590 methods, TEARDOWN, and REDIRECT, and if included in the request of 4591 the following methods it SHALL also be included in the response, 4592 OPTIONS, GETPARAMETER, and SETPARAMETER, and SHALL NOT be included in 4593 DESCRIBE. 4595 The timeout parameter MAY be included in a SETUP response, and SHALL 4596 NOT be included in requests. The server uses it to indicate to the 4597 client how long the server is prepared to wait between RTSP commands 4598 or other signs of life before closing the session due to lack of 4599 activity (see below and Section Appendix A). The timeout is measured 4600 in seconds, with a default of 60 seconds (1 minute). The length of 4601 the session timeout SHALL NOT be changed in a established session. 4603 The mechanisms for showing liveness of the client is, any RTSP 4604 request with a Session header, if RTP & RTCP is used an RTCP message, 4605 or through any other used media protocol capable of indicating 4606 liveness of the RTSP client. It is RECOMMENDED that a client does 4607 not wait to the last second of the timeout before trying to send a 4608 liveness message. The RTSP message may be lost or when using 4609 reliable protocols, such as TCP, the message may take some time to 4610 arrive safely at the receiver. To show liveness between RTSP request 4611 issued to accomplish other things, the following mechanisms can be 4612 used, in descending order of preference: 4614 RTCP: If RTP is used for media transport RTCP SHOULD be used. If 4615 RTCP is used to report transport statistics, it SHALL also work 4616 as keep alive. The server can determine the client by used 4617 network address and port together with the fact that the client 4618 is reporting on the servers SSRC(s). A downside of using RTCP 4619 is that it only gives statistical guarantees to reach the 4620 server. However that probability is so low that it can be 4621 ignored in most cases. For example, a session with 60 seconds 4622 timeout and enough bitrate assigned to RTCP messages to send a 4623 message from client to server on average every 5 seconds. That 4624 client have for a network with 5 \% packet loss, the 4625 probability to fail showing liveness sign in that session 4626 within the timeout interval of 2.4*E-16. In sessions with 4627 shorter timeout times, or much higher packet loss, or small 4628 RTCP bandwidths SHOULD also use any of the mechanisms below. 4630 SETPARAMETER: When using SETPARAMETER for keep alive, no body SHOULD 4631 be included. This method is the RECOMMENDED RTSP method to use 4632 in request only intended to perform keep-alive. 4634 OPTIONS: This method does also work. However it causes the server 4635 to perform more unnecessary processing and result in bigger 4636 responses than necessary for the task. The reason for this is 4637 that the server needs to determine what capabilities that are 4638 associated with the media resource to correctly populate the 4639 Public and Allow headers. 4641 Note that a session identifier identifies an RTSP session across 4642 transport sessions or connections. RTSP requests for a given session 4643 can use different URIs (Presentation and media URIs). Note, that 4644 there are restrictions depending on the session which URIs that are 4645 acceptable for a given method. However, multiple "user" sessions for 4646 the same URI from the same client will require use of different 4647 session identifiers. 4649 The session identifier is needed to distinguish several delivery 4650 requests for the same URI coming from the same client. 4652 The response 454 (Session Not Found) SHALL be returned if the session 4653 identifier is invalid. 4655 14.43. Supported 4657 The Supported header field enumerates all the extensions supported by 4658 the client or server using feature tags. The header carries the 4659 extensions supported by the message sending entity. The Supported 4660 header MAY be included in any request. When present in a request, 4661 the receiver MUST respond with its corresponding Supported header. 4663 Note, also in 4xx and 5xx responses is the supported header included. 4665 The Supported header field contains a list of feature-tags, described 4666 in SectionSection 3.7, that are understood by the client or server. 4668 Example: 4670 C->S: OPTIONS rtsp://example.com/ RTSP/2.0 4671 Supported: foo, bar, blech 4673 S->C: RTSP/2.0 200 OK 4674 Supported: bar, blech, baz 4676 14.44. Timestamp 4678 The Timestamp general-header field describes when the agent sent the 4679 request. The value of the timestamp is of significance only to the 4680 agent and may use any timescale. The responding agent MUST echo the 4681 exact same value and MAY, if it has accurate information about this, 4682 add a floating point number indicating the number of seconds that has 4683 elapsed since it has received the request. The timestamp is used by 4684 the agent to compute the round-trip time to the responding agent so 4685 that it can adjust the timeout value for retransmissions. It also 4686 resolves retransmission ambiguities for unreliable transport of RTSP. 4688 14.45. Transport 4690 The Transport request and response header field indicates which 4691 transport protocol is to be used and configures its parameters such 4692 as destination address, compression, multicast time-to-live and 4693 destination port for a single stream. It sets those values not 4694 already determined by a presentation description. 4696 Transports are comma separated, listed in order of preference. 4697 Parameters may be added to each transport, separated by a semicolon. 4698 The server SHOULD return a Transport response-header field in the 4699 response to indicate the values actually chosen. The Transport 4700 header field MAY also be used to change certain transport parameters. 4701 A server MAY refuse to change parameters of an existing stream. 4703 A Transport request header field MAY contain a list of transport 4704 options acceptable to the client, in the form of multiple transport- 4705 spec entries. In that case, the server MUST return the single 4706 (transport-spec) which was actually chosen. The number of transport- 4707 spec entries is expected to be limited as the client will get 4708 guidance on what configurations that are possible from the 4709 presentation description. 4711 A transport-spec transport option may only contain one of any given 4712 parameter within it. Parameters MAY be given in any order. 4713 Additionally, it may only contain the unicast or the multicast 4714 transport type parameter. Unknown parameters SHALL be ignored. The 4715 requester need to ensure that the responder understands the 4716 parameters through the use of feature tags and the Require header. 4718 Any parameters part of future extensions requires clarification if 4719 they are safe to ignore in accordance to this specification, or are 4720 required to be understood. If a parameter is required to be 4721 understood, then a feature-tag MUST be defined for the functionality 4722 and used in the Require or Proxy-Require headers. 4724 The Transport header field is restricted to describing a single 4725 media stream. (RTSP can also control multiple streams as a single 4726 entity.) Making it part of RTSP rather than relying on a 4727 multitude of session description formats greatly simplifies 4728 designs of firewalls. 4730 The general syntax for the transport specifier is a list of slash 4731 separated tokens: 4733 Value1/Value2/Value3... 4735 Which for RTP transports take the form: 4737 RTP/profile/lower-transport. 4739 The default value for the "lower-transport" parameters is specific to 4740 the profile. For RTP/AVP, the default is UDP. 4742 There are two different methods for how to specify where the media 4743 should be delivered: 4745 dest_addr: The presence of this parameter and its values indicates 4746 the destination address or addresses (host address and port 4747 pairs for IP flows) necessary for the media transport. 4749 No dest_addr: The lack of the dest_addr parameter indicates that the 4750 server SHALL send media to same address for which the RTSP 4751 messages originates. Does not work for transports requiring 4752 explicitly given destination ports. 4754 The choice of method for indicating where the media is to be 4755 delivered depends on the use case. In many case the only allowed 4756 method will be to use no explicit address indication and have the 4757 server deliver media to the source of the RTSP messages. 4759 An RTSP proxy will need to take care. If the media is not desired to 4760 be routed through the proxy, the proxy will need to introduce the 4761 destination indication. 4763 Below are the configuration parameters associated with transport: 4765 General parameters: 4767 unicast / multicast: This parameter is a mutually exclusive 4768 indication of whether unicast or multicast delivery will be 4769 attempted. One of the two values MUST be specified. Clients 4770 that are capable of handling both unicast and multicast 4771 transmission needs to indicate such capability by including two 4772 full transport-specs with separate parameters for each. 4774 layers: The number of multicast layers to be used for this media 4775 stream. The layers are sent to consecutive addresses starting 4776 at the dest_addr address. If the parameter is not included, it 4777 defaults to a single layer. 4779 dest_addr: A general destination address parameter that can contain 4780 one or more address specifications. Each combination of 4781 Protocol/Profile/Lower Transport needs to have the format and 4782 interpretation of its address specification defined. For RTP/ 4783 AVP/UDP and RTP/AVP/TCP, the address specification is a tuple 4784 containing a host address and port. Note, only a single 4785 destination entity per transport spec is intended. The usage 4786 of multiple destination to distribute a single media to 4787 multiple entities is unspecified. 4789 The client originating the RTSP request MAY specify the 4790 destination address of the stream recipient with the host 4791 address part of the tuple. When the destination address is 4792 specified, the recipient may be a different party than the 4793 originator of the request. To avoid becoming the unwitting 4794 perpetrator of a remote-controlled denial-of-service attack, a 4795 server MUST perform security checks (see Section Section 20.1) 4796 and SHOULD log such attempts before allowing the client to 4797 direct a media stream to a recipient address not chosen by the 4798 server. Implementations cannot rely on TCP as reliable means 4799 of client identification. If the server does not allow the 4800 host address part of the tuple to be set, it SHALL return 463 4801 (Destination Prohibited). 4803 The host address part of the tuple MAY be empty, for example 4804 ":58044", in cases when only destination port is desired to be 4805 specified. 4807 src_addr: A general source address parameter that can contain one or 4808 more address specifications. Each combination of Protocol/ 4809 Profile/Lower Transport needs to have the format and 4810 interpretation of its address specification defined. For RTP/ 4811 AVP/UDP and RTP/AVP/TCP, the address specification is a tuple 4812 containing a host address and port. 4814 This parameter MUST be specified by the server if it transmits 4815 media packets from another address than the one RTSP messages 4816 are sent to. This will allow the client to verify source 4817 address and give it a destination address for its RTCP feedback 4818 packets if RTP is used. The address or addresses indicated in 4819 the src_addr parameter SHOULD be used both for sending and 4820 receiving of the media streams data packets. The main reasons 4821 are threefold: First, indicating the port and source address(s) 4822 lets the receiver know where from the packets is expected to 4823 originate. Secondly, traversal of NATs are greatly simplified 4824 when traffic is flowing symmetrically over a NAT binding. 4825 Thirdly, certain NAT traversal mechanisms, needs to know to 4826 which address and port to send so called "binding packets" from 4827 the receiver to the sender, thus creating a address binding in 4828 the NAT that the sender to receiver packet flow can use. 4830 This information may also be available through SDP. 4831 However, since this is more a feature of transport than 4832 media initialization, the authoritative source for this 4833 information should be in the SETUP response. 4835 mode: The mode parameter indicates the methods to be supported for 4836 this session. Valid values are PLAY and RECORD. If not 4837 provided, the default is PLAY. The RECORD value was defined in 4838 RFC 2326 and is in this specification unspecified but reserved. 4840 interleaved: The interleaved parameter implies mixing the media 4841 stream with the control stream in whatever protocol is being 4842 used by the control stream, using the mechanism defined in 4843 SectionSection 12. The argument provides the channel number to 4844 be used in the $ statement and MUST be present. This parameter 4845 MAY be specified as a range, e.g., tt interleaved=4-5 in cases 4846 where the transport choice for the media stream requires it, 4847 e.g. for RTP with RTCP. The channel number given in the 4848 request are only a guidance from the client to the server on 4849 what channel number(s) to use. The server MAY set any valid 4850 channel number in the response. The declared channel(s) are 4851 bi-directional, so both end-parties MAY send data on the given 4852 channel. One example of such usage is the second channel used 4853 for RTCP, where both server and client sends RTCP packets on 4854 the same channel. 4856 This allows RTP/RTCP to be handled similarly to the way 4857 that it is done with UDP, i.e., one channel for RTP and 4858 the other for RTCP. 4860 Multicast-specific: 4862 ttl: multicast time-to-live. When included in requests the value 4863 indicate the TTL value that the client desires to use. In 4864 response the value actually being used is returned. A server 4865 will need to consider what values that are reasonable and also 4866 the authority of the user to set this value. 4868 RTP-specific: 4870 These parameters are MAY only be used if the media transport protocol 4871 is RTP. 4873 ssrc: The ssrc parameter, if included in a SETUP response, indicates 4874 the RTP SSRC [RFC3550] value(s) that will be used by the media 4875 server for RTP packets within the stream. It is expressed as 4876 an eight digit hexadecimal value. 4878 The ssrc parameter SHALL NOT be specified in requests. The 4879 functionality of specifying the ssrc parameter in a SETUP 4880 request is deprecated as it is incompatible with the 4881 specification of RTP in RFC 3550[RFC3550]. If the parameter is 4882 included in the Transport header of a SETUP request, the server 4883 MAY ignore it, and choose appropriate SSRCs for the stream. 4884 The server MAY set the ssrc parameter in the Transport header 4885 of the response. 4887 The parameters defined below MAY only be used if the media transport 4888 protocol if the lower-level transport is connection-oriented (such as 4889 TCP). However, these parameters MUST NOT be used when interleaving 4890 data over the RTSP control connection. 4892 setup: Clients use the setup parameter on the Transport line in a 4893 SETUP request, to indicate the roles it wishes to play in a TCP 4894 connection. This parameter is adapted from [RFC4145]. We 4895 discuss the use of this parameter in RTP/AVP/TCP non- 4896 interleaved transport in Appendix B.2.2; the discussion below 4897 is limited to syntactic issues. Clients may specify the 4898 following values for the setup parameter: ["active":] The 4899 client will initiate an outgoing connection. ["passive":] The 4900 client will accept an incoming connection. ["actpass":] The 4901 client is willing to accept an incoming connection or to 4902 initiate an outgoing connection. 4904 If a client does not specify a setup value, the "active" value 4905 is assumed. 4907 In response to a client SETUP request where the setup parameter 4908 is set to "active", a server's 2xx reply MUST assign the setup 4909 parameter to "passive" on the Transport header line. 4911 In response to a client SETUP request where the setup parameter 4912 is set to "passive", a server's 2xx reply MUST assign the setup 4913 parameter to "active" on the Transport header line. 4915 In response to a client SETUP request where the setup parameter 4916 is set to "actpass", a server's 2xx reply MUST assign the setup 4917 parameter to "active" or "passive" on the Transport header 4918 line. 4920 Note that the "holdconn" value for setup is not defined for 4921 RTSP use, and MUST NOT appear on a Transport line. 4923 connection: Clients use the setup parameter on the Transport line in 4924 a SETUP request, to indicate the SETUP request prefers the 4925 reuse of an existing connection between client and server (in 4926 which case the client sets the "connection" parameter to 4927 "existing"), or that the client requires the creation of a new 4928 connection between client and server (in which cast the client 4929 sets the "connection" parameter to "new"). Typically, clients 4930 use the "new" value for the first SETUP request for a URL, and 4931 "existing" for subsequent SETUP requests for a URL. 4933 If a client SETUP request assigns the "new" value to 4934 "connection", the server response MUST also assign the "new" 4935 value to "connection" on the Transport line. 4937 If a client SETUP request assigns the "existing" value to 4938 "connection", the server response MUST assign a value of 4939 "existing" or "new" to "connection" on the Transport line, at 4940 its discretion. 4942 The default value of "connection" is "existing", for all SETUP 4943 requests (initial and subsequent). 4945 The combination of transport protocol, profile and lower transport 4946 needs to be defined. A number of combinations are defined in the 4947 Appendix B. 4949 Below is a usage example, showing a client advertising the capability 4950 to handle multicast or unicast, preferring multicast. Since this is 4951 a unicast-only stream, the server responds with the proper transport 4952 parameters for unicast. 4954 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 4955 CSeq: 302 4956 Transport: RTP/AVP;multicast;mode="PLAY", 4957 RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ 4958 "192.0.2.5:3457";mode="PLAY" 4960 S->C: RTSP/2.0 200 OK 4961 CSeq: 302 4962 Date: 23 Jan 1997 15:35:06 GMT 4963 Session: 47112344 4964 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ 4965 "192.0.2.5:3457";src_addr="192.0.2.224:6256" 4966 /"192.0.2.224:6257";mode="PLAY" 4968 14.46. Unsupported 4970 The Unsupported response-header field lists the features not 4971 supported by the server. In the case where the feature was specified 4972 via the Proxy-Require field (SectionSection 14.31), if there is a 4973 proxy on the path between the client and the server, the proxy MUST 4974 send a response message with a status code of 551 (Option Not 4975 Supported). The request SHALL NOT be forwarded. 4977 See Section 14.37 for a usage example. 4979 14.47. User-Agent 4981 See [H14.43] for explanation, however the syntax is clarified due to 4982 an error in RFC 2616. A Client SHOULD include this header in all 4983 RTSP messages it sends. 4985 14.48. Vary 4987 See [H14.44]. 4989 14.49. Via 4991 See [H14.45]. 4993 14.50. WWW-Authenticate 4995 See [H14.47]. 4997 15. Proxies 4999 RTSP Proxies are RTSP agents that sit in between a client and a 5000 server. A proxy can take on both the role as a client and as server 5001 depending on what it tries to accomplish. Proxies are also 5002 introduced for several different reasons. 5004 Caching Proxy: This type of proxy is used to reduce the workload on 5005 servers and connections. By caching a presentation, both 5006 description and media streams the proxy can serve a client 5007 content without requesting it from the server once it has been 5008 cached and hasn't become stale. See the caching 5009 SectionSection 16. 5011 Access Proxy: This type of proxy is used to ensure that a RTSP 5012 client get access to servers on an external network. Thus this 5013 proxy is placed on the border between two domains, e.g. a 5014 private address space and the public internet. The proxy 5015 performs the necessary translation, usually addresses, and 5016 often also media stream translation or redirection. 5018 Security Proxy: This type of proxy is used to help facilitate 5019 security functions around RTSP. For example when having a 5020 firewalled network, the security proxy request that the 5021 necessary pinholes in the firewall is opened when a client in 5022 the protected network want to access media streams on the 5023 external side. It can also provide network owners with a 5024 logging and audit point for RTSP sessions, e.g. for 5025 corporations that tracks or limits their employees access to 5026 certain type of content. 5028 All type of proxies can be used also when using secured communication 5029 with TLS as RTSP 2.0 allows the client to approve certificates for 5030 connection establishment from a proxy, see SectionSection 18.3.2. 5031 However that trust model may not be suitable for all type of 5032 deployment, and instead secured sessions do by-pass of the proxies. 5034 Access proxies SHOULD NOT be used in equipment like NATs and 5035 firewalls that aren't expected to be regularly maintained, like home 5036 or small office equipment. In these cases it is better to use the 5037 NAT traversal procedures defined for RTSP 2.0 5038 [I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is 5039 that any extensions of RTSP resulting in new media transport 5040 protocols or profiles, new parameters etc may fail in a proxy that 5041 isn't maintained. Thus resulting in blocking further development of 5042 RTSP and its usage. 5044 The existence of proxies must always be considered when developing 5045 new RTSP extensions. There must be definition of how proxies may 5046 handle the extension, if it is required to understand it, thus 5047 requiring a feature-tag to be used in the Proxy-Require header. 5049 16. Caching 5051 In HTTP, response-request pairs are cached. RTSP differs 5052 significantly in that respect. Responses are not cacheable, with the 5053 exception of the presentation description returned by DESCRIBE. 5054 (Since the responses for anything but DESCRIBE and GETPARAMETER do 5055 not return any data, caching is not really an issue for these 5056 requests.) However, it is desirable for the continuous media data, 5057 typically delivered out-of-band with respect to RTSP, to be cached, 5058 as well as the session description. 5060 On receiving a SETUP or PLAY request, a proxy ascertains whether it 5061 has an up-to-date copy of the continuous media content and its 5062 description. It can determine whether the copy is up-to-date by 5063 issuing a SETUP or DESCRIBE request, respectively, and comparing the 5064 Last-Modified header with that of the cached copy. If the copy is 5065 not up-to-date, it modifies the SETUP transport parameters as 5066 appropriate and forwards the request to the origin server. 5067 Subsequent control commands such as PLAY or PAUSE then pass the proxy 5068 unmodified. The proxy delivers the continuous media data to the 5069 client, while possibly making a local copy for later reuse. The 5070 exact behavior allowed to the cache is given by the cache-response 5071 directives described in SectionSection 14.10. A cache MUST answer 5072 any DESCRIBE requests if it is currently serving the stream to the 5073 requestor, as it is possible that low-level details of the stream 5074 description may have changed on the origin-server. 5076 Note that an RTSP cache, unlike the HTTP cache, is of the "cut- 5077 through" variety. Rather than retrieving the whole resource from the 5078 origin server, the cache simply copies the streaming data as it 5079 passes by on its way to the client. Thus, it does not introduce 5080 additional latency. 5082 To the client, an RTSP proxy cache appears like a regular media 5083 server, to the media origin server like a client. Just as an HTTP 5084 cache has to store the content type, content language, and so on for 5085 the objects it caches, a media cache has to store the presentation 5086 description. Typically, a cache eliminates all transport-references 5087 (that is, e.g. multicast information) from the presentation 5088 description, since these are independent of the data delivery from 5089 the cache to the client. Information on the encodings remains the 5090 same. If the cache is able to translate the cached media data, it 5091 would create a new presentation description with all the encoding 5092 possibilities it can offer. 5094 17. Examples 5096 This section contains several different examples trying to illustrate 5097 possible ways of using RTSP. The examples can also help with the 5098 understanding of how functions of RTSP work. However remember that 5099 this is examples and the normative and syntax description in the 5100 other sections takes precedence. Please also note that many of the 5101 example contain syntax illegal line breaks to accommodate the 5102 formatting restriction that the RFC series impose. 5104 17.1. Media on Demand (Unicast) 5106 The is an example of media on demand streaming of a media stored in a 5107 container file. For purposes of this example, a container file is a 5108 storage entity in which multiple continuous media types pertaining to 5109 the same end-user presentation are present. In effect, the container 5110 file represents an RTSP presentation, with each of its components 5111 being RTSP controlled media streams. Container files are a widely 5112 used means to store such presentations. While the components are 5113 transported as independent streams, it is desirable to maintain a 5114 common context for those streams at the server end. 5116 This enables the server to keep a single storage handle open 5117 easily. It also allows treating all the streams equally in case 5118 of any prioritization of streams by the server. 5120 It is also possible that the presentation author may wish to prevent 5121 selective retrieval of the streams by the client in order to preserve 5122 the artistic effect of the combined media presentation. Similarly, 5123 in such a tightly bound presentation, it is desirable to be able to 5124 control all the streams via a single control message using an 5125 aggregate URI. 5127 The following is an example of using a single RTSP session to control 5128 multiple streams. It also illustrates the use of aggregate URIs. In 5129 a container file it is also desirable to not write any URI parts 5130 which is not kept, when the container is distributed, like the host 5131 and most of the path element. Therefore this example also uses the 5132 "*" and relative URI in the delivered SDP. 5134 Client C requests a presentation from media server M. The movie is 5135 stored in a container file. The client has obtained an RTSP URI to 5136 the container file. 5138 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 5139 CSeq: 1 5140 User-Agent: PhonyClient/1.2 5142 M->C: RTSP/2.0 200 OK 5143 CSeq: 1 5144 Server: PhonyServer/1.0 5145 Date: 23 Jan 1997 15:35:06 GMT 5146 Content-Type: application/sdp 5147 Content-Length: 257 5148 Content-Base: rtsp://example.com/twister.3gp/ 5149 Expires: 24 Jan 1997 15:35:06 GMT 5151 v=0 5152 o=- 2890844256 2890842807 IN IP4 192.0.2.5 5153 s=RTSP Session 5154 i=An Example of RTSP Session Usage 5155 e=adm@example.com 5156 a=control: * 5157 a=range: npt=0-0:10:34.10 5158 t=0 0 5159 m=audio 0 RTP/AVP 0 5160 a=control: trackID=1 5161 m=video 0 RTP/AVP 26 5162 a=control: trackID=4 5164 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 5165 CSeq: 2 5166 User-Agent: PhonyClient/1.2 5167 Require: play.basic 5168 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" 5170 M->C: RTSP/2.0 200 OK 5171 CSeq: 2 5172 Server: PhonyServer/1.0 5173 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001; 5174 src_addr="192.0.2.5:9000"/"192.0.2.5:9001" 5175 ssrc=93CB001E 5176 Session: 12345678 5177 Expires: 24 Jan 1997 15:35:12 GMT 5178 Date: 23 Jan 1997 15:35:12 GMT 5179 Accept-Ranges: NPT 5181 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 5182 CSeq: 3 5183 User-Agent: PhonyClient/1.2 5184 Require: play.basic 5185 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" 5186 Session: 12345678 5188 M->C: RTSP/2.0 200 OK 5189 CSeq: 3 5190 Server: PhonyServer/1.0 5191 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003; 5192 src_addr="192.0.2.5:9002"/"192.0.2.5:9003"; 5193 ssrc=A813FC13 5194 Session: 12345678 5195 Expires: 24 Jan 1997 15:35:13 GMT 5196 Date: 23 Jan 1997 15:35:13 GMT 5197 Accept-Range: NPT 5199 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 5200 CSeq: 4 5201 User-Agent: PhonyClient/1.2 5202 Range: npt=0-10, npt=30- 5203 Session: 12345678 5205 M->C: RTSP/2.0 200 OK 5206 CSeq: 4 5207 Server: PhonyServer/1.0 5208 Date: 23 Jan 1997 15:35:14 GMT 5209 Session: 12345678 5210 Range: npt=0-10, npt=30-623.10 5211 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 5212 ssrc=0D12F123:seq=12345;rtptime=3450012, 5213 url="rtsp://example.com/twister.3gp/trackID=1"; 5214 ssrc=4F312DD8:seq=54321;rtptime=2876889 5216 C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0 5217 CSeq: 5 5218 User-Agent: PhonyClient/1.2 5219 Session: 12345678 5221 M->C: RTSP/2.0 200 OK 5222 CSeq: 5 5223 Server: PhonyServer/1.0 5224 Date: 23 Jan 1997 15:36:01 GMT 5225 Session: 12345678 5226 Range: npt=34.57-623.10 5228 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 5229 CSeq: 6 5230 User-Agent: PhonyClient/1.2 5231 Range: npt=34.57-623.10 5232 Session: 12345678 5234 M->C: RTSP/2.0 200 OK 5235 CSeq: 6 5236 Server: PhonyServer/1.0 5237 Date: 23 Jan 1997 15:36:01 GMT 5238 Session: 12345678 5239 Range: npt=34.57-623.10 5240 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 5241 ssrc=0D12F123:seq=12555;rtptime=6330012, 5242 url="rtsp://example.com/twister.3gp/trackID=1" 5243 ssrc=4F312DD8:seq=55021;rtptime=3132889 5245 17.2. Media on Demand (Unicast) 5247 An alternative example of media on demand with a bit more tweaks is 5248 the following. Client C requests a movie distributed from two 5249 different media servers A (tt audio.example.com) and V (tt 5250 video.example.com). The media description is stored on a web server 5251 W. The media description contains descriptions of the presentation 5252 and all its streams, including the codecs that are available, dynamic 5253 RTP payload types, the protocol stack, and content information such 5254 as language or copyright restrictions. It may also give an 5255 indication about the timeline of the movie. 5257 In this example, the client is only interested in the last part of 5258 the movie. 5260 C->W: GET /twister.sdp HTTP/1.1 5261 Host: www.example.com 5262 Accept: application/sdp 5264 W->C: HTTP/1.0 200 OK 5265 Date: 23 Jan 1997 15:35:06 GMT 5266 Content-Type: application/sdp 5267 Content-Length: 264 5268 Expires: 23 Jan 1998 15:35:06 GMT 5270 v=0 5271 o=- 2890844526 2890842807 IN IP4 192.0.2.5 5272 s=RTSP Session 5273 e=adm@example.com 5274 a=range:npt=0-1:49:34 5275 t=0 0 5276 m=audio 0 RTP/AVP 0 5277 a=control:rtsp://audio.example.com/twister/audio.en 5278 m=video 0 RTP/AVP 31 5279 a=control:rtsp://video.example.com/twister/video 5281 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0 5282 CSeq: 1 5283 User-Agent: PhonyClient/1.2 5284 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057", 5285 RTP/AVP/TCP;unicast;interleaved=0-1 5287 A->C: RTSP/2.0 200 OK 5288 CSeq: 1 5289 Session: 12345678 5290 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057"; 5291 src_addr="192.0.2.5:5000"/"192.0.2.5:5001" 5292 Date: 23 Jan 1997 15:35:12 GMT 5293 Server: PhonyServer/1.0 5294 Expires: 24 Jan 1997 15:35:12 GMT 5295 Cache-Control: public 5296 Accept-Ranges: NPT, SMPTE 5298 C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0 5299 CSeq: 1 5300 User-Agent: PhonyClient/1.2 5301 Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059", 5302 RTP/AVP/TCP;unicast;interleaved=0-1 5304 V->C: RTSP/2.0 200 OK 5305 CSeq: 1 5306 Session: 23456789 5307 Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059"; 5308 src_addr="192.0.2.5:5002"/"192.0.2.5:5003" 5309 Date: 23 Jan 1997 15:35:12 GMT 5310 Server: PhonyServer/1.0 5311 Cache-Control: public 5312 Expires: 24 Jan 1997 15:35:12 GMT 5313 Accept-Ranges: NPT, SMPTE 5315 C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0 5316 CSeq: 2 5317 User-Agent: PhonyClient/1.2 5318 Session: 23456789 5319 Range: smpte=0:10:00- 5321 V->C: RTSP/2.0 200 OK 5322 CSeq: 2 5323 Session: 23456789 5324 Range: smpte=0:10:00-1:49:23 5325 RTP-Info: url="rtsp://video.example.com/twister/video" 5326 ssrc=A17E189D:seq=12312232;rtptime=78712811 5327 Server: PhonyServer/2.0 5328 Date: 23 Jan 1997 15:35:13 GMT 5330 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0 5331 CSeq: 2 5332 User-Agent: PhonyClient/1.2 5333 Session: 12345678 5334 Range: smpte=0:10:00- 5336 A->C: RTSP/2.0 200 OK 5337 CSeq: 2 5338 Session: 12345678 5339 Range: smpte=0:10:00-1:49:23 5340 RTP-Info: url="rtsp://audio.example.com/twister/audio.en" 5341 ssrc=3D124F01:seq=876655;rtptime=1032181 5342 Server: PhonyServer/1.0 5343 Date: 23 Jan 1997 15:35:13 GMT 5345 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0 5346 CSeq: 3 5347 User-Agent: PhonyClient/1.2 5348 Session: 12345678 5350 A->C: RTSP/2.0 200 OK 5351 CSeq: 3 5352 Server: PhonyServer/1.0 5353 Date: 23 Jan 1997 15:36:52 GMT 5355 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0 5356 CSeq: 3 5357 User-Agent: PhonyClient/1.2 5358 Session: 23456789 5360 V->C: RTSP/2.0 200 OK 5361 CSeq: 3 5362 Server: PhonyServer/2.0 5363 Date: 23 Jan 1997 15:36:52 GMT 5365 Even though the audio and video track are on two different servers, 5366 may start at slightly different times, and may drift with respect to 5367 each other, the client can perform initial synchronize of the two 5368 media using RTP-Info and Range received in the PLAY responses. If 5369 the two servers are time synchronized the RTCP packets can also be 5370 used to maintain synchronization. 5372 17.3. Single Stream Container Files 5374 Some RTSP servers may treat all files as though they are "container 5375 files", yet other servers may not support such a concept. Because of 5376 this, clients needs to use the rules set forth in the session 5377 description for Request-URIs, rather than assuming that a consistent 5378 URI may always be used throughout. Below are an example of how a 5379 multi-stream server might expect a single-stream file to be served: 5381 C->S: DESCRIBE rtsp://foo.com/test.wav RTSP/2.0 5382 Accept: application/x-rtsp-mh, application/sdp 5383 CSeq: 1 5384 User-Agent: PhonyClient/1.2 5386 S->C: RTSP/2.0 200 OK 5387 CSeq: 1 5388 Content-base: rtsp://foo.com/test.wav/ 5389 Content-type: application/sdp 5390 Content-length: 148 5391 Server: PhonyServer/1.0 5392 Date: 23 Jan 1997 15:35:06 GMT 5393 Expires: 23 Jan 1997 17:00:00 GMT 5395 v=0 5396 o=- 872653257 872653257 IN IP4 192.0.2.5 5397 s=mu-law wave file 5398 i=audio test 5399 t=0 0 5400 a=control: * 5401 m=audio 0 RTP/AVP 0 5402 a=control:streamid=0 5404 C->S: SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/2.0 5405 Transport: RTP/AVP/UDP;unicast; 5406 dest_addr=":6970"/":6971";mode="PLAY" 5407 CSeq: 2 5408 User-Agent: PhonyClient/1.2 5410 S->C: RTSP/2.0 200 OK 5411 Transport: RTP/AVP/UDP;unicast;dest_addr=":6970"/":6971"; 5412 src_addr="192.0.2.5:6970"/"192.0.2.5:6971"; 5413 mode="PLAY";ssrc=EAB98712 5414 CSeq: 2 5415 Session: 2034820394 5416 Expires: 23 Jan 1997 16:00:00 GMT 5417 Server: PhonyServer/1.0 5418 Date: 23 Jan 1997 15:35:07 GMT 5420 C->S: PLAY rtsp://foo.com/test.wav/ RTSP/2.0 5421 CSeq: 3 5422 User-Agent: PhonyClient/1.2 5423 Session: 2034820394 5425 S->C: RTSP/2.0 200 OK 5426 CSeq: 3 5427 Server: PhonyServer/1.0 5428 Date: 23 Jan 1997 15:35:08 GMT 5429 Session: 2034820394 5430 Range: npt=0-600 5431 RTP-Info: url="rtsp://foo.com/test.wav/streamid=0" 5432 ssrc=0D12F123:seq=981888;rtptime=3781123 5434 Note the different URI in the SETUP command, and then the switch back 5435 to the aggregate URI in the PLAY command. This makes complete sense 5436 when there are multiple streams with aggregate control, but is less 5437 than intuitive in the special case where the number of streams is 5438 one. However the server has declared that the aggregated control URI 5439 in the SDP and therefore this is legal. 5441 In this case, it is also required that servers accept implementations 5442 that use the non-aggregated interpretation and use the individual 5443 media URI, like this: 5445 C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0 5446 CSeq: 3 5447 User-Agent: PhonyClient/1.2 5449 17.4. Live Media Presentation Using Multicast 5451 The media server M chooses the multicast address and port. Here, it 5452 is assumed that the web server only contains a pointer to the full 5453 description, while the media server M maintains the full description. 5455 C->W: GET /sessions.html HTTP/2.0 5456 Host: www.example.com 5458 W->C: HTTP/2.0 200 OK 5459 Content-Type: text/html 5461 5462 ... 5463 5465 ... 5466 5468 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0 5469 CSeq: 1 5470 Supported: play.basic, play.scale 5472 M->C: RTSP/2.0 200 OK 5473 CSeq: 1 5474 Content-Type: application/sdp 5475 Content-Length: 182 5476 Server: PhonyServer/1.0 5477 Date: 23 Jan 1997 15:35:06 GMT 5478 Supported: play.basic 5480 v=0 5481 o=- 2890844526 2890842807 IN IP4 192.0.2.5 5482 s=RTSP Session 5483 m=audio 3456 RTP/AVP 0 5484 c=IN IP4 224.2.0.1/16 5485 a=control: rtsp://live.example.com/concert/audio 5486 a=range:npt=0- 5488 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0 5489 CSeq: 2 5490 Transport: RTP/AVP;multicast 5492 M->C: RTSP/2.0 200 OK 5493 CSeq: 2 5494 Server: PhonyServer/1.0 5495 Date: 23 Jan 1997 15:35:06 GMT 5496 Transport: RTP/AVP;multicast;dest_addr="224.2.0.1:3456"/" 5497 224.2.0.1:3457";ttl=16 5498 Session: 0456804596 5499 Accept-Ranges: NPT, UTC 5501 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0 5502 CSeq: 3 5503 Session: 0456804596 5505 M->C: RTSP/2.0 200 OK 5506 CSeq: 3 5507 Server: PhonyServer/1.0 5508 Date: 23 Jan 1997 15:35:07 GMT 5509 Session: 0456804596 5510 Range:npt=1256- 5511 RTP-Info: url="rtsp://live.example.com/concert/audio" 5512 ssrc=0D12F123:seq=1473; rtptime=80000 5514 17.5. Capability Negotiation 5516 This examples illustrate how the client and server determines their 5517 capability to support a special feature, in this case "play.scale". 5518 The server, through the clients request and the included Supported 5519 header, learns the client supports RTSP 2.0, and also supports the 5520 playback time scaling feature of RTSP. The server's response 5521 contains the following feature related information to the client; it 5522 supports the basic playback (play.basic), the extended functionality 5523 of time scaling of content (play.scale), and one "example.com" 5524 proprietary feature (com.example.flight). The client also learns the 5525 methods supported (Public header) by the server for the indicated 5526 resource. 5528 C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0 5529 CSeq: 1 5530 Supported: play.basic, play.scale 5531 User-Agent: PhonyClient/1.2 5533 S->C: RTSP/2.0 200 OK 5534 CSeq: 1 5535 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 5536 Server: PhonyServer/2.0 5537 Supported: play.basic, play.scale, com.example.flight 5539 When the client sends its SETUP request it tells the server that it 5540 is requires support of the play.scale feature for this session by 5541 including the Require header. 5543 C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0 5544 CSeq: 3 5545 User-Agent: PhonyClient/1.2 5546 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057", 5547 RTP/AVP/TCP;unicast;interleaved=0-1 5548 Require: play.scale 5550 S->C: RTSP/2.0 200 OK 5551 CSeq: 3 5552 Session: 12345678 5553 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057"; 5554 src_addr="192.0.2.5:5000"/"192.0.2.5:5001" 5555 Server: PhonyServer/2.0 5556 Accept-Ranges: NPT, SMPTE 5558 18. Security Framework 5560 The RTSP security framework consists of two high level components: 5561 the pure authentication mechanisms based on HTTP authentication, and 5562 the transport protection based on TLS, which is independent of RTSP. 5563 Because of the similarity in syntax and usage between RTSP servers 5564 and HTTP servers, the security for HTTP is re-used to a large extent. 5566 18.1. RTSP and HTTP Authentication 5568 RTSP and HTTP share common authentication schemes, and thus follow 5569 the same usage guidelines as specified in[RFC2617] and also in [H15]. 5570 Servers SHOULD implement both basic and digest [RFC2617] 5571 authentication. 5573 It should be stressed that using the HTTP authentication alone does 5574 not provide full control message security. Therefore, in 5575 environments requiring tighter security for the control messages, TLS 5576 SHOULD be used, see SectionSection 18.2. 5578 18.2. RTSP over TLS 5580 RTSP SHALL follow the same guidelines with regards to TLS [RFC4346] 5581 usage as specified for HTTP, see [RFC2818]. RTSP over TLS is 5582 separated from unsecured RTSP both on URI level and port level. 5583 Instead of using the "rtsp" scheme identifier in the URI, the "rtsps" 5584 scheme identifier MUST be used to signal RTSP over TLS. If no port 5585 is given in a URI with the "rtsps" scheme, port 322 SHALL be used for 5586 TLS over TCP/IP. 5588 When a client tries to setup an insecure channel to the server (using 5589 the "rtsp" URI), and the policy for the resource requires a secure 5590 channel, the server SHALL redirect the client to the secure service 5591 by sending a 301 redirect response code together with the correct 5592 Location URI (using the "rtsps" scheme). A user or client MAY 5593 upgrade a non secured URI to a secured by changing the scheme from 5594 "rtsp" to "rtsps". A server implementing support for "rtsps" SHALL 5595 allow this. 5597 It should be noted that TLS allows for mutual authentication (when 5598 using both server and client certificates). Still, one of the more 5599 common way TLS is used is to only provide server side authentication 5600 (often to avoid client certificates). TLS is then used in addition 5601 to HTTP authentication, providing transport security and server 5602 authentication, while HTTP Authentication is used to authenticate the 5603 client. 5605 RTSP includes the possibility to keep a TCP session up between the 5606 client and server, throughout the RTSP session lifetime. It may be 5607 convenient to keep the TCP session, not only to save the extra setup 5608 time for TCP, but also the extra setup time for TLS (even if TLS uses 5609 the resume function, there will be almost two extra roundtrips). 5610 Still, when TLS is used, such behavior introduces extra active state 5611 in the server, not only for TCP and RTSP, but also for TLS. This may 5612 increase the vulnerability to DoS attacks. 5614 In addition to these recommendations, Section Section 18.3 gives 5615 further recommendations of TLS usage with proxies. 5617 18.3. Security and Proxies 5619 The nature of a proxy is often to act as a "man-in-the-middle", while 5620 security is often about preventing the existence of a "man-in-the- 5621 middle". This section provides the clients with the possibility to 5622 use proxies even when applying secure transports (TLS). The client 5623 needs to select between using the procedure specified below or using 5624 a TLS connection directly (by-passing any proxies) to the server. 5625 The choice may be dependent on policies. 5627 There are basically two categories of proxies, the transparent 5628 proxies (of which the client is not aware) and the non-transparent 5629 proxies (of which the client is aware). An infrastructure based on 5630 proxies requires that the trust model is such that both client and 5631 servers can trust the proxies to handle the RTSP messages correctly. 5632 To be able to trust a proxy, the client and server also needs to be 5633 aware of the proxy. Hence, transparent proxies cannot generally be 5634 seen as trusted and will not work well with security (unless they 5635 work only at transport layer). In the rest of this section any 5636 reference to proxy will be to a non-transparent proxy, which inspects 5637 or manipulate the RTSP messages. 5639 HTTP Authentication is built on the assumption of proxies and can 5640 provide user-proxy authentication and proxy-proxy/server 5641 authentication in addition to the client-server authentication. 5643 When TLS is applied and a proxy is used, the client will connect to 5644 the proxy's address when connecting to any RTSP server. This implies 5645 that for TLS, the client will authenticate the proxy server and not 5646 the end server. Note that, when the client checks the server 5647 certificate in TLS, it MUST check the proxy's identity (URI or 5648 possibly other known identity) against the proxy's identity as 5649 presented in the proxy's Certificate message. 5651 The problem is that for a proxy accepted by the client, the proxy 5652 needs to be provided information on which grounds it should accept 5653 the next-hop certificate. Both the proxy and the user may have rules 5654 for this, and the user have the possibility to select the desired 5655 behavior. To handle this case, the Accept-Credentials header (See 5656 SectionSection 14.2) is used, where the client can force the proxy/ 5657 proxies to relay back the certificates used by any intermediate 5658 proxies as well as the server. Given the assumption that the proxies 5659 are viewed as trusted, it gives the user a possibility to enforce 5660 policies to each trusted proxy of whether it should accept the next 5661 entity in the chain. 5663 A proxy MUST use TLS for the next hop if the RTSP request includes a 5664 "rtsps" URI. TLS MAY be applied on intermediate links (e.g. between 5665 client and proxy, or between proxy and proxy), even if the resource 5666 and the end server does not require to use it. 5668 18.3.1. Accept-Credentials 5670 The Accept-Credentials header can be used by the client to distribute 5671 simple authorization policies to intermediate proxies. The client 5672 includes the Accept-Credentials header to dictate how the proxy 5673 treats the server/next proxy certificate. There are currently three 5674 methods defined: 5676 Any, which means that the proxy (or proxies) SHALL accept whatever 5677 certificate presented. This is of course not a recommended 5678 option to use, but may be useful in certain circumstances (such 5679 as testing). 5681 Proxy, which means that the proxy (or proxies) MUST use its own 5682 policies to validate the certificate and decide whether to 5683 accept it or not. This is convenient in cases where the user 5684 has a strong trust relation with the proxy. Reason why a 5685 strong trust relation may exist are; personal/company proxy, 5686 proxy has a out-of-band policy configuration mechanism. 5688 User, which means that the proxy (or proxies) MUST send credential 5689 information about the next hop to the client for authorization. 5690 The client can then decide whether the proxy should accept the 5691 certificate or not. See section Section 18.3.2 for further 5692 details. 5694 If the Accept-Credentials header is not included in the RTSP request 5695 from the client, then the "Proxy" method SHALL be used as default. 5696 If an other method than the "Proxy" is to be used, then the Accept- 5697 Credentials header SHALL be included in all of the RTSP request from 5698 the client. This is because it cannot be assumed that the proxy 5699 always keeps the TLS state or the users previously preference between 5700 different RTSP messages (in particular if the time interval between 5701 the messages is long). 5703 With the "Any" and "Proxy" methods the proxy will apply the policy as 5704 defined for respectively method. If the policy do not accept the 5705 credentials of the next hop, the entity SHALL respond with a message 5706 using status code 471 (Connection Credentials not accepted). 5708 An RTSP request in the direction server to client MUST NOT include 5709 the Accept-Credential header. As for the non-secured communication, 5710 the possibility for these request depends on the presence of a client 5711 established connection. However if the server to client request is 5712 in relation to a session established over a TLS secured channel, if 5713 MUST be sent in a TLS secured connection. That secured connection 5714 MUST also be the one used by the last client to server request. If 5715 no such transport connection exist at the time when the server desire 5716 to send the request, it silently fails. 5718 Further policies MAY be defined and registered, but should be done so 5719 with caution. 5721 18.3.2. User approved TLS procedure 5723 For the "User" method each proxy MUST perform the the following 5724 procedure for each RTSP request: 5726 o Setup the TLS session to the next hop if not already present (i.e. 5727 run the TLS handshake, but do not send the RTSP request). 5729 o Extract the peer certificate for the TLS session. 5731 o Check if a matching identity and hash of the peer certificate is 5732 present in the Accept-Credentials header. If present, send the 5733 message to the next hop, and conclude these procedures. If not, 5734 go to the next step. 5736 o The proxy responds to the RTSP request with a 470 or 407 response 5737 code. The 407 response code MAY be used when the proxy requires 5738 both user and connection authorization from user or client. In 5739 this message the proxy SHALL include a Connection-Credentials 5740 header, see section Section 14.12 with the next hop's identity and 5741 certificate. 5743 The client MUST upon receiving a 470 or 407 response with Connection- 5744 Credentials header take the decision on whether to accept the 5745 certificate or not (if it cannot do so, the user SHOULD be 5746 consulted). If the certificate is accepted, the client has to again 5747 send the RTSP request. In that request the client has to include the 5748 Accept-Credentials header including the hash over the DER encoded 5749 certificate for all trusted proxies in the chain. 5751 Example: 5753 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 5754 CSeq: 2 5755 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 5756 "192.0.2.5:4589" 5758 P->C: RTSP/2.0 470 Connection Authorization Required 5759 CSeq: 2 5760 Connection-Credentials: "rtsps://test.example.org"; 5761 MIIDNTCCAp... 5763 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 5764 CSeq: 2 5765 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 5766 "192.0.2.5:4589" 5767 Accept-Credentials: User "rtsps://test.example.org" ; 5768 dPYD 7txp oGTb AqZZ QJ+v aeOk yH4= ... 5770 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 5771 CSeq: 2 5772 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 5773 "192.0.2.5:4589" 5774 Via: RTSP/2.0 proxy.example.org 5775 Accept-Credentials: User "rtsps://test.example.org" ; 5776 dPYD 7txp oGTb AqZZ QJ+v aeOk yH4= ... 5778 One implication of this process is that the connection for secured 5779 RTSP messages may take significantly more round-trip times for the 5780 first message. An complete extra message exchange between the proxy 5781 connecting to the next hop and the client results because of the 5782 process for approval for each hop. However after the first message 5783 exchange the remaining message should not be delayed, if each message 5784 contains the chain of proxies that the requestor accepts. The 5785 procedure of including the credentials in each request rather than 5786 building state in each proxy, avoids the need for revocation 5787 procedures. 5789 19. Syntax 5791 The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF) 5792 as defined in RFC 4234 [RFC4234]. It uses the basic definitions 5793 present in RFC 4234. 5795 Please note that ABNF strings, e.g. "Accept", are case insensitive 5796 as specified in section 2.3 of RFC 4234. 5798 19.1. Base Syntax 5800 RTSP header field values can be folded onto multiple lines if the 5801 continuation line begins with a space or horizontal tab. All linear 5802 white space, including folding, has the same semantics as SP. A 5803 recipient MAY replace any linear white space with a single SP before 5804 interpreting the field value or forwarding the message downstream. 5805 This is intended to behave exactly as HTTP/1.1 as described in RFC 5806 2616 [RFC2616]. The SWS construct is used when linear white space is 5807 optional, generally between tokens and separators. 5809 To separate the header name from the rest of value, a colon is used, 5810 which, by the above rule, allows whitespace before, but no line 5811 break, and whitespace after, including a linebreak. The HCOLON 5812 defines this construct. 5814 OCTET = %x00-FF ; any 8-bit sequence of data 5815 CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127) 5816 UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z" 5817 LOALPHA = %x61-7A ;any US-ASCII lowercase letter "a".."z" 5818 ALPHA = UPALPHA / LOALPHA 5819 DIGIT = %x30-39 ; any US-ASCII digit "0".."9" 5820 CTL = %x00-1F / %x7F ; any US-ASCII control character 5821 ; (octets 0 - 31) and DEL (127) 5822 CR = %x0D ; US-ASCII CR, carriage return (13 5823 LF = %x0A ; US-ASCII LF, linefeed (10) 5824 SP = %x20 ; US-ASCII SP, space (32) 5825 HT = %x09 ; US-ASCII HT, horizontal-tab (9) 5826 DQ = %x22 ; US-ASCII double-quote mark (34) 5827 BACKSLASH = %x5C ; US-ASCII backslash (92) 5828 CRLF = CR LF 5829 LWS = [CRLF] 1*( SP / HT ) 5830 SWS = [LWS] ; sep whitespace 5831 HCOLON = *( SP / HT ) ":" SWS 5832 TEXT = %x20-7D / %x80-FF ; any OCTET except CTLs 5833 tspecials = "(" / ")" / "<" / ">" / "@" 5834 / "," / ";" / ":" / BACKSLASH / DQ 5835 / "/" / "" / "" / "?" / "=" 5836 / "" / "" / SP / HT 5837 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 5838 / %x41-5A / %x5E-7A / %x7C / %x7E) 5839 ; 1* 5840 quoted-string = ( DQ *qdtext DQ ) 5841 qdtext = %x20-21 / %x23-7D / %x80-FF ; any TEXT except <"> 5842 quoted-pair = BACKSLASH CHAR 5843 ctext = %x20-27 / %x2A-7D 5844 / %x80-FF ; any OCTET except CTLs, "(" and ")" 5845 generic-param = token [ EQUAL gen-value ] 5846 gen-value = token / host / quoted-string 5848 safe = "$" / "-" / "_" / "." / "+" 5849 extra = "!" / "*" / "'" / "(" / ")" / "," 5850 rtsp-extra = "!" / "*" / "'" / "(" / ")" 5852 HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 5853 / "a" / "b" / "c" / "d" / "e" / "f" 5854 LHEX = DIGIT / %x61-66 ;lowercase a-f 5855 reserved = ";" / "/" / "?" / ":" / "@" / "" / "=" 5857 unreserved = ALPHA / DIGIT / safe / extra 5858 rtsp-unreserved = ALPHA / DIGIT / safe / rtsp-extra 5860 base64 = *base64-unit [base64-pad] 5861 base64-unit = 4base64-char 5862 base64-pad = (2base64-char "==") / (3base64-char "=") 5863 base64-char = ALPHA / DIGIT / "+" / "/" 5864 SLASH = SWS "/" SWS ; slash 5865 EQUAL = SWS "=" SWS ; equal 5866 LPAREN = SWS "(" SWS ; left parenthesis 5867 RPAREN = SWS ")" SWS ; right parenthesis 5868 COMMA = SWS "," SWS ; comma 5869 SEMI = SWS ";" SWS ; semicolon 5870 COLON = SWS ":" SWS ; colon 5871 LDQUOT = SWS DQ ; open double quotation mark 5872 RDQUOT = DQ SWS ; close double quotation mark 5873 RAQUOT = ">" SWS ; right angle quote 5874 LAQUOT = SWS "<" ; left angle quote 5876 TEXT-UTF8char = %x21-7E / UTF8-NONASCII 5877 UTF8-NONASCII = %xC0-DF 1UTF8-CONT 5878 / %xE0-EF 2UTF8-CONT 5879 / %xF0-F7 3UTF8-CONT 5880 / %xF8-FB 4UTF8-CONT 5881 / %xFC-FD 5UTF8-CONT 5882 UTF8-CONT = %x80-BF 5884 19.2. RTSP Protocol Definition 5886 19.2.1. Generic Protocol elements 5887 RTSP-IRI = schemes ":" IRI-rest 5888 IRI-rest = ihier-part [ "?" iquery ] [ "#" ifragment ] 5889 ihier-part = "//" iauthority ipath-abempty 5890 RTSP-IRI-ref = RTSP-IRI / irelative-ref 5891 irelative-ref = irelative-part [ "?" iquery ] [ "#" ifragment ] 5892 irelative-part = "//" iauthority ipath-abempty 5893 / ipath-absolute 5894 / ipath-noscheme 5895 / ipath-empty 5897 iauthority = < As defined in RFC 3987> 5898 ipath = ipath-abempty ; begins with "/" or is empty 5899 / ipath-absolute ; begins with "/" but not "//" 5900 / ipath-noscheme ; begins with a non-colon segment 5901 / ipath-rootless ; begins with a segment 5902 / ipath-empty ; zero characters 5904 ipath-abempty = *( "/" isegment ) 5905 ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ] 5906 ipath-noscheme = isegment-nz-nc *( "/" isegment ) 5907 ipath-rootless = isegment-nz *( "/" isegment ) 5908 ipath-empty = 0 5910 isegment = *ipchar [";" *ipchar] 5911 isegment-nz = 1*ipchar [";" *ipchar] 5912 / ";" *ipchar 5913 isegment-nz-nc = (1*ipchar-nc [";" *ipchar-nc]) 5914 / ";" *ipchar-nc 5915 ; non-zero-length segment without any colon ":" 5917 ipchar = iunreserved / pct-encoded / sub-delims / ":" / "@" 5918 ipchar-nc = iunreserved / pct-encoded / sub-delims / "@" 5920 iquery = < As defined in RFC 3987> 5921 ifragment = < As defined in RFC 3987> 5922 iunreserved = < As defined in RFC 3987> 5923 pct-encoded = < As defined in RFC 3987> 5924 RTSP-URI = schemes ":" URI-rest 5925 RTSP-URI-Ref = RTSP-URI / RTSP-Relative 5926 schemes = "rtsp" / "rtsps" / scheme 5927 scheme = < As defined in RFC 3986> 5928 URI-rest = hier-part [ "?" query ] 5929 hier-part = "//" authority path-abempty 5931 RTSP-Relative = relative-part [ "?" query ] 5932 relative-part = "//" authority path-abempty 5933 / path-absolute 5934 / path-noscheme 5935 / path-empty 5937 authority = < As defined in RFC 3986> 5938 query = < As defined in RFC 3986> 5940 path = path-abempty ; begins with "/" or is empty 5941 / path-absolute ; begins with "/" but not "//" 5942 / path-noscheme ; begins with a non-colon segment 5943 / path-rootless ; begins with a segment 5944 / path-empty ; zero characters 5946 path-abempty = *( "/" segment ) 5947 path-absolute = "/" [ segment-nz *( "/" segment ) ] 5948 path-noscheme = segment-nz-nc *( "/" segment ) 5949 path-rootless = segment-nz *( "/" segment ) 5950 path-empty = 0 5952 segment = *pchar [";" *pchar] 5953 segment-nz = ( 1*pchar [";" *pchar]) / (";" *pchar) 5954 segment-nz-nc = ( 1*pchar-nc [";" *pchar-nc]) / (";" *pchar-nc) 5955 ; non-zero-length segment without any colon ":" 5957 pchar = unreserved / pct-encoded / sub-delims / ":" / "@" 5958 pchar-nc = unreserved / pct-encoded / sub-delims / "@" 5960 sub-delims = "!" / "" / "" / "'" / "(" / ")" 5961 / "*" / "+" / "," / "=" 5963 smpte-range = smpte-type "=" smpte-range-spec 5964 {rm ;Section ref{sec:smpte 5965 smpte-range-spec = ( smpte-time "-" [ smpte-time ] ) 5966 / ( "-" smpte-time ) 5967 smpte-type = "smpte" / "smpte-30-drop" 5968 / "smpte-25" / smpte-type-extension 5969 {rm ; other timecodes may be added 5970 smpte-type-extension = token 5971 smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT 5972 [ ":" 1*2DIGIT [ "." 1*2DIGIT ] ] 5974 npt-range = "npt=" npt-range-spec 5975 npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time ) 5976 npt-time = "now" / npt-sec / npt-hhmmss 5977 npt-sec = 1*DIGIT [ "." *DIGIT ] 5978 npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] 5979 npt-hh = 1*DIGIT ; any positive number 5980 npt-mm = 1*2DIGIT ; 0-59 5981 npt-ss = 1*2DIGIT ; 0-59 5983 utc-range = "clock=" utc-range-spec 5984 utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time ) 5985 utc-time = utc-date "T" utc-clock "Z" 5986 utc-date = 8DIGIT 5987 utc-clock = 6DIGIT [ "." fraction ] 5988 fraction = 1*DIGIT 5990 feature-tag = token 5992 session-id = 8*( ALPHA / DIGIT / safe ) 5994 extension-header = header-name HCOLON header-value 5995 header-name = token 5996 header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) 5998 19.2.2. Message Syntax 5999 RTSP-message = Request / Response ;RTSP/2.0 messages 6001 Request = Request-Line 6002 *(general-header 6003 / request-header 6004 / entity-header ) 6005 CRLF 6006 [ message-body ] 6008 Response = Status-Line 6009 *( general-header 6010 / response-header 6011 / entity-header ) 6012 CRLF 6013 [ message-body ] 6015 Request-Line = Method SP Request-URI SP RTSP-Version CRLF 6017 Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF 6019 Method = "DESCRIBE" 6020 / "GET_PARAMETER" 6021 / "OPTIONS" 6022 / "PAUSE" 6023 / "PLAY" 6024 / "REDIRECT" 6025 / "SETUP" 6026 / "SET_PARAMETER" 6027 / "TEARDOWN" 6028 / extension-method 6030 extension-method = token 6032 Request-URI = "*" / RTSP-URI 6033 RTSP-Version = "RTSP/" 1*DIGIT "." 1*DIGIT 6035 message-body = 1*OCTET 6037 Status-Code = "100" ; Continue 6038 / "200" ; OK 6039 / "300" ; Multiple Choices 6040 / "301" ; Moved Permanently 6041 / "302" ; Found 6042 / "303" ; See Other 6043 / "304" ; Not Modified 6044 / "305" ; Use Proxy 6045 / "400" ; Bad Request 6046 / "401" ; Unauthorized 6047 / "402" ; Payment Required 6048 / "403" ; Forbidden 6049 / "404" ; Not Found 6050 / "405" ; Method Not Allowed 6051 / "406" ; Not Acceptable 6052 / "407" ; Proxy Authentication Required 6053 / "408" ; Request Time-out 6054 / "410" ; Gone 6055 / "411" ; Length Required 6056 / "412" ; Precondition Failed 6057 / "413" ; Request Entity Too Large 6058 / "414" ; Request-URI Too Large 6059 / "415" ; Unsupported Media Type 6060 / "451" ; Parameter Not Understood 6061 / "452" ; reserved 6062 / "453" ; Not Enough Bandwidth 6063 / "454" ; Session Not Found 6064 / "455" ; Method Not Valid in This State 6065 / "456" ; Header Field Not Valid for Resource 6066 / "457" ; Invalid Range 6067 / "458" ; Parameter Is Read-Only 6068 / "459" ; Aggregate operation not allowed 6069 / "460" ; Only aggregate operation allowed 6070 / "461" ; Unsupported Transport 6071 / "462" ; Destination Unreachable 6072 / "463" ; Destination Prohibited 6073 / "464" ; Data Transport Not Ready Yet 6074 / "470" ; Connection Authorization Required 6075 / "471" ; Connection Credentials not accepted 6076 / "500" ; Internal Server Error 6077 / "501" ; Not Implemented 6078 / "502" ; Bad Gateway 6079 / "503" ; Service Unavailable 6080 / "504" ; Gateway Time-out 6081 / "505" ; RTSP Version not supported 6082 / "551" ; Option not supported 6083 / extension-code 6085 extension-code = 3DIGIT 6087 Reason-Phrase = *TEXT 6088 general-header 6089 = Cache-Control 6090 / Connection 6091 / CSeq 6092 / Date 6093 / Proxy-Supported 6094 / Supported 6095 / Timestamp 6096 / Via 6097 / extension-header 6099 request-header 6100 = Accept 6101 / Accept-Credentials 6102 / Accept-Encoding 6103 / Accept-Language 6104 / Authorization 6105 / Bandwidth 6106 / Blocksize 6107 / From 6108 / If-Match 6109 / If-Modified-Since 6110 / If-None-Match 6111 / Proxy-Require 6112 / Range 6113 / Referer 6114 / Require 6115 / Scale 6116 / Session 6117 / Speed 6118 / Supported 6119 / Transport 6120 / User-Agent 6121 / extension-header 6123 response-header = Accept-Credentials 6124 / Accept-Ranges 6125 / Connection-Credentials 6126 / ETag 6127 / Location 6128 / Proxy-Authenticate 6129 / Public 6130 / Range 6131 / Retry-After 6132 / RTP-Info 6133 / Scale 6134 / Session 6135 / Server 6136 / Speed 6137 / Transport 6138 / Unsupported 6139 / Vary 6140 / WWW-Authenticate 6141 / extension-header 6143 entity-header 6144 = Allow 6145 / Content-Base 6146 / Content-Encoding 6147 / Content-Language 6148 / Content-Length 6149 / Content-Location 6150 / Content-Type 6151 / Expires 6152 / Last-Modified 6153 / extension-header 6155 19.2.3. Header Syntax 6157 All header syntaxes not defined in this section are defined in 6158 section 14 of the HTTP 1.1 specification [RFC2616]. 6160 Accept = "Accept" HCOLON 6161 [ accept-range *(COMMA accept-range) ] 6162 accept-range = media-range *(SEMI accept-param) 6163 media-range = ( "*/*" 6164 / ( m-type SLASH "*" ) 6165 / ( m-type SLASH m-subtype ) 6166 ) *( SEMI m-parameter ) 6167 accept-param = ("q" EQUAL qvalue) / generic-param 6168 qvalue = ( "0" [ "." *3DIGIT ] ) 6169 / ( "1" [ "." *3("0") ] ) 6171 Accept-Credentials = "Accept-Credentials" HCOLON cred-decision CRLF 6172 cred-decision = ("User" COMMA [cred-info]) 6173 / "Proxy" 6174 / "Any" 6175 / token ; For future extensions 6176 cred-info = cred-info-data *(COMMA cred-info-data) 6178 cred-info-data = DQ RTSP-URI DQ SEMI hash-alg SEMI base64 6179 hash-alg = "sha-1" / extension-alg 6180 extension-alg = token 6181 Accept-Encoding = "Accept-Encoding" HCOLON 6182 [ encoding *(COMMA encoding) ] 6183 encoding = codings *(SEMI accept-param) 6184 codings = content-coding / "*" 6185 content-coding = token 6186 Accept-Language = "Accept-Language" HCOLON 6187 [ language *(COMMA language) ] 6188 language = language-range *(SEMI accept-param) 6189 language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" ) 6190 Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges CRLF 6191 acceptable-ranges = (range-unit *(COMMA range-unit)) 6192 / "none" 6193 range-unit = "NPT" / "SMPTE" / "UTC" / extension-format 6194 extension-format = token 6195 Allow = "Allow" HCOLON [Method *(COMMA Method)] 6197 Authorization = "Authorization" HCOLON credentials 6198 credentials = ("Digest" LWS digest-response) 6199 / other-response 6200 digest-response = dig-resp *(COMMA dig-resp) 6201 dig-resp = username / realm / nonce / digest-uri 6202 / dresponse / algorithm / cnonce 6203 / opaque / message-qop 6204 / nonce-count / auth-param 6205 username = "username" EQUAL username-value 6206 username-value = quoted-string 6207 digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT 6208 digest-uri-value = Request-URI 6209 ; by HTTP/1.1 6210 message-qop = "qop" EQUAL qop-value 6211 cnonce = "cnonce" EQUAL cnonce-value 6212 cnonce-value = nonce-value 6213 nonce-count = "nc" EQUAL nc-value 6214 nc-value = 8LHEX 6215 dresponse = "response" EQUAL request-digest 6216 request-digest = LDQUOT 32LHEX RDQUOT 6217 auth-param = auth-param-name EQUAL 6218 ( token / quoted-string ) 6220 auth-param-name = token 6221 other-response = auth-scheme LWS auth-param 6222 *(COMMA auth-param) 6223 auth-scheme = token 6225 Bandwidth = "Bandwidth" HCOLON 1*DIGIT CRLF 6227 Blocksize = "Blocksize" HCOLON 1*DIGIT CRLF 6229 Cache-Control = "Cache-Control" HCOLON cache-directive CRLF 6230 *(COMMA cache-directive) 6231 cache-directive = cache-rqst-directive 6232 / cache-rspns-directive 6234 cache-rqst-directive = "no-cache" 6235 / "max-stale" [EQUAL delta-seconds] 6236 / "min-fresh" EQUAL delta-seconds 6237 / "only-if-cached" 6238 / cache-extension 6240 cache-rspns-directive = "public" 6241 / "private" 6242 / "no-cache" 6243 / "no-transform" 6244 / "must-revalidate" 6245 / "proxy-revalidate" 6246 / "max-age" EQUAL delta-seconds 6247 / cache-extension 6249 cache-extension = token [EQUAL (token / quoted-string)] 6250 delta-seconds = 1*DIGIT 6252 Connection-Creds = "Connection-Credentials" HCOLON cred-info CRLF 6254 Connection = "Connection" HCOLON (connection-token) 6255 *(COMMA connection-token) CRLF 6256 connection-token = token 6258 Content-Base = "Content-Base" HCOLON RTSP-URI-Ref CRLF 6259 Content-Encoding = "Content-Encoding" HCOLON 6260 content-coding *(COMMA content-coding) 6261 Content-Language = "Content-Language" HCOLON 6262 language-tag *(COMMA language-tag) 6263 language-tag = primary-tag *( "-" subtag ) 6264 primary-tag = 1*8ALPHA 6265 subtag = 1*8ALPHA 6266 Content-Length = "Content-Length" HCOLON 1*DIGIT 6267 Content-Location = "Content-Location" HCOLON RTSP-URI-Ref 6268 Content-Type = ( "Content-Type" / "c" ) HCOLON media-type 6269 media-type = m-type SLASH m-subtype *(SEMI m-parameter) 6270 m-type = discrete-type / composite-type 6271 discrete-type = "text" / "image" / "audio" / "video" 6272 / "application" / extension-token 6273 composite-type = "message" / "multipart" / extension-token 6274 extension-token = ietf-token / x-token 6275 ietf-token = token 6276 x-token = "x-" token 6277 m-subtype = extension-token / iana-token 6278 iana-token = token 6279 m-parameter = m-attribute EQUAL m-value 6280 m-attribute = token 6281 m-value = token / quoted-string 6283 CSeq = "Cseq" HCOLON 1*DIGIT CRLF 6284 Date = "Date" HCOLON RTSP-date 6285 RTSP-date = rfc1123-date ; HTTP-date 6286 rfc1123-date = wkday "," SP date1 SP time SP "GMT" 6287 date1 = 2DIGIT SP month SP 4DIGIT 6288 ; day month year (e.g., 02 Jun 1982) 6289 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 6290 ; 00:00:00 - 23:59:59 6291 wkday = "Mon" / "Tue" / "Wed" 6292 / "Thu" / "Fri" / "Sat" / "Sun" 6293 month = "Jan" / "Feb" / "Mar" / "Apr" 6294 / "May" / "Jun" / "Jul" / "Aug" 6295 / "Sep" / "Oct" / "Nov" / "Dec" 6297 ETag = "ETag" HCOLON entity-tag 6298 Expires = "Expires" HCOLON delta-seconds 6299 From = "From" HCOLON from-spec 6300 from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) 6301 name-addr = [ display-name ] LAQUOT addr-spec RAQUOT 6302 addr-spec = RTSP-URI / absolute-URI 6303 absolute-URI = < As defined in RFC 3986> 6304 display-name = *(token LWS)/ quoted-string 6305 from-param = tag-param / generic-param 6306 tag-param = "tag" EQUAL token 6307 If-Match = "If-Match" HCOLON ( "*" / entity-tag-list) 6308 entity-tag-list = entity-tag *(COMMA entity-tag) 6309 entity-tag = [ weak ] opaque-tag 6310 weak = "W/" 6311 opaque-tag = quoted-string 6312 If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date 6313 If-None-Match = "If-None-Match" HCOLON ("*" / entity-tag-list) 6314 Last-Modified = "Last-Modified" HCOLON RTSP-date 6315 Location = "Location" HCOLON RTSP-URI 6317 Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge 6318 challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) 6319 / other-challenge 6320 other-challenge = auth-scheme LWS auth-param 6321 *(COMMA auth-param) 6322 digest-cln = realm / domain / nonce 6323 / opaque / stale / algorithm 6324 / qop-options / auth-param 6325 realm = "realm" EQUAL realm-value 6326 realm-value = quoted-string 6327 domain = "domain" EQUAL LDQUOT URI 6328 *( 1*SP URI ) RDQUOT 6329 URI = RTSP-URI / RTSP-URI-Ref 6330 nonce = "nonce" EQUAL nonce-value 6331 nonce-value = quoted-string 6332 opaque = "opaque" EQUAL quoted-string 6333 stale = "stale" EQUAL ( "true" / "false" ) 6334 algorithm = "algorithm" EQUAL ("MD5" / "MD5-sess" / token) 6335 qop-options = "qop" EQUAL LDQUOT qop-value 6336 *("," qop-value) RDQUOT 6337 qop-value = "auth" / "auth-int" / token 6338 Proxy-Require = "Proxy-Require" HCOLON feature-tag CRLF 6339 *(COMMA feature-tag) 6341 Proxy-Supported = "Proxy-Supported" HCOLON feature-tag 6342 *(COMMA feature-tag) CRLF 6344 Public = "Public" HCOLON Method *(COMMA Method) CRLF 6346 Range = "Range" HCOLON ranges-list [exec-time] CRLF 6347 ranges-list = ranges-spec *(COMMA ranges-spec) 6348 exec-time = SEMI "time" EQUAL utc-time 6349 ranges-spec = npt-range / utc-range / smpte-range 6350 / range-ext 6351 range-ext = extension-format "=" range-value 6352 range-value = 1*(rtsp-unreserved / quoted-string / ":" ) 6354 Referer = "Referer" HCOLON RTSP-URI-Ref 6355 Require = "Require" HCOLON feature-tag-list CRLF 6356 feature-tag-list = feature-tag *(COMMA feature-tag) 6357 RTP-Info = "RTP-Info" HCOLON rtsp-info-spec 6358 *(COMMA rtsp-info-spec) CRLF 6359 rtsp-info-spec = stream-url 1*ssrc-parameter 6360 stream-url = "url" EQUAL DQ RTSP-URI-Ref DQ 6361 ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON 6362 ri-parameter *(SEMI ri-parameter) 6363 ri-parameter = "seq" EQUAL 1*DIGIT 6364 / "rtptime" EQUAL 1*DIGIT 6366 Retry-After = "Retry-After" HCOLON delta-seconds 6367 [ comment ] *( SEMI retry-param ) 6368 retry-param = ("duration" EQUAL delta-seconds) 6369 / generic-param 6371 Scale = "Scale" HCOLON ["-"] 1*DIGIT [ "." *DIGIT ] CRLF 6373 Speed = "Speed" HCOLON 1*DIGIT [ "." *DIGIT ] CRLF 6375 Server = "Server" HCOLON ( product / comment ) 6376 *(LWS (product / comment)) CRLF 6377 product = token [SLASH product-version] 6378 product-version = token 6379 comment = LPAREN *( ctext / quoted-pair) RPAREN 6381 Session = "Session" HCOLON session-id 6382 [ SEMI "timeout" EQUAL delta-seconds ] CRLF 6384 Supported = "Supported" HCOLON [feature-tag-list] CRLF 6386 Timestamp = "Timestamp" HCOLON timestamp-value LWS [delay] 6387 timestamp-value = *DIGIT [ "." *DIGIT ] 6388 delay = *DIGIT [ "." *DIGIT ] 6390 Transport = "Transport" HCOLON transport-spec 6391 *(COMMA transport-spec) CRLF 6392 transport-spec = transport-id *tr-parameter 6393 transport-id = trans-id-rtp / other-trans 6394 trans-id-rtp = "RTP/" profile ["/" lower-transport] 6395 {rm ; no LWS is allowed inside transport-id 6396 other-trans = token *("/" token) 6398 profile = "AVP" / "SAVP" / "AVPF" / token 6399 lower-transport = "TCP" / "UDP" / token 6400 tr-parameter = SEMI ( "unicast" / "multicast" ) 6401 / SEMI "interleaved" EQUAL channel [ "-" channel ] 6402 / SEMI "append" 6403 / SEMI "ttl" EQUAL ttl 6404 / SEMI "layers" EQUAL 1*DIGIT 6405 / SEMI "ssrc" EQUAL ssrc *(SLASH ssrc) 6406 / SEMI "client_ssrc" EQUAL ssrc 6407 / SEMI "mode" EQUAL mode-spec 6408 / SEMI "dest_addr" EQUAL addr-list 6409 / SEMI "src_addr" EQUAL addr-list 6410 / SEMI trn-param-ext 6411 / SEMI "setup" EQUAL contrans-setup 6412 / SEMI "connection" EQUAL contrans-con 6413 contrans-setup = "active" / "passive" / "actpass" 6414 contrans-con = "new" / "existing" 6415 trn-param-ext = par-name EQUAL trn-par-value 6416 par-name = token 6417 trn-par-value = *(rtsp-unreserved / DQ *TEXT DQ) 6418 ttl = 1*3DIGIT ; 0 to 255 6419 ssrc = 8HEX 6420 channel = 1*3DIGIT 6421 mode-spec = ( DQ mode *(COMMA mode) DQ ) 6422 mode = "PLAY" / "RECORD" / token 6423 addr-list = quoted-addr *(SLASH quoted-addr) 6424 quoted-addr = DQ (host-port / extension-addr) DQ 6425 host-port = host [":" port] 6426 / ":" port 6427 extension-addr = 1*qdtext 6428 host = < As defined in RFC 3986> 6429 port = < As defined in RFC 3986> 6430 Unsupported & = & "Unsupported" HCOLON feature-tag-list CRLF 6432 User-Agent & = & "User-Agent" HCOLON ( product / comment ) 6433 & & 0*(LWS (product / comment)) CRLF 6435 Vary & = & "Vary" HCOLON ( "*" / field-name-list) 6436 field-name-list & = & field-name *(COMMA field-name) 6437 field-name & = & token 6438 Via & = & "Via" HCOLON via-parm *(COMMA via-parm) 6439 via-parm & = & sent-protocol LWS sent-by *( SEMI via-params ) 6440 via-params & = & via-ttl / via-maddr 6441 & / & via-received / via-branch 6442 & / & via-extension 6443 via-ttl & = & "ttl" EQUAL ttl 6444 via-maddr & = & "maddr" EQUAL host 6445 via-received & = & "received" EQUAL (IPv4address / IPv6address) 6446 IPv4address & =& < As defined in RFC 3986> 6447 IPv6address & =& < As defined in RFC 3986> 6448 via-branch & = & "branch" EQUAL token 6449 via-extension & = & generic-param 6450 sent-protocol & = & protocol-name SLASH protocol-version 6451 & & SLASH transport-prot 6452 protocol-name & = & "RTSP" / token 6453 protocol-version & = & token 6454 transport-prot & = & "UDP" / "TCP" / "TLS" / other-transport 6455 other-transport & = & token 6456 sent-by & = & host [ COLON port ] 6458 WWW-Authenticate & = & "WWW-Authenticate" HCOLON challenge 6460 19.3. SDP extension Syntax 6462 This section defines in ABNF the SDP extensions defined for RTSP. 6463 See section Appendix C for the definition of the extensions in text. 6465 control-attribute = "a=control:" *SP RTSP-URI 6467 a-range-def = "a=range:" ranges-spec CRLF 6469 a-etag-def = "a=etag:" entity-tag CRLF 6471 20. Security Considerations 6473 Because of the similarity in syntax and usage between RTSP servers 6474 and HTTP servers, the security considerations outlined in [H15] 6475 apply. Specifically, please note the following: 6477 Abuse of Server Log Information: RTSP and HTTP servers will 6478 presumably have similar logging mechanisms, and thus should be 6479 equally guarded in protecting the contents of those logs, thus 6480 protecting the privacy of the users of the servers. See 6481 [H15.1.1] for HTTP server recommendations regarding server 6482 logs. 6484 Transfer of Sensitive Information: There is no reason to believe 6485 that information transferred via RTSP may be any less sensitive 6486 than that normally transmitted via HTTP. Therefore, all of the 6487 precautions regarding the protection of data privacy and user 6488 privacy apply to implementors of RTSP clients, servers, and 6489 proxies. See [H15.1.2] for further details. 6491 Attacks Based On File and Path Names: Though RTSP URIs are opaque 6492 handles that do not necessarily have file system semantics, it 6493 is anticipated that many implementations will translate 6494 portions of the Request-URIs directly to file system calls. In 6495 such cases, file systems SHOULD follow the precautions outlined 6496 in [H15.5], such as checking for ".." in path components. 6498 Personal Information: RTSP clients are often privy to the same 6499 information that HTTP clients are (user name, location, etc.) 6500 and thus should be equally sensitive. See [H15.1] for further 6501 recommendations. 6503 Privacy Issues Connected to Accept Headers: Since may of the same 6504 "Accept" headers exist in RTSP as in HTTP, the same caveats 6505 outlined in [H15.1.4] with regards to their use should be 6506 followed. 6508 DNS Spoofing: Presumably, given the longer connection times 6509 typically associated to RTSP sessions relative to HTTP 6510 sessions, RTSP client DNS optimizations should be less 6511 prevalent. Nonetheless, the recommendations provided in 6512 [H15.3] are still relevant to any implementation which attempts 6513 to rely on a DNS-to-IP mapping to hold beyond a single use of 6514 the mapping. 6516 Location Headers and Spoofing: If a single server supports multiple 6517 organizations that do not trust each another, then it needs to 6518 check the values of Location and Content-Location header fields 6519 in responses that are generated under control of said 6520 organizations to make sure that they do not attempt to 6521 invalidate resources over which they have no authority. 6522 ([H15.4]) 6524 In addition to the recommendations in the current HTTP specification 6525 (RFC 2616 [RFC2616], as of this writing) and also of the previous 6526 RFC2068 [RFC2068], future HTTP specifications may provide additional 6527 guidance on security issues. 6529 The following are added considerations for RTSP implementations. 6531 Concentrated denial-of-service attack: The protocol offers the 6532 opportunity for a remote-controlled denial-of-service attack. 6533 See SectionSection 20.1. 6535 Session hijacking: Since there is no or little relation between a 6536 transport layer connection and an RTSP session, it is possible 6537 for a malicious client to issue requests with random session 6538 identifiers which would affect unsuspecting clients. The 6539 server SHOULD use a large, random and non-sequential session 6540 identifier to minimize the possibility of this kind of attack. 6541 For real session security, client authentication needs to be 6542 performed. 6544 Authentication: Servers SHOULD implement both basic and digest 6545 [RFC2617] authentication. In environments requiring tighter 6546 security for the control messages, the transport layer 6547 mechanism TLS (RFC 4346 [RFC4346]) SHOULD be used. 6549 Stream issues: RTSP only provides for stream control. Stream 6550 delivery issues are not covered in this section, nor in the 6551 rest of this draft. RTSP implementations will most likely rely 6552 on other protocols such as RTP, IP multicast, RSVP and IGMP, 6553 and should address security considerations brought up in those 6554 and other applicable specifications. 6556 Persistently suspicious behavior: RTSP servers SHOULD return error 6557 code 403 (Forbidden) upon receiving a single instance of 6558 behavior which is deemed a security risk. RTSP servers SHOULD 6559 also be aware of attempts to probe the server for weaknesses 6560 and entry points and MAY arbitrarily disconnect and ignore 6561 further requests clients which are deemed to be in violation of 6562 local security policy. 6564 Scope of Multicast: If RTSP is used to control the transmission of 6565 media onto a multicast network it is need to consider the scope 6566 that delivery has. RTSP supports the TTL Transport header 6567 parameter to indicate this scope. However such scope control 6568 is risk as it may be set to large and distribute media beyond 6569 the intended scope. 6571 TLS through proxies: If one uses the possibility to connect TLS in 6572 multiple legs (SectionSection 18.3 one really needs to be aware 6573 of the trust model. That procedure requires full faith and 6574 trust in all proxies that one allows to connect through. They 6575 are man in the middle and has access to all that goes on over 6576 the TLS connection. Thus it is important to consider if that 6577 trust model is acceptable in the actual application. 6579 20.1. Remote denial of Service Attack 6581 The attacker may initiate traffic flows to one or more IP addresses 6582 by specifying them as the destination in SETUP requests. While the 6583 attacker's IP address may be known in this case, this is not always 6584 useful in prevention of more attacks or ascertaining the attackers 6585 identity. Thus, an RTSP server MUST only allow client-specified 6586 destinations for RTSP-initiated traffic flows if the server has 6587 ensured that the specified destination address accepts receiving 6588 media through different security mechanisms. Security mechanism that 6589 are acceptable in an increased generality are; verification of the 6590 client's identity, either against a database of known users using 6591 RTSP authentication mechanisms (preferably digest authentication or 6592 stronger); a list of addresses that accept to be media destinations, 6593 especially considering user identity; and media path based 6594 verification. 6596 The server SHOULD NOT allow the destination field to be set unless a 6597 mechanism exists in the system to authorize the request originator to 6598 direct streams to the recipient. It is preferred that this 6599 authorization be performed by the media recipient (destination) 6600 itself and the credentials passed along to the server. However, in 6601 certain cases, such as when recipient address is a multicast group, 6602 or when the recipient is unable to communicate with the server in an 6603 out-of-band manner, this may not be possible. In these cases server 6604 may chose another method such as a server-resident authorization list 6605 to ensure that the request originator has the proper credentials to 6606 request stream delivery to the recipient. 6608 One solution that performs the necessary verification of acceptance 6609 of media suitable for unicast based delivery is the ICE based NAT 6610 traversal method described in [I-D.ietf-mmusic-rtsp-nat]. By using 6611 random passwords and username the probability of unintended 6612 indication as a valid media destination is very low. If the server 6613 include in its STUN requests a cookie (consisting of random material) 6614 that is the destination echo back the solution is also safe against 6615 having a off-path attacker being able to spoof the STUN checks. 6616 Leaving this solution vulnerable only to on-path attackers that can 6617 see the STUN requests go to the target of attack. 6619 For delivery to multicast addresses there is need for another 6620 solution which is not specified here. 6622 21. IANA Considerations 6624 This section sets up a number of registries for RTSP 2.0 that should 6625 be maintained by IANA. For each registry there is a description on 6626 what it is required to contain, what specification is needed when 6627 adding a entry with IANA, and finally the entries that this document 6628 needs to register. See also the section Section 1.6 "Extending 6629 RTSP". There is also an IANA registration of two SDP attributes. 6631 The sections describing how to register an item uses some of the 6632 requirements level described in RFC 2434 [RFC2434], namely "First 6633 Come, First Served", "Specification Required", and "Standards 6634 Action". 6636 A registration request to IANA MUST contain the following 6637 information: 6639 o A name of the item to register according to the rules specified by 6640 the intended registry. 6642 o Indication of who has change control over the feature (for 6643 example, IETF, ISO, ITU-T, other international standardization 6644 bodies, a consortium, a particular company or group of companies, 6645 or an individual); 6647 o A reference to a further description, if available, for example 6648 (in order of preference) an RFC, a published standard, a published 6649 paper, a patent filing, a technical report, documented source code 6650 or a computer manual; 6652 o For proprietary features, contact information (postal and email 6653 address); 6655 21.1. Feature-tags 6657 21.1.1. Description 6659 When a client and server try to determine what part and functionality 6660 of the RTSP specification and any future extensions that its counter 6661 part implements there is need for a namespace. This registry 6662 contains named entries representing certain functionality. 6664 The usage of feature-tags is explained in section Section 10 and 6665 Section 11.1. 6667 21.1.2. Registering New Feature-tags with IANA 6669 The registering of feature-tags is done on a first come, first served 6670 basis. 6672 The name of the feature MUST follow these rules: The name may be of 6673 any length, but SHOULD be no more than twenty characters long. The 6674 name MUST NOT contain any spaces, or control characters. The 6675 registration SHALL indicate if the feature-tag applies to clients, 6676 servers, or proxies only or any combinations of these. Any 6677 proprietary feature SHALL have as the first part of the name a vendor 6678 tag, which identifies the organization. 6680 21.1.3. Registered entries 6682 The following feature-tags are in this specification defined and 6683 hereby registered. The change control belongs to the IETF. 6685 play.basic: The minimal implementation for playback operations 6686 according to section Appendix D. Applies for both clients, 6687 servers and proxies. 6689 play.scale: Support of scale operations for media playback. Applies 6690 only for servers. 6692 play.speed: Support of the speed functionality for playback. 6693 Applies only for servers. 6695 21.2. RTSP Methods 6697 21.2.1. Description 6699 What a method is, is described in section Section 11. Extending the 6700 protocol with new methods allow for totally new functionality. 6702 21.2.2. Registering New Methods with IANA 6704 A new method MUST be registered through an IETF standard track 6705 document. The reason is that new methods may radically change the 6706 protocols behavior and purpose. 6708 A specification for a new RTSP method MUST consist of the following 6709 items: 6711 o A method name which follows the ABNF rules for methods. 6713 o A clear specification on what action and response a request with 6714 the method will result in. Which directions the method is used, 6715 C->S or S->C or both. How the use of headers, if any, modifies 6716 the behavior and effect of the method. 6718 o A list or table specifying which of the registered headers that 6719 are allowed to use with the method in request or/and response. 6721 o Describe how the method relates to network proxies. 6723 21.2.3. Registered Entries 6725 This specification, RFCXXXX, registers 9 methods: DESCRIBE, 6726 GETPARAMETER, OPTIONS, PAUSE, PLAY, REDIRECT, SETUP, SETPARAMETER, 6727 and TEARDOWN. 6729 21.3. RTSP Status Codes 6731 21.3.1. Description 6733 A status code is the three digit numbers used to convey information 6734 in RTSP response messages, seeSection 7. The number space is limited 6735 and care should be taken not to fill the space. 6737 21.3.2. Registering New Status Codes with IANA 6739 A new status code can only be registered by an IETF standards track 6740 document. A specification for a new status code MUST specify the 6741 following: 6743 o The requested number. 6745 o A description what the status code means and the expected behavior 6746 of the sender and receiver of the code. 6748 21.3.3. Registered Entries 6750 RFCXXX, registers the numbered status code defined in the ABNF entry 6751 "Status-Code" except "extension-code" in section Section 19.2.2. 6753 21.4. RTSP Headers 6755 21.4.1. Description 6757 By specifying new headers a method(s) can be enhanced in many 6758 different ways. An unknown header will be ignored by the receiving 6759 entity. If the new header is vital for a certain functionality, a 6760 feature-tag for the functionality can be created and demanded to be 6761 used by the counter-part with the inclusion of a Require header 6762 carrying the feature-tag. 6764 21.4.2. Registering New Headers with IANA 6766 A public available specification is required to register a header. 6767 The specification SHOULD be a standards document, preferable an IETF 6768 RFC. 6770 The specification MUST contain the following information: 6772 o The name of the header. 6774 o An ABNF specification of the header syntax. 6776 o A list or table specifying when the header may be used, 6777 encompassing all methods, their request or response, the direction 6778 (C->S or S->C). 6780 o How the header is to be handled by proxies. 6782 o A description of the purpose of the header. 6784 21.4.3. Registered entries 6786 All headers specified in section Section 14 in RFCXXXX are to be 6787 registered. 6789 Furthermore the following RTSP headers defined in other 6790 specifications are registered: 6792 o x-wap-profile defined in [3gpp-26234]. 6794 o x-wap-profile-diff defined in [3gpp-26234]. 6796 o x-wap-profile-warning defined in [3gpp-26234]. 6798 o x-predecbufsize defined in [3gpp-26234]. 6800 o x-initpredecbufperiod defined in [3gpp-26234]. 6802 o x-initpostdecbufperiod defined in [3gpp-26234]. 6804 o 3gpp-videopostdecbufsize defined in [3gpp-26234]. 6806 o 3GPP-Link-Char defined in [3gpp-26234]. 6808 o 3GPP-Adaptation defined in [3gpp-26234]. 6810 o 3GPP-QoE-Metrics defined in [3gpp-26234]. 6812 o 3GPP-QoE-Feedback defined in [3gpp-26234]. 6814 The use of "X-" is NOT RECOMMENDED but the above headers in the 6815 register list was defined prior to the clarification. 6817 21.5. Transport Header Registries 6819 The transport header contains a number of parameters which have 6820 possibilities for future extensions. Therefore registries for these 6821 needs to be defined. 6823 21.5.1. Transport Protocol Specification 6825 A registry for the parameter transport-protocol specification SHALL 6826 be defined with the following rules: 6828 o Registering require an public available standards specification. 6830 o A contact person or organization with address and email. 6832 o A value definition that are following the ABNF syntax definition. 6834 o A describing text that explains how the registered value are used 6835 in RTSP. 6837 This specification registers the following values: 6839 RTP/AVP: Use of the RTP[RFC3550] protocol for media transport in 6840 combination with the "RTP profile for audio and video 6841 conferences with minimal control"[RFC3551] over UDP. The usage 6842 is explained in RFC XXXX, appendix Appendix B.1. 6844 RTP/AVP/UDP: the same as RTP/AVP. 6846 RTP/AVPF: Use of the RTP[RFC3550] protocol for media transport in 6847 combination with the "Extended RTP Profile for RTCP-based 6848 Feedback (RTP/AVPF)"[RFC4585] over UDP. The usage is explained 6849 in RFC XXXX, appendix Appendix B.1. 6851 RTP/AVPF/UDP: the same as RTP/AVPF. 6853 RTP/SAVP: Use of the RTP[RFC3550] protocol for media transport in 6854 combination with the "The Secure Real-time Transport Protocol 6855 (SRTP)" [RFC3711] over UDP. The usage is explained in RFC 6856 XXXX, appendix Appendix B.1. 6858 RTP/SAVP/UDP: the same as RTP/SAVP. 6860 RTP/SAVPF: Use of the RTP[RFC3550] protocol for media transport in 6861 combination with the "[I-D.ietf-avt-profile-savpf] over UDP. 6862 The usage is explained in RFC XXXX, appendix Appendix B.1. 6864 RTP/SAVPF/UDP: the same as RTP/SAVPF. 6866 RTP/AVP/TCP: Use of the RTP[RFC3550] protocol for media transport in 6867 combination with the "RTP profile for audio and video 6868 conferences with minimal control"[RFC3551] over TCP. The usage 6869 is explained in RFC XXXX, appendix Appendix B.2.2. 6871 RTP/AVPF/TCP: Use of the RTP[RFC3550] protocol for media transport 6872 in combination with the "Extended RTP Profile for RTCP-based 6873 Feedback (RTP/AVPF)"[RFC4585] over TCP. The usage is explained 6874 in RFC XXXX, appendix Appendix B.2.2. 6876 RTP/SAVP/TCP: Use of the RTP[RFC3550] protocol for media transport 6877 in combination with the "The Secure Real-time Transport 6878 Protocol (SRTP)" [RFC3711] over TCP. The usage is explained in 6879 RFC XXXX, appendix Appendix B.2.2. 6881 RTP/SAVPF/TCP: Use of the RTP[RFC3550] protocol for media transport 6882 in combination with the "[I-D.ietf-avt-profile-savpf] over TCP. 6883 The usage is explained in RFC XXXX, appendix Appendix B.2.2. 6885 21.5.2. Transport modes 6887 A registry for the transport parameter mode SHALL be defined with the 6888 following rules: 6890 o Registering requires an IETF standard tracks document. 6892 o A contact person or organization with address and email. 6894 o A value definition that are following the ABNF token definition. 6896 o A describing text that explains how the registered value are used 6897 in RTSP. 6899 This specification registers 1 value: 6901 PLAY: See RFC XXXX. 6903 21.5.3. Transport Parameters 6905 A registry for parameters that may be included in the Transport 6906 header SHALL be defined with the following rules: 6908 o Registering required a Open Standards document. 6910 o A value definition that are following the ABNF token definition. 6912 o A describing text that explains how the registered value are used 6913 in RTSP. 6915 This specification registers all the transport parameters defined in 6916 SectionSection 14.45. 6918 21.6. Cache Directive Extensions 6920 There exist a number of cache directives which can be sent in the 6921 Cache-Control header. A registry for this cache directives SHALL be 6922 defined with the following rules: 6924 o Registering requires an IETF standard tracks document. 6926 o A registration is required to contain a contact person. 6928 o Name of the directive and a definition of the value, if any. 6930 o Specification if it is an request or response directive. 6932 o A describing text that explains how the cache directive is used 6933 for RTSP controlled media streams. 6935 This specification registers the following values: 6937 no-cache: 6939 public: 6941 private: 6943 no-transform: 6945 only-if-cached: 6947 max-stale: 6949 min-fresh: 6951 must-revalidate: 6953 proxy-revalidate: 6955 max-age: 6957 21.7. Accept-Credentials 6959 The security framework's TLS connection mechanism has two 6960 registerable entities. 6962 21.7.1. Accept-Credentials policies 6964 In sectionSection 18.3.1 three policies for how to handle 6965 certificates. Further policies may be defined and SHALL be 6966 registered with IANA using the following rules: 6968 o Registering requires an IETF standard tracks document. 6970 o A registration is required name a contact person. 6972 o Name of the policy. 6974 o A describing text that explains how the policy works for handling 6975 the certificates. 6977 This specification registers the following values: 6979 Any 6981 Proxy 6983 User 6985 21.7.2. Accept-Credentials hash algorithms 6987 The Accept-Credentials header (See SectionSection 14.2) allows for 6988 the usage of other algorithms for hashing the DER records of accepted 6989 entities. The registration of any future algorithm is expected to be 6990 extremely rare and could also be an interoperability problem. 6991 Therefore the XXX bare for registering new algorithms is placed 6992 intentional high. 6994 Any registration of a new hash algorithm SHALL meet the following 6995 requirement: 6997 o Registration requires an IETF standard track document. 6999 o A definition of the algorithm and its identifier meeting the 7000 "token" ABNF requirement. 7002 21.8. Range header formats 7004 The Range header allows for different range formats. New ones may be 7005 registered, but moderation should be applied as it makes 7006 interoperability more difficult. A registration SHALL fulfill the 7007 following requirements: 7009 o A publicly available standards document. 7011 o A ABNF definition of the range format that fulfils the "range-ext" 7012 definition. 7014 o A Contact person for the registration. 7016 o Rules for how one handles the range when using a negative Scale. 7018 21.9. URI Schemes 7020 This specification defines two URI schemes ("rtsp" and "rtsps") and 7021 reserves a third one ("rtspu"). Registrations are following RFC 7022 4395[RFC4395]. 7024 21.9.1. The rtsp URI Scheme 7026 URI scheme name: rtsp 7028 Status: Permanent 7030 URI scheme syntax: See SectionSection 19.2.1 of RFC XXXX. 7032 URI scheme semantics: The rtsp scheme is used to indicate resources 7033 accessible through the usage of the Real-time Streaming 7034 Protocol (RTSP). RTSP allows different operations on the 7035 resource identified by the URI, but the primary purpose is the 7036 streaming delivery of the resource to a client. However the 7037 operations that are currently defined are: Describing the 7038 resource for the purpose of configuring the receiving entity 7039 (DESCRIBE), configuring the delivery method and its addressing 7040 (SETUP), controlling the delivery (PLAY and PAUSE), reading or 7041 setting of resource related parameters (SETPARAMETER and 7042 GETPARAMETER, and termination of the session context created 7043 (TEARDOWN). 7045 Encoding considerations: IRIs in this scheme are defined and needs 7046 to be encoded as RTSP URIs when used within the RTSP protocol. 7047 That encoding is done according to RFC 3987 (XXX). 7049 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 7050 2326), RTSP 2.0 (RFC XXXX) 7052 Interoperability considerations: The change in URI syntax performed 7053 between RTSP 1.0 and 2.0 can create interoperability issues. 7055 Security considerations: All the security threats identified in 7056 Section 7 of RFC 3986 applies also to this scheme. They needs 7057 to be reviewed and considered in any implementation utilizing 7058 this scheme. 7060 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 7062 Author/Change controller: IETF MMUSIC WG 7064 References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX 7066 21.9.2. The rtsps URI Scheme 7068 URI scheme name: rtsps 7070 Status: Permanent 7072 URI scheme syntax: See SectionSection 19.2.1 of RFC XXXX. 7074 URI scheme semantics: The rtsps scheme is used to indicate resources 7075 accessible through the usage of the Real-time Streaming 7076 Protocol (RTSP) over TLS. RTSP allows different operations on 7077 the resource identified by the URI, but the primary purpose is 7078 the streaming delivery of the resource to a client. However 7079 the operations that are currently defined are: Describing the 7080 resource for the purpose of configuring the receiving entity 7081 (DESCRIBE), configuring the delivery method and its addressing 7082 (SETUP), controlling the delivery (PLAY and PAUSE), reading or 7083 setting of resource related parameters (SETPARAMETER and 7084 GETPARAMETER, and termination of the session context created 7085 (TEARDOWN). 7087 Encoding considerations: IRIs in this scheme are defined and needs 7088 to be encoded as RTSP URIs when used within the RTSP protocol. 7089 That encoding is done according to RFC 3987. 7091 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 7092 2326), RTSP 2.0 (RFC XXXX) 7094 Interoperability considerations: The change in URI syntax performed 7095 between RTSP 1.0 and 2.0 can create interoperability issues. 7097 Security considerations: All the security threats identified in 7098 Section 7 of RFC 3986 applies also to this scheme. They needs 7099 to be reviewed and considered in any implementation utilizing 7100 this scheme. 7102 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 7104 Author/Change controller: IETF MMUSIC WG 7106 References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX 7108 21.9.3. The rtspu URI Scheme 7110 URI scheme name: rtspu 7112 Status: Permanent 7114 URI scheme syntax: See Section 3.2 of RFC 2326. 7116 URI scheme semantics: The rtspu scheme is used to indicate resources 7117 accessible through the usage of the Real-time Streaming 7118 Protocol (RTSP) over unrelaible datagram transport. RTSP 7119 allows different operations on the resource identified by the 7120 URI, but the primary purpose is the streaming delivery of the 7121 resource to a client. However the operations that are 7122 currently defined are: Describing the resource for the purpose 7123 of configuring the receiving entity (DESCRIBE), configuring the 7124 delivery method and its addressing (SETUP), controlling the 7125 delivery (PLAY and PAUSE), reading or setting of resource 7126 related parameters (SETPARAMETER and GETPARAMETER, and 7127 termination of the session context created (TEARDOWN). 7129 Encoding considerations: IRIs in this scheme are defined and needs 7130 to be encoded as RTSP URIs when used within the RTSP protocol. 7131 That encoding is done according to RFC 3987. 7133 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 7134 2326) 7136 Interoperability considerations: The definition of the transport 7137 mechanism of RTSP over UDP has interoperability issues. That 7138 makes the usage of this scheme problematic. 7140 Security considerations: All the security threats identified in 7141 Section 7 of RFC 3986 applies also to this scheme. They needs 7142 to be reviewed and considered in any implementation utilizing 7143 this scheme. 7145 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 7147 Author/Change controller: IETF MMUSIC WG 7149 References: RFC 2326, RFC 3986, RFC 3987 7151 21.10. SDP attributes 7153 This specification defines two SDP [RFC4566] attributes that it is 7154 requested that IANA register. 7156 SDP Attribute ("att-field"): 7158 Attribute name: range 7159 Long form: Media Range Attribute 7160 Type of name: att-field 7161 Type of attribute: Media and session level 7162 Subject to charset: No 7163 Purpose: RFC XXXX 7164 Reference: RFC XXXX 7165 Values: See ABNF definition. 7167 Attribute name: control 7168 Long form: RTSP control URI 7169 Type of name: att-field 7170 Type of attribute: Media and session level 7171 Subject to charset: No 7172 Purpose: RFC XXXX 7173 Reference: RFC XXXX 7174 Values: Absolute or Relative URIs. 7176 Attribute name: etag 7177 Long form: Entity Tag 7178 Type of name: att-field 7179 Type of attribute: Media and session level 7180 Subject to charset: No 7181 Purpose: RFC XXXX 7182 Reference: RFC XXXX 7183 Values: See ABNF definition 7185 22. References 7187 22.1. Normative References 7189 [3gpp-26234] 7190 Third Generation Partnership Project (3GPP), "Transparent 7191 end-to-end Packet-switched Streaming Service (PSS); 7192 Protocols and codecs; Technical Specification 26.234", 7193 December 2002. 7195 [FIPS-pub-180-1] 7196 National Institute of Standards and Technology (NIST), 7197 "Federal Information Processing Standards Publications 7198 (FIPS PUBS) 180-1: Secure Hash Standard", April 1995. 7200 [I-D.ietf-avt-profile-savpf] 7201 Ott, J. and E. Carrara, "Extended Secure RTP Profile for 7202 RTCP-based Feedback (RTP/SAVPF)", 7203 draft-ietf-avt-profile-savpf-09 (work in progress), 7204 October 2006. 7206 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 7207 August 1980. 7209 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 7210 RFC 793, September 1981. 7212 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 7213 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 7214 RFC 2068, January 1997. 7216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 7217 Requirement Levels", BCP 14, RFC 2119, March 1997. 7219 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 7220 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 7221 October 1998. 7223 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 7224 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 7225 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 7227 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 7228 Leach, P., Luotonen, A., and L. Stewart, "HTTP 7229 Authentication: Basic and Digest Access Authentication", 7230 RFC 2617, June 1999. 7232 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 7234 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 7235 X.509 Public Key Infrastructure Certificate and 7236 Certificate Revocation List (CRL) Profile", RFC 3280, 7237 April 2002. 7239 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 7240 (IPv6) Addressing Architecture", RFC 3513, April 2003. 7242 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 7243 Encodings", RFC 3548, July 2003. 7245 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 7246 Jacobson, "RTP: A Transport Protocol for Real-Time 7247 Applications", STD 64, RFC 3550, July 2003. 7249 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 7250 Video Conferences with Minimal Control", STD 65, RFC 3551, 7251 July 2003. 7253 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 7254 10646", STD 63, RFC 3629, November 2003. 7256 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 7257 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 7258 RFC 3711, March 2004. 7260 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 7261 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 7262 August 2004. 7264 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 7265 Resource Identifier (URI): Generic Syntax", STD 66, 7266 RFC 3986, January 2005. 7268 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 7269 Identifiers (IRIs)", RFC 3987, January 2005. 7271 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 7272 Specifications: ABNF", RFC 4234, October 2005. 7274 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 7275 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 7277 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 7278 Registration Procedures for New URI Schemes", BCP 115, 7279 RFC 4395, February 2006. 7281 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 7282 Description Protocol", RFC 4566, July 2006. 7284 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 7285 Carrara, "Key Management Extensions for Session 7286 Description Protocol (SDP) and Real Time Streaming 7287 Protocol (RTSP)", RFC 4567, July 2006. 7289 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 7290 and RTP Control Protocol (RTCP) Packets over Connection- 7291 Oriented Transport", RFC 4571, July 2006. 7293 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 7294 "Extended RTP Profile for Real-time Transport Control 7295 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 7296 July 2006. 7298 22.2. Informative References 7300 [I-D.ietf-mmusic-rtsp-nat] 7301 Westerlund, M. and T. Zeng, "How to Enable Real-Time 7302 Streaming Protocol (RTSP) Traverse Network Address 7303 Translators (NAT) and Interact with Firewalls.", 7304 draft-ietf-mmusic-rtsp-nat-04 (work in progress), 7305 October 2005. 7307 [ISO.13818-1.2000] 7308 International Organization for Standardization, 7309 "Information technology - Generic coding of moving 7310 pictures and associated audio information: Systems", ISO/ 7311 IEC 13818-1:2000, December 2000. 7313 [ISO.13818-6.1995] 7314 International Organization for Standardization, 7315 "Information technology - Generic coding of moving 7316 pictures and associated audio information - part 6: 7317 Extension for digital storage media and control", 7318 ISO Draft Standard 13818-6, November 1995. 7320 [ISO.8601.2000] 7321 International Organization for Standardization, "Data 7322 elements and interchange formats - Information interchange 7323 - Representation of dates and times", ISO/IEC Standard 7324 8601, December 2000. 7326 [ITU.H323.1996] 7327 International Telecommunications Union, "Visual telephone 7328 systems and equipment for local area networks which 7329 provide a non-guaranteed quality of service", ITU- 7330 T Recommendation H.323, May 1996. 7332 [NOSSDAV-1997-1] 7333 Schulzrinne, H., "A comprehensive multimedia control 7334 architecture for the Internet", May 1997. 7336 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 7337 and Support", STD 3, RFC 1123, October 1989. 7339 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 7340 Specification, Implementation", RFC 1305, March 1992. 7342 [RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions 7343 Functional Specification", RFC 1644, July 1994. 7345 [RFC1961] McMahon, P., "GSS-API Authentication Method for SOCKS 7346 Version 5", RFC 1961, June 1996. 7348 [RFC2070] Yergeau, F., Nicol, G., Adams, G., and M. Duerst, 7349 "Internationalization of the Hypertext Markup Language", 7350 RFC 2070, January 1997. 7352 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 7353 Streaming Protocol (RTSP)", RFC 2326, April 1998. 7355 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 7356 A., Peterson, J., Sparks, R., Handley, M., and E. 7357 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 7358 June 2002. 7360 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 7361 Schulzrinne, "Grouping of Media Lines in the Session 7362 Description Protocol (SDP)", RFC 3388, December 2002. 7364 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 7365 the Session Description Protocol (SDP)", RFC 4145, 7366 September 2005. 7368 [W3C.REC-PICS-labels] 7369 Miller, J., Krauskopf, T., Resnick, P., and W. Treese, 7370 "PICS label distribution label syntax and communication 7371 protocols", W3C REC-PICS-labels-961031. 7373 [W3C.REC-PICS-services] 7374 Miller, J., Resnick, P., and D. Singer, "Rating services 7375 and rating systems (and their machine readable 7376 descriptions)", W3C REC-PICS-services-961031, 7377 October 1996. 7379 Appendix A. RTSP Protocol State Machine 7381 The RTSP session state machine describes the behavior of the protocol 7382 from RTSP session initialization through RTSP session termination. 7384 The State machine is defined on a per session basis which is uniquely 7385 identified by the RTSP session identifier. The session may contain 7386 one or more media streams depending on state. If a single media 7387 stream is part of the session it is in non-aggregated control. If 7388 two or more is part of the session it is in aggregated control. 7390 The below state machine is a normative description of the protocols 7391 behavior. However, in case of ambiguity with the earlier parts of 7392 this specification, the description in the earlier parts SHALL take 7393 precedence. 7395 A.1. States 7397 The state machine contains three states, described below. For each 7398 state there exist a table which shows which requests and events that 7399 is allowed and if they will result in a state change. 7401 Init: Initial state no session exist. 7403 Ready: Session is ready to start playing. 7405 Play: Session is playing, i.e. sending media stream data in the 7406 direction S->C. 7408 A.2. State variables 7410 This representation of the state machine needs more than its state to 7411 work. A small number of variables are also needed and is explained 7412 below. 7414 NRM: The number of media streams part of this session. 7416 RP: Resume point, the point in the presentation time line at which 7417 a request to continue will resume from. A time format for the 7418 variable is not mandated. 7420 A.3. Abbreviations 7422 To make the state tables more compact a number of abbreviations are 7423 used, which are explained below. 7425 IFI: IF Implemented. 7427 md: Media 7429 PP: Pause Point, the point in the presentation time line at which 7430 the presentation was paused. 7432 Prs: Presentation, the complete multimedia presentation. 7434 RedP: Redirect Point, the point in the presentation time line at 7435 which a REDIRECT was specified to occur. 7437 SES: Session. 7439 A.4. State Tables 7441 This section contains a table for each state. The table contains all 7442 the requests and events that this state is allowed to act on. The 7443 events which is method names are, unless noted, requests with the 7444 given method in the direction client to server (C->S). In some cases 7445 there exist one or more requisite. The response column tells what 7446 type of response actions should be performed. Possible actions that 7447 is requested for an event includes: response codes, e.g. 200, headers 7448 that MUST be included in the response, setting of state variables, or 7449 setting of other session related parameters. The new state column 7450 tells which state the state machine changes to. 7452 The response to valid request meeting the requisites is normally a 7453 2xx (SUCCESS) unless other noted in the response column. The 7454 exceptions needs to be given a response according to the response 7455 column. If the request does not meet the requisite, is erroneous or 7456 some other type of error occur the appropriate response code MUST be 7457 sent. If the response code is a 4xx the session state is unchanged. 7458 A response code of 3rr will result in that the session is ended and 7459 its state is changed to Init. A response code of 304 results in no 7460 state change. However there exist restrictions to when a 3rr 7461 response may be used. A 5xx response SHALL not result in any change 7462 of the session state, except if the error is not possible to recover 7463 from. A unrecoverable error SHALL result the ending of the session. 7464 As it in the general case can't be determined if it was a 7465 unrecoverable error or not the client will be required to test. In 7466 the case that the next request after a 5xx is responded with 454 7467 (Session Not Found) the client knows that the session has ended. 7469 The server will timeout the session after the period of time 7470 specified in the SETUP response, if no activity from the client is 7471 detected. Therefore there exist a timeout event for all states 7472 except Init. 7474 In the case that NRM = 1 the presentation URI is equal to the media 7475 URI or a specified presentation URI. For NRM > 1 the presentation 7476 URI MUST be other than any of the medias that are part of the 7477 session. This applies to all states. 7479 +--------------+-----------------+----------------------------------+ 7480 | Event | Prerequisite | Response | 7481 +--------------+-----------------+----------------------------------+ 7482 | DESCRIBE | Needs REDIRECT | 3rr, Redirect | 7483 | | | | 7484 | DESCRIBE | | 200, Session description | 7485 | | | | 7486 | OPTIONS | Session ID | 200, Reset session timeout timer | 7487 | | | | 7488 | OPTIONS | | 200 | 7489 | | | | 7490 | SETPARAMETER | Valid parameter | 200, change value of parameter | 7491 | | | | 7492 | GETPARAMETER | Valid parameter | 200, return value of parameter | 7493 +--------------+-----------------+----------------------------------+ 7495 Table 13: None state-machine changing events 7497 The methods in Table 13 do not have any effect on the state machine 7498 or the state variables. However some methods do change other session 7499 related parameters, for example SETPARAMETER which will set the 7500 parameter(s) specified in its body. Also all of these methods that 7501 allows Session header will also update the keep-alive timer for the 7502 session. 7504 +------------------+----------------+-----------+-------------------+ 7505 | Action | Requisite | New State | Response | 7506 +------------------+----------------+-----------+-------------------+ 7507 | SETUP | | Ready | NRM=1, RP=0.0 | 7508 | | | | | 7509 | SETUP | Needs Redirect | Init | 3rr Redirect | 7510 | | | | | 7511 | S -> C: REDIRECT | No Session hdr | Init | Terminate all SES | 7512 +------------------+----------------+-----------+-------------------+ 7514 Table 14: State: Init 7516 The initial state of the state machine, see Table 14 can only be left 7517 by processing a correct SETUP request. As seen in the table the two 7518 state variables are also set by a correct request. This table also 7519 shows that a correct SETUP can in some cases be redirected to another 7520 URI and/or server by a 3rr response. 7522 +--------------+-----------------+-----------+----------------------+ 7523 | Action | Requisite | New State | Response | 7524 +--------------+-----------------+-----------+----------------------+ 7525 | SETUP | New URI | Ready | NRM +=1 | 7526 | | | | | 7527 | SETUP | Setten up URI | Ready | Change transport | 7528 | | | | param | 7529 | | | | | 7530 | TEARDOWN | Prs URI, | Init | No session hdr, NRM | 7531 | | | | = 0 | 7532 | | | | | 7533 | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, NRM | 7534 | | | | = 0 | 7535 | | | | | 7536 | TEARDOWN | md URI,NRM>1 | Ready | Session hdr, NRM -= | 7537 | | | | 1 | 7538 | | | | | 7539 | PLAY | Prs URI, No | Play | Play from RP | 7540 | | range | | | 7541 | | | | | 7542 | PLAY | Prs URI, Range | Play | According to range | 7543 | | | | | 7544 | PAUSE | Prs URI | Ready | Return PP | 7545 | | | | | 7546 | SC:REDIRECT | Range hdr | Ready | Set RedP | 7547 | | | | | 7548 | SC:REDIRECT | no range hdr | Init | Session is removed | 7549 | | | | | 7550 | Timeout | | Init | | 7551 | | | | | 7552 | RedP reached | | Init | TEARDOWN of session | 7553 +--------------+-----------------+-----------+----------------------+ 7555 Table 15: State: Ready 7557 In the Ready state, see Table 15, some of the actions are depending 7558 on the number of media streams (NRM) in the session, i.e. aggregated 7559 or non-aggregated control. A setup request in the ready state can 7560 either add one more media stream to the session or if the media 7561 stream (same URI) already is part of the session change the transport 7562 parameters. TEARDOWN is depending on both the Request-URI and the 7563 number of media stream within the session. If the Request-URI is the 7564 presentations URI the whole session is torn down. If a media URI is 7565 used in the TEARDOWN request and more than one media exist in the 7566 session, the session will remain and a session header MUST be 7567 returned in the response. If only a single media stream remains in 7568 the session when performing a TEARDOWN with a media URI the session 7569 is removed. The number of media streams remaining after tearing down 7570 a media stream determines the new state. 7572 +--------------+-----------------+-----------+----------------------+ 7573 | Action | Requisite | New State | Response | 7574 +--------------+-----------------+-----------+----------------------+ 7575 | PAUSE | PrsURI | Ready | Set RP to present | 7576 | | | | point | 7577 | | | | | 7578 | PP reached | | Ready | RP = PP | 7579 | | | | | 7580 | End of media | All media | Play | Set RP = End of | 7581 | | | | media | 7582 | | | | | 7583 | End of range | | Play | Set RP = End of | 7584 | | | | range | 7585 | | | | | 7586 | PLAY | Prs URI, No | Play | Play from present | 7587 | | range | | point | 7588 | | | | | 7589 | PLAY | Prs URI, Range | Play | According to range | 7590 | | | | | 7591 | SETUP | New URI | Play | 455 | 7592 | | | | | 7593 | SETUP | Setuped URI | Play | 455 | 7594 | | | | | 7595 | SETUP | Setuped URI, | Play | Change transport | 7596 | | IFI | | param. | 7597 | | | | | 7598 | TEARDOWN | Prs URI | Init | No session hdr | 7599 | | | | | 7600 | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, | 7601 | | | | NRM=0 | 7602 | | | | | 7603 | TEARDOWN | md URI | Play | 455 | 7604 | | | | | 7605 | SC:REDIRECT | Range hdr | Play | Set RedP | 7606 | | | | | 7607 | SC:REDIRECT | no range hdr | Init | Session is removed | 7608 | | | | | 7609 | RedP reached | | Init | TEARDOWN of session | 7610 | | | | | 7611 | Timeout | | Init | Stop Media playout | 7612 +--------------+-----------------+-----------+----------------------+ 7614 Table 16: State: Play 7616 The Play state table, see Table 16, is the largest. The table 7617 contains an number of requests that has presentation URI as a 7618 prerequisite on the Request-URI, this is due to the exclusion of non- 7619 aggregated stream control in sessions with more than one media 7620 stream. 7622 To avoid inconsistencies between the client and server, automatic 7623 state transitions are avoided. This can be seen at for example "End 7624 of media" event when all media has finished playing, the session 7625 still remain in Play state. An explicit PAUSE request MUST be sent 7626 to change the state to Ready. It may appear that there exist an 7627 automatic transitions in "RedP reached" and "PP reached", however 7628 they are requested and acknowledge before they take place. The time 7629 at which the transition will happen is known by looking at the range 7630 header. If the client sends request close in time to these 7631 transitions it needs to be prepared for getting error message as the 7632 state may or may not have changed. 7634 Appendix B. Media Transport Alternatives 7636 This section defines how certain combinations of protocols, profiles 7637 and lower transports are used. This includes the usage of the 7638 Transport header's source and destination address parameters 7639 "src_addr" and "dest_addr". 7641 B.1. RTP 7643 This section defines the interaction of RTSP with respect to the RTP 7644 protocol [RFC3550]. It also defines any necessary media transport 7645 signalling with regards to RTP. 7647 The available RTP profiles and lower layer transports are described 7648 below along with rules on signalling the available combinations. 7650 B.1.1. AVP 7652 The usage of the "RTP Profile for Audio and Video Conferences with 7653 Minimal Control" [RFC3551] when using RTP for media transport over 7654 different lower layer transport protocols is defined below in regards 7655 to RTSP. 7657 One such case is defined within this document, the use of embedded 7658 (interleaved) binary data as defined in sectionSection 12. The usage 7659 of this method is indicated by include the "interleaved" parameter. 7661 When using embedded binary data the "src_addr" and "dest_addr" SHALL 7662 NOT be used. This addressing and multiplexing is used as defined 7663 with use of channel numbers and the interleaved parameter. 7665 B.1.2. AVP/UDP 7667 This part describes sending of RTP [RFC3550] over lower transport 7668 layer UDP [RFC0768] according to the profile "RTP Profile for Audio 7669 and Video Conferences with Minimal Control" defined in RFC 3551 7670 [RFC3551]. This profiles requires one or two uni- or bi-directional 7671 UDP flows per media stream. The first UDP flow is for RTP and the 7672 second is for RTCP. Embedding of RTP data with the RTSP messages, in 7673 accordance with section Section 12, SHOULD NOT be performed when RTSP 7674 messages are transported over unreliable transport protocols, like 7675 UDP [RFC0768]. 7677 The RTP/UDP and RTCP/UDP flows can be established using the Transport 7678 header's "src_addr", and "dest_addr" parameters. 7680 In RTSP PLAY mode, the transmission of RTP packets from client to 7681 server is unspecified. The behavior in regards to such RTP packets 7682 MAY be defined in future. 7684 The "src_addr" and "dest_addr" parameters are used in the following 7685 way for media playback, i.e. Mode=PLAY: 7687 o The "src_addr" and "dest_addr" parameters MUST contain either 1 or 7688 2 address specifications. 7690 o Each address specification for RTP/AVP/UDP or RTP/AVP/TCP MUST 7691 contain either: 7693 * both an address and a port number, or 7695 * a port number without an address. 7697 o The first address and port pair given in either of the parameters 7698 applies to the RTP stream. The second address and port pair if 7699 present applies to the RTCP stream. 7701 o The RTP/UDP packets from the server to the client SHALL be sent to 7702 the address and port given by first address and port pair of the 7703 "dest_addr" parameter. 7705 o The RTCP/UDP packets from the server to the client SHALL be sent 7706 to the address and port given by the second address and port pair 7707 of the "dest_addr" parameter. If no second pair is specified RTCP 7708 SHALL NOT be sent. 7710 o The RTCP/UDP packets from the client to the server SHALL be sent 7711 to the address and port given by the second address and port pair 7712 of the "src_addr" parameter. If no second pair is given RTCP 7713 SHALL NOT be sent. 7715 o The RTP/UDP packets from the client to the server SHALL be sent to 7716 the address and port given by the first address and port pair of 7717 the "src_addr" parameter. 7719 o RTP and RTCP Packets SHOULD be sent from the corresponding 7720 receiver port, i.e. RTCP packets from server should be sent from 7721 the "src_addr" parameters second address port pair. 7723 B.1.3. AVPF/UDP 7725 The RTP profile "Extended RTP Profile for RTCP-based Feedback (RTP/ 7726 AVPF)"[RFC4585] MAY be used as RTP profiles in session using RTP. 7727 All that is defined for AVP SHALL also apply for AVPF. 7729 The usage of AVPF is indicated by the media initialization protocol 7730 used. In the case of SDP it is indicated by media lines (m=) 7731 containing the profile RTP/AVPF. That SDP MAY also contain further 7732 AVPF related SDP attributes configuring the AVPF session regarding 7733 reporting interval and feedback messages that shall be used that 7734 SHALL be followed. 7736 B.1.4. SAVP/UDP 7738 The RTP profile "The Secure Real-time Transport Protocol (SRTP)" 7739 [RFC3711] is an RTP profile (SAVP) that MAY be used in RTSP sessions 7740 using RTP. All that is defined for AVP SHALL also apply for SAVP. 7742 The usage of SRTP requires that a security association is 7743 established. The RECOMMENDED mechanism for establishing that 7744 security association is to use MIKEY with RTSP as defined in RFC 4567 7745 [RFC4567]. 7747 B.1.5. SAVPF/UDP 7749 The RTP profile "Extended Secure RTP Profile for RTCP-based Feedback 7750 (RTP/SAVPF)" [I-D.ietf-avt-profile-savpf] is an RTP profile (SAVPF) 7751 that MAY be used in RTSP sessions using RTP. All that is defined for 7752 AVP SHALL also apply for SAVPF. 7754 The usage of SRTP requires that a security association is 7755 established. The RECOMMENDED mechanism for establishing that 7756 security association is to use MIKEY[RFC3830] with RTSP as defined in 7757 RFC 4567 [RFC4567]. 7759 B.2. RTP over TCP 7761 Transport of RTP over TCP can be done in two ways, over independent 7762 TCP connections using RFC 4571 [RFC4571] or interleaved in the RTSP 7763 control connection. In both cases the protocol SHALL be "rtp" and 7764 the lower layer SHALL be TCP. The profile may be any of the above 7765 specified ones; AVP, AVPF, SAVP or SAVPF. 7767 B.2.1. Interleaved RTP over TCP 7769 The use of embedded (interleaved) binary data transported on the RTSP 7770 connection is possible as specified in SectionSection 12. When using 7771 this declared combination of interleaved binary data the RTSP 7772 messages MUST be transported over TCP. TLS may or may not be used. 7774 One should however consider that this will result that all media 7775 streams go through any proxy. Using independent TCP connections can 7776 avoid that issue. 7778 B.2.2. RTP over independent TCP 7780 In this Appendix, we describe the sending of RTP [RFC3550] over lower 7781 transport layer TCP [RFC0793] according to "Framing Real-time 7782 Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over 7783 Connection-Oriented Transport" [RFC4571]. This Appendix adapts the 7784 guidelines for using RTP over TCP within SIP/SDP [RFC4145] to work 7785 with RTSP. 7787 A client codes the support of RTP over independent TCP by specifying 7788 an RTP/AVP/TCP transport option without an interleaved parameter in 7789 the Transport line of a SETUP request. This transport option MUST 7790 include the "unicast" parameter. 7792 If the client wishes to use RTP with RTCP, two ports (or two address/ 7793 port pairs) are specified by the dest_addr parameter. If the client 7794 wishes to use RTP without RTCP, one port (or one address/port pair) 7795 is specified by the dest_addr parameter. Ordering rules of dest_addr 7796 ports follow the rules for RTP/AVP/UDP. 7798 If the client wishes to play the active role in initiating the TCP 7799 connection, it MAY set the "setup" parameter (See 7800 sectionSection 14.45) on the Transport line to be "active", or it MAY 7801 omit the setup parameter, as active is the default. If the client 7802 signals the active role, the ports for all dest_addr values MUST be 7803 set to 9 (the discard port). 7805 If the client wishes to play the passive role in TCP connection 7806 initiation, it MUST set the "setup" parameter on the Transport line 7807 to be "passive". If the client is able to assume the active or the 7808 passive role, it MUST set the "setup" parameter on the Transport line 7809 to be "actpass". In either case, the dest_addr port value for RTP 7810 MUST be set to the TCP port number on which the client is expecting 7811 to receive the RTP stream connection, and the dest_addr port value 7812 for RTCP MUST be set to the TCP port number on which the client is 7813 expecting to receive the RTCP stream connection. 7815 If upon receipt of a non-interleaved RTP/AVP/TCP SETUP request, a 7816 server decides to accept this requested option, the 2xx reply MUST 7817 contain a Transport option that specifies RTP/AVP/TCP (without using 7818 the interleaved parameter, and with using the unicast parameter). 7819 The dest_addr parameter value MUST be echoed from the parameter value 7820 in the client request unless the destination address (only port) was 7821 not provided in which can the server MAY include the source address 7822 of the RTSP TCP connection with the port number unchanged. 7824 In addition, the server reply MUST set the setup parameter on the 7825 Transport line, to indicate the role the server will play in the 7826 connection setup. Permissible values are "active" (if a client set 7827 "setup" to "passive" or "actpass") and "passive" (if a client set 7828 "setup" to "active" or "actpass"). 7830 If a server sets "setup" to "passive", the "src_addr" in the reply 7831 MUST indicate the ports the server is willing to receive an RTP 7832 connection and (if the client requested an RTCP connection by 7833 specifying two dest_addr ports or address/port pairs) and RTCP 7834 connection. If a server sets "setup" to "active", the ports 7835 specified in "src_addr" MUST be set to 9. The server MAY use the 7836 "ssrc" parameter, following the guidance in Section 14.45. Port 7837 ordering for src_addr follows the rules for RTP/AVP/UDP. 7839 For cases when servers have a public IP-address it is RECOMMENDED 7840 that the server take the passive role and the client the active role. 7841 This help in cases when the client is behind a NAT. 7843 After sending (receiving) a 2xx reply for a SETUP method for a non- 7844 interleaved RTP/AVP/TCP media stream, the active party SHOULD 7845 initiate the TCP connection as soon as possible. The client SHALL 7846 NOT send a PLAY request prior to the establishment of all the TCP 7847 connections negotiated using SETUP for the session. In case the 7848 server receives a PLAY request in a session that has not yet 7849 established all the TCP connections, it SHALL respond using the 464 7850 "Data Transport Not Ready Yet" (SectionSection 13.4.16) error code. 7852 Once the PLAY request for a media resource transported over non- 7853 interleaved RTP/AVP/TCP occurs, media begins to flow from server to 7854 client over the RTP TCP connection, and RTCP packets flow 7855 bidirectionally over the RTCP TCP connection. As in the RTP/UDP 7856 case, client to server traffic on the TCP port is unspecified by this 7857 memo. The packets that travel on these connections SHALL be framed 7858 using the protocol defined in [RFC4571], not by the framing defined 7859 for interleaving RTP over the RTSP control connection defined in 7860 Section 12. 7862 A successful PAUSE request for a media being transported over RTP/ 7863 AVP/TCP pauses the flow of packets over the connections, without 7864 closing the connections. A successful TEARDOWN request signals that 7865 the TCP connections for RTP and RTCP are to be closed as soon as 7866 possible. 7868 Subsequent SETUP requests on an already-SETUP RTP/AVP/TCP URI may be 7869 ambiguous in the following way: does the client wish to open up new 7870 TCP RTP and RTCP connections for the URI, or does the client wish to 7871 continue using the existing TCP RTP and RTCP connections? The client 7872 SHOULD use the "connection" parameter (defined in Section 14.45) on 7873 the Transport line to make its intention clear in the regard (by 7874 setting "connection" to "new" if new connections are needed, and by 7875 setting "connection" to "existing" if the existing connections are to 7876 be used). After a 2xx reply for a SETUP request for a new 7877 connection, parties should close the pre-existing connections, after 7878 waiting a suitable period for any stray RTP or RTCP packets to 7879 arrive. 7881 Below, we rewrite part of the example media on demand example shown 7882 in Section 17.1 to use RTP/AVP/TCP non-interleaved: 7884 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 7885 CSeq: 1 7886 User-Agent: PhonyClient/1.2 7888 M->C: RTSP/2.0 200 OK 7889 CSeq: 1 7890 Server: PhonyServer/1.0 7891 Date: 23 Jan 1997 15:35:06 GMT 7892 Content-Type: application/sdp 7893 Content-Length: 257 7894 Content-Base: rtsp://example.com/twister.3gp/ 7895 Expires: 24 Jan 1997 15:35:06 GMT 7897 v=0 7898 o=- 2890844256 2890842807 IN IP4 192.0.2.5 7899 s=RTSP Session 7900 i=An Example of RTSP Session Usage 7901 e=adm@example.com 7902 a=control: * 7903 a=range: npt=0-0:10:34.10 7904 t=0 0 7905 m=audio 0 RTP/AVP 0 7906 a=control: trackID=1 7908 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 7909 CSeq: 2 7910 User-Agent: PhonyClient/1.2 7911 Require: play.basic 7912 Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9" 7913 setup=active;connection=new 7915 M->C: RTSP/2.0 200 OK 7916 CSeq: 2 7917 Server: PhonyServer/1.0 7918 Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9"; 7919 src_addr="192.0.2.5:9000"/"192.0.2.5:9001" 7920 setup=passive;connection=new;ssrc=93CB001E 7921 Session: 12345678 7922 Expires: 24 Jan 1997 15:35:12 GMT 7923 Date: 23 Jan 1997 15:35:12 GMT 7924 Accept-Ranges: NPT 7926 C->M: TCP Connection Establishment 7928 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 7929 CSeq: 4 7930 User-Agent: PhonyClient/1.2 7931 Range: npt=0-10, npt=30- 7932 Session: 12345678 7934 M->C: RTSP/2.0 200 OK 7935 CSeq: 4 7936 Server: PhonyServer/1.0 7937 Date: 23 Jan 1997 15:35:14 GMT 7938 Session: 12345678 7939 Range: npt=0-10, npt=30-623.10 7940 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1"; 7941 ssrc=4F312DD8:seq=54321;rtptime=2876889 7943 B.2.3. Handling NPT Jumps in the RTP Media Layer 7945 RTSP allows media clients to control selected, non-contiguous 7946 sections of media presentations, rendering those streams with an RTP 7947 media layer[RFC3550]. Such control allows jumps to be created in NPT 7948 timeline of the RTSP session. For example, jumps in NPT can be 7949 caused by multiple ranges in the range specifier of a PLAY request or 7950 through a "seek" opertaion on an RTSP session which involves a PLAY, 7951 PAUSE, PLAY scenario where a new NPT is set for the session. The 7952 media layer rendering the RTP stream should not be affected by jumps 7953 in NPT. Thus, both RTP sequence numbers and RTP timestamps MUST be 7954 continuous and monotonic across jumps of NPT. 7956 We cannot assume that the RTSP client can communicate with the RTP 7957 media agent, as the two may be independent processes. If the RTP 7958 timestamp shows the same gap as the NPT, the media agent will 7959 assume that there is a pause in the presentation. If the jump in 7960 NPT is large enough, the RTP timestamp may roll over and the media 7961 agent may believe later packets to be duplicates of packets just 7962 played out. 7964 As an example, assume a clock frequency of 8000 Hz, a packetization 7965 interval of 100 ms and an initial sequence number and timestamp of 7966 zero. 7968 C->S: PLAY rtsp://xyz/fizzle RTSP/2.0 7969 CSeq: 4 7970 Session: abcdefg 7971 Range: npt=10-15 7973 S->C: RTSP/2.0 200 OK 7974 CSeq: 4 7975 Session: abcdefg 7976 Range: npt=10-15 7977 RTP-Info: url="rtsp://xyz/fizzle/audiotrack" 7978 ssrc=0D12F123:seq=0;rtptime=0 7980 The ensuing RTP data stream is depicted below: 7982 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 7983 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 7984 . . . 7985 S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s 7987 Immediately after the end of the play range, the client follows up 7988 with a request to PLAY from a new NPT. 7990 C->S: PLAY rtsp://xyz/fizzle RTSP/2.0 7991 CSeq: 5 7992 Session: abcdefg 7993 Range: npt=18-20; 7995 S->C: RTSP/2.0 200 OK 7996 CSeq: 5 7997 Session: abcdefg 7998 Range: npt=18-20 7999 RTP-Info: url="rtsp://xyz/fizzle/audiotrack" 8000 ssrc=0D12F123:seq=50;rtptime=40100 8002 The ensuing RTP data stream is depicted below: 8004 S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s 8005 S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s 8006 . . . 8007 S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s 8009 In this example, first, NPT 10 through 15 is played, then the client 8010 request the server to skip ahead and play NPT 18 through 20. The 8011 first segment is presented as RTP packets with sequence numbers 0 8012 through 49 and timestamp 0 through 39,200. The second segment 8013 consists of RTP packets with sequence number 50 through 69, with 8014 timestamps 40,100 through 55,200. While there is a gap in the NPT, 8015 there is no gap in the sequence number space of the RTP data stream. 8017 The RTP timestamp gap is present in the above example due to the time 8018 it takes to perform the second play request, in this case 12.5 ms 8019 (100/8000). To avoid this gap in playback due to the time it takes 8020 to perform RTSP requests, a PLAY request with multiple ranges needs 8021 to be specified. That would result in the following example: 8023 C->S: PLAY rtsp://xyz/fizzle RTSP/2.0 8024 CSeq: 4 8025 Session: abcdefg 8026 Range: npt=10-15;npt=18-20 8028 S->C: RTSP/2.0 200 OK 8029 CSeq: 4 8030 Session: abcdefg 8031 Range: npt=10-15 8032 RTP-Info: url="rtsp://xyz/fizzle/audiotrack" 8033 ssrc=0D12F123:seq=0;rtptime=0 8035 The ensuing RTP data stream is depicted below: 8037 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 8038 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 8039 . . . 8040 S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s 8041 S -> C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s 8042 S -> C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s 8043 . . . 8044 S -> C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s 8046 B.2.4. Handling RTP Timestamps after PAUSE 8048 During a PAUSE / PLAY interaction in an RTSP session, the duration of 8049 time for which the RTP transmission was halted MUST be reflected in 8050 the RTP timestamp of each RTP stream. The duration can be calculated 8051 for each RTP stream as the time elapsed from when the last RTP packet 8052 was sent before the PAUSE request was received and when the first RTP 8053 packet was sent after the subsequent PLAY request was received. The 8054 duration includes all latency incurred and processing time required 8055 to complete the request. 8057 The RTP RFC [RFC3550] states that: The RTP timestamp for each 8058 unit[packet] would be related to the wallclock time at which the 8059 unit becomes current on the virtual presentation timeline. 8061 In order to satisfy the requirements of [RFC3550], the RTP 8062 timestamp space needs to increase continuously with real time. 8063 While this is not optimal for stored media, it is required for RTP 8064 and RTCP to function as intended. Using a continuous RTP 8065 timestamp space allows the same timestamp model for both stored 8066 and live media and allows better opportunity to integrate both 8067 types of media under a single control. 8069 As an example, assume a clock frequency of 8000 Hz, a packetization 8070 interval of 100 ms and an initial sequence number and timestamp of 8071 zero. 8073 C->S: PLAY rtsp://xyz/fizzle RTSP/2.0 8074 CSeq: 4 8075 Session: abcdefg 8076 Range: npt=10-15; 8078 S->C: RTSP/2.0 200 OK 8079 CSeq: 4 8080 Session: abcdefg 8081 Range: npt=10-15 8082 RTP-Info: url="rtsp://xyz/fizzle/audiotrack" 8083 ssrc=0D12F123:seq=0;rtptime=0 8085 The ensuing RTP data stream is depicted below: 8087 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 8088 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 8089 S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s 8090 S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s 8092 The client then sends a PAUSE request: 8094 C->S: PAUSE rtsp://xyz/fizzle RTSP/2.0 8095 CSeq: 5 8096 Session: abdcdefg 8098 S->C: RTSP/2.0 200 OK 8099 CSeq: 5 8100 Session: abcdefg 8101 Range: npt=10.4-15 8103 20 seconds elapse and then the client sends a PLAY request. In 8104 addition the server requires 15 ms to process the request: 8106 C->S: PLAY rtsp://xyz/fizzle RTSP/2.0 8107 CSeq: 6 8108 Session: abcdefg 8110 S->C: RTSP/2.0 200 OK 8111 CSeq: 6 8112 Session: abcdefg 8113 Range: npt=10.4-15 8114 RTP-Info: url="rtsp://xyz/fizzle/audiotrack" 8115 ssrc=0D12F123:seq=4;rtptime=164400 8117 The ensuing RTP data stream is depicted below: 8119 S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s 8120 S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s 8121 S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s 8123 First, NPT 10 through 10.3 is played, then a PAUSE is received by the 8124 server. After 20 seconds a PLAY is received by the server which take 8125 15ms to process. The duration of time for which the session was 8126 paused is reflected in the RTP timestamp of the RTP packets sent 8127 after this PLAY request. 8129 A client can use the RTSP range header and RTP-Info header to map NPT 8130 time of a presentation with the RTP timestamp. 8132 Note: In RFC 2326 [RFC2326], this matter was not clearly defined and 8133 was misunderstood commonly. However for RTSP 2.0 it is expected that 8134 this will be handled correctly and no exception handling will be 8135 required. 8137 B.2.5. RTSP / RTP Integration 8139 For certain datatypes, tight integration between the RTSP layer and 8140 the RTP layer will be necessary. This by no means precludes the 8141 above restrictions. Combined RTSP/RTP media clients should use the 8142 RTP-Info field to determine whether incoming RTP packets were sent 8143 before or after a seek or before or after a PAUSE. 8145 B.2.6. Scaling with RTP 8147 For scaling (see SectionSection 14.39), RTP timestamps should 8148 correspond to the playback timing. For example, when playing video 8149 recorded at 30 frames/second at a scale of two and speed (Section 8150 Section 14.40) of one, the server would drop every second frame to 8151 maintain and deliver video packets with the normal timestamp spacing 8152 of 3,000 per frame, but NPT would increase by 1/15 second for each 8153 video frame. 8155 Note: The above scaling puts requirements on the media codec or a 8156 media stream to support it. For example motion JPEG or other non- 8157 predictive video coding can easier handle the above example. 8159 B.2.7. Maintaining NPT synchronization with RTP timestamps 8161 The client can maintain a correct display of NPT by noting the RTP 8162 timestamp value of the first packet arriving after repositioning. 8163 The sequence parameter of the RTP-Info (SectionSection 14.38) header 8164 provides the first sequence number of the next segment. 8166 B.2.8. Continuous Audio 8168 For continuous audio, the server SHOULD set the RTP marker bit at the 8169 beginning of serving a new PLAY request or at jumps in timeline. 8170 This allows the client to perform playout delay adaptation. 8172 B.2.9. Multiple Sources in an RTP Session 8174 Note that more than one SSRC MAY be sent in the media stream. If it 8175 happens all sources are expected to be rendered simultaneously. 8177 B.2.10. Usage of SSRCs and the RTCP BYE Message During an RTSP Session 8179 The RTCP BYE message indicates the end of use of a given SSRC. If 8180 all sources leave an RTP session, it can, in most cases, be assumed 8181 to have ended. Therefore, a client or server SHALL NOT send a RTCP 8182 BYE message until it has finished using a SSRC. A server SHOULD keep 8183 using a SSRC until the RTP session is terminated. Prolonging the use 8184 of a SSRC allows the established synchronization context associated 8185 with that SSRC to be used to synchronize subsequent PLAY requests 8186 even if the PLAY response is late. 8188 An SSRC collision with the SSRC that transmits media does also have 8189 consequences, as it will force the media sender to change its SSRC in 8190 accordance with the RTP specification[RFC3550]. This will result in 8191 a loss of synchronization context, and require any receiver to wait 8192 for RTCP sender reports for all media requiring synchronization 8193 before being able to play out synchronized. Due to these reasons a 8194 client joining a session should take care to not select the same SSRC 8195 as the server. Any SSRC signalled in the Transport header SHOULD be 8196 avoided. A client detecting a collision prior to sending any RTP or 8197 RTCP messages can also select a new SSRC. 8199 B.3. Future Additions 8201 It is the intention that any future protocol or profile regarding 8202 both for media delivery and lower transport should be easy to add to 8203 RTSP. This section provides the necessary steps that needs to be 8204 meet. 8206 The following things needs to be considered when adding a new 8207 protocol of profile for use with RTSP: 8209 o The protocol or profile needs to define a name tag representing 8210 it. This tag is required to be a ABNF "token" to be possible to 8211 use in the Transport header specification. 8213 o The useful combinations of protocol/profile/lower-layer needs to 8214 be defined and for each combination declare the necessary 8215 parameters to use in the Transport header. 8217 o For new media protocols the interaction with RTSP needs to be 8218 addressed. One important factor will be the media 8219 synchronization. 8221 See the IANA section (Section 21) for information how to register new 8222 attributes. 8224 Appendix C. Use of SDP for RTSP Session Descriptions 8226 The Session Description Protocol (SDP, [RFC4566]) may be used to 8227 describe streams or presentations in RTSP. This description is 8228 typically returned in reply to a DESCRIBE request on an URI from a 8229 server to a client, or received via HTTP from a server to a client. 8231 This appendix describes how an SDP file determines the operation of 8232 an RTSP session. SDP as is provides no mechanism by which a client 8233 can distinguish, without human guidance, between several media 8234 streams to be rendered simultaneously and a set of alternatives 8235 (e.g., two audio streams spoken in different languages). However the 8236 SDP extension "Grouping of Media Lines in the Session Description 8237 Protocol (SDP)" [RFC3388] may provide such functionality depending on 8238 need. Also future grouping semantics may in the future be developed. 8240 C.1. Definitions 8242 The terms "session-level", "media-level" and other key/attribute 8243 names and values used in this appendix are to be used as defined in 8244 SDP (RFC 4566 [RFC4566]): 8246 C.1.1. Control URI 8248 The "a=control:" attribute is used to convey the control URI. This 8249 attribute is used both for the session and media descriptions. If 8250 used for individual media, it indicates the URI to be used for 8251 controlling that particular media stream. If found at the session 8252 level, the attribute indicates the URI for aggregate control 8253 (presentation URI). The session level URI SHALL be different from 8254 any media level URI. The presence of a session level control 8255 attribute SHALL be interpreted as support for aggregated control. 8256 The control attribute SHALL be present on media level unless the 8257 presentation only contains a single media stream, in which case the 8258 attribute MAY only be present on the session level. 8260 ABNF for the attribute is defined in sectionSection 19.3. 8262 Example: 8264 a=control:rtsp://example.com/foo 8266 This attribute MAY contain either relative or absolute URIs, 8267 following the rules and conventions set out in RFC 3986 [RFC3986]. 8268 Implementations SHALL look for a base URI in the following order: 8270 1. the RTSP Content-Base field; 8271 2. the RTSP Content-Location field; 8273 3. the RTSP Request-URI. 8275 If this attribute contains only an asterisk (*), then the URI SHALL 8276 be treated as if it were an empty embedded URI, and thus inherit the 8277 entire base URI. 8279 The URI handling for SDPs from container files need special 8280 consideration. For example lets assume that a container file has the 8281 URI: "rtsp://example.com/container.mp4". Lets further assume this 8282 URI is the base URI, and that there is a absolute media level URI: 8283 "rtsp://example.com/container.mp4/trackID=2". A relative media level 8284 URI that resolves in accordance with RFC 3986 [RFC3986] to the above 8285 given media URI is: "container.mp4/trackID=2". It is usually not 8286 desirable to need to include in or modify the SDP stored within the 8287 container file with the server local name of the container file. To 8288 avoid this, one can modify the base URI used to include a trailing 8289 slash, e.g. "rtsp://example.com/container.mp4/". In this case the 8290 relative URI for the media will only need to be: "trackID=2". 8291 However this will also mean that using "*" in the SDP will result in 8292 control URI including the trailing slash, i.e. 8293 "rtsp://example.com/container.mp4/". 8295 Note: The usage of TrackID in the above is not an standardized 8296 form, but one example out of several similar strings such as 8297 TrackID, Track_ID, StreamID that is used by different server 8298 vendors to indicate a particular piece of media inside a container 8299 file. 8301 C.1.2. Media Streams 8303 The "m=" field is used to enumerate the streams. It is expected that 8304 all the specified streams will be rendered with appropriate 8305 synchronization. If the session is over multicast, the port number 8306 indicated SHOULD be used for reception. The client MAY try to 8307 override the destination port, through the Transport header. The 8308 servers MAY allow this, the response will indicate if allowed or not. 8309 If the session is unicast, the port number is the ones RECOMMENDED by 8310 the server to the client, about which receiver ports to use; the 8311 client MUST still include its receiver ports in its SETUP request. 8312 The client MAY ignore this recommendation. If the server has no 8313 preference, it SHOULD set the port number value to zero. 8315 The "m=" lines contain information about what transport protocol, 8316 profile, and possibly lower-layer is to be used for the media stream. 8317 The combination of transport, profile and lower layer, like RTP/AVP/ 8318 UDP needs to be defined for how to be used with RTSP. The currently 8319 defined combinations are defined in section Appendix B, further 8320 combinations MAY be specified. 8322 Usage of grouping of media lines [RFC3388] to determine which media 8323 lines should or should not be included in a RTSP session is 8324 unspecified. 8326 Example: 8328 m=audio 0 RTP/AVP 31 8330 C.1.3. Payload Type(s) 8332 The payload type(s) are specified in the "m=" line. In case the 8333 payload type is a static payload type from RFC 3551 [RFC3551], no 8334 other information may be required. In case it is a dynamic payload 8335 type, the media attribute "rtpmap" is used to specify what the media 8336 is. The "encoding name" within the "rtpmap" attribute may be one of 8337 those specified in RFC 3551 (Sections 5 and 6), or an MIME type 8338 registered with IANA, or an experimental encoding as specified in SDP 8339 (RFC 4566 [RFC4566]). Codec-specific parameters are not specified in 8340 this field, but rather in the "fmtp" attribute described below. 8342 C.1.4. Format-Specific Parameters 8344 Format-specific parameters are conveyed using the "fmtp" media 8345 attribute. The syntax of the "fmtp" attribute is specific to the 8346 encoding(s) that the attribute refers to. Note that some of the 8347 format specific parameters may be specified outside of the fmtp 8348 parameters, like for example the "ptime" attribute for most audio 8349 encodings. 8351 C.1.5. Directionality of media stream 8353 The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly" 8354 provides instructions on which direction the media streams flow 8355 within a session. When using RTSP the SDP can be delivered to a 8356 client using either RTSP DESCRIBE or a number of RTSP external 8357 methods, like HTTP, FTP, and email. Based on this the SDP applies to 8358 how the RTSP client will see the complete session. Thus for media 8359 streams delivered from the RTSP server to the client would be given 8360 the "a=recvonly" attribute. A a=sendonly in a SDP provided to the 8361 client would indicate that a media stream would be sent from the 8362 client to the server. "a=sendrecv" would indicate media transmission 8363 occurs in both directions between client and server. 8365 The direction attributes are not commonly used in SDPs for RTSP, but 8366 may occur. To reflect this reality the following rules are defined. 8368 "a=recvonly" in a SDP provided to the RTSP client SHALL indicate that 8369 media delivery will only occur in the direction from the server to 8370 the client. Thus an RTSP client shall initiate any RTSP session in 8371 the "PLAY" mode. In SDP provided to the RTSP client that lacks any 8372 of the directionality attributes (a=recvonly, a=sendonly, a=sendrecv) 8373 SHALL behave as if the "a=recvonly" attribute was received. Note 8374 that this overrules the normal default rule defined in SDP[RFC4566]. 8375 The usage of "a=sendonly" or "a=sendrecv" is not defined, nor is the 8376 interpretation of SDP by other entities than the RTSP client. 8378 C.1.6. Range of Presentation 8380 The "a=range" attribute defines the total time range of the stored 8381 session or an individual media. Non-seekable live sessions can be 8382 indicated, while the length of live sessions can be deduced from the 8383 "t" and "r" SDP parameters. 8385 The attribute is both a session and a media level attribute. For 8386 presentations that contains media streams of the same durations, the 8387 range attribute SHOULD only be used at session-level. In case of 8388 different length the range attribute MUST be given at media level for 8389 all media, and SHOULD NOT be given at session level. If the 8390 attribute is present at both media level and session level the media 8391 level values SHALL be used. 8393 Note: Usually one will specify the same length for all media, even if 8394 there isn't media available for the full duration on all media. 8395 However that requires that the server accepts PLAY requests within 8396 that range. 8398 Servers SHALL take care to provide RTSP Range (see 8399 SectionSection 14.34) values that are consistent with what is 8400 presented in the SDP for the content. There are no reason for non 8401 dynamic content, like media clips provided on demand to have 8402 inconsistent values. Inconsistent values between the SDP and the 8403 actual values for the content handled by the server is likely to 8404 generate some failure, like 457 "Invalid Range", in case the client 8405 uses PLAY requests with a Range header. In case the content is 8406 dynamic in length and it is infeasible to provide a correct value in 8407 the SDP the server is recommended to describe this as non-seekable 8408 content (see below). The server MAY override that property in the 8409 response to a PLAY request using the correct values in the Range 8410 header. 8412 The unit is specified first, followed by the value range. The units 8413 and their values are as defined in Section Section 3.4, Section 3.5 8414 and Section 3.6 and MAY be extended with further formats. Any open 8415 ended range (start-), i.e. without stop range, is of unspecified 8416 duration and SHALL be considered as non-seekable content unless this 8417 property is overridden. Multiple instances carrying different clock 8418 formats MAY be included at either session or media level. 8420 ABNF for the attribute is defined in sectionSection 19.3. 8422 Examples: 8424 a=range:npt=0-34.4368 8425 a=range:clock=19971113T2115-19971113T2203 8426 Non seekable stream of unknown duration: 8427 a=range:npt=0- 8429 C.1.7. Time of Availability 8431 The "t=" field MUST contain suitable values for the start and stop 8432 times for both aggregate and non-aggregate stream control. The 8433 server SHOULD indicate a stop time value for which it guarantees the 8434 description to be valid, and a start time that is equal to or before 8435 the time at which the DESCRIBE request was received. It MAY also 8436 indicate start and stop times of 0, meaning that the session is 8437 always available. 8439 For sessions that are of live type, i.e. specific start time, unknown 8440 stop time, likely unseekable, the "t=" and "r=" field SHOULD be used 8441 to indicate the start time of the event. The stop time SHOULD be 8442 given so that the live event will have ended at that time, while 8443 still not be unnecessary long into the future. 8445 C.1.8. Connection Information 8447 In SDP, the "c=" field contains the destination address for the media 8448 stream. For on-demand unicast streams and some multicast streams, 8449 the destination address MAY be specified by the client via the SETUP 8450 request, thus overriding any specified address. To identify streams 8451 without a fixed destination address, where the client is required to 8452 specify a destination address, the "c=" field SHOULD be set to a null 8453 value. For addresses of type "IP4", this value SHALL be "0.0.0.0", 8454 and for type "IP6", this value SHALL be "0:0:0:0:0:0:0:0", i.e. the 8455 unspecified address according to RFC 3513 [RFC3513]. 8457 C.1.9. Entity Tag 8459 The optional "a=etag" attribute identifies a version of the session 8460 description. It is opaque to the client. SETUP requests may include 8461 this identifier in the If-Match field (see sectionSection 14.24) to 8462 only allow session establishment if this attribute value still 8463 corresponds to that of the current description. The attribute value 8464 is opaque and may contain any character allowed within SDP attribute 8465 values. 8467 ABNF for the attribute is defined in sectionSection 19.3. 8469 Example: 8471 a=etag:158bb3e7c7fd62ce67f12b533f06b83a 8473 One could argue that the "o=" field provides identical 8474 functionality. However, it does so in a manner that would put 8475 constraints on servers that need to support multiple session 8476 description types other than SDP for the same piece of media 8477 content. 8479 C.2. Aggregate Control Not Available 8481 If a presentation does not support aggregate control no session level 8482 "a=control:" attribute is specified. For a SDP with multiple media 8483 sections specified, each section will have its own control URI 8484 specified via the "a=control:" attribute. 8486 Example: 8488 v=0 8489 o=- 2890844256 2890842807 IN IP4 192.0.2.56 8490 s=I came from a web page 8491 e=adm@example.com 8492 c=IN IP4 0.0.0.0 8493 t=0 0 8494 m=video 8002 RTP/AVP 31 8495 a=control:rtsp://audio.com/movie.aud 8496 m=audio 8004 RTP/AVP 3 8497 a=control:rtsp://video.com/movie.vid 8499 Note that the position of the control URI in the description implies 8500 that the client establishes separate RTSP control sessions to the 8501 servers audio.com and video.com. 8503 It is recommended that an SDP file contains the complete media 8504 initialization information even if it is delivered to the media 8505 client through non-RTSP means. This is necessary as there is no 8506 mechanism to indicate that the client should request more detailed 8507 media stream information via DESCRIBE. 8509 C.3. Aggregate Control Available 8511 In this scenario, the server has multiple streams that can be 8512 controlled as a whole. In this case, there are both a media-level 8513 "a=control:" attributes, which are used to specify the stream URIs, 8514 and a session-level "a=control:" attribute which is used as the 8515 Request-URI for aggregate control. If the media-level URI is 8516 relative, it is resolved to absolute URIs according to 8517 SectionAppendix C.1.1 above. 8519 Example: 8521 C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0 8522 CSeq: 1 8524 M->C: RTSP/2.0 200 OK 8525 CSeq: 1 8526 Date: 23 Jan 1997 15:35:06 GMT 8527 Content-Type: application/sdp 8528 Content-Base: rtsp://example.com/movie/ 8529 Content-Length: 228 8531 v=0 8532 o=- 2890844256 2890842807 IN IP4 192.0.2.211 8533 s=I contain 8534 i= 8535 e=adm@example.com 8536 c=IN IP4 0.0.0.0 8537 t=0 0 8538 a=control:* 8539 m=video 8002 RTP/AVP 31 8540 a=control:trackID=1 8541 m=audio 8004 RTP/AVP 3 8542 a=control:trackID=2 8544 In this example, the client is required to establish a single RTSP 8545 session to the server, and uses the URIs 8546 rtsp://example.com/movie/trackID=1 and 8547 rtsp://example.com/movie/trackID=2 to set up the video and audio 8548 streams, respectively. The URI rtsp://example.com/movie/, which is 8549 resolved from the "*", controls the whole presentation (movie). 8551 A client is not required to issues SETUP requests for all streams 8552 within an aggregate object. Servers should allow the client to ask 8553 for only a subset of the streams. 8555 C.4. RTSP external SDP delivery 8557 There are some considerations that needs to be made when the session 8558 description is delivered to client outside of RTSP, for example in 8559 HTTP or email. 8561 First of all the SDP needs to contain absolute URIs, relative will in 8562 most cases not work as the delivery will not correctly forward the 8563 base URI. And as SDP might be temporarily stored on file system 8564 before being loaded into an RTSP capable client, thus if possible to 8565 transport the base URI it still would need to be merged into the 8566 file. 8568 The writing of the SDP session availability information, i.e. "t=" 8569 and "r=", needs to be carefully considered. When the SDP is fetched 8570 by the DESCRIBE method it is with very high probability that the it 8571 is valid. However the same are much less certain for SDPs 8572 distributed using other methods. Therefore the publisher of the SDP 8573 should take care to follow the recommendations about availability in 8574 the SDP specification [RFC4566]. 8576 Appendix D. Minimal RTSP Implementation 8578 This section defines the minimal implementation requirements for RTSP 8579 agents. 8581 D.1. Minimal Core Implementation 8583 The minimal core implementation is what is required to negotiate the 8584 usage of any other features. A minimal core implementation is not 8585 supporting any other feature set will be useless as the minimal 8586 implementation doesn't deliver any service. All feature sets SHALL 8587 include the minimal core. 8589 A minimal core implementation SHALL support the following 8590 functionalities: 8592 o Establishing a connection between RTSP agents using TCP. 8594 o Implement the reception and response to the OPTIONS method. 8596 o Implement the handling of all headers mandatory or conditional in 8597 regards to the usage of the OPTIONS method. See tables Table 9 8598 andTable 10. This include at least the capability to ignore 8599 unknown headers. 8601 o Implement the headers related to capability negotiation and 8602 exchange: 8604 * Require 8606 * Supported 8608 * Proxy-Require 8610 * Proxy-Supported 8612 * Unsupported 8614 D.2. Recommended Core Implementation 8616 A RTSP Agent is also RECOMMENDED to support the following: 8618 o RTSP basic and digest authentication: The 401 response, the WWW- 8619 Authenticate and Authorization headers, and both Basic and Digest 8620 authentication methods as defined by [RFC2617]. 8622 o Secure RTSP message transport as specified by section 8623 Appendix D.4. 8625 D.3. The Basic Playback Feature Support 8627 This section defines what is required to be supported for clients, 8628 proxies and servers to be supporting the "play.basic" feature-tag. 8630 D.3.1. Client 8632 A play.basic supporting client SHALL implement the following: 8634 o The RTSP methods as required by Table 7. 8636 o All the RTSP headers that are required required or conditional in 8637 requests or responses to method required to be supported according 8638 to Tables Table 9, Table 10, Table 11, and Table 12 and in 8639 addition the following headers: 8641 * Content-Base 8643 * Content-Encoding and at least the Identity method. 8645 * Content-Location 8647 * Location 8649 * Range and the npt time format 8651 * RTP-Info 8653 o Handling of all Status code categories. 8655 o Media delivery using RTP/AVP over UDP. 8657 A play.basic supporting client is also RECOMMENDED to support the 8658 following: 8660 o Expires header 8662 o From header 8664 D.3.2. Server 8666 A play.basic supporting server SHALL implement the following: 8668 o The RTSP methods as required by Table 7. 8670 o Reception and responding to all headers specified in 8671 SectionSection 14. The implementation of functionality provided 8672 by all these header with the following exceptions: 8674 * Scale 8676 * Speed 8678 * Blocksize 8680 o Media delivery using RTP/AVP over UDP. 8682 A play.basic supporting Server is also RECOMMENDED to support the 8683 following: 8685 o XXX Editor's note: empty element in minimal.text! 8687 D.3.3. Proxy 8689 A play.basic supporting proxy SHALL implement the following: 8691 o At least passing through all the methods listed in Table 7. 8693 o The handling of all RTSP headers that are required to be handled 8694 by the server and clients supporting "play.basic" and in addition 8695 the following headers: 8697 * Cache-Control 8699 * Expires 8701 * Via 8703 D.4. Secure Transport 8705 Any Client, Proxy or Server supporting secure transport of RTSP 8706 messages and usage of the "rtsps" URI scheme SHALL implement; The 8707 Accept-Credentials and Connection-Credentials headers; TLS over TCP. 8709 Appendix E. Requirements for Unreliable Transport of RTSP 8711 This section provides any one intending to define how to transport of 8712 RTSP messages over a unreliable transport protocol with some 8713 information learned by the attempt in RFC 2326 [RFC2326]. RFC 2326 8714 define both an URI scheme and some basic functionality for transport 8715 of RTSP messages over UDP, however it was not sufficient for reliable 8716 usage and successful interoperability. 8718 The RTSP scheme defined for unreliable transport of RTSP messages was 8719 "rtspu". It has been reserved by this specification as at least one 8720 commercial implementation exist, thus avoiding any collisions in the 8721 name space. 8723 The following considerations should exist for operation of RTSP over 8724 an unreliable transport protocol: 8726 o Request shall be acknowledged by the receiver. If there is no 8727 acknowledgement, the sender may resend the same message after a 8728 timeout of one round-trip time (RTT). Any retransmissions due to 8729 lack of acknowledgement must carry the same sequence number as the 8730 original request. 8732 o The round-trip time can be estimated as in TCP (RFC 1123) 8733 [RFC1123], with an initial round-trip value of 500 ms. An 8734 implementation may cache the last RTT measurement as the initial 8735 value for future connections. 8737 o If RTSP is used over a small-RTT LAN, standard procedures for 8738 optimizing initial TCP round trip estimates, such as those used in 8739 T/TCP (RFC 1644) [RFC1644], can be beneficial. 8741 o The Timestamp header (SectionSection 14.44) is used to avoid the 8742 retransmission ambiguity problem XXY Need ref for Stev94:TCP and 8743 obviates the need for Karn's algorithm. 8745 o The registered default port for RTSP over UDP for the server is 8746 554. 8748 o RTSP messages can be carried over any lower-layer transport 8749 protocol that is 8-bit clean. 8751 o RTSP messages are vulnerable to bit errors and should not be 8752 subjected to them. 8754 o Source authentication, or at least validation that RTSP messages 8755 comes from the same entity becomes extremely important, as session 8756 hijacking may be substantially easier for RTSP message transport 8757 using an unreliable protocol like UDP than for TCP. 8759 There exist two RTSP headers thats primarily are intended for being 8760 used by the unreliable handling of RTSP messages and which will be 8761 maintained: 8763 o [CSeq] See sectionSection 14.19 8765 o [Timestamp] See sectionSection 14.44 8767 Appendix F. Backwards Compatibility Considerations 8769 This section contains notes on issues about backwards compatibility 8770 with clients or servers being implemented according to RFC 2326 8771 [RFC2326]. Note that there exist no requirement to implement RTSP 8772 1.0, in fact we recommend against it as it is difficult to do in an 8773 interoperable way. 8775 A server implementing RTSP/2.0 MUST include a RTSP-Version of 8776 RTSP/2.0 in all responses to requests containing RTSP-Version 8777 RTSP/2.0. If a server receives a RTSP/1.0 request, it MAY respond 8778 with a RTSP/1.0 response if it chooses to support RFC 2326. If the 8779 server chooses not to support RFC 2326, it SHOULD respond with a 505 8780 (RTSP Version not supported) status code. A server MUST NOT respond 8781 to a RTSP-Version RTSP/1.0 request with a RTSP-Version RTSP/2.0 8782 response. 8784 Clients implementing RTSP/2.0 MAY use an OPTIONS request with a RTSP- 8785 Version of 2.0 to determine whether a server supports RTSP/2.0. If 8786 the server responds with either a RTSP-Version of 1.0 or a status 8787 code of 505 (RTSP Version not supported), the client will have to use 8788 RTSP/1.0 requests if it chooses to support RFC 2326. 8790 In RFC 2326, receivers were advised to be prepared to also interpret 8791 CR and LF by themselves as line terminators in addition to CRLF. If 8792 a server or client wishes to support RFC 2326, it should treat a CR 8793 or LF by itself as a CRLF. 8795 F.1. Play Request in Play mode 8797 The behavior in the server when a Play is received in Play mode has 8798 changed (SectionSection 11.4). In RFC 2326, the new PLAY request 8799 would be queued until the current Play completed. Any new PLAY 8800 request now take effect immediately replacing the previous request. 8802 F.2. Using Persistent Connections 8804 Some server implementations of RFC 2326 maintain a one-to-one 8805 relationship between a connection and an RTSP session. Such 8806 implementations require clients to use a persistent connection to 8807 communicate with the server and when a client closes its connection, 8808 the server may remove the RTSP session. This is worth noting if a 8809 RTSP 2.0 client also supporting 1.0 connects to a 1.0 server. 8811 Appendix G. Open Issues 8813 This section contains a list of open issues that still needs to be 8814 resolved. However also any open issues in the bug tracker at 8815 http://rtspspec.sourceforge.net should also be considered. 8817 1. Should the SMPTE range format be updated to support the 50 and 8818 60 frames per second modes? 8820 2. Should we define a recommended format for error message bodies? 8822 3. Today there is no recommended or required format for 300 8823 response entities containing URI lists. Should one be defined? 8825 4. Should the dest_addr parameter in the Transport header in 8826 responses include the destination used by the server? 8828 5. Should a IPv6 multicast scope parameter for the Transport header 8829 be defined? This would be similar to TTL. 8831 6. The Expires header (SectionSection 14.22 contains the below 8832 paragraph: 8834 Expires header field with a date value of some time in the 8835 future on a media stream that otherwise would by default be non- 8836 cacheable indicates that the media stream is cacheable, unless 8837 indicated otherwise by a Cache-Control header field (Section 8838 Section 14.10). 8840 Is there any purpose for this in RTSP, or could we remove this 8841 statement and instead rely on the Cache-Control header? 8843 7. Should proxies strip out the credentials for themselves when 8844 forwarding messages with Accept-Credentials? 8846 8. Is Session ID combined with TLS a sufficient mechanism to 8847 prevent hijacking? 8849 9. Move to start TLS mechanism like the one defined in RFC 2817? 8851 10. Look into the GRID communities proxy-certs and see how this 8852 relates to the current TLS proxy solution. 8854 11. Resolve Eric Rescorlas security comments on the Proxy TLS 8855 solution: 8857 1. There doesn't seem to be any way to communicate your cipher 8858 suite preferences. 8860 2. I don't see how certificate-based client authentication 8861 works. Is it supposed to? 8863 3. You need to provide the entire cert chain in Connection- 8864 Credentials, not just the certificate. 8866 12. Consider to switch to SHA256 instead of SHA1 for the digest over 8867 the DER encoded certs. 8869 13. Resolve the following Stephen Farrel issue: "C. I don't 8870 understand how the client-side proxies can be expected to know 8871 enough about proxies existing toward the server. If they don't 8872 then I'm not sure how they can be expected to make any decision 8873 that's better than would be the case were policy to be dealt 8874 with solely on a hop-by-hop basis. Maybe I'm missing something 8875 that can provide that information?" 8877 14. Resolve the following Stephen Farrel issue: "D. The "User" 8878 policy model is that a client presents acceptable name/URIs and 8879 digests to the proxy. TLS doesn't really provide a way for that 8880 proxy, as a client, to ask the server for the "right" 8881 certificate, so I suspect there's a gap here that'll be hard to 8882 fill. (If the client imposed a constraint as to the root-CA 8883 that had to be used then that'd map to the next TLS connection, 8884 but maybe it'd be too coarse-grained?)" 8886 Appendix H. Changes 8888 Compared to RTSP 1.0 (RFC 2326), the below changes has been made when 8889 defining RTSP 2.0. Note that this list does not reflect minor 8890 changes in wording or correction of typographical errors. 8892 o The Transport header has been changed in the following way: 8894 * The ABNF has been changed to define that extensions are 8895 possible, and that unknown extension parameters are to be 8896 ignored. 8898 * To prevent backwards compatibility issues, any extension or new 8899 parameter requires the usage of a feature-tag combined with the 8900 Require header. 8902 * Syntax unclarities with the Mode parameter has been resolved. 8904 * Syntax error with ";" for multicast and unicast has been 8905 resolved. 8907 * Two new addressing parameters has been defined, src_addr and 8908 dest_addr. These replaces the parameters "port", 8909 "client_port", "server_port", "destination", "source". 8911 * Support for IPv6 explicit addresses in all address fields has 8912 been included. 8914 * To handle URI definitions that contain ";" or "," a quoted URI 8915 format has been introduced and is required. 8917 * Defined IANA registries for the transport headers parameters, 8918 transport-protocol, profile, lower-transport, and mode. 8920 * The transport headers interleaved parameter's text was made 8921 more strict and use formal requirements levels. It was also 8922 clarified that the interleaved channels are symmetric and that 8923 it is the server that sets the channel numbers. 8925 * It has been clarified that the client can't request of the 8926 server to use a certain RTP SSRC, using a request with the 8927 transport parameter SSRC. 8929 * Syntax definition for SSRC has been clarified to require 8HEX. 8930 It has also been extend to allow multiple values for clients 8931 supporting this version. 8933 * Clarified the text on the transport headers "dest_addr" 8934 parameters regarding what security precautions the server is 8935 required to perform. 8937 o The Range formats has been changed in the following way: 8939 * The NPT format has been given a initial NPT identifier that 8940 must now be used. 8942 * All formats now support initial open ended formats of type 8943 "npt=-10". 8945 o RTSP message handling has been changed in the following way: 8947 * RTSP messages now uses URIs rather then URLs. 8949 * It has been clarified that a 4xx message due to missing CSeq 8950 header shall be returned without a CSeq header. 8952 * Rules for how to handle timing out RTSP messages has been 8953 added. 8955 o The HTTP references has been updated to RFC 2616 and RFC 2617. 8956 This has resulted in that the Public, and the Content-Base header 8957 needed to be defined in the RTSP specification. Known effects on 8958 RTSP due to HTTP clarifications: 8960 * Content-Encoding header can include encoding of type 8961 "identity". 8963 o The state machine section has completely been rewritten. It 8964 includes now more details and are also more clear about the model 8965 used. 8967 o A IANA section has been included with contains a number of 8968 registries and their rules. This will allow us to use IANA to 8969 keep track of RTSP extensions. 8971 o Than transport of RTSP messages has seen the following changes: 8973 * The use of UDP for RTSP message transport has been deprecated 8974 due to missing interest and to broken specification. 8976 * The rules for how TCP connections is to be handled has been 8977 clarified. Now it is made clear that servers should not close 8978 the TCP connection unless they have been unused for significant 8979 time. 8981 * Strong recommendations why server and clients should use 8982 persistent connections has also been added. 8984 * There is now a requirement on the servers to handle non- 8985 persistent connections as this provides fault tolerance. 8987 * Added wording on the usage of Connection:Close for RTSP. 8989 * specified usage of TLS for RTSP messages, including a scheme to 8990 approve a proxies TLS connection to the next hop. 8992 o The following header related changes have been made: 8994 * Accept-Ranges response header is added. This header clarifies 8995 which range formats that can be used for a resource. 8997 * Changed the Range header to allow multiple ranges for creating 8998 editing list. 9000 * Fixed the missing definitions for the Cache-Control header. 9001 Also added to the syntax definition the missing delta-seconds 9002 for max-stale and min-fresh parameters. 9004 * Put requirement on CSeq header that the value is increased by 9005 one for each new RTSP request. A Recommendation to start at 1 9006 has also been added. 9008 * Added requirement that the Date header must be used for all 9009 messages with entity and the Server should always include it. 9011 * Removed possibility of using Range header with Scale header to 9012 indicate when it is to be activated, since it can't work as 9013 defined. Also added rule that lack of Scale header in response 9014 indicates lack of support for the header. Feature-tags for 9015 scaled playback has been defined. 9017 * The Speed header must now be responded to indicate support and 9018 the actual speed going to be used. A feature-tag is defined. 9019 Notes on congestion control was also added. 9021 * The Supported header was borrowed from SIP to help with the 9022 feature negotiation in RTSP. 9024 * Clarified that the Timestamp header can be used to resolve 9025 retransmission ambiguities. 9027 * The Session header text has been expanded with a explanation on 9028 keep alive and which methods to use. SETPARAMETER is now 9029 recommended to use if only keep-alive within RTSP is desired. 9031 * It has been clarified how the Range header formats is used to 9032 indicate pause points in the PAUSE response. 9034 * Clarified that RTP-Info URIs that are relative, uses the 9035 Request-URI as base URI. Also clarified that used URI must be 9036 that one that was used in the SETUP request. They are now also 9037 required to be quoted. The header also expresses the SSRC for 9038 the provided RTP timestamp and sequence number values. 9040 * Added text that requires the Range to always be present in PLAY 9041 responses. Clarified what should be sent in case of live 9042 streams. 9044 * The headers table has been updated using a structured borrowed 9045 from SIP. Those tables carries much more information and 9046 should provide a good overview of the available headers. 9048 * It has been is clarified that any message with a message body 9049 is required to have a Content-Length header. This was the case 9050 in RFC 2326 but could be misinterpreted. 9052 * To resolve functionality around ETag. The ETag and If-None- 9053 Match header has been added from HTTP with necessary 9054 clarification in regards to RTSP operation. 9056 * Imported the Public header from HTTP RFC 2068 [RFC2068] since 9057 it has been removed from HTTP due to lack of use. Public is 9058 used quite frequently in RTSP. 9060 * Clarified rules for populating the Public header so that it is 9061 an intersection of the capabilities of all the RTSP agents in a 9062 chain. 9064 o The Protocol Syntax has been changed in the following way: 9066 * All BNF definitions are updated according to the rules defined 9067 in RFC 4234 [RFC4234] and has been gathered in a separate 9068 sectionSection 19. 9070 * The BNF for the User-Agent and Server headers has been 9071 corrected so now only the description is in the HTTP 9072 specification. 9074 * Some definitions in the introduction regarding the RTSP session 9075 has been changed. 9077 * The protocol has been made fully IPv6 capable. Certain of the 9078 functionality, like using explicit IPv6 addresses in fields 9079 requires that the protocol support this updated specification. 9081 * Added a fragment part to the RTSP URI. This seem to be 9082 indicated by the note below the definition however it was not 9083 part of the BNF. 9085 * The CHAR rule has been changed to exclude NULL. 9087 o The Status codes has been changed in the following way: 9089 * The use of status code 303 "See Other" has been deprecated as 9090 it does not make sense to use in RTSP. 9092 * When sending response 451 and 458 the response body should 9093 contain the offending parameters. 9095 * Clarification on when a 3rr redirect status code can be 9096 received has been added. This includes receiving 3rr as a 9097 result of request within a established session. This provides 9098 clarification to a previous unspecified behavior. 9100 * Removed the 201 (Created) and 250 (Low On Storage Space) status 9101 codes as they are only relevant to recording, which is 9102 deprecated. 9104 o The following functionality has been deprecated from the protocol: 9106 * The use of Queued Play. 9108 * The use of PLAY method for keep-alive in play state. 9110 * The RECORD and ANNOUNCE methods and all related functionality. 9111 Some of the syntax has been removed. 9113 * The possibility to use timed execution of methods with the time 9114 parameter in the Range header. 9116 * The description on how rtspu works is not part of the core 9117 specification and will require external description. Only that 9118 it exist is defined here and some requirements for the the 9119 transport is provided. 9121 o The following changes has been made in relation to methods: 9123 * The OPTIONS method has been clarified with regards to the use 9124 of the Public and Allow headers. 9126 * The RECORD and ANNOUNCE methods are removed as they are lacking 9127 implementation and not considered necessary in the core 9128 specification. Any work on these methods should be done as a 9129 extension document to RTSP. 9131 * Added text clarifying the usage of SETPARAMETER for keep-alive 9132 and usage without any body. 9134 * PLAY method is now allowed to be pipelined with the pipelining 9135 of one or more SETUP requests following the initial that 9136 generates the session for aggregated control. 9138 o Wrote a new section about how to setup different media transport 9139 alternatives and their profiles, and lower layer protocols. This 9140 resulted that the appendix on RTP interaction was moved there 9141 instead in the part describing RTP. The section also includes 9142 guidelines what to think of when writing usage guidelines for new 9143 protocols and profiles. 9145 o Setup and usage of independent TCP connections for transport of 9146 RTP has been specified. 9148 o Added a new section describing the available mechanisms to 9149 determine if functionality is supported, called "Capability 9150 Handling". Renamed option-tags to feature-tags. 9152 o Added a contributors section with people who have contributed 9153 actual text to the specification. 9155 o Added a section Use Cases that describes the major use cases for 9156 RTSP. 9158 o Clarified the usage of a=range and how to indicate live content 9159 that are not seekable with this header. 9161 o Text specifying the special behavior of PLAY for live content. 9163 H.1. Changes needing to be updated 9165 The minimal implementation specification has been changed: 9167 o Required Timestamp, Via, and Unsupported headers for a minimal 9168 server implementation. 9170 o Recommended that Cache-Control, Expires and Date headers be 9171 supported by server implementations. 9173 Appendix I. Contributors 9175 The following people have made written contributions that were 9176 included in the specification: 9178 o Tom Marshall contributed text on the usage of 3rr status codes. 9180 o Thomas Zheng contributed text on the usage of the Range in PLAY 9181 responses. 9183 o Sean Sheedy contributed text on the timeout behavior of RTSP 9184 messages and connections, and the 463 status code. 9186 o Fredrik Lindholm contributed text about the RTSP security 9187 framework. 9189 o John Lazzaro contributed the text for RTP over Independent TCP. 9191 The following people have provided detailed comments on updated 9192 versions of this specification: 9194 o Stephan Wenger 9196 Appendix J. Acknowledgements 9198 This draft is based on the functionality of the original RTSP draft 9199 submitted in October 1996. It also borrows format and descriptions 9200 from HTTP/1.1. 9202 This document has benefited greatly from the comments of all those 9203 participating in the MMUSIC-WG. In addition to those already 9204 mentioned, the following individuals have contributed to this 9205 specification: 9207 Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning, 9208 Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari, 9209 Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V. 9210 Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt, 9211 John K. Ho, Go Hori, Philipp Hoschka, Anne Jones, Anders Klemets, 9212 Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Thomas 9213 Marshall, Rob McCool, David Oran, Joerg Ott, Maria Papadopouli, Sujal 9214 Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Igor Plotnikov, 9215 Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff Smith, 9216 Alexander Sokolsky, Dale Stammen, John Francis Stracke, Maureen 9217 Chesire, David Walker, Geetha Srikantan, Stephan Wenger, Pekka Pessi, 9218 Jae-Hwan Kim, Holger Schmidt, Stephen Farrell and Mela Martti. 9220 Note: this paragraph is just a place-holder to avoid xml2rfc warnings 9221 while we assemble the new source otherwise we get warnings due to 9222 missing xref targets. Please ignore. [RFC3987]; [RFC3986]; 9223 [RFC4346]; [RFC2617]; [RFC0768]; [RFC0793]; [RFC3629]; [RFC3280]; 9224 [FIPS-pub-180-1]; [RFC3550]; [RFC2818]; [RFC2434]; [RFC4585]; 9225 [RFC3711]; [RFC4567]; [RFC3830]; [RFC4571]; [RFC3513]; 9226 [ISO.13818-1.2000]; [NOSSDAV-1997-1]; [ITU.H323.1996]; [RFC1961]; 9227 [W3C.REC-PICS-services]; [W3C.REC-PICS-labels]; [RFC1305]; 9228 [ISO.13818-6.1995]; [ISO.8601.2000]; 9230 Authors' Addresses 9232 Henning Schulzrinne 9233 Columbia University 9234 1214 Amsterdam Avenue 9235 New York, NY 10027 9236 USA 9238 Email: schulzrinne@cs.columbia.edu 9240 Anup Rao 9241 Cisco 9242 USA 9244 Email: anrao@cisco.com 9246 Rob Lanphier 9247 Real Networks 9248 Seattle, WA 9249 USA 9251 Email: robla@robla.net 9253 Magnus Westerlund 9254 Ericsson AB 9255 Torshamsgatan 23 9256 STOCKHOLM, SE-164 80 9257 SWEDEN 9259 Email: magnus.westerlund@ericsson.com 9261 Aravind 9262 Overture Computing Corp. 9263 East Windsor, NJ 08520 9264 USA 9266 Email: aravind.narasimhan@gmail.com 9267 Martin Stiemerling 9268 NEC Laboratories Europe, NEC Europe Ltd. 9269 Kurfuersten-Anlage 36 9270 Heidelberg 69115 9271 Germany 9273 Phone: +49 (0) 6221 4342 113 9274 Email: stiemerling@netlab.nec.de 9276 Full Copyright Statement 9278 Copyright (C) The IETF Trust (2007). 9280 This document is subject to the rights, licenses and restrictions 9281 contained in BCP 78, and except as set forth therein, the authors 9282 retain all their rights. 9284 This document and the information contained herein are provided on an 9285 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 9286 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 9287 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 9288 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 9289 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 9290 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 9292 Intellectual Property 9294 The IETF takes no position regarding the validity or scope of any 9295 Intellectual Property Rights or other rights that might be claimed to 9296 pertain to the implementation or use of the technology described in 9297 this document or the extent to which any license under such rights 9298 might or might not be available; nor does it represent that it has 9299 made any independent effort to identify any such rights. Information 9300 on the procedures with respect to rights in RFC documents can be 9301 found in BCP 78 and BCP 79. 9303 Copies of IPR disclosures made to the IETF Secretariat and any 9304 assurances of licenses to be made available, or the result of an 9305 attempt made to obtain a general license or permission for the use of 9306 such proprietary rights by implementers or users of this 9307 specification can be obtained from the IETF on-line IPR repository at 9308 http://www.ietf.org/ipr. 9310 The IETF invites any interested party to bring to its attention any 9311 copyrights, patents or patent applications, or other proprietary 9312 rights that may cover technology that may be required to implement 9313 this standard. Please address the information to the IETF at 9314 ietf-ipr@ietf.org. 9316 Acknowledgment 9318 Funding for the RFC Editor function is provided by the IETF 9319 Administrative Support Activity (IASA).