idnits 2.17.1 draft-ietf-mmusic-rfc2326bis-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 9620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 9631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 9638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 9644. 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 == Line 7604 has weird spacing: '...trolled by Re...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == 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 (November 19, 2007) is 6003 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 1517, but not defined == Missing Reference: 'H10' is mentioned on line 3133, but not defined == Missing Reference: 'H15' is mentioned on line 6772, but not defined == Missing Reference: 'CSeq' is mentioned on line 9101, but not defined == Missing Reference: 'Timestamp' is mentioned on line 9103, but not defined == Unused Reference: 'RFC4585' is defined on line 7592, but no explicit reference was found in the text == Unused Reference: 'NOSSDAV-1997-1' is defined on line 7634, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3gpp-26234' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-pub-180-2' == Outdated reference: A later version (-12) exists of draft-ietf-avt-profile-savpf-11 ** 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 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-05 -- 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: 13 errors (**), 0 flaws (~~), 16 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: May 22, 2008 Cisco 6 R. Lanphier 7 Real Networks 8 M. Westerlund 9 Ericsson AB 10 M. Stiemerling (Ed.) 11 NEC 12 November 19, 2007 14 Real Time Streaming Protocol 2.0 (RTSP) 15 draft-ietf-mmusic-rfc2326bis-16.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on May 22, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 This memorandum defines RTSP version 2.0 which is a revision of the 49 Proposed Standard RTSP version 1.0 which is defined in RFC 2326. 51 The Real Time Streaming Protocol, or RTSP, is an application-level 52 protocol for control over the delivery of data with real-time 53 properties. RTSP provides an extensible framework to enable 54 controlled, on-demand delivery of real-time data, such as audio and 55 video. Sources of data can include both live data feeds and stored 56 clips. This protocol is intended to control multiple data delivery 57 sessions, provide a means for choosing delivery channels such as UDP, 58 multicast UDP and TCP, and provide a means for choosing delivery 59 mechanisms based upon RTP (RFC 3550). 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 64 1.1. Scope and Background . . . . . . . . . . . . . . . . . . 8 65 1.2. RTSP Specificication Update . . . . . . . . . . . . . . 9 66 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 10 67 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . 10 68 2. RTSP Introduction . . . . . . . . . . . . . . . . . . . . . . 15 69 2.1. Protocol Properties . . . . . . . . . . . . . . . . . . 15 70 2.2. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 16 71 2.3. Overall Operation . . . . . . . . . . . . . . . . . . . 17 72 2.4. RTSP States . . . . . . . . . . . . . . . . . . . . . . 18 73 2.5. Relationship with Other Protocols . . . . . . . . . . . 19 74 3. RTSP Use Cases . . . . . . . . . . . . . . . . . . . . . . . 20 75 3.1. On-demand Playback of Stored Content . . . . . . . . . . 20 76 3.2. Unicast distribution of Live Content . . . . . . . . . . 21 77 3.3. On-demand Playback using Multicast . . . . . . . . . . . 22 78 3.4. Inviting an RTSP server into a conference . . . . . . . 22 79 3.5. Live Content using Multicast . . . . . . . . . . . . . . 23 80 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 25 81 4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 25 82 4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 25 83 4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 27 84 4.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . 27 85 4.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 27 86 4.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . 28 87 4.7. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 28 88 4.8. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 29 89 5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 30 90 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 30 91 5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 30 92 5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 30 93 5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 30 94 6. General Header Fields . . . . . . . . . . . . . . . . . . . . 32 95 7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 96 7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 33 97 7.2. Request Header Fields . . . . . . . . . . . . . . . . . 35 98 8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 37 99 8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 37 100 8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 37 101 8.2. Response Header Fields . . . . . . . . . . . . . . . . . 40 102 9. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 103 9.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 43 104 9.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 44 105 10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 45 106 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 45 107 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 46 108 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 47 109 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 48 110 10.5. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 48 111 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 49 112 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 51 113 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 52 114 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 53 115 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 54 116 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 56 117 13.3.1. Changing Transport Parameters . . . . . . . . . . . 58 118 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 59 119 13.5. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 64 120 13.6. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 66 121 13.7. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 67 122 13.8. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 68 123 13.9. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 69 124 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 73 125 15. Status Code Definitions . . . . . . . . . . . . . . . . . . . 75 126 15.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 75 127 15.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 75 128 15.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 75 129 15.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 75 130 15.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 76 131 15.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 76 132 15.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 76 133 15.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 76 134 15.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 76 135 15.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 77 136 15.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 77 137 15.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 77 138 15.4.2. 405 Method Not Allowed . . . . . . . . . . . . . . . 77 139 15.4.3. 451 Parameter Not Understood . . . . . . . . . . . . 77 140 15.4.4. 452 reserved . . . . . . . . . . . . . . . . . . . . 77 141 15.4.5. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 78 142 15.4.6. 454 Session Not Found . . . . . . . . . . . . . . . 78 143 15.4.7. 455 Method Not Valid in This State . . . . . . . . . 78 144 15.4.8. 456 Header Field Not Valid for Resource . . . . . . 78 145 15.4.9. 457 Invalid Range . . . . . . . . . . . . . . . . . 78 146 15.4.10. 458 Parameter Is Read-Only . . . . . . . . . . . . . 78 147 15.4.11. 459 Aggregate Operation Not Allowed . . . . . . . . 78 148 15.4.12. 460 Only Aggregate Operation Allowed . . . . . . . . 78 149 15.4.13. 461 Unsupported Transport . . . . . . . . . . . . . 79 150 15.4.14. 462 Destination Unreachable . . . . . . . . . . . . 79 151 15.4.15. 463 Destination Prohibited . . . . . . . . . . . . . 79 152 15.4.16. 464 Data Transport Not Ready Yet . . . . . . . . . . 79 153 15.4.17. 470 Connection Authorization Required . . . . . . . 79 154 15.4.18. 471 Connection Credentials not accepted . . . . . . 79 155 15.4.19. 472 Failure to establish secure connection . . . . . 80 156 15.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 80 157 15.5.1. 551 Option not supported . . . . . . . . . . . . . . 80 158 16. Header Field Definitions . . . . . . . . . . . . . . . . . . 81 159 16.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 90 160 16.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 90 161 16.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 91 162 16.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 91 163 16.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 91 164 16.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 91 165 16.7. Authorization . . . . . . . . . . . . . . . . . . . . . 92 166 16.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 92 167 16.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 92 168 16.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 92 169 16.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 95 170 16.12. Connection-Credentials . . . . . . . . . . . . . . . . . 95 171 16.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 96 172 16.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 96 173 16.15. Content-Language . . . . . . . . . . . . . . . . . . . . 96 174 16.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 96 175 16.17. Content-Location . . . . . . . . . . . . . . . . . . . . 97 176 16.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 97 177 16.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 97 178 16.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 97 179 16.21. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 97 180 16.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 98 181 16.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 99 182 16.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 99 183 16.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 99 184 16.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 100 185 16.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 100 186 16.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 100 187 16.29. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 100 188 16.30. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 101 189 16.31. Proxy-Authorization . . . . . . . . . . . . . . . . . . 101 190 16.32. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 101 191 16.33. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 102 192 16.34. Public . . . . . . . . . . . . . . . . . . . . . . . . . 103 193 16.35. Range . . . . . . . . . . . . . . . . . . . . . . . . . 103 194 16.36. Referer . . . . . . . . . . . . . . . . . . . . . . . . 105 195 16.37. Retry-After . . . . . . . . . . . . . . . . . . . . . . 105 196 16.38. Require . . . . . . . . . . . . . . . . . . . . . . . . 105 197 16.39. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 106 198 16.40. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 108 199 16.41. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 109 200 16.42. Server . . . . . . . . . . . . . . . . . . . . . . . . . 110 201 16.43. Session . . . . . . . . . . . . . . . . . . . . . . . . 110 202 16.44. Supported . . . . . . . . . . . . . . . . . . . . . . . 111 203 16.45. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 112 204 16.46. Transport . . . . . . . . . . . . . . . . . . . . . . . 112 205 16.47. Unsupported . . . . . . . . . . . . . . . . . . . . . . 118 206 16.48. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 118 207 16.49. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 118 208 16.50. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 118 209 16.51. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 119 210 17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 211 18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 212 19. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 123 213 19.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 123 214 19.2. Media on Demand using Pipelining . . . . . . . . . . . . 126 215 19.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 128 216 19.4. Single Stream Container Files . . . . . . . . . . . . . 131 217 19.5. Live Media Presentation Using Multicast . . . . . . . . 133 218 19.6. Capability Negotiation . . . . . . . . . . . . . . . . . 135 219 20. Security Framework . . . . . . . . . . . . . . . . . . . . . 137 220 20.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 137 221 20.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 137 222 20.3. Security and Proxies . . . . . . . . . . . . . . . . . . 138 223 20.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 139 224 20.3.2. User approved TLS procedure . . . . . . . . . . . . 140 225 21. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 226 21.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 143 227 21.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 145 228 21.2.1. Generic Protocol elements . . . . . . . . . . . . . 145 229 21.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 148 230 21.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 152 231 21.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 159 232 22. Security Considerations . . . . . . . . . . . . . . . . . . . 160 233 22.1. Remote denial of Service Attack . . . . . . . . . . . . 162 234 23. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 164 235 23.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 164 236 23.1.1. Description . . . . . . . . . . . . . . . . . . . . 164 237 23.1.2. Registering New Feature-tags with IANA . . . . . . . 165 238 23.1.3. Registered entries . . . . . . . . . . . . . . . . . 165 239 23.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 165 240 23.2.1. Description . . . . . . . . . . . . . . . . . . . . 165 241 23.2.2. Registering New Methods with IANA . . . . . . . . . 165 242 23.2.3. Registered Entries . . . . . . . . . . . . . . . . . 166 243 23.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 166 244 23.3.1. Description . . . . . . . . . . . . . . . . . . . . 166 245 23.3.2. Registering New Status Codes with IANA . . . . . . . 166 246 23.3.3. Registered Entries . . . . . . . . . . . . . . . . . 166 247 23.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 166 248 23.4.1. Description . . . . . . . . . . . . . . . . . . . . 166 249 23.4.2. Registering New Headers with IANA . . . . . . . . . 167 250 23.4.3. Registered entries . . . . . . . . . . . . . . . . . 167 251 23.5. Transport Header Registries . . . . . . . . . . . . . . 168 252 23.5.1. Transport Protocol Specification . . . . . . . . . . 168 253 23.5.2. Transport modes . . . . . . . . . . . . . . . . . . 169 254 23.5.3. Transport Parameters . . . . . . . . . . . . . . . . 170 255 23.6. Cache Directive Extensions . . . . . . . . . . . . . . . 170 256 23.7. Accept-Credentials . . . . . . . . . . . . . . . . . . . 171 257 23.7.1. Accept-Credentials policies . . . . . . . . . . . . 171 258 23.7.2. Accept-Credentials hash algorithms . . . . . . . . . 171 259 23.8. Range header formats . . . . . . . . . . . . . . . . . . 172 260 23.9. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 172 261 23.9.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 172 262 23.9.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 173 263 23.9.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 174 264 23.10. SDP attributes . . . . . . . . . . . . . . . . . . . . . 175 265 24. References . . . . . . . . . . . . . . . . . . . . . . . . . 176 266 24.1. Normative References . . . . . . . . . . . . . . . . . . 176 267 24.2. Informative References . . . . . . . . . . . . . . . . . 178 268 Appendix A. RTSP Protocol State Machine . . . . . . . . . . . . 181 269 A.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 181 270 A.2. State variables . . . . . . . . . . . . . . . . . . . . 181 271 A.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 181 272 A.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 182 273 Appendix B. Media Transport Alternatives . . . . . . . . . . . . 187 274 B.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 187 275 B.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 187 276 B.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 187 277 B.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 188 278 B.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 189 279 B.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 189 280 B.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 189 281 B.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 190 282 B.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 190 283 B.2.2. RTP over independent TCP . . . . . . . . . . . . . . 190 284 B.2.3. Handling NPT Jumps in the RTP Media Layer . . . . . 194 285 B.2.4. Handling RTP Timestamps after PAUSE . . . . . . . . 197 286 B.2.5. RTSP / RTP Integration . . . . . . . . . . . . . . . 199 287 B.2.6. Scaling with RTP . . . . . . . . . . . . . . . . . . 199 288 B.2.7. Maintaining NPT synchronization with RTP 289 timestamps . . . . . . . . . . . . . . . . . . . . . 199 290 B.2.8. Continuous Audio . . . . . . . . . . . . . . . . . . 199 291 B.2.9. Multiple Sources in an RTP Session . . . . . . . . . 199 292 B.2.10. Usage of SSRCs and the RTCP BYE Message During an 293 RTSP Session . . . . . . . . . . . . . . . . . . . . 199 294 B.3. Future Additions . . . . . . . . . . . . . . . . . . . . 200 295 Appendix C. Use of SDP for RTSP Session Descriptions . . . . . . 201 296 C.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 201 297 C.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 201 298 C.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 202 299 C.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 203 300 C.1.4. Format-Specific Parameters . . . . . . . . . . . . . 203 301 C.1.5. Directionality of media stream . . . . . . . . . . . 203 302 C.1.6. Range of Presentation . . . . . . . . . . . . . . . 204 303 C.1.7. Time of Availability . . . . . . . . . . . . . . . . 205 304 C.1.8. Connection Information . . . . . . . . . . . . . . . 205 305 C.1.9. Entity Tag . . . . . . . . . . . . . . . . . . . . . 205 306 C.2. Aggregate Control Not Available . . . . . . . . . . . . 206 307 C.3. Aggregate Control Available . . . . . . . . . . . . . . 206 308 C.4. RTSP external SDP delivery . . . . . . . . . . . . . . . 207 309 Appendix D. Minimal RTSP Implementation . . . . . . . . . . . . 209 310 D.1. Minimal Core Implementation . . . . . . . . . . . . . . 209 311 D.2. Recommended Core Implementation . . . . . . . . . . . . 209 312 D.3. The Basic Playback Feature Support . . . . . . . . . . . 210 313 D.3.1. Client . . . . . . . . . . . . . . . . . . . . . . . 210 314 D.3.2. Server . . . . . . . . . . . . . . . . . . . . . . . 210 315 D.3.3. Proxy . . . . . . . . . . . . . . . . . . . . . . . 211 316 D.4. Secure Transport . . . . . . . . . . . . . . . . . . . . 211 317 Appendix E. Requirements for Unreliable Transport of RTSP . . . 212 318 Appendix F. Backwards Compatibility Considerations . . . . . . . 214 319 F.1. Play Request in Play mode . . . . . . . . . . . . . . . 214 320 F.2. Using Persistent Connections . . . . . . . . . . . . . . 214 321 Appendix G. Open Issues . . . . . . . . . . . . . . . . . . . . 215 322 Appendix H. Changes . . . . . . . . . . . . . . . . . . . . . . 217 323 H.1. Changes needing to be updated . . . . . . . . . . . . . 222 324 Appendix I. Acknowledgements . . . . . . . . . . . . . . . . . . 224 325 I.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 224 326 Appendix J. RFC Editor Consideration . . . . . . . . . . . . . . 226 327 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 227 328 Intellectual Property and Copyright Statements . . . . . . . . . 228 330 1. Introduction 332 1.1. Scope and Background 334 This memo defines version 2.0 of the Real Time Streaming Protocol 335 (RTSP 2.0) which is an application-level protocol for control over 336 the delivery of data with real-time properties, typically streaming 337 media. Streaming media is, for instance, video on demand or audio 338 life streaming. Put simply, RTSP acts as a "network remote control" 339 for multimedia servers, as you know it from your TV set. 341 The protocol operates between RTSP 2.0 clients and servers, but also 342 supports the usage of RTSP 2.0 proxies between clients and servers. 343 Basically, clients can request information about streaming media from 344 servers, by asking for a description of the media or use media 345 description provided externally. Based on the media description 346 clients can request to play out the media, pause it, or stop it 347 completely, as known from a regular TV remote control. The requested 348 media can consist of multiple audio and video streams that are 349 delivered as a time- synchronized stream from servers to clients. 351 This memorandum describes the use of RTSP over a reliable connection 352 based transport level protocol, such as TCP. For security, TLS over 353 a connection oriented transport is supported. 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 The set of streams to be controlled in an RTSP session is defined by 364 a presentation description. This memorandum does not define a format 365 for the presentation description. However Appendix C describes how 366 SDP [RFC4566] is used for this purpose. The streams controlled by 367 RTSP may use RTP [RFC3550] for their data transport, but the 368 operation of RTSP does not depend on the transport mechanism used to 369 carry continuous media. RTSP is intentionally similar in syntax and 370 operation to HTTP/1.1 [RFC2616] so that extension mechanisms to HTTP 371 can in most cases also be applied to RTSP. However, RTSP differs in 372 a number of important aspects from HTTP: 374 * RTSP introduces a number of new methods and has a different 375 protocol identifier. 377 * RTSP has the notion of a session built into the protocol. 379 * An RTSP server needs to maintain state in almost all cases, as 380 opposed to the stateless nature of HTTP. 382 * Both an RTSP server and client can issue requests. 384 * Data is usually carried out-of-band by a different protocol. 385 Session descriptions returned in a DESCRIBE response (see 386 Section 13.2) and interleaving of RTP with RTSP over TCP are 387 exceptions to this rule (see Section 14). 389 * RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 390 8859-1, consistent with HTML internationalization efforts 391 [RFC2070]. 393 * The Request-URI always contains the absolute URI. Because of 394 backward compatibility with a historical blunder, HTTP/1.1 395 [RFC2616] carries only the absolute path in the request and 396 puts the host name in a separate header field. 397 This makes "virtual hosting" easier, where a single host with 398 one IP address hosts several document trees. 400 The protocol supports the following operations: 402 Retrieval of media from media server: The client can either request 403 a presentation description via RTSP DESCRIBE, HTTP or some 404 other method. If the presentation is being multicast, the 405 presentation description contains the multicast addresses and 406 ports to be used for the continuous media. If the presentation 407 is to be sent only to the client via unicast, the client 408 provides the destination. 410 Invitation of a media server to a conference: A media server can be 411 "invited" to join an existing conference to play back media 412 into the presentation. This mode is useful, for example, in 413 distributed teaching applications. Several parties in the 414 conference may take turns "pushing the remote control buttons". 415 Note: This functionality will require RTSP external application 416 level functionality. 418 RTSP requests may be handled by proxies, tunnels and caches as in 419 HTTP/1.1 [RFC2616]. 421 1.2. RTSP Specificication Update 423 This memorandum specifies RTSP 2.0 which is an update of RTSP 1.0, a 424 proposed standard defined in [RFC2326]. The goal of this version is 425 to correct the many flaws that have been identified in RTSP 1.0 since 426 its publication. The corrections are such that backwards 427 compatibility was impossible. Thus a new version was deemed the most 428 appropriate solution to get a more functional protocol. There are no 429 plans to revise RTSP 1.0. Appendix H catalogs the changes of this 430 version in relation to RTSP 1.0. 432 RTSP 2.0 has reduced functionality compared to RTSP 1.0 and aims at 433 specifying the RTSP core, functionality and rules for extensions, and 434 basic interaction with the media delivery protocol RTP [RFC3550]. 436 Any other functionality would need to be published as extension 437 documents. This specification provides rules for such extensions and 438 defines registries to avoid naming collisions. 440 1.3. Notational Conventions 442 Since many of the definitions and syntax are identical to HTTP/1.1, 443 this specification only points to the section where they are defined 444 rather than copying it. For brevity, [HX.Y] is to be taken to refer 445 to Section X.Y of the current HTTP/1.1 specification ([RFC2616]). 447 All the mechanisms specified in this document are described in both 448 prose and the Augmented Backus-Naur form (ABNF) described in detail 449 in [RFC4234]. 451 Indented and smaller-type paragraphs are used to provide informative 452 background and motivation. This is intended to give readers who were 453 not involved with the formulation of the specification an 454 understanding of why things are the way they are in RTSP. 456 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 457 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 458 document are to be interpreted as described in [RFC2119]. 460 The word, "unspecified" is used to indicate functionality or features 461 that are not defined in this specification. Such functionality 462 cannot be used in a standardized manner without further definition in 463 an extension specification to RTSP. 465 1.4. Terminology 467 Some of the terminology has been adopted from HTTP/1.1 [RFC2616]. 468 Terms not listed here are defined as in HTTP/1.1. 470 Aggregate control: The concept of controlling multiple streams using 471 a single timeline, generally maintained by the server. A client, 472 for example, uses aggregate control when it issues a single play 473 or pause message to simultaneously control both the audio and 474 video in a movie. A session which is under aggregate control is 475 referred to as an aggregated session. 477 Aggregate control URI: The URI used in an RTSP request to refer to 478 and control an aggregated session. It normally, but not always, 479 corresponds to the presentation URI specified in the session 480 description. See Section 13.3 for more information. 482 Conference: A multiparty, multimedia presentation, where "multi" 483 implies greater than or equal to one. 485 Client: The client requests media service from the media server. 487 Connection: A transport layer virtual circuit established between 488 two programs for the purpose of communication. 490 Container file: A file which may contain multiple media streams 491 which often constitutes a presentation when played together. The 492 concept of a container file is not embedded in the protocol. 493 However, RTSP servers may offer aggregate control on the media 494 streams within these files. 496 Continuous media: Data where there is a timing relationship between 497 source and sink; that is, the sink needs to reproduce the timing 498 relationship that existed at the source. The most common examples 499 of continuous media are audio and motion video. Continuous media 500 can be real-time (interactive or conversational), where there is a 501 "tight" timing relationship between source and sink, or streaming 502 (playback), where the relationship is less strict. 504 Entity: The information transferred as the payload of a request or 505 response. An entity consists of meta-information in the form of 506 entity-header fields and content in the form of an entity-body, as 507 described in Section 9. 509 Feature-tag: A tag representing a certain set of functionality, i.e. 510 a feature. 512 IRI: Internationalized Resource Identifier, is the same as an URI, 513 with the exception that it allows characters from the whole 514 Universal Character Set (Unicode/ISO 10646), rather than the US- 515 ASCII only. See [RFC3987] for more information. 517 Live: Normally used to describe a presentation or session with media 518 coming from an ongoing event. This generally results in the 519 session having an unbound or only loosely defined duration, and 520 sometimes no seek operations are possible. 522 Media initialization: Datatype/codec specific initialization. This 523 includes such things as clock rates, color tables, etc. Any 524 transport-independent information which is required by a client 525 for playback of a media stream occurs in the media initialization 526 phase of stream setup. 528 Media parameter: Parameter specific to a media type that may be 529 changed before or during stream playback. 531 Media server: The server providing playback services for one or more 532 media streams. Different media streams within a presentation may 533 originate from different media servers. A media server may reside 534 on the same host or on a different host from which the 535 presentation is invoked. 537 Media server indirection: Redirection of a media client to a 538 different media server. 540 (Media) stream: A single media instance, e.g., an audio stream or a 541 video stream as well as a single whiteboard or shared application 542 group. When using RTP, a stream consists of all RTP and RTCP 543 packets created by a source within an RTP session. 545 Message: The basic unit of RTSP communication, consisting of a 546 structured sequence of octets matching the syntax defined in 547 Section 21 and transmitted over a connection or a connectionless 548 transport. 550 Non-Aggregated Control: Control of a single media stream. This is 551 only possible in RTSP sessions with a single media. 553 Participant: Member of a conference. A participant may be a 554 machine, e.g., a playback server. 556 Presentation: A set of one or more streams presented to the client 557 as a complete media feed and described by a presentation 558 description as defined below. Presentations with more than one 559 media stream are often handled in RTSP under aggregate control. 561 Presentation description: A presentation description contains 562 information about one or more media streams within a presentation, 563 such as the set of encodings, network addresses and information 564 about the content. Other IETF protocols such as SDP ([RFC4566]) 565 use the term "session" for a presentation. The presentation 566 description may take several different formats, including but not 567 limited to the session description protocol format, SDP. 569 Response: An RTSP response. If an HTTP response is meant, that is 570 indicated explicitly. 572 Request: An RTSP request. If an HTTP request is meant, that is 573 indicated explicitly. 575 Request-URI: The URI used in a request to indicate the resource on 576 which the request is to be performed. 578 RTSP agent: Refers to either an RTSP client, an RTSP server, or an 579 RTSP Proxy. In this specification, there are many capabilities 580 that are common to these three entities such as the capability to 581 send requests or receive responses. This term will be used when 582 describing functionality that is applicable to all three of these 583 entities. 585 RTSP session: A stateful abstraction upon which the main control 586 methods of RTSP operate. An RTSP session is a server entity; it 587 is created, maintained and destroyed by the server. It is 588 established by an RTSP server upon the completion of a successful 589 SETUP request (when a 200 OK response is sent) and is labelled 590 with a session identifier at that time. The session exists until 591 timed out by the server or explicitly removed by a TEARDOWN 592 request. An RTSP session is a stateful entity; an RTSP server 593 maintains an explicit session state machine (see Appendix A) where 594 most state transitions are triggered by client requests. The 595 existence of a session implies the existence of state about the 596 session's media streams and their respective transport mechanisms. 597 A given session can have one or more media streams associated with 598 it. An RTSP server uses the session to aggregate control over 599 multiple media streams. 601 Transport initialization: The negotiation of transport information 602 (e.g., port numbers, transport protocols) between the client and 603 the server. 605 URI: Universal Resource Identifier, see [RFC3986]. The URIs used in 606 RTSP are generally URLs as they give a location for the resource. 607 As URLs are a subset of URIs, they will be referred to as URIs to 608 cover also the cases when an RTSP URI would not be an URL. 610 URL: Universal Resource Locator, is an URI which identifies the 611 resource through its primary access mechanism, rather than 612 identifying the resource by name or by some other attribute(s) of 613 that resource. 615 2. RTSP Introduction 617 2.1. Protocol Properties 619 RTSP has the following properties: 621 Extendable: New methods and parameters can be easily added to RTSP. 623 Easy to parse: RTSP can be parsed by standard HTTP or MIME parsers. 625 Secure: RTSP re-uses web security mechanisms, either at the 626 transport level (TLS, [RFC4346]) or within the protocol itself. 627 All HTTP authentication mechanisms such as basic ([RFC2616]) and 628 digest authentication ([RFC2617]) are directly applicable. 630 Transport-independent: RTSP does not preclude the use of unreliable 631 datagram protocol (UDP) ([RFC0768]) as it would be possible to 632 implement application-level reliability. The use of a 633 connectionless datagram protocol such as UDP requires additional 634 definition that may be provided as extensions to the core RTSP 635 specification. The reliable stream protocol TCP ([RFC0793]) and 636 the secured reliable stream protocol TLS over TCP [RFC4346] are 637 the currently defined transport protocols for RTSP messages. 639 Media-delivery protocol independent: The operation of RTSP does not 640 depend on the transport mechanism used to carry continuous media. 641 While most real-time media will use RTP as a transport protocol, 642 RTSP does not preclude the use of other protocols such as MPEG-2 643 [ISO.13818-1.2000]. The use of other protocols requires 644 additional definition that may be provided as extensions to the 645 core RTSP specification. 647 Multi-server capable: Each media stream within a presentation can 648 reside on a different server. The client automatically 649 establishes several concurrent control sessions with the different 650 media servers. Media synchronization in those cases is performed 651 at the transport level. 653 Separation of stream control and conference initiation: Stream 654 control is divorced from inviting a media server to a conference. 655 In particular, SIP [RFC3261] or H.323 [ITU.H323.1996] may be used 656 to invite a server to a conference; however, the exact procedures 657 are unspecified. 659 Suitable for professional applications: RTSP supports frame- level 660 accuracy through SMPTE time stamps to allow remote digital 661 editing. 663 Presentation description neutral: The protocol does not impose a 664 particular presentation description or metafile format and can 665 convey the type of format to be used. However, the presentation 666 description is required to contain at least one RTSP URI. 668 Proxy and firewall friendly: The protocol should be readily handled 669 by both application and transport-layer (SOCKS [RFC1961]) 670 firewalls. A firewall may need to understand the SETUP method to 671 open a "hole" for the media stream. 673 HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so that 674 the existing infrastructure can be reused. This infrastructure 675 includes PICS (Platform for Internet Content Selection 676 [W3C.REC-PICS-services] [W3C.REC-PICS-labels]) for associating 677 labels with content. However, RTSP does not just add methods to 678 HTTP since controlling continuous media requires server state in 679 most cases. 681 Appropriate server control: If a client can start a stream, it needs 682 to be able to stop a stream. Servers should not start streaming 683 to clients in such a way that clients cannot stop the stream. 685 Transport negotiation: The client can negotiate the transport method 686 prior to actually needing to process a continuous media stream. 688 2.2. Extending RTSP 690 Since not all media servers have the same functionality, media 691 servers by necessity will support different sets of requests. For 692 example: 694 o A server may not be capable of seeking (absolute positioning) if 695 it is to support live events only. 697 o Some servers may not support setting stream parameters and thus 698 not support GET_PARAMETER and SET_PARAMETER. 700 o Some server may support an RTSP extension. 702 It is up to the creators of presentation descriptions not to ask the 703 impossible of a server. This situation is similar in HTTP/1.1 704 [RFC2616], where the methods described in [H19.5] are not likely to 705 be supported across all servers. 707 RTSP can be extended in three ways, listed here in order of the 708 magnitude of changes supported: 710 o Existing methods can be extended with new parameters, e.g. 711 headers, as long as these parameters can be safely ignored by the 712 recipient. If the client needs negative acknowledgement when a 713 method extension is not supported, a tag corresponding to the 714 extension may be added in the field of the Require or Proxy- 715 Require headers (see Section 16.32). 717 o New methods can be added. If the recipient of the message does 718 not understand the request, it MUST respond with error code 501 719 (Not Implemented) so that the sender can avoid using this method 720 again. A client may also use the OPTIONS method to inquire about 721 methods supported by the server. The server MUST list the methods 722 it supports using the Public response header. 724 o A new version of the protocol can be defined, allowing almost all 725 aspects (except the position of the protocol version number) to 726 change. A new version of the protocol MUST be registered through 727 an IETF standard track document. 729 The basic capability discovery mechanism can be used to both discover 730 support for a certain feature and to ensure that a feature is 731 available when performing a request. For detailed explanation of 732 this see Section 11. 734 2.3. Overall Operation 736 Each presentation and media stream is identified by an RTSP URI. The 737 overall presentation and the properties of the media the presentation 738 is composed of are defined by a presentation description file, the 739 format of which is outside the scope of this specification. The 740 presentation description file may be obtained by the client using 741 HTTP or other means such as email and may not necessarily be stored 742 on the media server. 744 For the purposes of this specification, a presentation description is 745 assumed to describe one or more presentations, each of which 746 maintains a common time axis. For simplicity of exposition and 747 without loss of generality, it is assumed that the presentation 748 description contains exactly one such presentation. A presentation 749 may contain several media streams. 751 The presentation description file contains a description of the media 752 streams making up the presentation, including their encodings, 753 language, and other parameters that enable the client to choose the 754 most appropriate combination of media. In this presentation 755 description, each media stream that is individually controllable by 756 RTSP is identified by an RTSP URI, which points to the media server 757 handling that particular media stream and names the stream stored on 758 that server. Several media streams can be located on different 759 servers; for example, audio and video streams can be split across 760 servers for load sharing. The description also enumerates which 761 transport methods the server is capable of. 763 Besides the media parameters, the network destination address and 764 port need to be determined. Several modes of operation can be 765 distinguished: 767 Unicast: The media is transmitted to the source of the RTSP request 768 or the requested destination, with the port number chosen by the 769 client. Alternatively, the media is transmitted on the same 770 reliable stream as RTSP. 772 Multicast, server chooses address: The media server picks the 773 multicast address and port. This is the typical case for a live 774 or near-media-on-demand transmission. 776 Multicast, client chooses address: If the server is to participate 777 in an existing multicast conference, the multicast address, port 778 and encryption key are given by the conference description, 779 established by means outside the scope of this specification, for 780 example by a SIP created conference. 782 2.4. RTSP States 784 RTSP controls a stream which may be sent via a separate protocol, 785 independent of the control channel. For example, RTSP control may be 786 transported on a TCP connection while the media data is conveyed via 787 UDP. Thus, data delivery continues even if no RTSP requests are 788 received by the media server. Also, during its lifetime a single 789 media stream may be controlled by RTSP requests issued sequentially 790 on different TCP connections. Therefore, the server needs to 791 maintain "session state" to be able to correlate RTSP requests with a 792 stream. The state transitions are described in Appendix A. 794 Many methods in RTSP do not contribute to state. However, the 795 following play a central role in defining the allocation and usage of 796 stream resources on the server: SETUP, PLAY, PAUSE, REDIRECT, and 797 TEARDOWN. 799 SETUP: Causes the server to allocate resources for a stream and 800 create an RTSP session. 802 PLAY: Starts data transmission on a stream allocated via SETUP. 804 PAUSE: Temporarily halts a stream without freeing server resources. 806 REDIRECT: Indicates that the session should be moved to a new server 807 or location 809 TEARDOWN: Frees resources associated with the stream. The RTSP 810 session ceases to exist on the server. 812 RTSP methods that contribute to state use the Session header field 813 (Section 16.44) to identify the RTSP session whose state is being 814 manipulated. The server generates session identifiers in response to 815 SETUP requests (Section 13.3). 817 2.5. Relationship with Other Protocols 819 RTSP has some overlap in functionality with HTTP. It also may 820 interact with HTTP in that the initial contact with streaming content 821 will often be made through a web page. The current protocol 822 specification aims to allow different hand-off points between a web 823 server and the media server implementing RTSP. For example, the 824 presentation description can be retrieved using HTTP or RTSP, which 825 reduces round trips in web-browser-based scenarios, yet also allows 826 for stand alone RTSP servers and clients which do not rely on HTTP at 827 all. However, RTSP differs fundamentally from HTTP in that most data 828 delivery takes place out-of-band in a different protocol. HTTP is an 829 asymmetric protocol where the client issues requests and the server 830 responds. In RTSP, both the media client and media server can issue 831 requests. RTSP requests are also stateful; they may set parameters 832 and continue to control a media stream long after the request has 833 been acknowledged. 835 Re-using HTTP functionality has advantages in at least two areas, 836 namely security and proxies. The requirements are very similar, so 837 having the ability to adopt HTTP work on caches, proxies and 838 authentication is valuable. 840 RTSP assumes the existence of a presentation description format that 841 can express both static and temporal properties of a presentation 842 containing several media streams. Session Description Protocol (SDP) 843 [RFC4566] is generally the format of choice; however, RTSP is not 844 bound to it. For data delivery, most real-time media will use RTP as 845 a transport protocol. While RTSP works well with RTP, it is not tied 846 to RTP. 848 3. RTSP Use Cases 850 This section describes the most important and considered use cases 851 for RTSP. They are listed in descending order of importance in 852 regards to ensuring that all necessary functionality is present. 853 This specification only fully supports usage of the two first. Also 854 in these first two cases, there are special cases or exceptions that 855 are not supported without extensions, e.g. the redirection of media 856 to another address than the controlling entity. 858 3.1. On-demand Playback of Stored Content 860 An RTSP capable server stores content suitable for being streamed to 861 a client. A client desiring playback of any of the stored content 862 uses RTSP to set up the media transport required to deliver the 863 desired content. RTSP is then used to initiate, halt and manipulate 864 the actual transmission (playout) of the content. RTSP is also 865 required to provide necessary description and synchronization 866 information for the content. 868 The above high level description can be broken down into a number of 869 functions that RTSP needs to be capable of. 871 Presentation Description: Provide initialization information about 872 the presentation (content); for example, which media codecs are 873 needed for the content. Other information that is important 874 includes the number of media stream the presentation contains, 875 the transport protocols used for the media streams, and 876 identifiers for these media streams. This information is 877 required before setup of the content is possible and to 878 determine if the client is even capable of using the content. 880 This information need not be sent using RTSP; other external 881 protocols can be used to transmit the transport presentation 882 descriptions. Two good examples are the use of HTTP [RFC2616] 883 or email to fetch or receive presentation descriptions like SDP 884 [RFC4566] 886 Setup: Set up some or all of the media streams in a presentation. 887 The setup itself consist of selecting the protocol for media 888 transport and the necessary parameters for the protocol, like 889 addresses and ports. 891 Control of Transmission: After the necessary media streams have been 892 established the client can request the server to start 893 transmitting the content. The client must be allowed to start 894 or stop the transmission of the content at arbitrary times. 895 The client must also be able to start the transmission at any 896 point in the timeline of the presentation. 898 Synchronization: For media transport protocols like RTP [RFC3550] it 899 might be beneficial to carry synchronization information within 900 RTSP. This may be due to either the lack of inter-media 901 synchronization within the protocol itself, or the potential 902 delay before the synchronization is established (which is the 903 case for RTP when using RTCP). 905 Termination: Terminate the established contexts. 907 For this use case there are a number of assumptions about how it 908 works. These are: 910 On-Demand content: The content is stored at the server and can be 911 accessed at any time during a time period when it is intended 912 to be available. 914 Independent sessions: A server is capable of serving a number of 915 clients simultaneously, including from the same piece of 916 content at different points in that presentations time-line. 918 Unicast Transport: Content for each individual client is transmitted 919 to them using unicast traffic. 921 It is also possible to redirect the media traffic to a different 922 destination than that of the entity controlling the traffic. 923 However, allowing this without appropriate mechanisms for checking 924 that the destination approves of this allows for distributed denial 925 of service attacks (DDoS). 927 3.2. Unicast distribution of Live Content 929 This use cases is similar to the above on-demand content case (see 930 Section 3.1) the difference is the nature of the content itself. 931 Live content is continuously distributed as it becomes available from 932 a source; i.e., the main difference from on-demand is that one starts 933 distributing content before the end of it has become available to the 934 server. 936 In many cases the consumer of live content is only interested in 937 consuming what is actually happens "now"; i.e., very similar to 938 broadcast TV. However in this case it is assumed that there exist no 939 broadcast or multicast channel to the users, and instead the server 940 functions as a distribution node, sending the same content to 941 multiple receivers, using unicast traffic between server and client. 942 This unicast traffic and the transport parameters are individually 943 negotiated for each receiving client. 945 Another aspect of live content is that it often has a very limited 946 time of availability, as it is only is available for the duration of 947 the event the content covers. An example of such a live content 948 could be a music concert which lasts 2 hour and starts at a 949 predetermined time. Thus there is need to announce when and for how 950 long the live content is available. 952 In some cases, the server providing live content may be saving some 953 or all of the content to allow clients to pause the stream and resume 954 it from the paused point, or to "rewind" and play continuously from a 955 point earlier than the live point. Hence, this use case does not 956 necessarily exclude playing from other than the live point of the 957 stream, playing with scales other than 1.0, etc. 959 3.3. On-demand Playback using Multicast 961 It is possible to use RTSP to request that media be delivered to a 962 multicast group. The entity setting up the session (the controller) 963 will then control when and what media is delivered to the group. 964 This use case has some potential for denial of service attacks by 965 flooding a multicast group. Therefore, a mechanism is needed to 966 indicate that the group actually accepts the traffic from the RTSP 967 server. 969 An open issue in this use case is how one ensures that all receivers 970 listening to the multicast or broadcast receives the session 971 presentation configuring the receivers. 973 3.4. Inviting an RTSP server into a conference 975 If one has an established conference or group session, it is possible 976 to have an RTSP server distribute media to the whole group. 977 Transmission to the group is simplest when controlled by a single 978 participant or leader of the conference. Shared control might be 979 possible, but would require further investigation and possibly 980 extensions. 982 This use case assumes that there exists either multicast or a 983 conference focus that redistribute media to all participants. 985 This use case is intended to be able to handle the following 986 scenario: A conference leader or participant (hereafter called the 987 controller) has some pre-stored content on an RTSP server that he 988 wants to share with the group. The controller sets up an RTSP 989 session at the streaming server for this content and retrieves the 990 session description for the content. The destination for the media 991 content is set to the shared multicast group or conference focus. 992 When desired by the controller, he/she can start and stop the 993 transmission of the media to the conference group. 995 There are several issues with this use case that are not solved by 996 this core specification for RTSP: 998 Denial of service: To avoid an RTSP server from being an unknowing 999 participant in a denial of service attack the server needs to 1000 be able to verify the destination's acceptance of the media. 1001 Such a mechanism to verify the approval of received media does 1002 not yet exist; instead, only policies can be used, which can be 1003 made to work in controlled environments. 1005 Distributing the presentation description to all participants in the 1006 group: To enable a media receiver to correctly decode the content 1007 the media configuration information needs to be distributed 1008 reliably to all participants. This will most likely require 1009 support from an external protocol. 1011 Passing control of the session: If it is desired to pass control of 1012 the RTSP session between the participants, some support will be 1013 required by an external protocol to exchange state information 1014 and possibly floor control of who is controlling the RTSP 1015 session. 1017 If there interest in this use case, further work is required on the 1018 necessary extensions. 1020 3.5. Live Content using Multicast 1022 This use case in its simplest form does not require any use of RTSP 1023 at all; this is what multicast conferences being announced with SAP 1024 and SDP are intended to handle. However in use cases where more 1025 advanced features like access control to the multicast session are 1026 desired, RTSP could be used for session establishment. 1028 A client desiring to join a live multicasted media session with 1029 cryptographic (encryption) access control could use RTSP in the 1030 following way. The source of the session announces the session and 1031 gives all interested an RTSP URI. The client connects to the server 1032 and requests the presentation description, allowing configuration for 1033 reception of the media. In this step it is possible for the client 1034 to use secured transport and any desired level of authentication; for 1035 example, for billing or access control. An RTSP link also allows for 1036 load balancing between multiple servers. 1038 If these were the only goals, they could be achieved by simply using 1039 HTTP. However, for cases where the sender likes to keep track of 1040 each individual receiver of a session, and possibly use the session 1041 as a side channel for distributing key-updates or other information 1042 on a per-receiver basis, and the full set of receivers is not know 1043 prior to the session start, the state establishment that RTSP 1044 provides can be beneficial. In this case a client would establish an 1045 RTSP session for this multicast group with the RTSP server. The RTSP 1046 server will not transmit any media, but instead will point to the 1047 multicast group. The client and server will be able to keep the 1048 session alive for as long as the receiver participates in the session 1049 thus enabling, for example, the server to push updates to the client. 1051 This use case will most likely not be able to be implemented without 1052 some extensions to the server-to-client push mechanism. Here a 1053 method like ANNOUNCE (see [RFC2326]) might be suitable; however, it 1054 will require a RTSP extension to revive the method. 1056 4. Protocol Parameters 1058 4.1. RTSP Version 1060 HTTP specification section [H3.1] applies, with "HTTP" replaced by 1061 "RTSP". This specification defines version 2.0 of RTSP. 1063 4.2. RTSP IRI and URI 1065 RTSP 2.0 defines and registers three URI schemas "rtsp", "rtsps" and 1066 "rtspu". The usage of the last, "rtspu", is unspecified in RTSP 2.0, 1067 and is defined here to register and reserve the URI scheme that is 1068 defined in RTSP 1.0. The "rtspu" scheme indicates undefined 1069 transport of the RTSP messages over unreliable transport (UDP). The 1070 syntax of "rtsp" and "rtsps" URIs has been changed from RTSP 1.0. 1072 This specification also defines the format of the RTSP IRI [RFC3987] 1073 that can be used as RTSP resource identifiers and locators, in web 1074 pages, user interfaces, on paper, etc. However, the RTSP request 1075 message format only allows usage of the absolute URI format. The 1076 RTSP IRI format SHALL use the rules and transformation for IRIs 1077 defined in [RFC3987]. This way RTSP 2.0 URIs for request can be 1078 produced from an RTSP IRI. 1080 The RTSP IRI and URI are both syntax restricted compared to the 1081 generic syntax defined in [RFC3986] and RFC [RFC3987]: 1083 o An absolute URI requires the authority part; i.e., a host identity 1084 must be provided. 1086 o Parameters in the path element are prefixed with the reserved 1087 separator ";". 1089 The RTSP URI and IRI is case sensitive, with the exception of those 1090 parts that [RFC3986] and [RFC3987] defines as case-insensitive; for 1091 example, the scheme and host part. 1093 The fragment identifier is used as defined in sections 3.5 and 4.3 of 1094 [RFC3986], i.e. the fragment is to be stripped from the URI by the 1095 requestor and not included in the request. The user agent also needs 1096 to interpret the value of the fragment based on the media type the 1097 request relates to; i.e., the media type indicated in Content-Type 1098 header in the response to DESCRIBE. 1100 The syntax of any URI query string is unspecified and responder 1101 (usually the server) specific. The query is, from the requestor's 1102 perspective, an opaque string and needs to be handled as such. 1104 The URI scheme "rtsp" requires that commands are issued via a 1105 reliable protocol (within the Internet, TCP), while the scheme 1106 "rtsps" identifies a reliable transport using secure transport (TLS 1107 [RFC4346], see (Section 20). 1109 For the scheme "rtsp", if no port number is provided in the authority 1110 part of the URI port number 554 SHALL be used. For the scheme 1111 "rtsps", the TCP port 322 is registered and SHALL be assumed. 1113 A presentation or a stream is identified by a textual media 1114 identifier, using the character set and escape conventions of URIs 1115 (RFC 3986 [RFC3986]). URIs may refer to a stream or an aggregate of 1116 streams; i.e., a presentation. Accordingly, requests described in 1117 (Section 13) can apply to either the whole presentation or an 1118 individual stream within the presentation. Note that some request 1119 methods can only be applied to streams, not presentations, and vice 1120 versa. 1122 For example, the RTSP URI: 1124 rtsp://media.example.com:554/twister/audiotrack 1126 may identify the audio stream within the presentation "twister", 1127 which can be controlled via RTSP requests issued over a TCP 1128 connection to port 554 of host media.example.com. 1130 Also, the RTSP URI: 1132 rtsp://media.example.com:554/twister 1134 identifies the presentation "twister", which may be composed of audio 1135 and video streams, but could also be something else like a random 1136 media redirector. 1138 This does not imply a standard way to reference streams in URIs. 1139 The presentation description defines the hierarchical 1140 relationships in the presentation and the URIs for the individual 1141 streams. A presentation description may name a stream "a.mov" and 1142 the whole presentation "b.mov". 1144 The path components of the RTSP URI are opaque to the client and do 1145 not imply any particular file system structure for the server. 1147 This decoupling also allows presentation descriptions to be used 1148 with non-RTSP media control protocols simply by replacing the 1149 scheme in the URI. 1151 4.3. Session Identifiers 1153 Session identifiers are strings of any arbitrary length. A session 1154 identifier MUST be chosen cryptographically random (See [RFC4086] ) 1155 and MUST be at least eight characters (can contain a maximum of 48 1156 bits of entropy) long to make guessing it more difficult. It is 1157 RECOMMENDED that it contains 128 bits of entropy, i.e. approxamitely 1158 22 characters from a high quality generator. (See Section 22.) 1159 However, it needs to be noted that the session identifier does not 1160 provide any security against session hijacking unless it is kept 1161 confidential between client, server and trusted proxies. 1163 4.4. SMPTE Relative Timestamps 1165 A SMPTE relative timestamp expresses time relative to the start of 1166 the clip. Relative timestamps are expressed as SMPTE time codes for 1167 frame-level access accuracy. The time code has the format 1169 hours:minutes:seconds:frames.subframes, 1171 with the origin at the start of the clip. The default smpte format 1172 is "SMPTE 30 drop" format, with frame rate is 29.97 frames per 1173 second. Other SMPTE codes MAY be supported (such as "SMPTE 25") 1174 through the use of alternative use of "smpte-type". For SMPTE 30, 1175 the "frames" field in the time value can assume the values 0 through 1176 29. The difference between 30 and 29.97 frames per second is handled 1177 by dropping the first two frame indices (values 00 and 01) of every 1178 minute, except every tenth minute. If the frame and the subframe 1179 values are zero, they may be omitted. Subframes are measured in one- 1180 hundredth of a frame. 1182 Examples: 1184 smpte=10:12:33:20- 1185 smpte=10:07:33- 1186 smpte=10:07:00-10:07:33:05.01 1187 smpte-25=10:07:00-10:07:33:05.01 1189 4.5. Normal Play Time 1191 Normal play time (NPT) indicates the stream absolute position 1192 relative to the beginning of the presentation, not to be confused 1193 with the Network Time Protocol (NTP) [RFC1305]. The timestamp 1194 consists of a decimal fraction. The part left of the decimal may be 1195 expressed in either seconds or hours, minutes, and seconds. The part 1196 right of the decimal point measures fractions of a second. 1198 The beginning of a presentation corresponds to 0.0 seconds. Negative 1199 values are not defined. The special constant "now" is defined as the 1200 current instant of a live event. It MAY only be used for live 1201 events, and SHALL NOT be used for on-demand (i.e., non-live) content. 1203 NPT is defined as in DSM-CC [ISO.13818-6.1995]: "Intuitively, NPT is 1204 the clock the viewer associates with a program. It is often 1205 digitally displayed on a VCR. NPT advances normally when in normal 1206 play mode (scale = 1), advances at a faster rate when in fast scan 1207 forward (high positive scale ratio), decrements when in scan reverse 1208 (high negative scale ratio) and is fixed in pause mode. NPT is 1209 (logically) equivalent to SMPTE time codes." 1211 Examples: 1213 npt=123.45-125 1214 npt=12:05:35.3- 1215 npt=now- 1217 The syntax conforms to ISO 8601 [ISO.8601.2000]. The npt-sec 1218 notation is optimized for automatic generation, the npt-hhmmss 1219 notation for consumption by human readers. The "now" constant 1220 allows clients to request to receive the live feed rather than the 1221 stored or time-delayed version. This is needed since neither 1222 absolute time nor zero time are appropriate for this case. 1224 4.6. Absolute Time 1226 Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps, 1227 using UTC (GMT). Fractions of a second may be indicated. 1229 Example for November 8, 1996 at 14h37 and 20 and a quarter seconds 1230 UTC: 1232 19961108T143720.25Z 1234 4.7. Feature-tags 1236 Feature-tags are unique identifiers used to designate features in 1237 RTSP. These tags are used in Require ( (Section 16.38)), Proxy- 1238 Require (Section 16.32), Proxy-Supported ( (Section 16.33)), 1239 Unsupported ( (Section 16.47)), and header fields. 1241 A feature-tag definition MUST indicate which combination of clients, 1242 servers or proxies they applies to. 1244 The creator of a new RTSP feature-tag should either prefix the 1245 feature-tag with a reverse domain name (e.g., 1246 "com.example.mynewfeature" is an apt name for a feature whose 1247 inventor can be reached at "example.com"), or register the new 1248 feature-tag with the Internet Assigned Numbers Authority (IANA) (see 1249 IANA Section 23). 1251 The usage of feature-tags is further described in Section 11 that 1252 deals with capability handling. 1254 4.8. Entity Tags 1256 Entity tags are opaque strings that are used to compare two entities 1257 from the same resource, for example in caches or to optimize setup 1258 after a redirect. Further explanation is present in [H3.11]. For an 1259 explanation of how to compare entity tags see [H13.3]. Entity tags 1260 can be carried in the ETag header (see Section 16.21) or in SDP (see 1261 Appendix C.1.9). 1263 Entity tags are used in RTSP to make some methods conditional. The 1264 methods are made conditional through the inclusion of headers, see 1265 Section 16.24 and Section 16.26. Note that RTSP entity tags apply to 1266 the complete presentation; i.e., both the session description and the 1267 individual media streams. Thus entity tags can be used to verify at 1268 setup time after a redirect that the same session description applies 1269 to the media at the new location using the If-Match header. 1271 5. RTSP Message 1273 RTSP is a text-based protocol and uses the ISO 10646 character set in 1274 UTF-8 encoding (RFC 3629 [RFC3629]). Lines SHALL be terminated by 1275 CRLF. 1277 Text-based protocols make it easier to add optional parameters in 1278 a self-describing manner. Since the number of parameters and the 1279 frequency of commands is low, processing efficiency is not a 1280 concern. Text-based protocols, if done carefully, also allow easy 1281 implementation of research prototypes in scripting languages such 1282 as Tcl, Visual Basic and Perl. 1284 The ISO 10646 character set avoids tricky character set switching, 1285 but is invisible to the application as long as US-ASCII is being 1286 used. This is also the encoding used for RTCP [RFC3550]. ISO 8859-1 1287 translates directly into Unicode with a high-order octet of zero. 1288 ISO 8859-1 characters with the most-significant bit set are 1289 represented as 1100001x 10xxxxxx. (See RFC 3629 [RFC3629]) 1291 Requests contain methods, the object the method is operating upon and 1292 parameters to further describe the method. Methods are idempotent 1293 unless otherwise noted. Methods are also designed to require little 1294 or no state maintenance at the media server. 1296 5.1. Message Types 1298 See [H4.1]. 1300 5.2. Message Headers 1302 See [H4.2]. 1304 5.3. Message Body 1306 See [H4.3]. 1308 Unlike HTTP, the presence of a message-body in either a request or a 1309 response MUST be signaled by the inclusion of a Content-Length header 1310 field (see Section 16.16). 1312 5.4. Message Length 1314 When a message body is included with a message, the length of that 1315 body is determined by one of the following (in order of precedence): 1317 1. Any response message which MUST NOT include a message body (such 1318 as the 1xx, 204, and 304 responses) is always terminated by the 1319 first empty line after the header fields, regardless of the 1320 entity-header fields present in the message. (Note: An empty 1321 line is a line with nothing preceding the CRLF.) 1323 2. If a Content-Length header field (Section 16.16) is present, its 1324 value in bytes represents the length of the message-body. If 1325 this header field is not present, a value of zero is assumed. 1327 Unlike an HTTP message, an RTSP message MUST contain a Content-Length 1328 header field whenever it contains a message body. Note that RTSP 1329 does not support the HTTP/1.1 "chunked" transfer coding (see 1330 [H3.6.1]). 1332 Given the moderate length of presentation descriptions returned, 1333 the server should always be able to determine its length, even if 1334 it is generated dynamically, making the chunked transfer encoding 1335 unnecessary. 1337 6. General Header Fields 1339 See [H4.5], except that the Pragma, Trailer, Transfer-Encoding, 1340 Upgrade, and Warning headers are not defined. RTSP further defines 1341 the CSeq, Pipelined-Requests, Proxy-Supported and Timestamp headers. 1342 The general headers are listed in Table 1: 1344 +--------------------+--------------------+ 1345 | Header Name | Defined in Section | 1346 +--------------------+--------------------+ 1347 | Cache-Control | Section 16.10 | 1348 | | | 1349 | Connection | Section 16.11 | 1350 | | | 1351 | CSeq | Section 16.19 | 1352 | | | 1353 | Date | Section 16.20 | 1354 | | | 1355 | Pipelined-Requests | Section 16.29 | 1356 | | | 1357 | Proxy-Supported | Section 16.33 | 1358 | | | 1359 | Supported | Section 16.44 | 1360 | | | 1361 | Timestamp | Section 16.45 | 1362 | | | 1363 | Via | Section 16.50 | 1364 +--------------------+--------------------+ 1366 Table 1: The general headers used in RTSP 1368 7. Request 1370 A request message uses the format outlined below regardless of the 1371 direction of a request, client to server or server to client: 1373 o Request line, containing the method to be applied to the resource, 1374 the identifier of the resource, and the protocol version in use; 1376 o Zero or more Header lines, that can be of the following types: 1377 general (Section 6), request (Section 7.2), or entity 1378 (Section 9.1); 1380 o One empty line (CRLF) to indicate the end of the header section; 1382 o Optionally a message body (entity), consisting of one or more 1383 lines. The length of the message body in bytes is indicated by 1384 the Content-Length entity header. 1386 7.1. Request Line 1388 The request line provides the key information about the request: what 1389 method, on what resources and using which RTSP version. The methods 1390 that are defined by this specification are listed in Table 2. 1392 +---------------+--------------------+ 1393 | Method | Defined in Section | 1394 +---------------+--------------------+ 1395 | DESCRIBE | Section 13.2 | 1396 | | | 1397 | GET_PARAMETER | Section 13.7 | 1398 | | | 1399 | OPTIONS | Section 13.1 | 1400 | | | 1401 | PAUSE | Section 13.5 | 1402 | | | 1403 | PLAY | Section 13.4 | 1404 | | | 1405 | REDIRECT | Section 13.9 | 1406 | | | 1407 | SETUP | Section 13.3 | 1408 | | | 1409 | SET_PARAMETER | Section 13.8 | 1410 | | | 1411 | TEARDOWN | Section 13.6 | 1412 +---------------+--------------------+ 1414 Table 2: The RTSP Methods 1416 The syntax of the RTSP request line is the following: 1418 CRLF 1420 Note: This syntax cannot be freely changed in future versions of 1421 RTSP. This line needs to remain parsable by older RTSP 1422 implementations since it indicates the RTSP version of the message. 1424 In contrast to HTTP/1.1 [RFC2616], RTSP requests identify the 1425 resource through an absolute RTSP URI (scheme, host, and port) (see 1426 Section 4.2) rather than just the absolute path. 1428 HTTP/1.1 requires servers to understand the absolute URI, but 1429 clients are supposed to use the Host request header. This is 1430 purely needed for backward-compatibility with HTTP/1.0 servers, a 1431 consideration that does not apply to RTSP. 1433 An asterisk "*" can be used instead of an absolute URI in the 1434 Request-URI part to indicate that the request does not apply to a 1435 particular resource, but to the server or proxy itself, and is only 1436 allowed when the request method does not necessarily apply to a 1437 resource. 1439 For example: 1441 OPTIONS * RTSP/2.0 1443 An OPTIONS in this form will determine the capabilities of the server 1444 or the proxy that first receives the request. If the capability of 1445 the specific server needs to be determined, without regard to the 1446 capability of an intervening proxy, the server should be addressed 1447 explicitly with an absolute URI that contains the server's address. 1449 For example: 1451 OPTIONS rtsp://example.com RTSP/2.0 1453 7.2. Request Header Fields 1455 The RTSP headers in Table 3 can be included in a request, as request 1456 headers, to modify the specifics of the request. Some of these 1457 headers may also be used in the response to a request, as response 1458 headers, to modify the specifics of a response (Section 8.2). 1460 +--------------------+--------------------+ 1461 | Header | Defined in Section | 1462 +--------------------+--------------------+ 1463 | Accept | Section 16.1 | 1464 | | | 1465 | Accept-Credentials | Section 16.2 | 1466 | | | 1467 | Accept-Encoding | Section 16.3 | 1468 | | | 1469 | Accept-Language | Section 16.4 | 1470 | | | 1471 | Authorization | Section 16.7 | 1472 | | | 1473 | Bandwidth | Section 16.8 | 1474 | | | 1475 | Blocksize | Section 16.9 | 1476 | | | 1477 | From | Section 16.23 | 1478 | | | 1479 | If-Match | Section 16.24 | 1480 | | | 1481 | If-Modified-Since | Section 16.25 | 1482 | | | 1483 | If-None-Match | Section 16.26 | 1484 | | | 1485 | Proxy-Require | Section 16.32 | 1486 | | | 1487 | Range | Section 16.35 | 1488 | | | 1489 | Referer | Section 16.36 | 1490 | | | 1491 | Require | Section 16.38 | 1492 | | | 1493 | Scale | Section 16.40 | 1494 | | | 1495 | Session | Section 16.43 | 1496 | | | 1497 | Speed | Section 16.41 | 1498 | | | 1499 | Supported | Section 16.44 | 1500 | | | 1501 | Transport | Section 16.46 | 1502 | | | 1503 | User-Agent | Section 16.48 | 1504 +--------------------+--------------------+ 1506 Table 3: The RTSP request headers 1508 Detailed headers definition are provided in Section 16. 1510 New request headers may be defined. If the receiver of the request 1511 is required to understand the request header, the request MUST 1512 include a corresponding feature tag in a Require or Proxy-Require 1513 header to ensure the correct processing of the header. 1515 8. Response 1517 [H6] applies except that HTTP-Version is replaced by RTSP-Version. 1518 Also, RTSP defines additional status codes and does not define some 1519 of the HTTP codes. The valid response codes and the methods they can 1520 be used with are listed in Table 4. 1522 After receiving and interpreting a request message, the recipient 1523 responds with an RTSP response message. 1525 8.1. Status-Line 1527 The first line of a Response message is the Status-Line, consisting 1528 of the protocol version followed by a numeric status code and the 1529 textual phrase associated with the status code, with each element 1530 separated by SP characters. No CR or LF is allowed except in the 1531 final CRLF sequence. 1533 SP SP CRLF 1535 8.1.1. Status Code and Reason Phrase 1537 The Status-Code element is a 3-digit integer result code of the 1538 attempt to understand and satisfy the request. These codes are fully 1539 defined in Section 15. The Reason-Phrase is intended to give a short 1540 textual description of the Status-Code. The Status-Code is intended 1541 for use by automata and the Reason-Phrase is intended for the human 1542 user. The client is not required to examine or display the Reason- 1543 Phrase. 1545 The first digit of the Status-Code defines the class of response. 1546 The last two digits do not have any categorization role. There are 5 1547 values for the first digit: 1549 1xx: Informational - Request received, continuing process 1551 2xx: Success - The action was successfully received, understood, and 1552 accepted 1554 3rr: Redirection - Further action needs to be taken in order to 1555 complete the request 1557 4xx: Client Error - The request contains bad syntax or cannot be 1558 fulfilled 1560 5xx: Server Error - The server failed to fulfill an apparently valid 1561 request 1563 The individual values of the numeric status codes defined for 1564 RTSP/2.0, and an example set of corresponding Reason-Phrases, are 1565 presented in Table 4. The reason phrases listed here are only 1566 recommended; they may be replaced by local equivalents without 1567 affecting the protocol. Note that RTSP adopts most HTTP/1.1 1568 [RFC2616] status codes and adds RTSP-specific status codes starting 1569 at x50 to avoid conflicts with newly defined HTTP status codes. 1571 RTSP status codes are extensible. RTSP applications are not required 1572 to understand the meaning of all registered status codes, though such 1573 understanding is obviously desirable. However, applications MUST 1574 understand the class of any status code, as indicated by the first 1575 digit, and treat any unrecognized response as being equivalent to the 1576 x00 status code of that class, with the exception that an 1577 unrecognized response MUST NOT be cached. For example, if an 1578 unrecognized status code of 431 is received by the client, it can 1579 safely assume that there was something wrong with its request and 1580 treat the response as if it had received a 400 status code. In such 1581 cases, user agents SHOULD present to the user the entity returned 1582 with the response, since that entity is likely to include human- 1583 readable information which will explain the unusual status. 1585 +------+----------------------------------------+-----------------+ 1586 | Code | Reason | Method | 1587 +------+----------------------------------------+-----------------+ 1588 | 100 | Continue | all | 1589 | | | | 1590 | | | | 1591 | 200 | OK | all | 1592 | | | | 1593 | | | | 1594 | 300 | Multiple Choices | all | 1595 | | | | 1596 | 301 | Multiple Choices | all | 1597 | | | | 1598 | 301 | Moved Permanently | all | 1599 | | | | 1600 | 302 | Found | all | 1601 | | | | 1602 | 303 | See Other | all | 1603 | | | | 1604 | 305 | Use Proxy | all | 1605 | | | | 1606 | | | | 1607 | 400 | Bad Request | all | 1608 | 401 | Unauthorized | all | 1609 | | | | 1610 | 402 | Payment Required | all | 1611 | | | | 1612 | 403 | Forbidden | all | 1613 | | | | 1614 | 404 | Not Found | all | 1615 | | | | 1616 | 405 | Method Not Allowed | all | 1617 | | | | 1618 | 406 | Not Acceptable | all | 1619 | | | | 1620 | 407 | Proxy Authentication Required | all | 1621 | | | | 1622 | 408 | Request Timeout | all | 1623 | | | | 1624 | 410 | Gone | all | 1625 | | | | 1626 | 411 | Length Required | all | 1627 | | | | 1628 | 412 | Precondition Failed | DESCRIBE, SETUP | 1629 | | | | 1630 | 413 | Request Entity Too Large | all | 1631 | | | | 1632 | 414 | Request-URI Too Long | all | 1633 | | | | 1634 | 415 | Unsupported Media Type | all | 1635 | | | | 1636 | 451 | Parameter Not Understood | SET_PARAMETER | 1637 | | | | 1638 | 452 | reserved | n/a | 1639 | | | | 1640 | 453 | Not Enough Bandwidth | SETUP | 1641 | | | | 1642 | 454 | Session Not Found | all | 1643 | | | | 1644 | 455 | Method Not Valid In This State | all | 1645 | | | | 1646 | 456 | Header Field Not Valid | all | 1647 | | | | 1648 | 457 | Invalid Range | PLAY, PAUSE | 1649 | | | | 1650 | 458 | Parameter Is Read-Only | SET_PARAMETER | 1651 | | | | 1652 | 459 | Aggregate Operation Not Allowed | all | 1653 | | | | 1654 | 460 | Only Aggregate Operation Allowed | all | 1655 | | | | 1656 | 461 | Unsupported Transport | all | 1657 | | | | 1658 | 462 | Destination Unreachable | all | 1659 | | | | 1660 | 463 | Destination Prohibited | SETUP | 1661 | | | | 1662 | 464 | Data Transport Not Ready Yet | PLAY | 1663 | | | | 1664 | 470 | Connection Authorization Required | all | 1665 | | | | 1666 | 471 | Connection Credentials not accepted | all | 1667 | | | | 1668 | 472 | Failure to establish secure connection | all | 1669 | | | | 1670 | | | | 1671 | 500 | Internal Server Error | all | 1672 | | | | 1673 | 501 | Not Implemented | all | 1674 | | | | 1675 | 502 | Bad Gateway | all | 1676 | | | | 1677 | 503 | Service Unavailable | all | 1678 | | | | 1679 | 504 | Gateway Timeout | all | 1680 | | | | 1681 | 505 | RTSP Version Not Supported | all | 1682 | | | | 1683 | 551 | Option not support | all | 1684 +------+----------------------------------------+-----------------+ 1686 Table 4: Status codes and their usage with RTSP methods 1688 8.2. Response Header Fields 1690 The response-header fields allow the request recipient to pass 1691 additional information about the response which cannot be placed in 1692 the Status-Line. These header fields give information about the 1693 server and about further access to the resource identified by the 1694 Request-URI. All headers currently classified as response headers 1695 are listed in Table 5. 1697 +------------------------+--------------------+ 1698 | Header | Defined in Section | 1699 +------------------------+--------------------+ 1700 | Accept-Credentials | Section 16.2 | 1701 | | | 1702 | Accept-Ranges | Section 16.5 | 1703 | | | 1704 | Connection-Credentials | Section 16.12 | 1705 | | | 1706 | ETag | Section 16.21 | 1707 | | | 1708 | Location | Section 16.28 | 1709 | | | 1710 | Proxy-Authenticate | Section 16.30 | 1711 | | | 1712 | Public | Section 16.34 | 1713 | | | 1714 | Range | Section 16.35 | 1715 | | | 1716 | Retry-After | Section 16.37 | 1717 | | | 1718 | RTP-Info | Section 16.39 | 1719 | | | 1720 | Scale | Section 16.40 | 1721 | | | 1722 | Session | Section 16.43 | 1723 | | | 1724 | Server | Section 16.42 | 1725 | | | 1726 | Speed | Section 16.41 | 1727 | | | 1728 | Transport | Section 16.46 | 1729 | | | 1730 | Unsupported | Section 16.47 | 1731 | | | 1732 | Vary | Section 16.49 | 1733 | | | 1734 | WWW-Authenticate | Section 16.51 | 1735 +------------------------+--------------------+ 1737 Table 5: The RTSP response headers 1739 Response-header field names can be extended reliably only in 1740 combination with a change in the protocol version. However the usage 1741 of feature-tags in the request allows the responding party to learn 1742 the capability of the receiver of the response. New or experimental 1743 header fields MAY be given the semantics of response-header fields if 1744 all parties in the communication recognize them to be response-header 1745 fields. Unrecognized header fields in responses are treated as 1746 entity-header fields. 1748 9. Entity 1750 Request and Response messages MAY transfer an entity if not otherwise 1751 restricted by the request method or response status code. An entity 1752 consists of entity-header fields and an entity-body, although some 1753 responses will only include the entity-headers. 1755 The SETPARAMETER and GET_PARAMETER request and response, and DESCRIBE 1756 response MAY have an entity. All 4xx and 5xx responses MAY also have 1757 an entity. 1759 In this section, both sender and recipient refer to either the client 1760 or the server, depending on who sends and who receives the entity. 1762 9.1. Entity Header Fields 1764 Entity-header fields define meta-information about the entity-body 1765 or, if no body is present, about the resource identified by the 1766 request. The entity header fields are listed in Table 6. 1768 +------------------+--------------------+ 1769 | Header | Defined in Section | 1770 +------------------+--------------------+ 1771 | Allow | Section 16.6 | 1772 | | | 1773 | Content-Base | Section 16.13 | 1774 | | | 1775 | Content-Encoding | Section 16.14 | 1776 | | | 1777 | Content-Language | Section 16.15 | 1778 | | | 1779 | Content-Length | Section 16.16 | 1780 | | | 1781 | Content-Location | Section 16.17 | 1782 | | | 1783 | Content-Type | Section 16.18 | 1784 | | | 1785 | Expires | Section 16.22 | 1786 | | | 1787 | Last-Modified | Section 16.27 | 1788 +------------------+--------------------+ 1790 Table 6: The RTSP entity headers 1792 The extension-header mechanism allows additional entity-header fields 1793 to be defined without changing the protocol, but these fields cannot 1794 be assumed to be recognizable by the recipient. Unrecognized header 1795 fields SHOULD be ignored by the recipient and forwarded by proxies. 1797 9.2. Entity Body 1799 See [H7.2] with the addition that an RTSP message with an entity body 1800 MUST include the Content-Type and Content-Length headers. 1802 10. Connections 1804 RTSP requests can be transmitted using the two different connection 1805 scenarios listed below: 1807 o persistent - a transport connection is used for several request/ 1808 response transactions; 1810 o transient - a transport connection is used for a single request/ 1811 response transaction. 1813 RFC 2326 attempted to specify an optional mechanism for transmitting 1814 RTSP messages in connectionless mode over a transport protocol such 1815 as UDP. However, it was not specified in sufficient detail to allow 1816 for interoperable implementations. In an attempt to reduce 1817 complexity and scope, and due to lack of interest, RTSP 2.0 does not 1818 attempt to define a mechanism for supporting RTSP over UDP or other 1819 connectionless transport protocols. A side-effect of this is that 1820 RTSP requests SHALL NOT be sent to multicast groups since no 1821 connection can be established with a specific receiver in multicast 1822 environments. 1824 Certain RTSP headers, such as the CSeq header Section 16.19), which 1825 may appear to be relevant only to connectionless transport scenarios 1826 are still retained and must be implemented according to the 1827 specification. In the case of CSeq, it is quite useful for matching 1828 responses to requests if the requests are pipelined (see Section 12). 1829 It is also useful in proxies for keeping track of the different 1830 requests when aggregating several client requests on a single TCP 1831 connection. 1833 10.1. Reliability and Acknowledgements 1835 When RTSP messages are transmitted using reliable transport 1836 protocols, they MUST NOT be retransmitted at the RTSP protocol level. 1837 Instead, the implementation must rely on the underlying transport to 1838 provide reliability. The RTSP implementation may use any indication 1839 of reception acknowledgement of the message from the underlying 1840 transport protocols to optimize the RTSP behavior. 1842 If both the underlying reliable transport such as TCP and the RTSP 1843 application retransmit requests, each packet loss or message loss 1844 may result in two retransmissions. The receiver typically cannot 1845 take advantage of the application-layer retransmission since the 1846 transport stack will not deliver the application-layer 1847 retransmission before the first attempt has reached the receiver. 1848 If the packet loss is caused by congestion, multiple 1849 retransmissions at different layers will exacerbate the 1850 congestion. 1852 Lack of acknowledgement of an RTSP request should be handled within 1853 the constraints of the connection timeout considerations described 1854 below (Section 10.4). 1856 10.2. Using Connections 1858 A TCP transport can be used for both persistent connections (for 1859 several message exchanges) and transient connections (for a single 1860 message exchange). Implementations of this specification MUST 1861 support RTSP over TCP. The scheme of the RTSP URI (Section 4.2) 1862 indicates the default port that the server will listen on. 1864 A server MUST handle both persistent and transient connections. 1866 Transient connections facilitate mechanisms for fault tolerance. 1867 They also allow for application layer mobility. A server and 1868 client pair that support transient connections can survive the 1869 loss of a TCP connection; e.g., due to a NAT timeout. When the 1870 client has discovered that the TCP connection has been lost, it 1871 can set up a new one when there is need to communicate again. 1873 A persistent connection MAY be used for all transactions between the 1874 server and client, including messages for multiple RTSP sessions. 1875 However a persistent connection MAY also be closed after a few 1876 message exchanges. For example, a client may use a persistent 1877 connection for the initial SETUP and PLAY message exchanges in a 1878 session and then close the connection. Later, when the client wishes 1879 to send a new request, such as a PAUSE for the session, a new 1880 connection would be opened. This connection may either be transient 1881 or persistent. 1883 An RTSP agent SHOULD NOT have more than one connection to the server 1884 at any given point. If a client or proxy handles multiple RTSP 1885 sessions on the same server, it SHOULD use only one connection for 1886 managing those sessions. 1888 This saves connection resources on the server. It also reduces 1889 complexity by and enabling the server to maintain less state about 1890 its sessions and connections. 1892 Unlike HTTP, RTSP allows a server to send requests to a client. 1893 However, this can be supported only if a client establishes a 1894 persistent connection with the server. In cases where a persistent 1895 connection does not exist between a server and its client, due to the 1896 lack of a signalling channel the server may be forced to drop an RTSP 1897 session without notifying the client. An example of such a case is 1898 when the server desires to send a REDIRECT request for an RTSP 1899 session to the client but is not able to do so because it cannot 1900 reach the client. 1902 Without a persistent connection between the client and the server, 1903 the media server has no reliable way of reaching the client. 1904 Also, this is the only way that requests from a server to its 1905 client are likely to traverse firewalls. 1907 In light of the above, it is RECOMMENDED that clients use persistent 1908 connections whenever possible. A client that supports persistent 1909 connections MAY "pipeline" its requests (see Section 12). 1911 10.3. Closing Connections 1913 The client MAY close a connection at any point when no outstanding 1914 request/response transactions exist for any RTSP session being 1915 managed through the connection. The server, however, SHOULD NOT 1916 close a connection until all RTSP sessions being managed through the 1917 connection have been timed out (Section 16.43). A server SHOULD NOT 1918 close a connection immediately after responding to a session-level 1919 TEARDOWN request for the last RTSP session being controlled through 1920 the connection. Instead, it should wait for a reasonable amount of 1921 time for the client to receive the TEARDOWN response, take 1922 appropriate action, and initiate the connection closing. The server 1923 SHOULD wait at least 10 seconds after sending the TEARDOWN response 1924 before closing the connection. 1926 This is to ensure that the client has time to issue a SETUP for a 1927 new session on the existing connection after having torn the last 1928 one down. 10 seconds should give the client ample opportunity get 1929 its message to the server. 1931 A server SHOULD NOT close the connection directly as a result of 1932 responding to a request with an error code. 1934 Certain error responses such as "460 Only Aggregate Operation 1935 Allowed" (Section 15.4.12) are used for negotiating capabilities 1936 of a server with respect to content or other factors. In such 1937 cases, it is inefficient for the server to close a connection on 1938 an error response. Also, such behavior would prevent 1939 implementation of advanced/special types of requests or result in 1940 extra overhead for the client when testing for new features. On 1941 the flip side, keeping connections open after sending an error 1942 response poses a Denial of Service security risk (Section 22). 1944 If a server initiates a connection close while the client is 1945 attempting to send a new request, the client will have to close its 1946 current connection, establish a new connection and send its request 1947 over the new connection. 1949 An RTSP message should not be terminated by closing the connection. 1950 Such a message MAY be considered to be incomplete by the receiver and 1951 discarded. An RTSP message is properly terminated as defined in 1952 Section 5. 1954 10.4. Timing Out Connections and RTSP Messages 1956 Receivers of a request (responder) SHOULD respond to requests in a 1957 timely manner even when a reliable transport such as TCP is used. 1958 Similarly, the sender of a request (requestor) SHOULD wait for a 1959 sufficient time for a response before concluding that the responder 1960 will not be acting upon its request. 1962 A responder SHOULD respond to all requests within 5 seconds. If the 1963 responder recognizes that processing of a request will take longer 1964 than 5 seconds, it SHOULD send a 100 (Continue) response as soon as 1965 possible. It SHOULD continue sending a 100 response every 5 seconds 1966 thereafter until it is ready to send the final response to the 1967 requestor. After sending a 100 response, the receiver MUST send a 1968 final response indicating the success or failure of the request. 1970 A requestor SHOULD wait at least 10 seconds for a response before 1971 concluding that the responder will not be responding to its request. 1972 After receiving a 100 response, the requestor SHOULD continue waiting 1973 for further responses. If more than 10 seconds elapses without 1974 receiving any response, the requestor MAY assume that the responder 1975 is unresponsive and abort the connection. 1977 A requestor SHOULD wait longer than 10 seconds for a response if it 1978 is experiencing significant transport delays on its connection to the 1979 responder. The requestor is capable of determining the RTT of the 1980 request/response cycle using the Timestamp header (Section 16.45) in 1981 any RTSP request. 1983 10.5. Use of IPv6 1985 Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP 1986 2.0 has been updated for explicit IPv6 support. Implementations of 1987 RTSP 2.0 MUST understand literal IPv6 addresses in URIs and headers. 1989 11. Capability Handling 1991 This section describes the capability handling mechanism available in 1992 RTSP which allows RTSP to be extended. Extensions to this version of 1993 the protocol are basically done in two ways. First, new headers can 1994 be added. Secondly, new methods can be added. The capability 1995 handling mechanism is designed to handle both cases. 1997 When a method is added, the involved parties can use the OPTIONS 1998 method to discover wether it is supported. This is done by issuing a 1999 OPTIONS request to the other party. Depending on the URI it will 2000 either apply in regards to a certain media resource, the whole server 2001 in general, or simply the next hop. The OPTIONS response MUST 2002 contain a Public header which declares all methods supported for the 2003 indicated resource. 2005 It is not necessary to use OPTIONS to discover support of a method, 2006 the client could simply try the method. If the receiver of the 2007 request does not support the method it will respond with an error 2008 code indicating the the method is either not implemented (501) or 2009 does not apply for the resource (405). The choice between the two 2010 discovery methods depends on the requirements of the service. 2012 Feature-Tags are defined to handle functionality additions that are 2013 not new methods. Each feature-tag represents a certain block of 2014 functionality. The amount of functionality that a feature-tag 2015 represents can vary significantly. A feature-tag can for example 2016 represent the functionality a single RTSP header provides. Another 2017 feature-tag can represent much more functionality, such as the 2018 "play.basic" feature-tag which represents the minimal playback 2019 implementation. 2021 Feature-tags are used to determine wether the client, server or proxy 2022 supports the functionality that is necessary to achieve the desired 2023 service. To determine support of a feature-tag, several different 2024 headers can be used, each explained below: 2026 Supported: The supported header is used to determine the complete 2027 set of functionality that both client and server have. The 2028 intended usage is to determine before one needs to use a 2029 functionality that it is supported. It can be used in any 2030 method, however OPTIONS is the most suitable one as it at the 2031 same time determines all methods that are implemented. When 2032 sending a request the requestor declares all its capabilities 2033 by including all supported feature-tags. This results in that 2034 the receiver learns the requestors feature support. The 2035 receiver then includes its set of features in the response. 2037 Proxy-Supported: The Proxy-Supported header is used similar to the 2038 Supported header, but instead of giving the supported 2039 functionality of the client or server it provides both the 2040 requestor and the responder a view of what functionality the 2041 proxy chain between the two supports. Proxies are required to 2042 add this header whenever the Supported header is present, but 2043 proxies may independently of the requestor add it. 2045 Require: The Require header can be included in any request where the 2046 end-point, i.e. the client or server, is required to understand 2047 the feature to correctly perform the request. This can, for 2048 example, be a SETUP request where the server is required to 2049 understand a certain parameter to be able to set up the media 2050 delivery correctly. Ignoring this parameter would not have the 2051 desired effect and is not acceptable. Therefore the end-point 2052 receiving a request containing a Require MUST negatively 2053 acknowledge any feature that it does not understand and not 2054 perform the request. The response in cases where features are 2055 not supported are 551 (Option Not Supported). Also the 2056 features that are not supported are given in the Unsupported 2057 header in the response. 2059 Proxy-Require: This method has the same purpose and workings as 2060 Require except that it only applies to proxies and not the end- 2061 point. Features that needs to be supported by both proxies and 2062 end-point needs to be included in both the Require and Proxy- 2063 Require header. 2065 Unsupported: This header is used in a 551 error response, to 2066 indicate which feature(s) that was not supported. Such a 2067 response is only the result of the usage of the Require and/or 2068 Proxy-Require header where one or more feature where not 2069 supported. This information allows the requestor to make the 2070 best of situations as it knows which features are not 2071 supported. 2073 12. Pipelining Support 2075 Pipelining is a general method to improve performance of request 2076 response protocols by allowing the requesting entity to have more 2077 than one request outstanding and send them over the same persistent 2078 connection. For RTSP where the relative order of requests will 2079 matter it is important to maintain the order of the requests. 2080 Because of this the the responding entity SHALL process the incoming 2081 requests in their sending order. The sending order can be determined 2082 by the CSeq header and its sequence number. For TCP the delivery 2083 order will be the same as the sending order. The processing of the 2084 request SHALL also have been finished before processing the next 2085 request from the same entity. The responses MUST be sent in the 2086 order the requests was processed. 2088 RTSP 2.0 has extended support for pipelining compared to RTSP 1.0. 2089 The major improvement is to allow all requests to setup and initiate 2090 media playback to be pipelined after each other. This is 2091 accomplished by the utilization of the Pipelined-Requests header (See 2092 Section 16.29). This header allows a client to request that two or 2093 more requests is to be processed in the same RTSP session context 2094 which the first request creates. In other words a client can request 2095 that two or more media streams are set-up and then played without 2096 needing to wait for a single response. This speeds up the initial 2097 startup time for an RTSP session with at least one RTT. 2099 When pipelining requests care must be taken. If a pipelined request 2100 builds on the succesful completion of one or more prior requests the 2101 requestor must verify that all requests was executed as expected. O 2102 common example will be two SETUP requests and a PLAY request. In 2103 case one of the SETUP fails unexpectedly, the PLAY request can still 2104 be succesfully executed. However, not as expected by the requesting 2105 client as only a single media instead of two will be played. In this 2106 case the client can send a PAUSE request, correct the failing SETUP 2107 request and then request it to be played. 2109 13. Method Definitions 2111 The method indicates what is to be performed on the resource 2112 identified by the Request-URI. The method name is case-sensitive. 2113 New methods may be defined in the future. Method names SHALL NOT 2114 start with a $ character (decimal 24) and MUST be a token as defined 2115 by the ABNF [RFC4234] in the syntax chapter Section 21. The methods 2116 are summarized in Table 7. 2118 +---------------+-----------+--------+--------------+---------------+ 2119 | method | direction | object | Server req. | Client req. | 2120 +---------------+-----------+--------+--------------+---------------+ 2121 | DESCRIBE | C -> S | P,S | recommended | recommended | 2122 | | | | | | 2123 | GET_PARAMETER | C -> S | P,S | optional | optional | 2124 | | | | | | 2125 | | S -> C | | | | 2126 | | | | | | 2127 | OPTIONS | C -> S | P,S | R=Req, | Sd=Req, R=Opt | 2128 | | | | Sd=Opt | | 2129 | | | | | | 2130 | | S -> C | | | | 2131 | | | | | | 2132 | PAUSE | C -> S | P,S | required | required | 2133 | | | | | | 2134 | PLAY | C -> S | P,S | required | required | 2135 | | | | | | 2136 | REDIRECT | S -> C | P,S | optional | required | 2137 | | | | | | 2138 | SETUP | C -> S | S | required | required | 2139 | | | | | | 2140 | SETPARAMETER | C -> S | P,S | required | optional | 2141 | | | | | | 2142 | | S -> C | | | | 2143 | | | | | | 2144 | TEARDOWN | C -> S | P,S | required | required | 2145 +---------------+-----------+--------+--------------+---------------+ 2147 Table 7: Overview of RTSP methods, their direction, and what objects 2148 (P: presentation, S: stream) they operate on. Legend: R=Respond, 2149 Sd=Send, Opt: Optional, Req: Required 2151 Note on Table 7: GET_PARAMETER is recommended, but not required. 2152 For example, a fully functional server can be built to deliver 2153 media without any parameters. SETPARAMETER is required however 2154 due to its usage for keep-alive. PAUSE is now required due to 2155 that it is the only way of getting out of the state machines play 2156 state without terminating the whole session. 2158 If an RTSP agent does not support a particular method, it MUST return 2159 501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD 2160 NOT try this method again for the given agent / resource combination. 2162 13.1. OPTIONS 2164 The semantics of the RTSP OPTIONS method is equivalent to that of the 2165 HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is 2166 bi-directional, in that a client can request it to a server and vice 2167 versa. A client MUST implement the capability to send an OPTIONS 2168 request and a server or a proxy MUST implement the capability to 2169 respond to an OPTIONS request. The client, server or proxy MAY also 2170 implement the converse of their required capability. 2172 An OPTIONS request may be issued at any time. Such a request does 2173 not modify the session state. However, it may prolong the session 2174 lifespan (see below). The URI in an OPTIONS request determines the 2175 scope of the request and the corresponding response. If the Request- 2176 URI refers to a specific media resource on a given host, the scope is 2177 limited to the set of methods supported for that media resource by 2178 the indicated RTSP agent. A Request-URI with only the host address 2179 limits the scope to the specified RTSP agent's general capabilities 2180 without regard to any specific media. If the Request-URI is an 2181 asterisk ("*"), the scope is limited to the general capabilities of 2182 the next hop (i.e. the RTSP agent in direct communication with the 2183 request sender). 2185 Regardless of scope of the request, the Public header MUST always be 2186 included in the OPTIONS response listing the methods that are 2187 supported by the responding RTSP agent. In addition, if the scope of 2188 the request is limited to a media resource, the Allow header MUST be 2189 included in the response to enumerate the set of methods that are 2190 allowed for that resource unless the set of methods completely 2191 matches the set in the Public header. If the given resource is not 2192 available, the RTSP agent SHOULD return an appropriate response code 2193 such as 3rr or 4xx. The Supported header MAY be included in the 2194 request to query the set of features that are supported by the 2195 responding RTSP agent. 2197 The OPTIONS method can be used to keep an RTSP session alive. 2198 However, it is not the preferred means of session keep-alive 2199 signalling, see Section 16.43. An OPTIONS request intended for 2200 keeping alive an RTSP session MUST include the Session header with 2201 the associated session ID. Such a request SHOULD also use the media 2202 or the aggregated control URI as the Request-URI. 2204 Example: 2206 C->S: OPTIONS * RTSP/2.0 2207 CSeq: 1 2208 User-Agent: PhonyClient/1.2 2209 Require: 2210 Proxy-Require: gzipped-messages 2211 Supported: play.basic 2213 S->C: RTSP/2.0 200 OK 2214 CSeq: 1 2215 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE 2216 Supported: play.basic, implicit-play, gzipped-messages 2217 Server: PhonyServer/1.1 2219 Note that some of the feature-tags in Require and Proxy-Require are 2220 fictional features. 2222 13.2. DESCRIBE 2224 The DESCRIBE method is used to retrieve the description of a 2225 presentation or media object from a server. The Request-URI of the 2226 DESCRIBE request identifies the media resource of interest. The 2227 client MAY include the Accept header in the request to list the 2228 description formats that it understands. The server SHALL respond 2229 with a description of the requested resource and return the 2230 description in the entity of the response. The DESCRIBE reply- 2231 response pair constitutes the media initialization phase of RTSP. 2233 Example: 2235 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 2236 CSeq: 312 2237 User-Agent: PhonyClient 1.2 2238 Accept: application/sdp, application/example 2240 S->C: RTSP/2.0 200 OK 2241 CSeq: 312 2242 Date: 23 Jan 1997 15:35:06 GMT 2243 Server: PhonyServer 1.1 2244 Content-Type: application/sdp 2245 Content-Length: 367 2247 v=0 2248 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46 2249 s=SDP Seminar 2250 i=A Seminar on the session description protocol 2251 u=http://www.example.com/lectures/sdp.ps 2252 e=seminar@example.com (Seminar Management) 2253 c=IN IP4 224.2.17.12/127 2254 t=2873397496 2873404696 2255 a=recvonly 2256 m=audio 3456 RTP/AVP 0 2257 m=video 2232 RTP/AVP 31 2258 m=application 32416 UDP WB 2259 a=orient:portrait 2261 The DESCRIBE response SHOULD contain all media initialization 2262 information for the resource(s) that it describes. Servers SHOULD 2263 NOT use the DESCRIBE response as a means of media indirection by 2264 having the description point at another server, instead usage of 3rr 2265 responses are recommended. 2267 By forcing a DESCRIBE response to contain all media initialization 2268 for the set of streams that it describes, and discouraging the use 2269 of DESCRIBE for media indirection, any looping problems can be 2270 avoided that might have resulted from other approaches. 2272 Media initialization is a requirement for any RTSP-based system, but 2273 the RTSP specification does not dictate that this is required to be 2274 done via the DESCRIBE method. There are three ways that an RTSP 2275 client may receive initialization information: 2277 o via an RTSP DESCRIBE request 2279 o via some other protocol (HTTP, email attachment, etc.) 2281 o via some form of a user interface 2282 If a client obtains a valid description from an alternate source, the 2283 client MAY use this description for initialization purposes without 2284 issuing a DESCRIBE request for the same media. 2286 It is RECOMMENDED that minimal servers support the DESCRIBE method, 2287 and highly recommended that minimal clients support the ability to 2288 act as "helper applications" that accept a media initialization file 2289 from a user interface, and/or other means that are appropriate to the 2290 operating environment of the clients. 2292 13.3. SETUP 2294 The SETUP request for an URI specifies the transport mechanism to be 2295 used for the streamed media. The SETUP method may be used in three 2296 different cases; Create an RTSP session, add a media to a session, 2297 and change the transport parameters of already set up media stream. 2298 When in PLAY state, using SETUP to create or add media to a session 2299 when in PLAY state is unspecified. Otherwise SETUP can be used in 2300 all three states; INIT, and READY, for both purposes and in PLAY to 2301 change the transport parameters. 2303 The Transport header, see Section 16.46, specifies the transport 2304 parameters acceptable to the client for data transmission; the 2305 response will contain the transport parameters selected by the 2306 server. This allows the client to enumerate in descending order of 2307 preference the transport mechanisms and parameters acceptable to it, 2308 while the server can select the most appropriate. It is expected 2309 that the session description format used will enable the client to 2310 select a limited number possible configurations that are offered to 2311 the server to choose from. All transport related parameters shall be 2312 included in the Transport header, the use of other headers for this 2313 purpose is discouraged due to middle boxes such as firewalls, or 2314 NATs. 2316 For the benefit of any intervening firewalls, a client SHALL indicate 2317 the known transport parameters, even if it has no influence over 2318 these parameters, for example, where the server advertises a fixed 2319 multicast address as destination. 2321 Since SETUP includes all transport initialization information, 2322 firewalls and other intermediate network devices (which need this 2323 information) are spared the more arduous task of parsing the 2324 DESCRIBE response, which has been reserved for media 2325 initialization. 2327 The client SHALL include the Accept-Ranges header in the request 2328 indicating all supported unit formats in the Range header. This 2329 allows the server to know which format it may use in future session 2330 related responses, such as PLAY response without any range in the 2331 request. If the client does not support a time format necessary for 2332 the presentation the server SHALL respond using 456 (Header Field Not 2333 Valid for Resource) and include the Accept-Ranges header with the 2334 range unit formats supported for the resource. 2336 In a SETUP response the server SHALL include the Accept-Ranges header 2337 (see Section 16.5) to indicate which time formats that are acceptable 2338 to use for this media resource. 2340 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 2341 CSeq: 302 2342 Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589", 2343 RTP/AVP/TCP;unicast;interleaved=0-1 2344 Accept-Ranges: NPT, UTC 2345 User-Agent: PhonyClient/1.2 2347 S->C: RTSP/2.0 200 OK 2348 CSeq: 302 2349 Date: 23 Jan 1997 15:35:06 GMT 2350 Server: PhonyServer 1.1 2351 Session: 47112344;timeout=60 2352 Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589"; 2353 src_addr="192.0.2.241:6256"/"192.0.2.241:6257"; 2354 ssrc=2A3F93ED 2355 Accept-Ranges: NPT 2357 In the above example the client wants to create an RTSP session 2358 containing the media resource "rtsp://example.com/foo/bar/baz.rm". 2359 The transport parameters acceptable to the client is either RTP/AVP/ 2360 UDP (UDP per default) to be received on client port 4588 and 4589 or 2361 RTP/AVP interleaved on the RTSP control channel. The server selects 2362 the RTP/AVP/UDP transport and adds the ports it will send and 2363 received RTP and RTCP from, and the RTP SSRC that will be used by the 2364 server. 2366 The server MUST generate a session identifier in response to a 2367 successful SETUP request, unless a SETUP request to a server includes 2368 a session identifier, in which case the server MUST bundle this setup 2369 request into the existing session (aggregated session) or return 2370 error 459 (Aggregate Operation Not Allowed) (see Section 15.4.11). 2371 An Aggregate control URI MUST be used to control an aggregated 2372 session. This URI MUST be different from the stream control URIs of 2373 the individual media streams included in the aggregate. The 2374 Aggregate control URI is to be specified by the session description 2375 if the server supports aggregated control and aggregated control is 2376 desired for the session. However even if aggregated control is 2377 offered the client MAY chose to not set up the session in aggregated 2378 control. If an Aggregate control URI is not specified in the session 2379 description, it is normally an indication that non-aggregated control 2380 should be used. The SETUP of media streams in an aggregate which has 2381 not been given an aggregated control URI is unspecified. 2383 While the session ID sometimes has enough information for 2384 aggregate control of a session, the Aggregate control URI is still 2385 important for some methods such as SETPARAMETER where the control 2386 URI enables the resource in question to be easily identified. The 2387 Aggregate control URI is also useful for proxies, enabling them to 2388 route the request to the appropriate server, and for logging, 2389 where it is useful to note the actual resource that a request was 2390 operating on. 2392 A session will exist until it is either removed by a TEARDOWN request 2393 or is timed-out by the server. The server MAY remove a session that 2394 has not demonstrated liveness signs from the client(s) within a 2395 certain timeout period. The default timeout value is 60 seconds; the 2396 server MAY set this to a different value and indicate so in the 2397 timeout field of the Session header in the SETUP response. For 2398 further discussion see Section 16.43. Signs of liveness for an RTSP 2399 session are: 2401 o Any RTSP request from a client(s) which includes a Session header 2402 with that session's ID. 2404 o If RTP is used as a transport for the underlying media streams, an 2405 RTCP sender or receiver report from the client(s) for any of the 2406 media streams in that RTSP session. RTCP Sender Reports may for 2407 example be received in sessions where the server is invited into a 2408 conference session and is as valid for keep-alive. 2410 If a SETUP request on a session fails for any reason, the session 2411 state, as well as transport and other parameters for associated 2412 streams SHALL remain unchanged from their values as if the SETUP 2413 request had never been received by the server. 2415 13.3.1. Changing Transport Parameters 2417 A client MAY issue a SETUP request for a stream that is already set 2418 up or playing in the session to change transport parameters, which a 2419 server MAY allow. If it does not allow changing of parameters, it 2420 MUST respond with error 455 (Method Not Valid In This State). 2421 Reasons to support changing transport parameters, is to allow for 2422 application layer mobility and flexibility to utilize the best 2423 available transport as it becomes available. If a client receives a 2424 455 when trying to change transport parameters while the server is in 2425 play state, it MAY try to put the server in ready state using PAUSE, 2426 before issuing the SETUP request again. If also that fails the 2427 changing of transport parameters will require that the client 2428 performs a TEARDOWN of the affected media and then setting it up 2429 again. In aggregated session avoiding tearing down all the media at 2430 the same time will avoid the creation of a new session. 2432 All transport parameters MAY be changed. However the primary usage 2433 expected is to either change transport protocol completely, like 2434 switching from Interleaved TCP mode to UDP or vise versa or change 2435 delivery address. 2437 In a SETUP response for a request to change the transport parameters 2438 while in Play state, the server SHALL include the Range to indicate 2439 from what point the new transport parameters are used. Further, if 2440 RTP is used for delivery, the server SHALL also include the RTP-Info 2441 header to indicate from what timestamp and RTP sequence number the 2442 change has taken place. If both RTP-Info and Range is included in 2443 the response the "rtp_time" parameter and range MUST be for the 2444 corresponding time, i.e. be used in the same way as for PLAY to 2445 ensure the correct synchronization information is available. 2447 If the transport parameters change while in PLAY state results in a 2448 change of synchronization related information, for example changing 2449 RTP SSRC, the server MUST provide in the SETUP response the necessary 2450 synchronization information. However the server is RECOMMENDED to 2451 avoid changing the synchronization information if possible. 2453 13.4. PLAY 2455 The PLAY method tells the server to start sending data via the 2456 mechanism specified in SETUP. PLAY requests are valid when the 2457 session is in READY or PLAY states. A PLAY request MUST include a 2458 Session header to indicate which session the request applies to. 2460 For aggregated sessions where the initial SETUP request (creating a 2461 session) is followed by one or more additional SETUP request, a PLAY 2462 request MAY be pipelined after those additional SETUP requests 2463 without awaiting their responses. This can procedure can reduce the 2464 delay from start of session establishment until media play-out has 2465 started with one round trip time. However an client needs to be 2466 aware that using this procedure will result in the playout of the 2467 server state established at the time of processing the PLAY, i.e. 2468 after the processing of all the requests prior to the PLAY request in 2469 the pipeline. This may not be the intended one due to failure of any 2470 of the prior requests. However a client easily determine this based 2471 on the responses from those requests. In case of failure the client 2472 can halt the media playout using PAUSE and try to establish the 2473 intended state again before issuing another PLAY request. 2475 In an aggregated session the PLAY request MUST contain an aggregated 2476 control URI. A server SHALL responde with error 460 (Only Aggregate 2477 Operation Allowed) if the client PLAY Request-URI is for one of the 2478 media. The media in an aggregate SHALL be played in sync. If a 2479 client want individual control of the media it needs to use separate 2480 RTSP sessions for each media. 2482 Upon receipt of the PLAY request, the server SHALL position the 2483 normal play time to the beginning of the range specified in the 2484 received Range header and delivers stream data until the end of the 2485 range if given, or until a new PLAY request is received, else to the 2486 end of the media is reached. To allow for precise composition 2487 multiple ranges MAY be specified in one PLAY Request. The range 2488 values are valid if all given ranges are part of any media within the 2489 aggregate. If a given range value points outside of the media, the 2490 response SHALL be the 457 (Invalid Range) error code. 2492 The below example will first play seconds 10 through 15, then, 2493 immediately following, seconds 20 to 25, and finally seconds 30 2494 through the end. 2496 C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0 2497 CSeq: 835 2498 Session: 12345678 2499 Range: npt=10-15, npt=20-25, npt=30- 2500 User-Agent: PhonyClient/1.2 2502 See the description of the PAUSE request for further examples. 2504 A PLAY request without a Range header is legal. It SHALL start 2505 playing a stream from the beginning (npt=0-) unless the stream has 2506 been paused or is currently playing. If a stream has been paused via 2507 PAUSE, stream delivery resumes at the pause point. If a stream is 2508 currently playing, the new PLAY begins at the current stream 2509 position. The stream SHALL play until the end of the media. 2511 The Range header MUST NOT contain a time parameter. The usage of 2512 time in PLAY method has been deprecated. If a request with time 2513 parameter is received the server SHOULD respond with a 457 (Invalid 2514 Range) to indicate that the time parameter is not supported. 2516 Server MUST include a "Range" header in any PLAY response. The 2517 response MUST use the same format as the request's range header 2518 contained. If no Range header was in the request, the NPT time 2519 format SHOULD be used unless the client showed support for an other 2520 format more appropriate. Also for a session with live media streams 2521 the Range header MUST indicate a valid time. It is RECOMMENDED that 2522 normal play time is used, either the "now" indicator, for example 2523 "npt=now-", or the time since session start as an open interval, e.g. 2524 "npt=96.23-". An absolute time value (clock) for the corresponding 2525 time MAY be given, i.e. "clock=20030213T143205Z-". The UTC clock 2526 format SHOULD only be used if client has shown support for it. 2528 For an on-demand stream, the server MUST reply with the actual range 2529 that will be played back, i.e. for which duration any media (having 2530 content at this time) is delivered. This may differ from the 2531 requested range if alignment of the requested range to valid frame 2532 boundaries is required for the media source. Note that some media 2533 streams in an aggregate may need to be delivered from even earlier 2534 points. Also, some media format have a very long duration per 2535 individual data unit, therefore it might be necessary for the client 2536 to parse the data unit, and select where to start. 2538 Example: Single audio stream (MIDI) 2540 C->S: PLAY rtsp://example.com/audio RTSP/2.0 2541 CSeq: 836 2542 Session: 12345678 2543 Range: npt=7.05- 2544 User-Agent: PhonyClient/1.2 2546 S->C: RTSP/2.0 200 OK 2547 CSeq: 836 2548 Date: 23 Jan 1997 15:35:06 GMT 2549 Server: PhonyServer 1.0 2550 Range: npt=3.52- 2551 RTP-Info:url="rtsp://example.com/audio" 2552 ssrc=0D12F123:seq=14783;rtptime=2345962545 2554 S->C: RTP Packet TS=2345962545 => NPT=3.52 2555 Duration=4.15 seconds 2557 In this example the client receives the first media packet that 2558 stretches all the way up and past the requested playtime. Thus, it 2559 is the client's decision if to render to the user the time between 2560 3.52 and 7.05, or to skip it. In most cases it is probably most 2561 suitable to not render that time period. 2563 For live media sources it might be impossible to specify from which 2564 point in time all media streams carrying active content can actually 2565 be delivered. Therefore a server MAY specify a start time (or now-) 2566 in the range header, for which not all media will be available from. 2568 If no range is specified in the request, the start position SHALL 2569 still be returned in the reply. If the medias that are part of an 2570 aggregate has different lengths, the PLAY request SHALL be performed 2571 as long as the given range is valid for any media, for example the 2572 longest media. Media will be sent whenever it is available for the 2573 given play-out point. 2575 A PLAY response MAY include a header(s) carrying synchronization 2576 information. As the information necessary is dependent on the media 2577 transport format, further rules specifying the header and its usage 2578 is needed. For RTP the RTP-Info header is specified, see 2579 Section 16.39. 2581 After playing the desired range, the presentation does NOT transition 2582 to the READY state, media delivery simply stops. A PAUSE request 2583 MUST be issued before the stream enters the READY state. A PLAY 2584 request while the stream is still in the PLAYING state is legal, and 2585 can be issued without an intervening PAUSE request. Such a request 2586 SHALL replace the current PLAY action with the new one requested, 2587 i.e. being handle the same as the request was received in ready 2588 state. In the case the first time range in Range header has a open 2589 start time (-endtime), the server SHALL continue to play from where 2590 it currently was until the specified end point. This is useful to 2591 change ongoing playback to play another sequence, or end at another 2592 point than in the previous request. 2594 A client desiring to play the media from the beginning MUST send a 2595 PLAY request with a Range header pointing at the beginning, e.g. 2596 npt=0-. If a PLAY request is received without a Range header when 2597 media delivery has stopped at the end, the server SHOULD respond with 2598 a 457 "Invalid Range" error response. In that response the current 2599 pause point in a Range header SHALL be included. 2601 The following example plays the whole presentation starting at SMPTE 2602 time code 0:10:20 until the end of the clip. Note: The RTP-Info 2603 headers has been broken into several lines to fit the page. 2605 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0 2606 CSeq: 833 2607 Session: 12345678 2608 Range: smpte=0:10:20- 2609 User-Agent: PhonyClient/1.2 2611 S->C: RTSP/2.0 200 OK 2612 CSeq: 833 2613 Date: 23 Jan 1997 15:35:06 GMT 2614 Server: PhonyServer 1.0 2615 Range: smpte=0:10:22-0:15:45 2616 RTP-Info:url="rtsp://example.com/twister.en" 2617 ssrc=0D12F123:seq=14783;rtptime=2345962545 2619 For playing back a recording of a live presentation, it may be 2620 desirable to use clock units: 2622 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0 2623 CSeq: 835 2624 Session: 12345678 2625 Range: clock=19961108T142300Z-19961108T143520Z 2626 User-Agent: PhonyClient/1.2 2628 S->C: RTSP/2.0 200 OK 2629 CSeq: 835 2630 Date: 23 Jan 1997 15:35:06 GMT 2631 Server:PhonyServer 1.0 2632 Range: clock=19961108T142300Z-19961108T143520Z 2633 RTP-Info:url="rtsp://example.com/meeting.en" 2634 ssrc=0D12F123:seq=53745;rtptime=484589019 2636 All range specifiers in this specification allow for ranges with 2637 unspecified begin times (e.g. "npt=-30"). When used in a PLAY 2638 request, the server treats this as a request to start/resume playback 2639 from the current pause point, ending at the end time specified in the 2640 Range header. If the pause point is located later than the given end 2641 value, a 457 (Invalid Range) response SHALL be given. 2643 The possibility to replace a current PLAY request with a new one 2644 replaces two RTSP 1.0 functions: 2646 o The queued play functionality described in RFC 2326 [RFC2326] is 2647 removed and multiple ranges can be used to achieve a similar 2648 functionality. 2650 o The use of PLAY for keep-alive signaling, i.e. PLAY request 2651 without a range header in PLAY state, has also been deprecated. 2652 Instead a client can use, SETPARAMETER (recommended) or OPTIONS 2653 (allowed) for keep alive. 2655 An example of using PLAY request to change the behavior, if a server 2656 has received requests to play ranges 10 to 15 and then 13 to 20 (that 2657 is, overlapping ranges), a PLAY request 4 seconds after the first 2658 would take effect while the server plays the first range. Thus 2659 changing the behavior to continue to play to 25 seconds, i.e. the 2660 played range equal play with range: npt=10-25. If the second PLAY 2661 request would arrive as the second range in the first request was 2662 playing, then the equivalent request would be play with range:npt=10- 2663 15,npt=13-25. 2665 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 2666 CSeq: 834 2667 Session: 12345678 2668 Range: npt=10-15, npt=13-20 2669 User-Agent: PhonyClient/1.2 2671 S->C: RTSP/2.0 200 OK 2672 CSeq: 834 2673 Date: 23 Jan 1997 15:35:06 GMT 2674 Server: PhonyServer 1.0 2675 Range: npt=10-15, npt=13-20 2676 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 2677 ssrc=0D12F123:seq=5712;rtptime=934207921, 2678 url="rtsp://example.com/fizzle/videotrack" 2679 ssrc=789DAF12:seq=57654;rtptime=2792482193 2680 Session: 12345678 2682 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 2683 CSeq: 835 2684 Session: 12345678 2685 Range: npt=-25 2686 User-Agent: PhonyClient/1.2 2688 S->C: RTSP/2.0 200 OK 2689 CSeq: 835 2690 Date: 23 Jan 1997 15:35:09 GMT 2691 Server: PhonyServer 1.0 2692 Range: npt=14-25 2693 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 2694 ssrc=0D12F123:seq=5712;rtptime=934239921, 2695 url="rtsp://example.com/fizzle/videotrack" 2696 ssrc=789DAF12:seq=57654;rtptime=2792842193 2697 Session: 12345678 2699 13.5. PAUSE 2701 The PAUSE request causes the stream delivery to immediately be 2702 interrupted (halted). A PAUSE request MUST be done either with the 2703 aggregated control URI for aggregated sessions, resulting in all 2704 media being halted, or the media URI for non-aggregated sessions. 2705 Any attempt to do muting of a single media with an PAUSE request in 2706 an aggregated session SHALL be responded with error 460 (Only 2707 Aggregate Operation Allowed). After resuming playback, 2708 synchronization of the tracks MUST be maintained. Any server 2709 resources are kept, though servers MAY close the session and free 2710 resources after being paused for the duration specified with the 2711 timeout parameter of the Session header in the SETUP message. 2713 Example: 2715 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 2716 CSeq: 834 2717 Session: 12345678 2718 User-Agent: PhonyClient/1.2 2720 S->C: RTSP/2.0 200 OK 2721 CSeq: 834 2722 Date: 23 Jan 1997 15:35:06 GMT 2723 Range: npt=45.76- 2725 The PAUSE request causes stream delivery to be interrupted 2726 immediately on receipt of the message and the pause point is set to 2727 the current point in the presentation. That pause point in the media 2728 stream needs to be maintained. A subsequent PLAY request without 2729 Range header SHALL resume from the pause point and play until media 2730 end. 2732 The pause point after any PAUSE request SHALL be returned to the 2733 client by adding a Range header with what remains unplayed of the 2734 PLAY request's ranges, i.e. including all the remaining ranges part 2735 of multiple range specification. If one desires to resume playing a 2736 ranged request, one simply includes the Range header from the PAUSE 2737 response. 2739 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 2740 CSeq: 834 2741 Session: 12345678 2742 Range: npt=10-30 2743 User-Agent: PhonyClient/1.2 2745 S->C: RTSP/2.0 200 OK 2746 CSeq: 834 2747 Date: 23 Jan 1997 15:35:06 GMT 2748 Server: PhonyServer 1.0 2749 Range: npt=10-30 2750 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 2751 ssrc=0D12F123:seq=5712;rtptime=934207921, 2752 url="rtsp://example.com/fizzle/videotrack" 2753 ssrc=4FAD8726:seq=57654;rtptime=2792482193 2754 Session: 12345678 2756 after 11 seconds, i.e. at 21 seconds into the presentation: 2757 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 2758 CSeq: 835 2759 Session: 12345678 2760 User-Agent: PhonyClient/1.2 2762 S->C: RTSP/2.0 200 OK 2763 CSeq: 835 2764 Date: 23 Jan 1997 15:35:09 GMT 2765 Server: PhonyServer 1.0 2766 Range: npt=21-30 2767 Session: 12345678 2769 If a client issues a PAUSE request and the server acknowledges and 2770 enters the READY state, the proper server response, if the player 2771 issues another PAUSE, is still 200 OK. The 200 OK response MUST 2772 include the Range header with the current pause point. See examples 2773 below: 2775 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 2776 CSeq: 834 2777 Session: 12345678 2778 User-Agent: PhonyClient/1.2 2780 S->C: RTSP/2.0 200 OK 2781 CSeq: 834 2782 Session: 12345678 2783 Date: 23 Jan 1997 15:35:06 GMT 2784 Range: npt=45.76-98.36 2786 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 2787 CSeq: 835 2788 Session: 12345678 2789 User-Agent: PhonyClient/1.2 2791 S->C: RTSP/2.0 200 OK 2792 CSeq: 835 2793 Session: 12345678 2794 Date: 23 Jan 1997 15:35:07 GMT 2795 Range: npt=45.76-98.36 2797 13.6. TEARDOWN 2799 The TEARDOWN client to server request stops the stream delivery for 2800 the given URI, freeing the resources associated with it. A TEARDOWN 2801 request MAY be performed on either an aggregated or a media control 2802 URI. However some restrictions apply depending on the current state. 2803 The TEARDOWN request SHALL contain a Session header indicating what 2804 session the request applies to. 2806 A TEARDOWN using the aggregated control URI or the media URI in a 2807 session under non-aggregated control (single media session) MAY be 2808 done in any state (Ready, and Play). A successful request SHALL 2809 result in that media delivery is immediately halted and the session 2810 state is destroyed. This SHALL be indicated through the lack of a 2811 Session header in the response. 2813 A TEARDOWN using a media URI in an aggregated session MAY only be 2814 done in Ready state. Such a request only removes the indicated media 2815 stream and associated resources from the session. This may result in 2816 that a session returns to non-aggregated control, due to that it only 2817 contains a single media after the requests completion. A session 2818 that will exist after the processing of the TEARDOWN request SHALL in 2819 the response to that TEARDOWN request contain a Session header. Thus 2820 the presence of the Session header indicates to the receiver of the 2821 response if the session is still existing or has been removed. 2823 Example: 2825 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0 2826 CSeq: 892 2827 Session: 12345678 2828 User-Agent: PhonyClient/1.2 2830 S->C: RTSP/2.0 200 OK 2831 CSeq: 892 2832 Server: PhonyServer 1.0 2834 13.7. GET_PARAMETER 2836 The GET_PARAMETER request retrieves the value of a parameter or 2837 parameters for a presentation or stream specified in the URI. If the 2838 Session header is present in a request, the value of a parameter MUST 2839 be retrieved in the specified session context. The content of the 2840 reply and response is left to the implementation. 2842 The method MAY also be used without a body (entity). If the this 2843 request is successful, i.e. a 200 OK response is received, then the 2844 keep-alive timer has been updated. Any non-required header present 2845 in such a request may or may not been processed. To allow a client 2846 to determine if any such header has been processed, it is necessary 2847 to use a feature-tag and the Require header. Due to this reason it 2848 is RECOMMENDED that any parameters to be retrieved are sent in the 2849 body, rather than using any header. 2851 Example: 2853 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 2854 CSeq: 431 2855 Content-Type: text/parameters 2856 Session: 12345678 2857 Content-Length: 26 2858 User-Agent: PhonyClient/1.2 2860 packets_received 2861 jitter 2863 C->S: RTSP/2.0 200 OK 2864 CSeq: 431 2865 Content-Length: 38 2866 Content-Type: text/parameters 2868 packets_received: 10 2869 jitter: 0.3838 2871 The "text/parameters" section is only an example type for a body 2872 carrying parameters. 2874 13.8. SET_PARAMETER 2876 This method requests to set the value of a parameter or a set of 2877 parameters for a presentation or stream specified by the URI. The 2878 method MAY also be used without a body (entity). It is the 2879 RECOMMENDED method to use in request sent for the sole purpose of 2880 updating the keep-alive timer. If this request is successful, i.e. a 2881 200 OK response is received, then the keep-alive timer has been 2882 updated. Any non-required header present in such a request may or 2883 may not been processed. To allow a client to determine if any such 2884 header has been processed, it is necessary to use a feature tag and 2885 the Require header. Due to this reason it is RECOMMENDED that any 2886 parameters are sent in the body, rather than using any header. 2888 A request is RECOMMENDED to only contain a single parameter to allow 2889 the client to determine why a particular request failed. If the 2890 request contains several parameters, the server MUST only act on the 2891 request if all of the parameters can be set successfully. A server 2892 MUST allow a parameter to be set repeatedly to the same value, but it 2893 MAY disallow changing parameter values. If the receiver of the 2894 request does not understand or cannot locate a parameter, error 451 2895 (Parameter Not Understood) SHALL be used. In the case a parameter is 2896 not allowed to change, the error code is 458 (Parameter Is Read- 2897 Only). The response body SHOULD contain only the parameters that 2898 have errors. Otherwise no body SHALL be returned. 2900 Note: transport parameters for the media stream MUST only be set with 2901 the SETUP command. 2903 Restricting setting transport parameters to SETUP is for the 2904 benefit of firewalls. 2906 The parameters are split in a fine-grained fashion so that there 2907 can be more meaningful error indications. However, it may make 2908 sense to allow the setting of several parameters if an atomic 2909 setting is desirable. Imagine device control where the client 2910 does not want the camera to pan unless it can also tilt to the 2911 right angle at the same time. 2913 Example: 2915 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 2916 CSeq: 421 2917 User-Agent: PhonyClient/1.2 2918 Content-length: 20 2919 Content-type: text/parameters 2921 barparam: barstuff 2923 S->C: RTSP/2.0 451 Parameter Not Understood 2924 CSeq: 421 2925 Content-length: 10 2926 Content-type: text/parameters 2928 barparam: barstuff 2930 The "text/parameters" section is only an example type for 2931 parameters. This method is intentionally loosely defined with the 2932 intention that the reply content and response content will be 2933 defined by the one desiring to use this mechanism. 2935 13.9. REDIRECT 2937 The REDIRECT method is issued by a server to inform a client that it 2938 required to connect to another server location to access the resource 2939 indicated by the Request-URI. The presence of the Session header in 2940 a REDIRECT request indicates the scope of the request, and determines 2941 the specific semantics of the request. 2943 A REDIRECT request with a Session header has end-to-end (i.e. server 2944 to client) scope and applies only to the given session. Any 2945 intervening proxies SHOULD NOT disconnect the control channel while 2946 there are other remaining end-to-end sessions. The OPTIONAL Location 2947 header, if included in such a request, SHALL contain a complete 2948 absolute URI pointing to the resource to which the client SHOULD 2949 reconnect. Specifically, the Location SHALL NOT contain just the 2950 host and port. A client may receive a REDIRECT request with a 2951 Session header, if and only if, an end-to-end session has been 2952 established. 2954 A client may receive a REDIRECT request without a Session header at 2955 any time when it has communication or a connection established with a 2956 server. The scope of such a request is limited to the next-hop (i.e. 2957 the RTSP agent in direct communication with the server) and applies, 2958 as well, to the control connection between the next-hop RTSP agent 2959 and the server. A REDIRECT request without a Session header 2960 indicates that all sessions and pending requests being managed via 2961 the control connection MUST be redirected. The OPTIONAL Location 2962 header, if included in such a request, SHOULD contain an absolute URI 2963 with only the host address and the OPTIONAL port number of the server 2964 to which the RTSP agent SHOULD reconnect. Any intervening proxies 2965 SHOULD do all of the following in the order listed: 2967 1. respond to the REDIRECT request 2969 2. disconnect the control channel from the requesting server 2971 3. connect to the server at the given host address 2973 4. pass the REDIRECT request to each applicable client (typically 2974 those clients with an active session or an unanswered request) 2976 Note: The proxy is responsible for accepting REDIRECT responses 2977 from its clients; these responses MUST NOT be passed on to either 2978 the original server or the redirected server. 2980 The lack of a Location header in any REDIRECT request is indicative 2981 of the server no longer being able to fulfill the current request and 2982 having no alternatives for the client to continue with its normal 2983 operation. It is akin to a server initiated TEARDOWN that applies 2984 both to sessions as well as the general connection associated with 2985 that client. 2987 When the Range header is not included in a REDIRECT request, the 2988 client SHOULD perform the redirection immediately and return a 2989 response to the server. The server can consider the session as 2990 terminated and can free any associated state after it receives the 2991 successful (2xx) response. The server MAY close the signalling 2992 connection upon receiving the response and the client SHOULD close 2993 the signalling connection after sending the 2xx response. The 2994 exception to this is when the client has several sessions on the 2995 server being managed by the given signalling connection. In this 2996 case, the client SHOULD close the connection when it has received and 2997 responded to REDIRECT requests for all the sessions managed by the 2998 signalling connection. 3000 If the OPTIONAL Range header is included in a REDIRECT request, it 3001 indicates when the redirection takes effect. The range value MUST be 3002 an open ended single value, e.g. npt=59-, indicating the play out 3003 time when redirection SHALL occur. Alternatively, a range with a 3004 time= parameter indicates the wall clock time by when the redirection 3005 MUST take place. When the time= parameter is present in the range, 3006 any range value MUST be ignored even though it MUST be syntactically 3007 correct. To allow a client to determine that redirect time without 3008 being time synchronized with the server, the server SHALL include a 3009 Date header in the request. When the indicated redirect point is 3010 reached, a client MUST issue a TEARDOWN request and SHOULD close the 3011 signalling connection after receiving a 2xx response. The normal 3012 connection considerations apply for the server. 3014 The differentiation of REDIRECT requests with and without range 3015 headers is to allow for clear and explicit state handling. As the 3016 state in the server needs to be kept until the point of 3017 redirection, the handling becomes more clear if the client is 3018 required to TEARDOWN the session at the redirect point. 3020 If the REDIRECT request times out following the rules in Section 10.4 3021 the server MAY terminate the session or transport connection that 3022 would be redirected by the request. This is a safeguard against 3023 misbehaving clients that refuses to respond to a REDIRECT request. 3024 That should not provide any benefit. 3026 After a REDIRECT request has been processed, a client that wants to 3027 continue to send or receive media for the resource identified by the 3028 Request-URI will have to establish a new session with the designated 3029 host. If the URI given in the Location header is a valid resource 3030 URI, a client SHOULD issue a DESCRIBE request for the URI. 3032 Note: The media resource indicated by the \header {Location header 3033 can be identical, slightly different or totally different. This 3034 is the reason why a new DESCRIBE request SHOULD be issued. 3036 If the Location header contains only a host address, the client MAY 3037 assume that the media on the new server is identical to the media on 3038 the old server, i.e. all media configuration information from the old 3039 session is still valid except for the host address. However the 3040 usage of conditional SETUP using ETag identifiers are RECOMMENDED to 3041 verify the assumption. 3043 This example request redirects traffic for this session to the new 3044 server at the given absolute time: 3046 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0 3047 CSeq: 732 3048 Location: rtsp://s2.example.com:8001 3049 Range: npt=0- ;time=19960213T143205Z 3050 Session: uZ3ci0K+Ld-M 3052 C->S: RTSP/2.0 200 OK 3053 CSeq: 732 3054 User-Agent: PhonyClient/1.2 3056 14. Embedded (Interleaved) Binary Data 3058 In order to fulfill certain requirements on the network side, e.g. in 3059 conjunction with network address translators that block RTP traffic 3060 over UDP, it may be necessary to interleave RTSP messages and media 3061 stream data. This interleaving should generally be avoided unless 3062 necessary since it complicates client and server operation and 3063 imposes additional overhead. Also head of line blocking may cause 3064 problems. Interleaved binary data SHOULD only be used if RTSP is 3065 carried over TCP. 3067 Stream data such as RTP packets is encapsulated by an ASCII dollar 3068 sign (24 decimal), followed by a one-byte channel identifier, 3069 followed by the length of the encapsulated binary data as a binary, 3070 two-byte integer in network byte order. The stream data follows 3071 immediately afterwards, without a CRLF, but including the upper-layer 3072 protocol headers. Each $ block SHALL contain exactly one upper-layer 3073 protocol data unit, e.g., one RTP packet. 3075 0 1 2 3 3076 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 3077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3078 | "$" = 24 | Channel ID | Length in bytes | 3079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3080 : Length number of bytes of binary data : 3081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3083 The channel identifier is defined in the Transport header with the 3084 interleaved parameter (Section 16.46). 3086 When the transport choice is RTP, RTCP messages are also interleaved 3087 by the server over the TCP connection. The usage of RTCP messages is 3088 indicated by including a range containing a second channel in the 3089 interleaved parameter of the Transport header, see Section 16.46. If 3090 RTCP is used, packets SHALL be sent on the first available channel 3091 higher than the RTP channel. The channels are bi-directional and 3092 therefore RTCP traffic are sent on the second channel in both 3093 directions. 3095 RTCP is sometime needed for synchronization when two or more 3096 streams are interleaved in such a fashion. Also, this provides a 3097 convenient way to tunnel RTP/RTCP packets through the TCP control 3098 connection when required by the network configuration and transfer 3099 them onto UDP when possible. 3101 C->S: SETUP rtsp://example.com/bar.file RTSP/2.0 3102 CSeq: 2 3103 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 3104 Accept-Ranges: NPT, SMPTE, UTC 3105 User-Agent: PhonyClient/1.2 3107 S->C: RTSP/2.0 200 OK 3108 CSeq: 2 3109 Date: 05 Jun 1997 18:57:18 GMT 3110 Transport: RTP/AVP/TCP;unicast;interleaved=5-6 3111 Session: 12345678 3112 Accept-Ranges: NPT 3114 C->S: PLAY rtsp://example.com/bar.file RTSP/2.0 3115 CSeq: 3 3116 Session: 12345678 3117 User-Agent: PhonyClient/1.2 3119 S->C: RTSP/2.0 200 OK 3120 CSeq: 3 3121 Session: 12345678 3122 Date: 05 Jun 1997 18:59:15 GMT 3123 RTP-Info: url="rtsp://example.com/bar.file" 3124 ssrc=0D12F123:seq=232433;rtptime=972948234 3125 Range: npt=0-56.8 3127 S->C: $005{2 byte length}{"length" bytes data, w/RTP header} 3128 S->C: $005{2 byte length}{"length" bytes data, w/RTP header} 3129 S->C: $006{2 byte length}{"length" bytes RTCP packet} 3131 15. Status Code Definitions 3133 Where applicable, HTTP status [H10] codes are reused. Status codes 3134 that have the same meaning are not repeated here. See Table 4 for a 3135 listing of which status codes may be returned by which requests. All 3136 error messages, 4xx and 5xx MAY return a body containing further 3137 information about the error. 3139 15.1. Success 1xx 3141 15.1.1. 100 Continue 3143 See, [H10.1.1]. 3145 15.2. Success 2xx 3147 15.3. Redirection 3xx 3149 The notation "3rr" indicates response codes from 300 to 399 inclusive 3150 which are meant for redirection. The response code 304 is excluded 3151 from this set, as it is not used for redirection. 3153 See [H10.3] for definition of status code 300 to 305. However 3154 comments are given for some to how they apply to RTSP. 3156 Within RTSP, redirection may be used for load balancing or 3157 redirecting stream requests to a server topologically closer to the 3158 client. Mechanisms to determine topological proximity are beyond the 3159 scope of this specification. 3161 A 3rr code MAY be used to respond to any request. It is RECOMMENDED 3162 that they are used if necessary before a session is established, i.e. 3163 in response to DESCRIBE or SETUP. However in cases where a server is 3164 not able to send a REDIRECT request to the client, the server MAY 3165 need to resort to using 3rr responses to inform a client with a 3166 established session about the need for redirecting the session. If 3167 an 3rr response is received for an request in relation to a 3168 established session, the client SHOULD send a TEARDOWN request for 3169 the session, and MAY reestablish the session using the resource 3170 indicated by the Location. 3172 If the the Location header is used in a response it SHALL contain an 3173 absolute URI pointing out the media resource the client is redirected 3174 to, the URI SHALL NOT only contain the host name. 3176 15.3.1. 300 Multiple Choices 3178 See [H10.3.1]. 3180 15.3.2. 301 Moved Permanently 3182 The request resource are moved permanently and resides now at the URI 3183 given by the location header. The user client SHOULD redirect 3184 automatically to the given URI. This response MUST NOT contain a 3185 message-body. The Location header MUST be included in the response. 3187 15.3.3. 302 Found 3189 The requested resource resides temporarily at the URI given by the 3190 Location header. The Location header MUST be included in the 3191 response. This response is intended to be used for many types of 3192 temporary redirects; e.g., load balancing. It is RECOMMENDED that 3193 the server set the reason phrase to something more meaningful than 3194 "Found" in these cases. The user client SHOULD redirect 3195 automatically to the given URI. This response MUST NOT contain a 3196 message-body. 3198 This example shows a client being redirected to a different server: 3200 C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0 3201 CSeq: 2 3202 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 3203 Accept-Ranges: NPT, SMPTE, UTC 3204 User-Agent: PhonyClient/1.2 3206 S->C: RTSP/2.0 302 Try Other Server 3207 CSeq: 2 3208 Location: rtsp://s2.example.com:8001/fizzle/foo 3210 15.3.4. 303 See Other 3212 This status code SHALL NOT be used in RTSP. However as it was 3213 allowed to use in RTSP 1.0 (RFC 2326). 3215 15.3.5. 304 Not Modified 3217 If the client has performed a conditional DESCRIBE or SETUP (see 3218 Section 16.25) and the requested resource has not been modified, the 3219 server SHOULD send a 304 response. This response MUST NOT contain a 3220 message-body. 3222 The response MUST include the following header fields: 3224 o Date 3226 o ETag and/or Content-Location, if the header(s) would have been 3227 sent in a 200 response to the same request. 3229 o Expires, Cache-Control, and/or Vary, if the field-value might 3230 differ from that sent in any previous response for the same 3231 variant. 3233 This response is independent for the DESCRIBE and SETUP requests. 3234 That is, a 304 response to DESCRIBE does NOT imply that the resource 3235 content is unchanged (only the session description) and a 304 3236 response to SETUP does NOT imply that the resource description is 3237 unchanged. The ETag and If-Match headers may be used to link the 3238 DESCRIBE and SETUP in this manner. 3240 15.3.6. 305 Use Proxy 3242 See [H10.3.6]. 3244 15.4. Client Error 4xx 3246 15.4.1. 400 Bad Request 3248 The request could not be understood by the server due to malformed 3249 syntax. The client SHOULD NOT repeat the request without 3250 modifications [H10.4.1]. If the request does not have a CSeq header, 3251 the server MUST NOT include a CSeq in the response. 3253 15.4.2. 405 Method Not Allowed 3255 The method specified in the request is not allowed for the resource 3256 identified by the Request-URI. The response MUST include an Allow 3257 header containing a list of valid methods for the requested resource. 3258 This status code is also to be used if a request attempts to use a 3259 method not indicated during SETUP. 3261 15.4.3. 451 Parameter Not Understood 3263 The recipient of the request does not support one or more parameters 3264 contained in the request. When returning this error message the 3265 sender SHOULD return a entity body containing the offending 3266 parameter(s). 3268 15.4.4. 452 reserved 3270 This error code was removed from RFC 2326 [RFC2326] and is obsolete. 3272 15.4.5. 453 Not Enough Bandwidth 3274 The request was refused because there was insufficient bandwidth. 3275 This may, for example, be the result of a resource reservation 3276 failure. 3278 15.4.6. 454 Session Not Found 3280 The RTSP session identifier in the Session header is missing, 3281 invalid, or has timed out. 3283 15.4.7. 455 Method Not Valid in This State 3285 The client or server cannot process this request in its current 3286 state. The response SHALL contain an Allow header to make error 3287 recovery possible. 3289 15.4.8. 456 Header Field Not Valid for Resource 3291 The server could not act on a required request header. For example, 3292 if PLAY contains the Range header field but the stream does not allow 3293 seeking. This error message may also be used for specifying when the 3294 time format in Range is impossible for the resource. In that case 3295 the Accept-Ranges header SHALL be returned to inform the client of 3296 which format(s) that are allowed. 3298 15.4.9. 457 Invalid Range 3300 The Range value given is out of bounds, e.g., beyond the end of the 3301 presentation. 3303 15.4.10. 458 Parameter Is Read-Only 3305 The parameter to be set by SET_PARAMETER can be read but not 3306 modified. When returning this error message the sender SHOULD return 3307 a entity body containing the offending parameter(s). 3309 15.4.11. 459 Aggregate Operation Not Allowed 3311 The requested method may not be applied on the URI in question since 3312 it is an aggregate (presentation) URI. The method may be applied on 3313 a media URI. 3315 15.4.12. 460 Only Aggregate Operation Allowed 3317 The requested method may not be applied on the URI in question since 3318 it is not an aggregate control (presentation) URI. The method may be 3319 applied on the aggregate control URI. 3321 15.4.13. 461 Unsupported Transport 3323 The Transport field did not contain a supported transport 3324 specification. 3326 15.4.14. 462 Destination Unreachable 3328 The data transmission channel could not be established because the 3329 client address could not be reached. This error will most likely be 3330 the result of a client attempt to place an invalid dest_addr 3331 parameter in the Transport field. 3333 15.4.15. 463 Destination Prohibited 3335 The data transmission channel was not established because the server 3336 prohibited access to the client address. This error is most likely 3337 the result of a client attempt to redirect media traffic to another 3338 destination with a dest_addr parameter in the Transport header. 3340 15.4.16. 464 Data Transport Not Ready Yet 3342 The data transmission channel to the media destination is not yet 3343 ready for carrying data. However the responding entity still expects 3344 that the data transmission channel will be established at this point 3345 in time. Note however that this may result in a permanent failure 3346 like 462 "Destination Unreachable". 3348 An example when this error may occur is in the case a client sends a 3349 PLAY request to a server prior to ensuring that the TCP connections 3350 negotiated for carrying media data was successful established (In 3351 violation of this specification). The server would use this error 3352 code to indicate that the requested action could not be performed due 3353 to the failure of completing the connection establishment. 3355 15.4.17. 470 Connection Authorization Required 3357 The secured connection attempt need user or client authorization 3358 before proceeding. The next hops certificate is included in this 3359 response in the Accept-Credentials header. 3361 15.4.18. 471 Connection Credentials not accepted 3363 When performing a secure connection over multiple connections, a 3364 intermediary has refused to connect to the next hop and carry out the 3365 request due to unacceptable credentials for the used policy. 3367 15.4.19. 472 Failure to establish secure connection 3369 A proxy fails to establish a secure connection to the next hop RTSP 3370 agent. This is primarily caused by a fatal failure at the TLS 3371 handshake, for example due to server not accepting any cipher suits. 3373 15.5. Server Error 5xx 3375 15.5.1. 551 Option not supported 3377 A feature-tag given in the Require or the Proxy-Require fields was 3378 not supported. The Unsupported header SHALL be returned stating the 3379 feature for which there is no support. 3381 16. Header Field Definitions 3383 +---------------+----------------+--------+---------+------+ 3384 | method | direction | object | acronym | Body | 3385 +---------------+----------------+--------+---------+------+ 3386 | DESCRIBE | C -> S | P,S | DES | r | 3387 | | | | | | 3388 | GET_PARAMETER | C -> S, S -> C | P,S | GPR | R,r | 3389 | | | | | | 3390 | OPTIONS | C -> S | P,S | OPT | | 3391 | | | | | | 3392 | | S -> C | | | | 3393 | | | | | | 3394 | PAUSE | C -> S | P,S | PSE | | 3395 | | | | | | 3396 | PLAY | C -> S | P,S | PLY | | 3397 | | | | | | 3398 | REDIRECT | S -> C | P,S | RDR | | 3399 | | | | | | 3400 | SETUP | C -> S | S | STP | | 3401 | | | | | | 3402 | SETPARAMETER | C -> S, S -> C | P,S | SPR | R,r | 3403 | | | | | | 3404 | TEARDOWN | C -> S | P,S | TRD | | 3405 +---------------+----------------+--------+---------+------+ 3407 Table 8: Overview of RTSP methods, their direction, and what objects 3408 (P: presentation, S: stream) they operate on. Body notes if a method 3409 is allowed to carry body and in which direction, R = Request, 3410 r=response. Note: It is allowed for all error messages 4xx and 5xx to 3411 have a body 3413 The general syntax for header fields is covered in Section 5.2. This 3414 section lists the full set of header fields along with notes on 3415 meaning, and usage. The syntax definition for header fields are 3416 present in Section 21.2.3. Throughout this section, we use [HX.Y] to 3417 refer to Section X.Y of the current HTTP/1.1 specification RFC 2616 3418 [RFC2616]. Examples of each header field are given. 3420 Information about header fields in relation to methods and proxy 3421 processing is summarized in Table 9, Table 10, Table 11, and 3422 Table 12. 3424 The "where" column describes the request and response types in which 3425 the header field can be used. Values in this column are: 3427 R: header field may only appear in requests; 3429 r: header field may only appear in responses; 3431 2xx, 4xx, etc.: A numerical value or range indicates response codes 3432 with which the header field can be used; 3434 c: header field is copied from the request to the response. 3436 An empty entry in the "where" column indicates that the header field 3437 may be present in both requests and responses. 3439 The "proxy" column describes the operations a proxy may perform on a 3440 header field. An empty proxy column indicates that the proxy SHALL 3441 NOT do any changes to that header, all allowed operations are 3442 explicitly stated: 3444 a: A proxy can add or concatenate the header field if not present. 3446 m: A proxy can modify an existing header field value. 3448 d: A proxy can delete a header field value. 3450 r: A proxy needs to be able to read the header field, and thus 3451 this header field cannot be encrypted. 3453 The rest of the columns relate to the presence of a header field in a 3454 method. The method names when abbreviated, are according to table 3455 XXX {tab:methods2: 3457 c: Conditional; requirements on the header field depend on the 3458 context of the message. 3460 m: The header field is mandatory. 3462 m*: The header field SHOULD be sent, but clients/servers need to be 3463 prepared to receive messages without that header field. 3465 o: The header field is optional. 3467 *: The header field is SHALL be present if the message body is not 3468 empty. See Section 16.16, Section 16.18 and Section 5.3 for 3469 details. 3471 -: The header field is not applicable. 3473 "Optional" means that a Client/Server MAY include the header field in 3474 a request or response. The Client/Server behavior when receiving 3475 such headers varies, for some it may ignore the header field, in 3476 other case it is request to process the header. This is regulated by 3477 the method and header descriptions. Example of such headers that 3478 require processing are the Require and Proxy-Require header fields 3479 discussed in Section 16.38 and Section 16.32. A "mandatory" header 3480 field MUST be present in a request, and MUST be understood by the 3481 Client/Server receiving the request. A mandatory response header 3482 field MUST be present in the response, and the header field MUST be 3483 understood by the Client/Server processing the response. "Not 3484 applicable" means that the header field MUST NOT be present in a 3485 request. If one is placed in a request by mistake, it MUST be 3486 ignored by the Client/Server receiving the request. Similarly, a 3487 header field labeled "not applicable" for a response means that the 3488 Client/Server MUST NOT place the header field in the response, and 3489 the Client/Server MUST ignore the header field in the response. 3491 An RTSP agent SHALL ignore extension headers that are not understood. 3493 The From and Location header fields contain an URI. If the URI 3494 contains a comma, or semicolon, the URI MUST be enclosed in double 3495 quotas ("). Any URI parameters are contained within these quotas. 3496 If the URI is not enclosed in double quotas, any semicolon- delimited 3497 parameters are header-parameters, not URI parameters. 3499 +----------------+------+-----+-----+-----+------+-----+------+-----+ 3500 | Header | Wher | Pro | DES | OPT | SETU | PLA | PAUS | TRD | 3501 | | e | xy | | | P | Y | E | | 3502 +----------------+------+-----+-----+-----+------+-----+------+-----+ 3503 | Accept | R | | o | - | - | - | - | - | 3504 | | | | | | | | | | 3505 | Accept-Credent | R | r | o | o | o | o | o | o | 3506 | ials | | | | | | | | | 3507 | | | | | | | | | | 3508 | Accept-Encodin | R | r | o | - | - | - | - | - | 3509 | g | | | | | | | | | 3510 | | | | | | | | | | 3511 | Accept-Languag | R | r | o | - | - | - | - | - | 3512 | e | | | | | | | | | 3513 | | | | | | | | | | 3514 | Accept-Ranges | R | r | - | - | m | - | - | - | 3515 | | | | | | | | | | 3516 | Accept-Ranges | r | r | - | - | o | - | - | - | 3517 | | | | | | | | | | 3518 | Accept-Ranges | 456 | r | - | - | - | o | - | - | 3519 | | | | | | | | | | 3520 | Allow | r | am | c | c | c | - | - | - | 3521 | | | | | | | | | | 3522 | Allow | 405 | am | m | m | m | m | m | m | 3523 | Authorization | R | | o | o | o | o | o | o | 3524 | | | | | | | | | | 3525 | Bandwidth | R | | o | o | o | o | - | - | 3526 | | | | | | | | | | 3527 | Blocksize | R | | o | - | o | o | - | - | 3528 | | | | | | | | | | 3529 | Cache-Control | | r | o | - | o | - | - | - | 3530 | | | | | | | | | | 3531 | Connection | | | o | o | o | o | o | o | 3532 | | | | | | | | | | 3533 | Connection-Cre | 470, | ar | o | o | o | o | o | o | 3534 | dentials | 407 | | | | | | | | 3535 | | | | | | | | | | 3536 | Content-Base | r | | o | - | - | - | - | - | 3537 | | | | | | | | | | 3538 | Content-Base | 4xx, | | o | o | o | o | o | o | 3539 | | 5xx | | | | | | | | 3540 | | | | | | | | | | 3541 | Content-Encodi | R | r | - | - | - | - | - | - | 3542 | ng | | | | | | | | | 3543 | | | | | | | | | | 3544 | Content-Encodi | r | r | o | - | - | - | - | - | 3545 | ng | | | | | | | | | 3546 | | | | | | | | | | 3547 | Content-Encodi | 4xx, | r | o | o | o | o | o | o | 3548 | ng | 5xx | | | | | | | | 3549 | | | | | | | | | | 3550 | Content-Langua | R | r | - | - | - | - | - | - | 3551 | ge | | | | | | | | | 3552 | | | | | | | | | | 3553 | Content-Langua | r | r | o | - | - | - | - | - | 3554 | ge | | | | | | | | | 3555 | | | | | | | | | | 3556 | Content-Langua | 4xx, | r | o | o | o | o | o | o | 3557 | ge | 5xx | | | | | | | | 3558 | | | | | | | | | | 3559 | Content-Length | r | r | * | - | - | - | - | - | 3560 | | | | | | | | | | 3561 | Content-Length | 4xx, | r | * | * | * | * | * | * | 3562 | | 5xx | | | | | | | | 3563 | | | | | | | | | | 3564 | Content-Locati | r | | o | - | - | - | - | - | 3565 | on | | | | | | | | | 3566 | | | | | | | | | | 3567 | Content-Locati | 4xx, | | o | o | o | o | o | o | 3568 | on | 5xx | | | | | | | | 3569 | | | | | | | | | | 3570 | Content-Type | r | | * | - | - | - | - | - | 3571 | Content-Type | 4xx, | | * | * | * | * | * | * | 3572 | | 5xx | | | | | | | | 3573 | | | | | | | | | | 3574 | CSeq | Rc | rm | m | m | m | m | m | m | 3575 | | | | | | | | | | 3576 | Date | | am | o | o | o | o | o | o | 3577 | | | | | | | | | | 3578 | ETag | r | r | o | - | o | - | - | - | 3579 | | | | | | | | | | 3580 | Expires | r | r | o | - | - | - | - | - | 3581 | | | | | | | | | | 3582 | From | R | r | o | o | o | o | o | o | 3583 | | | | | | | | | | 3584 | If-Match | R | r | - | - | o | - | - | - | 3585 | | | | | | | | | | 3586 | If-Modified-Si | R | r | o | - | o | - | - | - | 3587 | nce | | | | | | | | | 3588 | | | | | | | | | | 3589 | If-None-Match | R | r | o | - | - | - | - | - | 3590 | | | | | | | | | | 3591 | Last-Modified | r | r | o | - | - | - | - | - | 3592 | | | | | | | | | | 3593 | Location | 3rr | | o | o | o | o | o | o | 3594 +----------------+------+-----+-----+-----+------+-----+------+-----+ 3596 Table 9: Overview of RTSP header fields (A-L) related to methods 3597 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 3599 +------------+-------+------+----+-----+-------+------+-------+-----+ 3600 | Header | Where | Prox | DE | OPT | SETUP | PLAY | PAUSE | TRD | 3601 | | | y | S | | | | | | 3602 +------------+-------+------+----+-----+-------+------+-------+-----+ 3603 | Pipelined- | | amdr | - | o | o | o | o | o | 3604 | Requests | | | | | | | | | 3605 | | | | | | | | | | 3606 | Proxy- | 407 | amr | m | m | m | m | m | m | 3607 | Authentica | | | | | | | | | 3608 | te | | | | | | | | | 3609 | | | | | | | | | | 3610 | Proxy- | R | rd | o | o | o | o | o | o | 3611 | Authorizat | | | | | | | | | 3612 | ion | | | | | | | | | 3613 | | | | | | | | | | 3614 | Proxy- | R | ar | o | o | o | o | o | o | 3615 | Require | | | | | | | | | 3616 | | | | | | | | | | 3617 | Proxy- | r | r | c | c | c | c | c | c | 3618 | Require | | | | | | | | | 3619 | Proxy- | R | amr | c | c | c | c | c | c | 3620 | Supported | | | | | | | | | 3621 | | | | | | | | | | 3622 | Proxy- | r | | c | c | c | c | c | c | 3623 | Supported | | | | | | | | | 3624 | | | | | | | | | | 3625 | Public | r | admr | - | m | - | - | - | - | 3626 | | | | | | | | | | 3627 | Public | 501 | admr | m | m | m | m | m | m | 3628 | | | | | | | | | | 3629 | Range | R | | - | - | - | o | - | - | 3630 | | | | | | | | | | 3631 | Range | r | | - | - | c | m | m | - | 3632 | | | | | | | | | | 3633 | Referer | R | | o | o | o | o | o | o | 3634 | | | | | | | | | | 3635 | Require | R | | o | o | o | o | o | o | 3636 | | | | | | | | | | 3637 | Retry-Afte | 3rr,5 | | o | o | o | - | - | - | 3638 | r | 03 | | | | | | | | 3639 | | | | | | | | | | 3640 | RTP-Info | r | | - | - | c | c | - | - | 3641 | | | | | | | | | | 3642 | Scale | | | - | - | - | o | - | - | 3643 | | | | | | | | | | 3644 | Session | R | r | - | o | o | m | m | m | 3645 | | | | | | | | | | 3646 | Session | r | r | - | c | m | m | m | o | 3647 | | | | | | | | | | 3648 | Server | R | r | - | o | - | - | - | - | 3649 | | | | | | | | | | 3650 | Server | r | r | o | o | o | o | o | o | 3651 | | | | | | | | | | 3652 | Speed | | | - | - | - | o | - | - | 3653 | | | | | | | | | | 3654 | Supported | R | amr | o | o | o | o | o | o | 3655 | | | | | | | | | | 3656 | Supported | r | amr | c | c | c | c | c | c | 3657 | | | | | | | | | | 3658 | Timestamp | R | admr | o | o | o | o | o | o | 3659 | | | | | | | | | | 3660 | Timestamp | c | admr | m | m | m | m | m | m | 3661 | | | | | | | | | | 3662 | Transport | | amr | - | - | m | - | - | - | 3663 | | | | | | | | | | 3664 | Unsupporte | r | | c | c | c | c | c | c | 3665 | d | | | | | | | | | 3666 | | | | | | | | | | 3667 | User-Agent | R | | m* | m* | m* | m* | m* | m* | 3668 | | | | | | | | | | 3669 | Vary | r | | c | c | c | c | c | c | 3670 | | | | | | | | | | 3671 | Via | R | amr | o | o | o | o | o | o | 3672 | | | | | | | | | | 3673 | Via | c | dr | m | m | m | m | m | m | 3674 | | | | | | | | | | 3675 | WWW- | 401 | | m | m | m | m | m | m | 3676 | Authentica | | | | | | | | | 3677 | te | | | | | | | | | 3678 +------------+-------+------+----+-----+-------+------+-------+-----+ 3680 Table 10: Overview of RTSP header fields (P-W) related to methods 3681 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 3683 +------------------------+---------+-------+-----+-----+-----+ 3684 | Header | Where | Proxy | GPR | SPR | RDR | 3685 +------------------------+---------+-------+-----+-----+-----+ 3686 | Accept-Credentials | R | r | o | o | o | 3687 | | | | | | | 3688 | Allow | 405 | amr | m | m | m | 3689 | | | | | | | 3690 | Authorization | R | | o | o | o | 3691 | | | | | | | 3692 | Bandwidth | R | | - | o | - | 3693 | | | | | | | 3694 | Blocksize | R | | - | o | - | 3695 | | | | | | | 3696 | Connection | | | o | o | o | 3697 | | | | | | | 3698 | Connection-Credentials | 470,407 | ar | o | o | o | 3699 | | | | | | | 3700 | Content-Base | R | | o | o | - | 3701 | | | | | | | 3702 | Content-Base | r | | o | o | - | 3703 | | | | | | | 3704 | Content-Base | 4xx,5xx | | o | o | o | 3705 | | | | | | | 3706 | Content-Encoding | R | r | o | o | - | 3707 | | | | | | | 3708 | Content-Encoding | r | r | o | o | - | 3709 | | | | | | | 3710 | Content-Encoding | 4xx,5xx | r | o | o | o | 3711 | | | | | | | 3712 | Content-Language | R | r | o | o | - | 3713 | | | | | | | 3714 | Content-Language | r | r | o | o | - | 3715 | Content-Language | 4xx,5xx | r | o | o | o | 3716 | | | | | | | 3717 | Content-Length | R | r | * | * | - | 3718 | | | | | | | 3719 | Content-Length | r | r | * | * | - | 3720 | | | | | | | 3721 | Content-Length | 4xx,5xx | r | * | * | * | 3722 | | | | | | | 3723 | Content-Location | R | | o | o | - | 3724 | | | | | | | 3725 | Content-Location | r | | o | o | - | 3726 | | | | | | | 3727 | Content-Location | 4xx,5xx | | o | o | o | 3728 | | | | | | | 3729 | Content-Type | R | | * | * | - | 3730 | | | | | | | 3731 | Content-Type | r | | * | * | - | 3732 | | | | | | | 3733 | Content-Type | 4xx | | * | * | * | 3734 | | | | | | | 3735 | CSeq | R,c | mr | m | m | m | 3736 | | | | | | | 3737 | Date | R | a | o | o | m | 3738 | | | | | | | 3739 | Date | r | am | o | o | o | 3740 | | | | | | | 3741 | From | R | r | o | o | o | 3742 | | | | | | | 3743 | Last-Modified | R | r | - | - | - | 3744 | | | | | | | 3745 | Last-Modified | r | r | o | - | - | 3746 | | | | | | | 3747 | Location | 3rr | | o | o | o | 3748 | | | | | | | 3749 | Location | R | | - | - | m | 3750 | | | | | | | 3751 | Pipelined-Requests | | amdr | o | o | o | 3752 | | | | | | | 3753 | Proxy-Authenticate | 407 | amr | m | m | m | 3754 | | | | | | | 3755 | Proxy-Authorization | R | rd | o | o | o | 3756 | | | | | | | 3757 | Proxy-Require | R | ar | o | o | o | 3758 | | | | | | | 3759 | Proxy-Require | r | r | c | c | c | 3760 | | | | | | | 3761 | Proxy-Supported | R | amr | c | c | c | 3762 | | | | | | | 3763 | Proxy-Supported | r | | c | c | c | 3764 | | | | | | | 3765 | Public | 501 | admr | m | m | m | 3766 +------------------------+---------+-------+-----+-----+-----+ 3768 Table 11: Overview of RTSP header fields (A-P) related to methods 3769 GETPARAMETER, SETPARAMETER, and REDIRECT. 3771 +------------------+---------+-------+-----+-----+-----+ 3772 | Header | Where | Proxy | GPR | SPR | RDR | 3773 +------------------+---------+-------+-----+-----+-----+ 3774 | Range | R | | - | - | o | 3775 | | | | | | | 3776 | Referer | R | | o | o | o | 3777 | | | | | | | 3778 | Require | R | r | o | o | o | 3779 | | | | | | | 3780 | Retry-After | 3rr,503 | | o | o | - | 3781 | | | | | | | 3782 | Scale | | | - | - | - | 3783 | | | | | | | 3784 | Session | R | r | o | o | o | 3785 | | | | | | | 3786 | Session | r | r | c | c | o | 3787 | | | | | | | 3788 | Server | R | r | o | o | o | 3789 | | | | | | | 3790 | Server | r | r | o | o | - | 3791 | | | | | | | 3792 | Supported | R | adrm | o | o | o | 3793 | | | | | | | 3794 | Supported | r | adrm | c | c | c | 3795 | | | | | | | 3796 | Timestamp | R | adrm | o | o | o | 3797 | | | | | | | 3798 | Timestamp | c | adrm | m | m | m | 3799 | | | | | | | 3800 | Unsupported | r | arm | c | c | c | 3801 | | | | | | | 3802 | User-Agent | R | r | m* | m* | - | 3803 | | | | | | | 3804 | User-Agent | r | r | - | - | m* | 3805 | | | | | | | 3806 | Vary | r | | c | c | - | 3807 | | | | | | | 3808 | Via | R | amr | o | o | o | 3809 | | | | | | | 3810 | Via | c | dr | m | m | m | 3811 | WWW-Authenticate | 401 | | m | m | m | 3812 +------------------+---------+-------+-----+-----+-----+ 3814 Table 12: Overview of RTSP header fields (R-W) related to methods 3815 GETPARAMETER, SETPARAMETER, and REDIRECT. 3817 16.1. Accept 3819 The Accept request-header field can be used to specify certain 3820 presentation description content types which are acceptable for the 3821 response. 3823 See [H14.1] for syntax. 3825 Example of use: 3827 Accept: application/example q=1.0, application/sdp 3829 16.2. Accept-Credentials 3831 The Accept-Credentials header is a request header used to indicate to 3832 any trusted intermediary how to handle further secured connections to 3833 proxies or servers. See Section 20 for the usage of this header. It 3834 SHALL NOT be included in server to client requests. 3836 In a request the header SHALL contain the method (User, Proxy, or 3837 Any) for approving credentials selected by the requestor. The method 3838 SHALL NOT be changed by any proxy, unless it is "proxy" when a proxy 3839 MAY change it to "user" to take the role of user approving each 3840 further hop. If the method is "User" the header contains zero or 3841 more of credentials that the client accept. The header may contain 3842 zero credentials in the first RTSP request to a RTSP server when 3843 using the "User" method. This as the client has not yet received any 3844 credentials to accept. Each credential SHALL consist of one URI 3845 identifying the proxy or server, the hash algorithm identifier, and 3846 the hash over that entity's DER encoded certificate [RFC3280] in 3847 Base64 [RFC4648]. All RTSP clients and proxies SHALL implement the 3848 SHA-256[FIPS-pub-180-2] algorithm for computation of the hash of the 3849 DER encoded certificate. The SHA-256 algorithm is identified by the 3850 token "sha-256". 3852 The intention with allowing for other hash algorithms is to enable 3853 the future retirement of algorithms that are not implemented 3854 somewhere else than here. Thus the definition of future algorithms 3855 for this purpose is intended to be extremely limited. A feature tag 3856 can be used to ensure that support for the replacement algorithm 3857 exist. 3859 Example: 3861 Accept-Credentials:User 3862 "rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=, 3863 "rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M= 3865 16.3. Accept-Encoding 3867 See [H14.3]. 3869 16.4. Accept-Language 3871 See [H14.4]. Note that the language specified applies to the 3872 presentation description and any reason phrases, not the media 3873 content. 3875 16.5. Accept-Ranges 3877 The Accept-Ranges request and response-header field allows indication 3878 of the format supported in the Range header. The client SHALL 3879 include the header in SETUP requests to indicate which formats it 3880 support to receive in PLAY and PAUSE responses, and REDIRECT 3881 requests. The server SHALL include the header in SETUP and 456 error 3882 responses to indicate the formats supported for the resource 3883 indicated by the request URI. 3885 Accept-Ranges: NPT, SMPTE 3887 This header has the same syntax as [H14.5] and the syntax is defined 3888 in Section 21.2.3. However, new range-units are defined. 3890 16.6. Allow 3892 The Allow entity-header field lists the methods supported by the 3893 resource identified by the Request-URI. The purpose of this field is 3894 to strictly inform the recipient of valid methods associated with the 3895 resource. An Allow header field MUST be present in a 405 (Method Not 3896 Allowed) response. See [H14.7] for syntax definition. The Allow 3897 header MUST also be present in all OPTIONS responses where the 3898 content of the header will not include exactly the same methods as 3899 listed in the Public header. 3901 The Allow SHALL also be included in SETUP and DESCRIBE responses, if 3902 the methods allowed for the resource is different than the minimal 3903 implementation set. 3905 Example of use: 3907 Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE 3909 16.7. Authorization 3911 See [H14.8]. 3913 16.8. Bandwidth 3915 The Bandwidth request-header field describes the estimated bandwidth 3916 available to the client, expressed as a positive integer and measured 3917 in bits per second. The bandwidth available to the client may change 3918 during an RTSP session, e.g., due to mobility, congestion, etc. 3920 Example: 3922 Bandwidth: 62360 3924 16.9. Blocksize 3926 The Blocksize request-header field is sent from the client to the 3927 media server asking the server for a particular media packet size. 3928 This packet size does not include lower-layer headers such as IP, 3929 UDP, or RTP. The server is free to use a blocksize which is lower 3930 than the one requested. The server MAY truncate this packet size to 3931 the closest multiple of the minimum, media-specific block size, or 3932 override it with the media-specific size if necessary. The block 3933 size MUST be a positive decimal number, measured in octets. The 3934 server only returns an error (4xx) if the value is syntactically 3935 invalid. 3937 16.10. Cache-Control 3939 The Cache-Control general-header field is used to specify directives 3940 that MUST be obeyed by all caching mechanisms along the request/ 3941 response chain. 3943 Cache directives MUST be passed through by a proxy or gateway 3944 application, regardless of their significance to that application, 3945 since the directives may be applicable to all recipients along the 3946 request/response chain. It is not possible to specify a cache- 3947 directive for a specific cache. 3949 Cache-Control should only be specified in a SETUP request and its 3950 response. Note: Cache-Control does em not govern the caching of 3951 responses as for HTTP, instead it applies to the media stream 3952 identified by the SETUP request. The RTSP requests are generally not 3953 cacheable, for further information see Section 18. Below is the 3954 description of the cache directives that can be included in the 3955 Cache-Control header. 3957 no-cache: Indicates that the media stream MUST NOT be cached 3958 anywhere. This allows an origin server to prevent caching even 3959 by caches that have been configured to return stale responses 3960 to client requests. Note, there are no security function 3961 enforcing that the content can't be cached. 3963 public: Indicates that the media stream is cacheable by any cache. 3965 private: Indicates that the media stream is intended for a single 3966 user and MUST NOT be cached by a shared cache. A private (non- 3967 shared) cache may cache the media streams. 3969 no-transform: An intermediate cache (proxy) may find it useful to 3970 convert the media type of a certain stream. A proxy might, for 3971 example, convert between video formats to save cache space or 3972 to reduce the amount of traffic on a slow link. Serious 3973 operational problems may occur, however, when these 3974 transformations have been applied to streams intended for 3975 certain kinds of applications. For example, applications for 3976 medical imaging, scientific data analysis and those using end- 3977 to-end authentication all depend on receiving a stream that is 3978 bit-for-bit identical to the original media stream. Therefore, 3979 if a response includes the no-transform directive, an 3980 intermediate cache or proxy MUST NOT change the encoding of the 3981 stream. Unlike HTTP, RTSP does not provide for partial 3982 transformation at this point, e.g., allowing translation into a 3983 different language. 3985 only-if-cached: In some cases, such as times of extremely poor 3986 network connectivity, a client may want a cache to return only 3987 those media streams that it currently has stored, and not to 3988 receive these from the origin server. To do this, the client 3989 may include the only-if-cached directive in a request. If it 3990 receives this directive, a cache SHOULD either respond using a 3991 cached media stream that is consistent with the other 3992 constraints of the request, or respond with a 504 (Gateway 3993 Timeout) status. However, if a group of caches is being 3994 operated as a unified system with good internal connectivity, 3995 such a request MAY be forwarded within that group of caches. 3997 max-stale: Indicates that the client is willing to accept a media 3998 stream that has exceeded its expiration time. If max-stale is 3999 assigned a value, then the client is willing to accept a 4000 response that has exceeded its expiration time by no more than 4001 the specified number of seconds. If no value is assigned to 4002 max-stale, then the client is willing to accept a stale 4003 response of any age. 4005 min-fresh: Indicates that the client is willing to accept a media 4006 stream whose freshness lifetime is no less than its current age 4007 plus the specified time in seconds. That is, the client wants 4008 a response that will still be fresh for at least the specified 4009 number of seconds. 4011 must-revalidate: When the must-revalidate directive is present in a 4012 SETUP response received by a cache, that cache MUST NOT use the 4013 entry after it becomes stale to respond to a subsequent request 4014 without first revalidating it with the origin server. That is, 4015 the cache is required to do an end-to-end revalidation every 4016 time, if, based solely on the origin server's Expires, the 4017 cached response is stale.) 4019 proxy-revalidate: The proxy-revalidate directive has the same 4020 meaning as the must-revalidate directive, except that it does 4021 not apply to non-shared user agent caches. It can be used on a 4022 response to an authenticated request to permit the user's cache 4023 to store and later return the response without needing to 4024 revalidate it (since it has already been authenticated once by 4025 that user), while still requiring proxies that service many 4026 users to revalidate each time (in order to make sure that each 4027 user has been authenticated). Note that such authenticated 4028 responses also need the public cache control directive in order 4029 to allow them to be cached at all. 4031 max-age: When an intermediate cache is forced, by means of a max- 4032 age=0 directive, to revalidate its own cache entry, and the 4033 client has supplied its own validator in the request, the 4034 supplied validator might differ from the validator currently 4035 stored with the cache entry. In this case, the cache MAY use 4036 either validator in making its own request without affecting 4037 semantic transparency. 4039 However, the choice of validator might affect performance. The best 4040 approach is for the intermediate cache to use its own validator when 4041 making its request. If the server replies with 304 (Not Modified), 4042 then the cache can return its now validated copy to the client with a 4043 200 (OK) response. If the server replies with a new entity and cache 4044 validator, however, the intermediate cache can compare the returned 4045 validator with the one provided in the client's request, using the 4046 strong comparison function. If the client's validator is equal to 4047 the origin server's, then the intermediate cache simply returns 304 4048 (Not Modified). Otherwise, it returns the new entity with a 200 (OK) 4049 response. 4051 16.11. Connection 4053 See [H14.10]. The use of the connection option "close" in RTSP 4054 messages SHOULD be limited to error messages when the server is 4055 unable to recover and therefore see it necessary to close the 4056 connection. The reason is that the client has the choice of 4057 continuing using a connection indefinitely, as long as it sends valid 4058 messages. 4060 16.12. Connection-Credentials 4062 The Connection-Credentials response header is used to carry the chain 4063 of credentials of any next hop that need to be approved by the 4064 requestor. It SHALL only be used in server to client responses. 4066 The Connection-Credentials header in an RTSP response SHALL, if 4067 included, contain the credential information (in form of a list of 4068 certificates providing the chain of certification) of the next hop 4069 that an intermediary needs to securely connect to. The header MUST 4070 include the URI of the next hop (proxy or server) and a base64 4071 [RFC4648] encoded binary structure containg a sequence of DER encoded 4072 X.509v3 certificates[RFC3280] . 4074 The binary structure starts with the number of certificates 4075 (NR_CERTS) included as a 16 bit unsigned integer. This is followed 4076 by NR_CERTS number of 16 bit unsigned integers providing the size in 4077 octets of each DER encoded certificate. This is followed by NR_CERTS 4078 number of DER encoded X.509v3 certificates in a sequence (chain). 4079 The proxy or server's certificate must come first in the structure. 4080 Each following certificate must directly certify the one preceding 4081 it. Because certificate validation requires that root keys be 4082 distributed independently, the self-signed certificate which 4083 specifies the root certificate authority may optionally be omitted 4084 from the chain, under the assumption that the remote end must already 4085 possess it in order to validate it in any case. 4087 Example: 4089 Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC... 4091 Where MIIDNTCC... is a BASE64 encoding of the following structure: 4093 0 1 2 3 4094 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 4095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4096 | Number of certifcates | Size of certificate #1 | 4097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4098 | Size of certificate #2 | Size of certificate #3 | 4099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4100 : DER Encoding of Certificate #1 : 4101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4102 : DER Encoding of Certificate #2 : 4103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4104 : DER Encoding of Certificate #3 : 4105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4107 16.13. Content-Base 4109 The Content-Base entity-header field may be used to specify the base 4110 URI for resolving relative URIs within the entity. 4112 Content-Base: rtsp://media.example.com/movie/twister 4114 If no Content-Base field is present, the base URI of an entity is 4115 defined either by its Content-Location (if that Content-Location URI 4116 is an absolute URI) or the URI used to initiate the request, in that 4117 order of precedence. Note, however, that the base URI of the 4118 contents within the entity-body may be redefined within that entity- 4119 body. 4121 16.14. Content-Encoding 4123 See [H14.11]. 4125 16.15. Content-Language 4127 See [H14.12]. 4129 16.16. Content-Length 4131 The Content-Length general-header field contains the length of the 4132 body (entity) of the message (i.e. after the double CRLF following 4133 the last header). Unlike HTTP, it MUST be included in all messages 4134 that carry body beyond the header portion of the message. If it is 4135 missing, a default value of zero is assumed. It is interpreted 4136 according to [H14.13]. 4138 16.17. Content-Location 4140 See [H14.14]. 4142 16.18. Content-Type 4144 See [H14.17]. Note that the content types suitable for RTSP are 4145 likely to be restricted in practice to presentation descriptions and 4146 parameter-value types. 4148 16.19. CSeq 4150 The CSeq general-header field specifies the sequence number for an 4151 RTSP request-response pair. This field MUST be present in all 4152 requests and responses. For every RTSP request containing the given 4153 sequence number, the corresponding response will have the same 4154 number. Any retransmitted request MUST contain the same sequence 4155 number as the original (i.e. the sequence number is em not 4156 incremented for retransmissions of the same request). For each new 4157 RTSP request the CSeq value SHALL be incremented by one. The initial 4158 sequence number MAY be any number, however it is RECOMMENDED to start 4159 at 0. Each sequence number series is unique between each requester 4160 and responder, i.e. the client has one series for its request to a 4161 server and the server has another when sending request to the client. 4162 Each requester and responder is identified with its network address. 4164 Proxies that aggregate several sessions on the same transport will 4165 regularly need to renumber the CSeq header field in requests and 4166 responses to fulfill the rules for the header. 4168 Example: 4170 CSeq: 239 4172 16.20. Date 4174 See [H14.18]. An RTSP message containing a body MUST include a Date 4175 header if the sending host has a clock. Servers SHOULD include a 4176 Date header in all other RTSP messages. 4178 16.21. ETag 4180 The ETag response header MAY be included in DESCRIBE or SETUP 4181 responses. The entity tags (Section 4.8) returned in a DESCRIBE 4182 response, and the one in SETUP refers to the presentation, i.e. both 4183 the returned session description and the media stream. This allows 4184 for verification that one has the right session description to a 4185 media resource at the time of the SETUP request. However it has the 4186 disadvantage that a change in any of the parts results in 4187 invalidation of all the parts. 4189 If the ETag is provided both inside the entity, e.g. within the 4190 "a=etag" attribute in SDP, and in the response message, then both 4191 tags SHALL be identical. It is RECOMMENDED that the ETag is 4192 primarily given in the RTSP response message, to ensure that caches 4193 can use the ETag without requiring content inspection. However for 4194 session descriptions that are distributed outside of RTSP, for 4195 example using HTTP, etc. it will be necessary to include the entity 4196 tag in the session description as specified in Appendix C.1.9. 4198 SETUP and DESCRIBE requests can be made conditional upon the ETag 4199 using the headers If-Match (Section 16.24) and If-None-Match ( 4200 Section 16.26). 4202 16.22. Expires 4204 The Expires entity-header field gives a date and time after which the 4205 description or media-stream should be considered stale. The 4206 interpretation depends on the method: 4208 DESCRIBE response: The Expires header indicates a date and time 4209 after which the presentation description (body) SHOULD be 4210 considered stale. 4212 SETUP response: The Expires header indicate a date and time after 4213 which the media stream SHOULD be considered stale. 4215 A stale cache entry may not normally be returned by a cache (either a 4216 proxy cache or an user agent cache) unless it is first validated with 4217 the origin server (or with an intermediate cache that has a fresh 4218 copy of the entity). See Section 18 for further discussion of the 4219 expiration model. 4221 The presence of an Expires field does not imply that the original 4222 resource will change or cease to exist at, before, or after that 4223 time. 4225 The format is an absolute date and time as defined by HTTP-date in 4226 [H3.3]; it MUST be in RFC1123-date format: 4228 An example of its use is 4230 Expires: Thu, 01 Dec 1994 16:00:00 GMT 4232 RTSP/2.0 clients and caches MUST treat other invalid date formats, 4233 especially including the value "0", as having occurred in the past 4234 (i.e., already expired). 4236 To mark a response as "already expired," an origin server should use 4237 an Expires date that is equal to the Date header value. To mark a 4238 response as "never expires," an origin server SHOULD use an Expires 4239 date approximately one year from the time the response is sent. 4240 RTSP/2.0 servers SHOULD NOT send Expires dates more than one year in 4241 the future. 4243 The presence of an Expires header field with a date value of some 4244 time in the future on a media stream that otherwise would by default 4245 be non-cacheable indicates that the media stream is cacheable, unless 4246 indicated otherwise by a Cache-Control header field (Section 16.10). 4248 16.23. From 4250 See [H14.22]. 4252 16.24. If-Match 4254 See [H14.24]. 4256 The If-Match request-header field is especially useful for ensuring 4257 the integrity of the presentation description, in both the case where 4258 it is fetched via means external to RTSP (such as HTTP), or in the 4259 case where the server implementation is guaranteeing the integrity of 4260 the description between the time of the DESCRIBE message and the 4261 SETUP message. By including the ETag given in or with the session 4262 description in a SETUP request, the client ensures that resources set 4263 up are matching the description. A SETUP request for which the ETag 4264 validation check fails, SHALL responde using 412 (Precondition 4265 Failed). 4267 This validation check is also very useful if a session has been 4268 redirected from one server to another. 4270 16.25. If-Modified-Since 4272 The If-Modified-Since request-header field is used with the DESCRIBE 4273 and SETUP methods to make them conditional. If the requested variant 4274 has not been modified since the time specified in this field, a 4275 description will not be returned from the server (DESCRIBE) or a 4276 stream will not be set up (SETUP). Instead, a 304 (Not Modified) 4277 response SHALL be returned without any message-body. 4279 An example of the field is: 4281 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 4283 16.26. If-None-Match 4285 See [H14.26]. 4287 This request header can be used with one or several entity tags to 4288 make DESCRIBE requests conditional. A new session description is 4289 retrieved only if another entity than the ones already available 4290 would be included. If the entity available for delivery is matching 4291 the one the client already has, then a 304 (Not Modified) response is 4292 given. 4294 16.27. Last-Modified 4296 The Last-Modified entity-header field indicates the date and time at 4297 which the origin server believes the presentation description or 4298 media stream was last modified. See [H14.29]. For the methods 4299 DESCRIBE, the header field indicates the last modification date and 4300 time of the description, for SETUP that of the media stream. 4302 16.28. Location 4304 See [H14.30]. 4306 16.29. Pipelined-Requests 4308 The Pipelined-Requests general header is used to indicate that a 4309 request is to be executed in the context created by previous 4310 requests. The primary usage of this header is to allow pipelining of 4311 SETUP requests so that any additional SETUP request after the first 4312 one doesn't need to wait for the session ID to be sent back to the 4313 requesting entity. The header contains a unique identifier that is 4314 scoped by thepersistent connection used to send the requests. 4316 Upon receiving a request with the Pipelined-Requests the responding 4317 entity SHALL look up if there exist a binding between this Pipelined- 4318 Requests identifier for the current persistent connection and an RTSP 4319 session ID. If that exist then the received request is processed the 4320 same way as if it did contain the Session header with the looked up 4321 session ID. If there doesn't exist a mapping and no Session header 4322 is included in the request, the responding entity SHALL create a 4323 binding upon the succesful completion of a session creating request, 4324 i.e. SETUP. If the request failed to create an RTSP session no 4325 binding SHALL be created. In case the request contains both a 4326 Session header and the Pipelined-Requests header the Pipelined- 4327 Requests SHALL be ignored. 4329 Note: Based on the above definition at least the first request 4330 containing a new unique Pipelined-Requests will be required to be a 4331 SETUP request (unless the protocol is extended with new methods of 4332 creating a session). After that first one, additional SETUP requests 4333 or request of any type using the RTSP session context may includ the 4334 Pipelined-Requests header. 4336 For all responses to request that contained the Pipelined-Requests, 4337 the Session header and the Pipelined-Requests SHALL both be included, 4338 assuming that it is allowed for that response and that the binding 4339 between the header values exist. Pipelined-Requests SHOULD NOT be 4340 used in requests after that the client has received the RTSP Session 4341 ID. This as using the real session ID allows the request to be used 4342 also in cases the persistent connection has been terminated and a new 4343 connection is needed. 4345 It is the sender of the request that is responsible for using a 4346 previously unused identifier within this transport connection scope 4347 when a new RTSP session is to be cretated with this method. A server 4348 side binding SHALL be deleted upon the termination of the related 4349 RTSP session. Note: Although this definition would allow for reusing 4350 previously used pipelining identifiers, this is NOT RECOMMENDED to 4351 allow for better error handling and logging. 4353 RTSP Proxies may need to translate Pipelined-Requests identifier 4354 values from incoming request to outgoing to allow for aggregation of 4355 requests onto a persistent connection. 4357 16.30. Proxy-Authenticate 4359 See [H14.33]. 4361 16.31. Proxy-Authorization 4363 See [H14.34]. 4365 16.32. Proxy-Require 4367 The Proxy-Require request-header field is used to indicate proxy- 4368 sensitive features that MUST be supported by the proxy. Any Proxy- 4369 Require header features that are not supported by the proxy MUST be 4370 negatively acknowledged by the proxy to the client using the 4371 Unsupported header. The proxy SHALL use the 551 (Option Not 4372 Supported) status code in the response. Any feature-tag included in 4373 the Proxy-Require does not apply to the end-point (server or client). 4374 To ensure that a feature is supported by both proxies and servers the 4375 tag needs to be included in also a Require header. 4377 See Section 16.38 for more details on the mechanics of this message 4378 and a usage example. 4380 Example of use: 4382 Proxy-Require: play.basic 4384 16.33. Proxy-Supported 4386 The Proxy-Supported header field enumerates all the extensions 4387 supported by the proxy using feature-tags. The header carries the 4388 intersection of extensions supported by the forwarding proxies. The 4389 Proxy-Supported header MAY be included in any request by a proxy. It 4390 SHALL be added by any proxy if the Supported header is present in a 4391 request. When present in a request, the receiver MUST in the 4392 response copy the received Proxy-Supported header. 4394 The Proxy-Supported header field contains a list of feature-tags 4395 applicable to proxies, as described in Section 4.7. The list are the 4396 intersection of all feature-tags understood by the proxies. To 4397 achieve an intersection, the proxy adding the Proxy-Supported header 4398 includes all proxy feature-tags it understands. Any proxy receiving 4399 a request with the header, checks the list and removes any feature- 4400 tag it do not support. A Proxy-Supported header present in the 4401 response SHALL NOT be touched by the proxies. 4403 Example: 4405 C->P1: OPTIONS rtsp://example.com/ RTSP/2.0 4406 Supported: foo, bar, blech 4407 User-Agent: PhonyClient/1.2 4409 P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0 4410 Supported: foo, bar, blech 4411 Proxy-Supported: proxy-foo, proxy-bar, proxy-blech 4412 Via: 2.0 prox1.example.com 4414 P2->S: OPTIONS rtsp://example.com/ RTSP/2.0 4415 Supported: foo, bar, blech 4416 Proxy-Supported: proxy-foo, proxy-blech 4417 Via: 2.0 prox1.example.com, 2.0 prox2.example.com 4419 S->C: RTSP/2.0 200 OK 4420 Supported: foo, bar, baz 4421 Proxy-Supported: proxy-foo, proxy-blech 4422 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 4423 Via: 2.0 prox1.example.com, 2.0 prox2.example.com 4425 16.34. Public 4427 The Public response header field lists the set of methods supported 4428 by the response sender. This header applies to the general 4429 capabilities of the sender and its only purpose is to indicate the 4430 sender's capabilities to the recipient. The methods listed may or 4431 may not be applicable to the Request-URI; the Allow header field 4432 (section 14.7) MAY be used to indicate methods allowed for a 4433 particular URI. 4435 Example of use: 4437 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 4439 In the event that there are proxies between the sender and the 4440 recipient of a response, each intervening proxy MUST modify the 4441 Public header field to remove any methods that are not supported via 4442 that proxy. The resulting Public header field will contain an 4443 intersection of the sender's methods and the methods allowed through 4444 by the intervening proxies. 4446 In general proxies should allow all methods to transparently pass 4447 through from the sending RTSP agent to the receiving RTSP agent, 4448 but there may be cases where this is not desirable for a given 4449 proxy. Modification of the Public response header field by the 4450 intervening proxies ensures that the request sender gets an 4451 accurate response indicating the methods that can be used on the 4452 target agent via the proxy chain. 4454 16.35. Range 4456 The Range header specifies a time range in PLAY ( Section 13.4), 4457 PAUSE (Section 13.5), SETUP (Section 13.3), and REDIRECT ( 4458 Section 13.9) requests and responses. 4460 The range can be specified in a number of units. This specification 4461 defines smpte (Section 4.4), npt (Section 4.5), and clock 4462 (Section 4.6) range units. While byte ranges [H14.35.1] and other 4463 extended units MAY be used, their behavior is unspecified since they 4464 are not normally meaningful in RTSP. Servers supporting the Range 4465 header MUST understand the NPT range format and SHOULD understand the 4466 SMPTE range format. If the Range header is sent in a time format 4467 that is not understood, the recipient SHOULD return 456 (Header Field 4468 Not Valid for Resource) and include an Accept-Ranges header 4469 indicating the supported time formats for the given resource. 4471 The Range header MAY contain a time parameter in UTC, specifying the 4472 time at which the operation is to be made effective. This 4473 functionality SHALL be used only with the REDIRECT method. 4475 Ranges are half-open intervals, including the first point, but 4476 excluding the second point. In other words, a range of A-B starts 4477 exactly at time A, but stops just before B. Only the start time of a 4478 media unit such as a video or audio frame is relevant. For example, 4479 assume that video frames are generated every 40 ms. A range of 10.0- 4480 10.1 would include a video frame starting at 10.0 or later time and 4481 would include a video frame starting at 10.08, even though it lasted 4482 beyond the interval. A range of 10.0-10.08, on the other hand, would 4483 exclude the frame at 10.08. 4485 Example: 4487 Range: clock=19960213T143205Z-;time=19970123T143720Z 4489 The notation is similar to that used for the HTTP/1.1 [RFC2616] 4490 byte-range header. It allows clients to select an excerpt from 4491 the media object, and to play from a given point to the end as 4492 well as from the current location to a given point. 4494 By default, range intervals increase, where the second point is 4495 larger than the first point. 4497 Example: 4499 Range: npt=10-15 4501 However, range intervals can also decrease if the Scale header (see 4502 Section 16.40) indicates a negative scale value. For example, this 4503 would be the case when a playback in reverse is desired. 4505 Example: 4507 Scale: -1 4508 Range: npt=15-10 4510 Decreasing ranges are still half open intervals as described above. 4511 Thus, for range A-B, A is closed and B is open. In the above 4512 example, 15 is closed and 10 is open. An exception to this rule is 4513 the case when B=0 in a decreasing range. In this case, the range is 4514 closed on both ends, as otherwise there would be no way to reach 0 on 4515 a reverse playback for formats that have such a notion, like NPT and 4516 SMPTE. 4518 Example: 4520 Scale: -1 4521 Range: npt=15-0 4523 In this range both 15 and 0 are closed. 4525 A decreasing range interval without a corresponding negative Scale 4526 header is not valid. 4528 16.36. Referer 4530 See [H14.36]. The URI refers to that of the presentation 4531 description, typically retrieved via HTTP. 4533 16.37. Retry-After 4535 See [H14.37]. 4537 16.38. Require 4539 The Require request-header field is used by clients or servers to 4540 ensure that the other end-point supports features that are required 4541 in respect to this request. It can also be used to query if the 4542 other end-point supports certain features, however the use of the 4543 Supported (Section 16.44) is much more effective in this purpose. 4544 The server MUST respond to this header by using the Unsupported 4545 header to negatively acknowledge those feature-tags which are NOT 4546 supported. The response SHALL use the error code 551 (Option Not 4547 Supported). This header does not apply to proxies, for the same 4548 functionality in respect to proxies see, header Proxy-Require ( 4549 Section 16.32). 4551 This is to make sure that the client-server interaction will 4552 proceed without delay when all features are understood by both 4553 sides, and only slow down if features are not understood (as in 4554 the example below). For a well-matched client-server pair, the 4555 interaction proceeds quickly, saving a round-trip often required 4556 by negotiation mechanisms. In addition, it also removes state 4557 ambiguity when the client requires features that the server does 4558 not understand. 4560 Example (Not complete): 4562 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/2.0 4563 CSeq: 302 4564 Require: funky-feature 4565 Funky-Parameter: funkystuff 4567 S->C: RTSP/2.0 551 Option not supported 4568 CSeq: 302 4569 Unsupported: funky-feature 4571 In this example, "funky-feature" is the feature-tag which indicates 4572 to the client that the fictional Funky-Parameter field is required. 4573 The relationship between "funky-feature" and Funky-Parameter is not 4574 communicated via the RTSP exchange, since that relationship is an 4575 immutable property of "funky-feature" and thus should not be 4576 transmitted with every exchange. 4578 Proxies and other intermediary devices SHALL ignore this header. If 4579 a particular extension requires that intermediate devices support it, 4580 the extension should be tagged in the Proxy-Require field instead 4581 (see Section 16.32). 4583 16.39. RTP-Info 4585 The RTP-Info response-header field is used to set RTP-specific 4586 parameters in the PLAY response. For streams using RTP as transport 4587 protocol the RTP-Info header SHOULD be part of a 200 response to 4588 PLAY. 4590 The exclusion of the RTP-Info in a PLAY response for RTP 4591 transported media will result in that a client needs to 4592 synchronize the media streams using RTCP. This may have negative 4593 impact as the RTCP can be lost, and does not need to be 4594 particulary timely in their arrival. Also functionality as 4595 informing the client from which packet a seek has occurred is 4596 affected. 4598 The RTP-Info MAY also be included in SETUP responses to provide 4599 synchronization information when changing transport parameters, see 4600 Section 13.3. 4602 The header can carry the following parameters: 4604 url: Indicates the stream URI which for which the following RTP 4605 parameters correspond, this URI MUST be the same used in the 4606 SETUP request for this media stream. Any relative URI SHALL 4607 use the Request-URI as base URI. This parameter SHALL be 4608 present. 4610 ssrc: The Synchronization source (SSRC) that the RTP timestamp and 4611 sequence number provide applies to. This parameter SHALL be 4612 present. 4614 seq: Indicates the sequence number of the first packet of the stream 4615 that is direct result of the request. This allows clients to 4616 gracefully deal with packets when seeking. The client uses 4617 this value to differentiate packets that originated before the 4618 seek from packets that originated after the seek. Note that a 4619 client may not receive the packet with the expressed sequence 4620 number, and instead packets with a higher sequence number, due 4621 to packet loss or reordering. This parameter is RECOMMENDED to 4622 be present. 4624 rtptime: SHALL indicate the RTP timestamp value corresponding to the 4625 start time value in the Range response header, or if not 4626 explicitly given the implied start point. The client uses this 4627 value to calculate the mapping of RTP time to NPT or other 4628 media timescale. This parameter SHOULD be present to ensure 4629 inter-media synchronization is achieved. There exist no 4630 requirement that any received RTP packet will have the same RTP 4631 timestamp value as the one in the parameter used to establish 4632 synchronization. 4634 A mapping from RTP timestamps to NTP timestamps (wall clock) is 4635 available via RTCP. However, this information is not sufficient 4636 to generate a mapping from RTP timestamps to media clock time 4637 (NPT, etc.). Furthermore, in order to ensure that this 4638 information is available at the necessary time (immediately at 4639 startup or after a seek), and that it is delivered reliably, this 4640 mapping is placed in the RTSP control channel. 4642 In order to compensate for drift for long, uninterrupted 4643 presentations, RTSP clients should additionally map NPT to NTP, 4644 using initial RTCP sender reports to do the mapping, and later 4645 reports to check drift against the mapping. 4647 Example: 4649 Range:npt=3.25-15 4650 RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102; 4651 rtptime=12345678,url="rtsp://example.com/foo/video" 4652 ssrc=9A9DE123:seq=30211;rtptime=29567112 4654 Lets assume that audio uses a 16kHz RTP timestamp clock and Video 4655 a 90kHz RTP timestamp clock. Then the media synchronization is 4656 depicted in the following way. 4658 NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6 4659 Audio PA A 4660 Video V PV 4662 X: NPT time value = 3.25, from Range header. 4663 A: RTP timestamp value for Audio from RTP-Info header (12345678). 4664 V: RTP timestamp value for Video from RTP-Info header (29567112). 4665 PA: RTP audio packet carrying an RTP timestamp of 12344878. Which 4666 corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2 4667 PV: RTP video packet carrying an RTP timestamp of 29573412. Which 4668 corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32 4670 16.40. Scale 4672 A scale value of 1 indicates normal play at the normal forward 4673 viewing rate. If not 1, the value corresponds to the rate with 4674 respect to normal viewing rate. For example, a ratio of 2 indicates 4675 twice the normal viewing rate ("fast forward") and a ratio of 0.5 4676 indicates half the normal viewing rate. In other words, a ratio of 2 4677 has normal play time increase at twice the wallclock rate. For every 4678 second of elapsed (wallclock) time, 2 seconds of content will be 4679 delivered. A negative value indicates reverse direction. For 4680 certain media transports this may require certain considerations to 4681 work consistent, see Appendix B.1 for description on how RTP handles 4682 this. 4684 Unless requested otherwise by the Speed parameter, the data rate 4685 SHOULD not be changed. Implementation of scale changes depends on 4686 the server and media type. For video, a server may, for example, 4687 deliver only key frames or selected key frames. For audio, it may 4688 time-scale the audio while preserving pitch or, less desirably, 4689 deliver fragments of audio. 4691 The server should try to approximate the viewing rate, but may 4692 restrict the range of scale values that it supports. The response 4693 MUST contain the actual scale value chosen by the server. 4695 If the server does not implement the possibility to scale, it will 4696 not return a Scale header. A server supporting Scale operations for 4697 PLAY SHALL indicate this with the use of the "play.scale" feature- 4698 tags. 4700 When indicating a negative scale for a reverse playback, the Range 4701 header MUST indicate a decreasing range as described in 4702 Section 16.35. 4704 Example of playing in reverse at 3.5 times normal rate: 4706 Scale: -3.5 4707 Range: npt=15-10 4709 16.41. Speed 4711 The Speed request-header field requests the server to deliver data to 4712 the client at a particular speed, contingent on the server's ability 4713 and desire to serve the media stream at the given speed. 4714 Implementation by the server is OPTIONAL. The default is the bit 4715 rate of the stream. 4717 The parameter value is expressed as a decimal ratio, e.g., a value of 4718 2.0 indicates that data is to be delivered twice as fast as normal. 4719 A speed of zero is invalid. All speeds may not be possible to 4720 support. Therefore the actual used speed MUST be included in the 4721 response. The lack of a response header is indication of lack of 4722 support from the server of this functionality. Support of the speed 4723 functionality are indicated by the "play.speed" feature\-tag. 4725 Example: 4727 Speed: 2.5 4729 Use of this field changes the bandwidth used for data delivery. It 4730 is meant for use in specific circumstances where preview of the 4731 presentation at a higher or lower rate is necessary. Implementors 4732 should keep in mind that bandwidth for the session may be negotiated 4733 beforehand (by means other than RTSP), and therefore re-negotiation 4734 may be necessary. When data is delivered over UDP, it is highly 4735 recommended that means such as RTCP be used to track packet loss 4736 rates. If the data transport is performed over non-dedicated best- 4737 effort networks the sender is required to perform congestion control 4738 of the stream(s). This can result in that the communicated speed is 4739 impossible to maintain. 4741 16.42. Server 4743 See [H14.38], however the header syntax is corrected in 4744 Section 21.2.3. 4746 16.43. Session 4748 The Session request-header and response-header field identifies an 4749 RTSP session. An RTSP session is created by the server as a result 4750 of a successful SETUP request and in the response the session 4751 identifier is given to the client. The RTSP session exist until 4752 destroyed by a TEARDOWN or timed out by the server. 4754 The session identifier is chosen by the server (see Section 4.3) and 4755 MUST be returned in the SETUP response. Once a client receives a 4756 session identifier, it SHALL be included in any request related to 4757 that session. This means that the Session header MUST be included in 4758 a request using the following methods: PLAY, PAUSE, and TEARDOWN, and 4759 MAY be included in SETUP, OPTIONS, SETPARAMETER, GET_PARAMETER, and 4760 REDIRECT, and SHALL NOT be included in DESCRIBE. In an RTSP response 4761 the session header SHALL be included in methods, SETUP, PLAY, and 4762 PAUSE, and MAY be included in methods, TEARDOWN, and REDIRECT, and if 4763 included in the request of the following methods it SHALL also be 4764 included in the response, OPTIONS, GET_PARAMETER, and SETPARAMETER, 4765 and SHALL NOT be included in DESCRIBE. 4767 The timeout parameter MAY be included in a SETUP response, and SHALL 4768 NOT be included in requests. The server uses it to indicate to the 4769 client how long the server is prepared to wait between RTSP commands 4770 or other signs of life before closing the session due to lack of 4771 activity (see below and Appendix A). The timeout is measured in 4772 seconds, with a default of 60 seconds (1 minute). The length of the 4773 session timeout SHALL NOT be changed in a established session. 4775 The mechanisms for showing liveness of the client is, any RTSP 4776 request with a Session header, if RTP & RTCP is used an RTCP message, 4777 or through any other used media protocol capable of indicating 4778 liveness of the RTSP client. It is RECOMMENDED that a client does 4779 not wait to the last second of the timeout before trying to send a 4780 liveness message. The RTSP message may be lost or when using 4781 reliable protocols, such as TCP, the message may take some time to 4782 arrive safely at the receiver. To show liveness between RTSP request 4783 issued to accomplish other things, the following mechanisms can be 4784 used, in descending order of preference: 4786 RTCP: If RTP is used for media transport RTCP SHOULD be used. If 4787 RTCP is used to report transport statistics, it SHALL also work 4788 as keep alive. The server can determine the client by used 4789 network address and port together with the fact that the client 4790 is reporting on the servers SSRC(s). A downside of using RTCP 4791 is that it only gives statistical guarantees to reach the 4792 server. However that probability is so low that it can be 4793 ignored in most cases. For example, a session with 60 seconds 4794 timeout and enough bitrate assigned to RTCP messages to send a 4795 message from client to server on average every 5 seconds. That 4796 client have for a network with 5 \% packet loss, the 4797 probability to fail showing liveness sign in that session 4798 within the timeout interval of 2.4*E-16. In sessions with 4799 shorter timeout times, or much higher packet loss, or small 4800 RTCP bandwidths SHOULD also use any of the mechanisms below. 4802 SETPARAMETER: When using SETPARAMETER for keep alive, no body SHOULD 4803 be included. This method is the RECOMMENDED RTSP method to use 4804 in request only intended to perform keep-alive. 4806 OPTIONS: This method does also work. However it causes the server 4807 to perform more unnecessary processing and result in bigger 4808 responses than necessary for the task. The reason for this is 4809 that the server needs to determine what capabilities that are 4810 associated with the media resource to correctly populate the 4811 Public and Allow headers. 4813 Note that a session identifier identifies an RTSP session across 4814 transport sessions or connections. RTSP requests for a given session 4815 can use different URIs (Presentation and media URIs). Note, that 4816 there are restrictions depending on the session which URIs that are 4817 acceptable for a given method. However, multiple "user" sessions for 4818 the same URI from the same client will require use of different 4819 session identifiers. 4821 The session identifier is needed to distinguish several delivery 4822 requests for the same URI coming from the same client. 4824 The response 454 (Session Not Found) SHALL be returned if the session 4825 identifier is invalid. 4827 16.44. Supported 4829 The Supported header field enumerates all the extensions supported by 4830 the client or server using feature tags. The header carries the 4831 extensions supported by the message sending entity. The Supported 4832 header MAY be included in any request. When present in a request, 4833 the receiver MUST respond with its corresponding Supported header. 4835 Note, also in 4xx and 5xx responses is the supported header included. 4837 The Supported header field contains a list of feature-tags, described 4838 in Section 4.7, that are understood by the client or server. 4840 Example: 4842 C->S: OPTIONS rtsp://example.com/ RTSP/2.0 4843 Supported: foo, bar, blech 4844 User-Agent: PhonyClient/1.2 4846 S->C: RTSP/2.0 200 OK 4847 Supported: bar, blech, baz 4849 16.45. Timestamp 4851 The Timestamp general-header field describes when the agent sent the 4852 request. The value of the timestamp is of significance only to the 4853 agent and may use any timescale. The responding agent MUST echo the 4854 exact same value and MAY, if it has accurate information about this, 4855 add a floating point number indicating the number of seconds that has 4856 elapsed since it has received the request. The timestamp is used by 4857 the agent to compute the round-trip time to the responding agent so 4858 that it can adjust the timeout value for retransmissions. It also 4859 resolves retransmission ambiguities for unreliable transport of RTSP. 4861 16.46. Transport 4863 The Transport request and response header field indicates which 4864 transport protocol is to be used and configures its parameters such 4865 as destination address, compression, multicast time-to-live and 4866 destination port for a single stream. It sets those values not 4867 already determined by a presentation description. 4869 Transports are comma separated, listed in order of preference. 4870 Parameters may be added to each transport, separated by a semicolon. 4871 The server SHOULD return a Transport response-header field in the 4872 response to indicate the values actually chosen. The Transport 4873 header field MAY also be used to change certain transport parameters. 4874 A server MAY refuse to change parameters of an existing stream. 4876 A Transport request header field MAY contain a list of transport 4877 options acceptable to the client, in the form of multiple transport- 4878 spec entries. In that case, the server MUST return the single 4879 (transport-spec) which was actually chosen. The number of transport- 4880 spec entries is expected to be limited as the client will get 4881 guidance on what configurations that are possible from the 4882 presentation description. 4884 A transport-spec transport option may only contain one of any given 4885 parameter within it. Parameters MAY be given in any order. 4886 Additionally, it may only contain the unicast or the multicast 4887 transport type parameter. Unknown parameters SHALL be ignored. The 4888 requester need to ensure that the responder understands the 4889 parameters through the use of feature tags and the Require header. 4891 Any parameters part of future extensions requires clarification if 4892 they are safe to ignore in accordance to this specification, or are 4893 required to be understood. If a parameter is required to be 4894 understood, then a feature-tag MUST be defined for the functionality 4895 and used in the Require or Proxy-Require headers. 4897 The Transport header field is restricted to describing a single 4898 media stream. (RTSP can also control multiple streams as a single 4899 entity.) Making it part of RTSP rather than relying on a 4900 multitude of session description formats greatly simplifies 4901 designs of firewalls. 4903 The general syntax for the transport specifier is a list of slash 4904 separated tokens: 4906 Value1/Value2/Value3... 4908 Which for RTP transports take the form: 4910 RTP/profile/lower-transport. 4912 The default value for the "lower-transport" parameters is specific to 4913 the profile. For RTP/AVP, the default is UDP. 4915 There are two different methods for how to specify where the media 4916 should be delivered: 4918 dest_addr: The presence of this parameter and its values indicates 4919 the destination address or addresses (host address and port 4920 pairs for IP flows) necessary for the media transport. 4922 No dest_addr: The lack of the dest_addr parameter indicates that the 4923 server SHALL send media to same address for which the RTSP 4924 messages originates. Does not work for transports requiring 4925 explicitly given destination ports. 4927 The choice of method for indicating where the media is to be 4928 delivered depends on the use case. In many case the only allowed 4929 method will be to use no explicit address indication and have the 4930 server deliver media to the source of the RTSP messages. 4932 An RTSP proxy will need to take care. If the media is not desired to 4933 be routed through the proxy, the proxy will need to introduce the 4934 destination indication. 4936 Below are the configuration parameters associated with transport: 4938 General parameters: 4940 unicast / multicast: This parameter is a mutually exclusive 4941 indication of whether unicast or multicast delivery will be 4942 attempted. One of the two values MUST be specified. Clients 4943 that are capable of handling both unicast and multicast 4944 transmission needs to indicate such capability by including two 4945 full transport-specs with separate parameters for each. 4947 layers: The number of multicast layers to be used for this media 4948 stream. The layers are sent to consecutive addresses starting 4949 at the dest_addr address. If the parameter is not included, it 4950 defaults to a single layer. 4952 dest_addr: A general destination address parameter that can contain 4953 one or more address specifications. Each combination of 4954 Protocol/Profile/Lower Transport needs to have the format and 4955 interpretation of its address specification defined. For RTP/ 4956 AVP/UDP and RTP/AVP/TCP, the address specification is a tuple 4957 containing a host address and port. Note, only a single 4958 destination entity per transport spec is intended. The usage 4959 of multiple destination to distribute a single media to 4960 multiple entities is unspecified. 4962 The client originating the RTSP request MAY specify the 4963 destination address of the stream recipient with the host 4964 address part of the tuple. When the destination address is 4965 specified, the recipient may be a different party than the 4966 originator of the request. To avoid becoming the unwitting 4967 perpetrator of a remote-controlled denial-of-service attack, a 4968 server MUST perform security checks (see Section 22.1) and 4969 SHOULD log such attempts before allowing the client to direct a 4970 media stream to a recipient address not chosen by the server. 4971 Implementations cannot rely on TCP as reliable means of client 4972 identification. If the server does not allow the host address 4973 part of the tuple to be set, it SHALL return 463 (Destination 4974 Prohibited). 4976 The host address part of the tuple MAY be empty, for example 4977 ":58044", in cases when only destination port is desired to be 4978 specified. 4980 src_addr: A general source address parameter that can contain one or 4981 more address specifications. Each combination of Protocol/ 4982 Profile/Lower Transport needs to have the format and 4983 interpretation of its address specification defined. For RTP/ 4984 AVP/UDP and RTP/AVP/TCP, the address specification is a tuple 4985 containing a host address and port. 4987 This parameter MUST be specified by the server if it transmits 4988 media packets from another address than the one RTSP messages 4989 are sent to. This will allow the client to verify source 4990 address and give it a destination address for its RTCP feedback 4991 packets if RTP is used. The address or addresses indicated in 4992 the src_addr parameter SHOULD be used both for sending and 4993 receiving of the media streams data packets. The main reasons 4994 are threefold: First, indicating the port and source address(s) 4995 lets the receiver know where from the packets is expected to 4996 originate. Secondly, traversal of NATs are greatly simplified 4997 when traffic is flowing symmetrically over a NAT binding. 4998 Thirdly, certain NAT traversal mechanisms, needs to know to 4999 which address and port to send so called "binding packets" from 5000 the receiver to the sender, thus creating a address binding in 5001 the NAT that the sender to receiver packet flow can use. 5003 This information may also be available through SDP. 5004 However, since this is more a feature of transport than 5005 media initialization, the authoritative source for this 5006 information should be in the SETUP response. 5008 mode: The mode parameter indicates the methods to be supported for 5009 this session. Valid values are PLAY and RECORD. If not 5010 provided, the default is PLAY. The RECORD value was defined in 5011 RFC 2326 and is in this specification unspecified but reserved. 5013 interleaved: The interleaved parameter implies mixing the media 5014 stream with the control stream in whatever protocol is being 5015 used by the control stream, using the mechanism defined in 5016 Section 14. The argument provides the channel number to be 5017 used in the $ statement and MUST be present. This parameter 5018 MAY be specified as a range, e.g., tt interleaved=4-5 in cases 5019 where the transport choice for the media stream requires it, 5020 e.g. for RTP with RTCP. The channel number given in the 5021 request are only a guidance from the client to the server on 5022 what channel number(s) to use. The server MAY set any valid 5023 channel number in the response. The declared channel(s) are 5024 bi-directional, so both end-parties MAY send data on the given 5025 channel. One example of such usage is the second channel used 5026 for RTCP, where both server and client sends RTCP packets on 5027 the same channel. 5029 This allows RTP/RTCP to be handled similarly to the way 5030 that it is done with UDP, i.e., one channel for RTP and 5031 the other for RTCP. 5033 Multicast-specific: 5035 ttl: multicast time-to-live. When included in requests the value 5036 indicate the TTL value that the client desires to use. In 5037 response the value actually being used is returned. A server 5038 will need to consider what values that are reasonable and also 5039 the authority of the user to set this value. 5041 RTP-specific: 5043 These parameters are MAY only be used if the media transport protocol 5044 is RTP. 5046 ssrc: The ssrc parameter, if included in a SETUP response, indicates 5047 the RTP SSRC [RFC3550] value(s) that will be used by the media 5048 server for RTP packets within the stream. It is expressed as 5049 an eight digit hexadecimal value. 5051 The ssrc parameter SHALL NOT be specified in requests. The 5052 functionality of specifying the ssrc parameter in a SETUP 5053 request is deprecated as it is incompatible with the 5054 specification of RTP in RFC 3550[RFC3550]. If the parameter is 5055 included in the Transport header of a SETUP request, the server 5056 MAY ignore it, and choose appropriate SSRCs for the stream. 5057 The server MAY set the ssrc parameter in the Transport header 5058 of the response. 5060 The parameters defined below MAY only be used if the media transport 5061 protocol if the lower-level transport is connection-oriented (such as 5062 TCP). However, these parameters MUST NOT be used when interleaving 5063 data over the RTSP control connection. 5065 setup: Clients use the setup parameter on the Transport line in a 5066 SETUP request, to indicate the roles it wishes to play in a TCP 5067 connection. This parameter is adapted from [RFC4145]. We 5068 discuss the use of this parameter in RTP/AVP/TCP non- 5069 interleaved transport in Appendix B.2.2; the discussion below 5070 is limited to syntactic issues. Clients may specify the 5071 following values for the setup parameter: ["active":] The 5072 client will initiate an outgoing connection. ["passive":] The 5073 client will accept an incoming connection. ["actpass":] The 5074 client is willing to accept an incoming connection or to 5075 initiate an outgoing connection. 5077 If a client does not specify a setup value, the "active" value 5078 is assumed. 5080 In response to a client SETUP request where the setup parameter 5081 is set to "active", a server's 2xx reply MUST assign the setup 5082 parameter to "passive" on the Transport header line. 5084 In response to a client SETUP request where the setup parameter 5085 is set to "passive", a server's 2xx reply MUST assign the setup 5086 parameter to "active" on the Transport header line. 5088 In response to a client SETUP request where the setup parameter 5089 is set to "actpass", a server's 2xx reply MUST assign the setup 5090 parameter to "active" or "passive" on the Transport header 5091 line. 5093 Note that the "holdconn" value for setup is not defined for 5094 RTSP use, and MUST NOT appear on a Transport line. 5096 connection: Clients use the setup parameter on the Transport line in 5097 a SETUP request, to indicate the SETUP request prefers the 5098 reuse of an existing connection between client and server (in 5099 which case the client sets the "connection" parameter to 5100 "existing"), or that the client requires the creation of a new 5101 connection between client and server (in which cast the client 5102 sets the "connection" parameter to "new"). Typically, clients 5103 use the "new" value for the first SETUP request for a URL, and 5104 "existing" for subsequent SETUP requests for a URL. 5106 If a client SETUP request assigns the "new" value to 5107 "connection", the server response MUST also assign the "new" 5108 value to "connection" on the Transport line. 5110 If a client SETUP request assigns the "existing" value to 5111 "connection", the server response MUST assign a value of 5112 "existing" or "new" to "connection" on the Transport line, at 5113 its discretion. 5115 The default value of "connection" is "existing", for all SETUP 5116 requests (initial and subsequent). 5118 The combination of transport protocol, profile and lower transport 5119 needs to be defined. A number of combinations are defined in the 5120 Appendix B. 5122 Below is a usage example, showing a client advertising the capability 5123 to handle multicast or unicast, preferring multicast. Since this is 5124 a unicast-only stream, the server responds with the proper transport 5125 parameters for unicast. 5127 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 5128 CSeq: 302 5129 Transport: RTP/AVP;multicast;mode="PLAY", 5130 RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ 5131 "192.0.2.5:3457";mode="PLAY" 5132 Accept-Ranges: NPT, SMPTE, UTC 5133 User-Agent: PhonyClient/1.2 5135 S->C: RTSP/2.0 200 OK 5136 CSeq: 302 5137 Date: 23 Jan 1997 15:35:06 GMT 5138 Session: 47112344 5139 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ 5140 "192.0.2.5:3457";src_addr="192.0.2.224:6256" 5141 /"192.0.2.224:6257";mode="PLAY" 5142 Accept-Ranges: NPT 5144 16.47. Unsupported 5146 The Unsupported response-header field lists the features not 5147 supported by the server. In the case where the feature was specified 5148 via the Proxy-Require field (Section 16.32), if there is a proxy on 5149 the path between the client and the server, the proxy MUST send a 5150 response message with a status code of 551 (Option Not Supported). 5151 The request SHALL NOT be forwarded. 5153 See Section 16.38 for a usage example. 5155 16.48. User-Agent 5157 See [H14.43] for explanation, however the syntax is clarified due to 5158 an error in RFC 2616. A Client SHOULD include this header in all 5159 RTSP messages it sends. 5161 16.49. Vary 5163 See [H14.44]. 5165 16.50. Via 5167 See [H14.45]. 5169 16.51. WWW-Authenticate 5171 See [H14.47]. 5173 17. Proxies 5175 RTSP Proxies are RTSP agents that sit in between a client and a 5176 server. A proxy can take on both the role as a client and as server 5177 depending on what it tries to accomplish. Proxies are also 5178 introduced for several different reasons. 5180 Caching Proxy: This type of proxy is used to reduce the workload on 5181 servers and connections. By caching a presentation, both 5182 description and media streams the proxy can serve a client 5183 content without requesting it from the server once it has been 5184 cached and hasn't become stale. See the caching Section 18. 5186 Access Proxy: This type of proxy is used to ensure that a RTSP 5187 client get access to servers on an external network. Thus this 5188 proxy is placed on the border between two domains, e.g. a 5189 private address space and the public internet. The proxy 5190 performs the necessary translation, usually addresses, and 5191 often also media stream translation or redirection. 5193 Security Proxy: This type of proxy is used to help facilitate 5194 security functions around RTSP. For example when having a 5195 firewalled network, the security proxy request that the 5196 necessary pinholes in the firewall is opened when a client in 5197 the protected network want to access media streams on the 5198 external side. It can also provide network owners with a 5199 logging and audit point for RTSP sessions, e.g. for 5200 corporations that tracks or limits their employees access to 5201 certain type of content. 5203 All type of proxies can be used also when using secured communication 5204 with TLS as RTSP 2.0 allows the client to approve certificate chains 5205 used for connection establishment from a proxy, see Section 20.3.2. 5206 However that trust model may not be suitable for all type of 5207 deployment, and instead secured sessions do by-pass of the proxies. 5209 Access proxies SHOULD NOT be used in equipment like NATs and 5210 firewalls that aren't expected to be regularly maintained, like home 5211 or small office equipment. In these cases it is better to use the 5212 NAT traversal procedures defined for RTSP 2.0 5213 [I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is 5214 that any extensions of RTSP resulting in new media transport 5215 protocols or profiles, new parameters etc may fail in a proxy that 5216 isn't maintained. Thus resulting in blocking further development of 5217 RTSP and its usage. 5219 The existence of proxies must always be considered when developing 5220 new RTSP extensions. There must be definition of how proxies may 5221 handle the extension, if it is required to understand it, thus 5222 requiring a feature-tag to be used in the Proxy-Require header. 5224 18. Caching 5226 In HTTP, response-request pairs are cached. RTSP differs 5227 significantly in that respect. Responses are not cacheable, with the 5228 exception of the presentation description returned by DESCRIBE. 5229 (Since the responses for anything but DESCRIBE and GET_PARAMETER do 5230 not return any data, caching is not really an issue for these 5231 requests.) However, it is desirable for the continuous media data, 5232 typically delivered out-of-band with respect to RTSP, to be cached, 5233 as well as the session description. 5235 On receiving a SETUP or PLAY request, a proxy ascertains whether it 5236 has an up-to-date copy of the continuous media content and its 5237 description. It can determine whether the copy is up-to-date by 5238 issuing a SETUP or DESCRIBE request, respectively, and comparing the 5239 Last-Modified header with that of the cached copy. If the copy is 5240 not up-to-date, it modifies the SETUP transport parameters as 5241 appropriate and forwards the request to the origin server. 5242 Subsequent control commands such as PLAY or PAUSE then pass the proxy 5243 unmodified. The proxy delivers the continuous media data to the 5244 client, while possibly making a local copy for later reuse. The 5245 exact behavior allowed to the cache is given by the cache-response 5246 directives described in Section 16.10. A cache MUST answer any 5247 DESCRIBE requests if it is currently serving the stream to the 5248 requestor, as it is possible that low-level details of the stream 5249 description may have changed on the origin-server. 5251 Note that an RTSP cache, unlike the HTTP cache, is of the "cut- 5252 through" variety. Rather than retrieving the whole resource from the 5253 origin server, the cache simply copies the streaming data as it 5254 passes by on its way to the client. Thus, it does not introduce 5255 additional latency. 5257 To the client, an RTSP proxy cache appears like a regular media 5258 server, to the media origin server like a client. Just as an HTTP 5259 cache has to store the content type, content language, and so on for 5260 the objects it caches, a media cache has to store the presentation 5261 description. Typically, a cache eliminates all transport-references 5262 (that is, e.g. multicast information) from the presentation 5263 description, since these are independent of the data delivery from 5264 the cache to the client. Information on the encodings remains the 5265 same. If the cache is able to translate the cached media data, it 5266 would create a new presentation description with all the encoding 5267 possibilities it can offer. 5269 19. Examples 5271 This section contains several different examples trying to illustrate 5272 possible ways of using RTSP. The examples can also help with the 5273 understanding of how functions of RTSP work. However remember that 5274 this is examples and the normative and syntax description in the 5275 other sections takes precedence. Please also note that many of the 5276 example contain syntax illegal line breaks to accommodate the 5277 formatting restriction that the RFC series impose. 5279 19.1. Media on Demand (Unicast) 5281 The is an example of media on demand streaming of a media stored in a 5282 container file. For purposes of this example, a container file is a 5283 storage entity in which multiple continuous media types pertaining to 5284 the same end-user presentation are present. In effect, the container 5285 file represents an RTSP presentation, with each of its components 5286 being RTSP controlled media streams. Container files are a widely 5287 used means to store such presentations. While the components are 5288 transported as independent streams, it is desirable to maintain a 5289 common context for those streams at the server end. 5291 This enables the server to keep a single storage handle open 5292 easily. It also allows treating all the streams equally in case 5293 of any prioritization of streams by the server. 5295 It is also possible that the presentation author may wish to prevent 5296 selective retrieval of the streams by the client in order to preserve 5297 the artistic effect of the combined media presentation. Similarly, 5298 in such a tightly bound presentation, it is desirable to be able to 5299 control all the streams via a single control message using an 5300 aggregate URI. 5302 The following is an example of using a single RTSP session to control 5303 multiple streams. It also illustrates the use of aggregate URIs. In 5304 a container file it is also desirable to not write any URI parts 5305 which is not kept, when the container is distributed, like the host 5306 and most of the path element. Therefore this example also uses the 5307 "*" and relative URI in the delivered SDP. 5309 Client C requests a presentation from media server M. The movie is 5310 stored in a container file. The client has obtained an RTSP URI to 5311 the container file. 5313 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 5314 CSeq: 1 5315 User-Agent: PhonyClient/1.2 5317 M->C: RTSP/2.0 200 OK 5318 CSeq: 1 5319 Server: PhonyServer/1.0 5320 Date: 23 Jan 1997 15:35:06 GMT 5321 Content-Type: application/sdp 5322 Content-Length: 257 5323 Content-Base: rtsp://example.com/twister.3gp/ 5324 Expires: 24 Jan 1997 15:35:06 GMT 5326 v=0 5327 o=- 2890844256 2890842807 IN IP4 192.0.2.5 5328 s=RTSP Session 5329 i=An Example of RTSP Session Usage 5330 e=adm@example.com 5331 a=control: * 5332 a=range: npt=0-0:10:34.10 5333 t=0 0 5334 m=audio 0 RTP/AVP 0 5335 a=control: trackID=1 5336 m=video 0 RTP/AVP 26 5337 a=control: trackID=4 5339 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 5340 CSeq: 2 5341 User-Agent: PhonyClient/1.2 5342 Require: play.basic 5343 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" 5344 Accept-Ranges: NPT, SMPTE, UTC 5346 M->C: RTSP/2.0 200 OK 5347 CSeq: 2 5348 Server: PhonyServer/1.0 5349 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001; 5350 src_addr="192.0.2.5:9000"/"192.0.2.5:9001" 5351 ssrc=93CB001E 5352 Session: 12345678 5353 Expires: 24 Jan 1997 15:35:12 GMT 5354 Date: 23 Jan 1997 15:35:12 GMT 5355 Accept-Ranges: NPT 5357 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 5358 CSeq: 3 5359 User-Agent: PhonyClient/1.2 5360 Require: play.basic 5361 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" 5362 Session: 12345678 5363 Accept-Ranges: NPT, SMPTE, UTC 5365 M->C: RTSP/2.0 200 OK 5366 CSeq: 3 5367 Server: PhonyServer/1.0 5368 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003; 5369 src_addr="192.0.2.5:9002"/"192.0.2.5:9003"; 5370 ssrc=A813FC13 5371 Session: 12345678 5372 Expires: 24 Jan 1997 15:35:13 GMT 5373 Date: 23 Jan 1997 15:35:13 GMT 5374 Accept-Range: NPT 5376 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 5377 CSeq: 4 5378 User-Agent: PhonyClient/1.2 5379 Range: npt=0-10, npt=30- 5380 Session: 12345678 5382 M->C: RTSP/2.0 200 OK 5383 CSeq: 4 5384 Server: PhonyServer/1.0 5385 Date: 23 Jan 1997 15:35:14 GMT 5386 Session: 12345678 5387 Range: npt=0-10, npt=30-623.10 5388 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 5389 ssrc=0D12F123:seq=12345;rtptime=3450012, 5390 url="rtsp://example.com/twister.3gp/trackID=1"; 5391 ssrc=4F312DD8:seq=54321;rtptime=2876889 5393 C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0 5394 CSeq: 5 5395 User-Agent: PhonyClient/1.2 5396 Session: 12345678 5398 M->C: RTSP/2.0 200 OK 5399 CSeq: 5 5400 Server: PhonyServer/1.0 5401 Date: 23 Jan 1997 15:36:01 GMT 5402 Session: 12345678 5403 Range: npt=34.57-623.10 5405 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 5406 CSeq: 6 5407 User-Agent: PhonyClient/1.2 5408 Range: npt=34.57-623.10 5409 Session: 12345678 5411 M->C: RTSP/2.0 200 OK 5412 CSeq: 6 5413 Server: PhonyServer/1.0 5414 Date: 23 Jan 1997 15:36:01 GMT 5415 Session: 12345678 5416 Range: npt=34.57-623.10 5417 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 5418 ssrc=0D12F123:seq=12555;rtptime=6330012, 5419 url="rtsp://example.com/twister.3gp/trackID=1" 5420 ssrc=4F312DD8:seq=55021;rtptime=3132889 5422 19.2. Media on Demand using Pipelining 5424 This example is basically the example above ( Section 19.1) but now 5425 utilizing pipelining to speed up the setup. Into requiring only two 5426 round trip times until media starts flowing. First getting the 5427 session description to determine what media resources need to be 5428 setup. In the second one send the necessary SETUP requests and the 5429 PLAY request to initiate media delivery. 5431 Client C requests a presentation from media server M. The movie is 5432 stored in a container file. The client has obtained an RTSP URI to 5433 the container file. 5435 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 5436 CSeq: 1 5437 User-Agent: PhonyClient/1.2 5439 M->C: RTSP/2.0 200 OK 5440 CSeq: 1 5441 Server: PhonyServer/1.0 5442 Date: 23 Jan 1997 15:35:06 GMT 5443 Content-Type: application/sdp 5444 Content-Length: 257 5445 Content-Base: rtsp://example.com/twister.3gp/ 5446 Expires: 24 Jan 1997 15:35:06 GMT 5448 v=0 5449 o=- 2890844256 2890842807 IN IP4 192.0.2.5 5450 s=RTSP Session 5451 i=An Example of RTSP Session Usage 5452 e=adm@example.com 5453 a=control: * 5454 a=range: npt=0-0:10:34.10 5455 t=0 0 5456 m=audio 0 RTP/AVP 0 5457 a=control: trackID=1 5458 m=video 0 RTP/AVP 26 5459 a=control: trackID=4 5461 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 5462 CSeq: 2 5463 User-Agent: PhonyClient/1.2 5464 Require: play.basic 5465 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" 5466 Accept-Ranges: NPT, SMPTE, UTC 5467 Pipelined-Requests: 7654 5469 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 5470 CSeq: 3 5471 User-Agent: PhonyClient/1.2 5472 Require: play.basic 5473 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" 5474 Accept-Ranges: NPT, SMPTE, UTC 5475 Pipelined-Requests: 7654 5477 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 5478 CSeq: 4 5479 User-Agent: PhonyClient/1.2 5480 Range: npt=0-10, npt=30- 5481 Session: 12345678 5482 Pipelined-Requests: 7654 5484 M->C: RTSP/2.0 200 OK 5485 CSeq: 2 5486 Server: PhonyServer/1.0 5487 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001; 5488 src_addr="192.0.2.5:9000"/"192.0.2.5:9001" 5489 ssrc=93CB001E 5490 Session: 12345678 5491 Expires: 24 Jan 1997 15:35:12 GMT 5492 Date: 23 Jan 1997 15:35:12 GMT 5493 Accept-Ranges: NPT 5494 Pipelined-Requests: 7654 5496 M->C: RTSP/2.0 200 OK 5497 CSeq: 3 5498 Server: PhonyServer/1.0 5499 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003; 5500 src_addr="192.0.2.5:9002"/"192.0.2.5:9003"; 5501 ssrc=A813FC13 5502 Session: 12345678 5503 Expires: 24 Jan 1997 15:35:13 GMT 5504 Date: 23 Jan 1997 15:35:13 GMT 5505 Accept-Range: NPT 5506 Pipelined-Requests: 7654 5508 M->C: RTSP/2.0 200 OK 5509 CSeq: 4 5510 Server: PhonyServer/1.0 5511 Date: 23 Jan 1997 15:35:14 GMT 5512 Session: 12345678 5513 Range: npt=0-10, npt=30-623.10 5514 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 5515 ssrc=0D12F123:seq=12345;rtptime=3450012, 5516 url="rtsp://example.com/twister.3gp/trackID=1"; 5517 ssrc=4F312DD8:seq=54321;rtptime=2876889 5518 Pipelined-Requests: 7654 5520 19.3. Media on Demand (Unicast) 5522 An alternative example of media on demand with a bit more tweaks is 5523 the following. Client C requests a movie distributed from two 5524 different media servers A (tt audio.example.com) and V (tt 5525 video.example.com). The media description is stored on a web server 5526 W. The media description contains descriptions of the presentation 5527 and all its streams, including the codecs that are available, dynamic 5528 RTP payload types, the protocol stack, and content information such 5529 as language or copyright restrictions. It may also give an 5530 indication about the timeline of the movie. 5532 In this example, the client is only interested in the last part of 5533 the movie. 5535 C->W: GET /twister.sdp HTTP/1.1 5536 Host: www.example.com 5537 Accept: application/sdp 5539 W->C: HTTP/1.0 200 OK 5540 Date: 23 Jan 1997 15:35:06 GMT 5541 Content-Type: application/sdp 5542 Content-Length: 264 5543 Expires: 23 Jan 1998 15:35:06 GMT 5545 v=0 5546 o=- 2890844526 2890842807 IN IP4 192.0.2.5 5547 s=RTSP Session 5548 e=adm@example.com 5549 a=range:npt=0-1:49:34 5550 t=0 0 5551 m=audio 0 RTP/AVP 0 5552 a=control:rtsp://audio.example.com/twister/audio.en 5553 m=video 0 RTP/AVP 31 5554 a=control:rtsp://video.example.com/twister/video 5556 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0 5557 CSeq: 1 5558 User-Agent: PhonyClient/1.2 5559 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057", 5560 RTP/AVP/TCP;unicast;interleaved=0-1 5561 Accept-Ranges: NPT, SMPTE, UTC 5563 A->C: RTSP/2.0 200 OK 5564 CSeq: 1 5565 Session: 12345678 5566 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057"; 5567 src_addr="192.0.2.5:5000"/"192.0.2.5:5001" 5568 Date: 23 Jan 1997 15:35:12 GMT 5569 Server: PhonyServer/1.0 5570 Expires: 24 Jan 1997 15:35:12 GMT 5571 Cache-Control: public 5572 Accept-Ranges: NPT, SMPTE 5574 C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0 5575 CSeq: 1 5576 User-Agent: PhonyClient/1.2 5577 Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059", 5578 RTP/AVP/TCP;unicast;interleaved=0-1 5579 Accept-Ranges: NPT, SMPTE, UTC 5581 V->C: RTSP/2.0 200 OK 5582 CSeq: 1 5583 Session: 23456789 5584 Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059"; 5585 src_addr="192.0.2.5:5002"/"192.0.2.5:5003" 5586 Date: 23 Jan 1997 15:35:12 GMT 5587 Server: PhonyServer/1.0 5588 Cache-Control: public 5589 Expires: 24 Jan 1997 15:35:12 GMT 5590 Accept-Ranges: NPT, SMPTE 5592 C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0 5593 CSeq: 2 5594 User-Agent: PhonyClient/1.2 5595 Session: 23456789 5596 Range: smpte=0:10:00- 5598 V->C: RTSP/2.0 200 OK 5599 CSeq: 2 5600 Session: 23456789 5601 Range: smpte=0:10:00-1:49:23 5602 RTP-Info: url="rtsp://video.example.com/twister/video" 5603 ssrc=A17E189D:seq=12312232;rtptime=78712811 5604 Server: PhonyServer/2.0 5605 Date: 23 Jan 1997 15:35:13 GMT 5607 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0 5608 CSeq: 2 5609 User-Agent: PhonyClient/1.2 5610 Session: 12345678 5611 Range: smpte=0:10:00- 5613 A->C: RTSP/2.0 200 OK 5614 CSeq: 2 5615 Session: 12345678 5616 Range: smpte=0:10:00-1:49:23 5617 RTP-Info: url="rtsp://audio.example.com/twister/audio.en" 5618 ssrc=3D124F01:seq=876655;rtptime=1032181 5619 Server: PhonyServer/1.0 5620 Date: 23 Jan 1997 15:35:13 GMT 5622 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0 5623 CSeq: 3 5624 User-Agent: PhonyClient/1.2 5625 Session: 12345678 5627 A->C: RTSP/2.0 200 OK 5628 CSeq: 3 5629 Server: PhonyServer/1.0 5630 Date: 23 Jan 1997 15:36:52 GMT 5632 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0 5633 CSeq: 3 5634 User-Agent: PhonyClient/1.2 5635 Session: 23456789 5637 V->C: RTSP/2.0 200 OK 5638 CSeq: 3 5639 Server: PhonyServer/2.0 5640 Date: 23 Jan 1997 15:36:52 GMT 5642 Even though the audio and video track are on two different servers, 5643 may start at slightly different times, and may drift with respect to 5644 each other, the client can perform initial synchronize of the two 5645 media using RTP-Info and Range received in the PLAY responses. If 5646 the two servers are time synchronized the RTCP packets can also be 5647 used to maintain synchronization. 5649 19.4. Single Stream Container Files 5651 Some RTSP servers may treat all files as though they are "container 5652 files", yet other servers may not support such a concept. Because of 5653 this, clients needs to use the rules set forth in the session 5654 description for Request-URIs, rather than assuming that a consistent 5655 URI may always be used throughout. Below are an example of how a 5656 multi-stream server might expect a single-stream file to be served: 5658 C->S: DESCRIBE rtsp://foo.com/test.wav RTSP/2.0 5659 Accept: application/x-rtsp-mh, application/sdp 5660 CSeq: 1 5661 User-Agent: PhonyClient/1.2 5663 S->C: RTSP/2.0 200 OK 5664 CSeq: 1 5665 Content-base: rtsp://foo.com/test.wav/ 5666 Content-type: application/sdp 5667 Content-length: 148 5668 Server: PhonyServer/1.0 5669 Date: 23 Jan 1997 15:35:06 GMT 5670 Expires: 23 Jan 1997 17:00:00 GMT 5672 v=0 5673 o=- 872653257 872653257 IN IP4 192.0.2.5 5674 s=mu-law wave file 5675 i=audio test 5676 t=0 0 5677 a=control: * 5678 m=audio 0 RTP/AVP 0 5679 a=control:streamid=0 5681 C->S: SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/2.0 5682 Transport: RTP/AVP/UDP;unicast; 5683 dest_addr=":6970"/":6971";mode="PLAY" 5684 CSeq: 2 5685 User-Agent: PhonyClient/1.2 5686 Accept-Ranges: NPT, SMPTE, UTC 5688 S->C: RTSP/2.0 200 OK 5689 Transport: RTP/AVP/UDP;unicast;dest_addr=":6970"/":6971"; 5690 src_addr="192.0.2.5:6970"/"192.0.2.5:6971"; 5691 mode="PLAY";ssrc=EAB98712 5692 CSeq: 2 5693 Session: 2034820394 5694 Expires: 23 Jan 1997 16:00:00 GMT 5695 Server: PhonyServer/1.0 5696 Date: 23 Jan 1997 15:35:07 GMT 5697 Accept-Ranges: NPT 5699 C->S: PLAY rtsp://foo.com/test.wav/ RTSP/2.0 5700 CSeq: 3 5701 User-Agent: PhonyClient/1.2 5702 Session: 2034820394 5704 S->C: RTSP/2.0 200 OK 5705 CSeq: 3 5706 Server: PhonyServer/1.0 5707 Date: 23 Jan 1997 15:35:08 GMT 5708 Session: 2034820394 5709 Range: npt=0-600 5710 RTP-Info: url="rtsp://foo.com/test.wav/streamid=0" 5711 ssrc=0D12F123:seq=981888;rtptime=3781123 5713 Note the different URI in the SETUP command, and then the switch back 5714 to the aggregate URI in the PLAY command. This makes complete sense 5715 when there are multiple streams with aggregate control, but is less 5716 than intuitive in the special case where the number of streams is 5717 one. However the server has declared that the aggregated control URI 5718 in the SDP and therefore this is legal. 5720 In this case, it is also required that servers accept implementations 5721 that use the non-aggregated interpretation and use the individual 5722 media URI, like this: 5724 C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0 5725 CSeq: 3 5726 User-Agent: PhonyClient/1.2 5728 19.5. Live Media Presentation Using Multicast 5730 The media server M chooses the multicast address and port. Here, it 5731 is assumed that the web server only contains a pointer to the full 5732 description, while the media server M maintains the full description. 5734 C->W: GET /sessions.html HTTP/2.0 5735 Host: www.example.com 5737 W->C: HTTP/2.0 200 OK 5738 Content-Type: text/html 5740 5741 ... 5742 5744 ... 5745 5747 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0 5748 CSeq: 1 5749 Supported: play.basic, play.scale 5750 User-Agent: PhonyClient/1.2 5752 M->C: RTSP/2.0 200 OK 5753 CSeq: 1 5754 Content-Type: application/sdp 5755 Content-Length: 182 5756 Server: PhonyServer/1.0 5757 Date: 23 Jan 1997 15:35:06 GMT 5758 Supported: play.basic 5760 v=0 5761 o=- 2890844526 2890842807 IN IP4 192.0.2.5 5762 s=RTSP Session 5763 m=audio 3456 RTP/AVP 0 5764 c=IN IP4 224.2.0.1/16 5765 a=control: rtsp://live.example.com/concert/audio 5766 a=range:npt=0- 5768 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0 5769 CSeq: 2 5770 Transport: RTP/AVP;multicast 5771 Accept-Ranges: NPT, SMPTE, UTC 5772 User-Agent: PhonyClient/1.2 5774 M->C: RTSP/2.0 200 OK 5775 CSeq: 2 5776 Server: PhonyServer/1.0 5777 Date: 23 Jan 1997 15:35:06 GMT 5778 Transport: RTP/AVP;multicast;dest_addr="224.2.0.1:3456"/" 5779 224.2.0.1:3457";ttl=16 5780 Session: 0456804596 5781 Accept-Ranges: NPT, UTC 5783 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0 5784 CSeq: 3 5785 Session: 0456804596 5786 User-Agent: PhonyClient/1.2 5788 M->C: RTSP/2.0 200 OK 5789 CSeq: 3 5790 Server: PhonyServer/1.0 5791 Date: 23 Jan 1997 15:35:07 GMT 5792 Session: 0456804596 5793 Range:npt=1256- 5794 RTP-Info: url="rtsp://live.example.com/concert/audio" 5795 ssrc=0D12F123:seq=1473; rtptime=80000 5797 19.6. Capability Negotiation 5799 This examples illustrate how the client and server determines their 5800 capability to support a special feature, in this case "play.scale". 5801 The server, through the clients request and the included Supported 5802 header, learns the client supports RTSP 2.0, and also supports the 5803 playback time scaling feature of RTSP. The server's response 5804 contains the following feature related information to the client; it 5805 supports the basic playback (play.basic), the extended functionality 5806 of time scaling of content (play.scale), and one "example.com" 5807 proprietary feature (com.example.flight). The client also learns the 5808 methods supported (Public header) by the server for the indicated 5809 resource. 5811 C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0 5812 CSeq: 1 5813 Supported: play.basic, play.scale 5814 User-Agent: PhonyClient/1.2 5816 S->C: RTSP/2.0 200 OK 5817 CSeq: 1 5818 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 5819 Server: PhonyServer/2.0 5820 Supported: play.basic, play.scale, com.example.flight 5822 When the client sends its SETUP request it tells the server that it 5823 is requires support of the play.scale feature for this session by 5824 including the Require header. 5826 C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0 5827 CSeq: 3 5828 User-Agent: PhonyClient/1.2 5829 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057", 5830 RTP/AVP/TCP;unicast;interleaved=0-1 5831 Require: play.scale 5832 Accept-Ranges: NPT, SMPTE, UTC 5833 User-Agent: PhonyClient/1.2 5835 S->C: RTSP/2.0 200 OK 5836 CSeq: 3 5837 Session: 12345678 5838 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057"; 5839 src_addr="192.0.2.5:5000"/"192.0.2.5:5001" 5840 Server: PhonyServer/2.0 5841 Accept-Ranges: NPT, SMPTE 5843 20. Security Framework 5845 The RTSP security framework consists of two high level components: 5846 the pure authentication mechanisms based on HTTP authentication, and 5847 the transport protection based on TLS, which is independent of RTSP. 5848 Because of the similarity in syntax and usage between RTSP servers 5849 and HTTP servers, the security for HTTP is re-used to a large extent. 5851 20.1. RTSP and HTTP Authentication 5853 RTSP and HTTP share common authentication schemes, and thus follow 5854 the same usage guidelines as specified in[RFC2617] and also in [H15]. 5855 Servers SHOULD implement both basic and digest [RFC2617] 5856 authentication. 5858 It should be stressed that using the HTTP authentication alone does 5859 not provide full control message security. Therefore, in 5860 environments requiring tighter security for the control messages, TLS 5861 SHOULD be used, see Section 20.2. 5863 20.2. RTSP over TLS 5865 RTSP SHALL follow the same guidelines with regards to TLS [RFC4346] 5866 usage as specified for HTTP, see [RFC2818]. RTSP over TLS is 5867 separated from unsecured RTSP both on URI level and port level. 5868 Instead of using the "rtsp" scheme identifier in the URI, the "rtsps" 5869 scheme identifier MUST be used to signal RTSP over TLS. If no port 5870 is given in a URI with the "rtsps" scheme, port 322 SHALL be used for 5871 TLS over TCP/IP. 5873 When a client tries to setup an insecure channel to the server (using 5874 the "rtsp" URI), and the policy for the resource requires a secure 5875 channel, the server SHALL redirect the client to the secure service 5876 by sending a 301 redirect response code together with the correct 5877 Location URI (using the "rtsps" scheme). A user or client MAY 5878 upgrade a non secured URI to a secured by changing the scheme from 5879 "rtsp" to "rtsps". A server implementing support for "rtsps" SHALL 5880 allow this. 5882 It should be noted that TLS allows for mutual authentication (when 5883 using both server and client certificates). Still, one of the more 5884 common way TLS is used is to only provide server side authentication 5885 (often to avoid client certificates). TLS is then used in addition 5886 to HTTP authentication, providing transport security and server 5887 authentication, while HTTP Authentication is used to authenticate the 5888 client. 5890 RTSP includes the possibility to keep a TCP session up between the 5891 client and server, throughout the RTSP session lifetime. It may be 5892 convenient to keep the TCP session, not only to save the extra setup 5893 time for TCP, but also the extra setup time for TLS (even if TLS uses 5894 the resume function, there will be almost two extra roundtrips). 5895 Still, when TLS is used, such behavior introduces extra active state 5896 in the server, not only for TCP and RTSP, but also for TLS. This may 5897 increase the vulnerability to DoS attacks. 5899 In addition to these recommendations, Section 20.3 gives further 5900 recommendations of TLS usage with proxies. 5902 20.3. Security and Proxies 5904 The nature of a proxy is often to act as a "man-in-the-middle", while 5905 security is often about preventing the existence of a "man-in-the- 5906 middle". This section provides the clients with the possibility to 5907 use proxies even when applying secure transports (TLS) between the 5908 RTSP agents. The TLS proxy mechanism allows for server and proxy 5909 identification using certificates. However, the client can not be 5910 identified based on certificates. The client needs to select between 5911 using the procedure specified below or using a TLS connection 5912 directly (by-passing any proxies) to the server. The choice may be 5913 dependent on policies. 5915 There are basically two categories of proxies, the transparent 5916 proxies (of which the client is not aware) and the non-transparent 5917 proxies (of which the client is aware). An infrastructure based on 5918 proxies requires that the trust model is such that both client and 5919 servers can trust the proxies to handle the RTSP messages correctly. 5920 To be able to trust a proxy, the client and server also needs to be 5921 aware of the proxy. Hence, transparent proxies cannot generally be 5922 seen as trusted and will not work well with security (unless they 5923 work only at transport layer). In the rest of this section any 5924 reference to proxy will be to a non-transparent proxy, which inspects 5925 or manipulate the RTSP messages. 5927 HTTP Authentication is built on the assumption of proxies and can 5928 provide user-proxy authentication and proxy-proxy/server 5929 authentication in addition to the client-server authentication. 5931 When TLS is applied and a proxy is used, the client will connect to 5932 the proxy's address when connecting to any RTSP server. This implies 5933 that for TLS, the client will authenticate the proxy server and not 5934 the end server. Note that when the client checks the server 5935 certificate in TLS, it MUST check the proxy's identity (URI or 5936 possibly other known identity) against the proxy's identity as 5937 presented in the proxy's Certificate message. 5939 The problem is that for a proxy accepted by the client, the proxy 5940 needs to be provided information on which grounds it should accept 5941 the next-hop certificate. Both the proxy and the user may have rules 5942 for this, and the user have the possibility to select the desired 5943 behavior. To handle this case, the Accept-Credentials header (See 5944 Section 16.2) is used, where the client can force the proxy/proxies 5945 to relay back the chain of certificates used to authenticate any 5946 intermediate proxies as well as the server. Given the assumption 5947 that the proxies are viewed as trusted, it gives the user a 5948 possibility to enforce policies to each trusted proxy of whether it 5949 should accept the next entity in the chain. 5951 A proxy MUST use TLS for the next hop if the RTSP request includes a 5952 "rtsps" URI. TLS MAY be applied on intermediate links (e.g. between 5953 client and proxy, or between proxy and proxy), even if the resource 5954 and the end server does not require to use it. The proxy SHALL when 5955 initiating the next hop TLS connection use the incomming TLS 5956 connections CipherSuite list, only modified by removing any cipher 5957 suits that the proxy does not support. In case a proxy fails to 5958 establish a TLS connection due to cipher suite mismatch between proxy 5959 and next hop proxy or server, this is indicated using error code 472 5960 (Failure to establish secure connection). 5962 20.3.1. Accept-Credentials 5964 The Accept-Credentials header can be used by the client to distribute 5965 simple authorization policies to intermediate proxies. The client 5966 includes the Accept-Credentials header to dictate how the proxy 5967 treats the server/next proxy certificate. There are currently three 5968 methods defined: 5970 Any, which means that the proxy (or proxies) SHALL accept whatever 5971 certificate presented. This is of course not a recommended 5972 option to use, but may be useful in certain circumstances (such 5973 as testing). 5975 Proxy, which means that the proxy (or proxies) MUST use its own 5976 policies to validate the certificate and decide whether to 5977 accept it or not. This is convenient in cases where the user 5978 has a strong trust relation with the proxy. Reason why a 5979 strong trust relation may exist are; personal/company proxy, 5980 proxy has a out-of-band policy configuration mechanism. 5982 User, which means that the proxy (or proxies) MUST send credential 5983 information about the next hop to the client for authorization. 5984 The client can then decide whether the proxy should accept the 5985 certificate or not. See Section 20.3.2 for further details. 5987 If the Accept-Credentials header is not included in the RTSP request 5988 from the client, then the "Proxy" method SHALL be used as default. 5989 If an other method than the "Proxy" is to be used, then the Accept- 5990 Credentials header SHALL be included in all of the RTSP request from 5991 the client. This is because it cannot be assumed that the proxy 5992 always keeps the TLS state or the users previously preference between 5993 different RTSP messages (in particular if the time interval between 5994 the messages is long). 5996 With the "Any" and "Proxy" methods the proxy will apply the policy as 5997 defined for respectively method. If the policy do not accept the 5998 credentials of the next hop, the entity SHALL respond with a message 5999 using status code 471 (Connection Credentials not accepted). 6001 An RTSP request in the direction server to client MUST NOT include 6002 the Accept-Credential header. As for the non-secured communication, 6003 the possibility for these request depends on the presence of a client 6004 established connection. However if the server to client request is 6005 in relation to a session established over a TLS secured channel, if 6006 MUST be sent in a TLS secured connection. That secured connection 6007 MUST also be the one used by the last client to server request. If 6008 no such transport connection exist at the time when the server desire 6009 to send the request, it silently fails. 6011 Further policies MAY be defined and registered, but should be done so 6012 with caution. 6014 20.3.2. User approved TLS procedure 6016 For the "User" method each proxy MUST perform the the following 6017 procedure for each RTSP request: 6019 o Setup the TLS session to the next hop if not already present (i.e. 6020 run the TLS handshake, but do not send the RTSP request). 6022 o Extract the peer certificate chain for the TLS session. 6024 o Check if a matching identity and hash of the peer certificate is 6025 present in the Accept-Credentials header. If present, send the 6026 message to the next hop, and conclude these procedures. If not, 6027 go to the next step. 6029 o The proxy responds to the RTSP request with a 470 or 407 response 6030 code. The 407 response code MAY be used when the proxy requires 6031 both user and connection authorization from user or client. In 6032 this message the proxy SHALL include a Connection-Credentials 6033 header, see Section 16.12 with the next hop's identity and 6034 certificate. 6036 The client MUST upon receiving a 470 or 407 response with Connection- 6037 Credentials header take the decision on whether to accept the 6038 certificate or not (if it cannot do so, the user SHOULD be 6039 consulted). If the certificate is accepted, the client has to again 6040 send the RTSP request. In that request the client has to include the 6041 Accept-Credentials header including the hash over the DER encoded 6042 certificate for all trusted proxies in the chain. 6044 Example: 6046 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 6047 CSeq: 2 6048 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 6049 "192.0.2.5:4589" 6050 Accept-Ranges: NPT, SMPTE, UTC 6051 Accept-Credentials: User 6053 P->C: RTSP/2.0 470 Connection Authorization Required 6054 CSeq: 2 6055 Connection-Credentials: "rtsps://test.example.org"; 6056 MIIDNTCCAp... 6058 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 6059 CSeq: 2 6060 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 6061 "192.0.2.5:4589" 6062 Accept-Credentials: User "rtsps://test.example.org";sha-256; 6063 dPYD7txpoGTbAqZZQJ+vaeOkyH4= 6064 Accept-Ranges: NPT, SMPTE, UTC 6066 P->S: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 6067 CSeq: 2 6068 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 6069 "192.0.2.5:4589" 6070 Via: RTSP/2.0 proxy.example.org 6071 Accept-Credentials: User "rtsps://test.example.org";sha-256; 6072 dPYD7txpoGTbAqZZQJ+vaeOkyH4= 6073 Accept-Ranges: NPT, SMPTE, UTC 6075 One implication of this process is that the connection for secured 6076 RTSP messages may take significantly more round-trip times for the 6077 first message. An complete extra message exchange between the proxy 6078 connecting to the next hop and the client results because of the 6079 process for approval for each hop. However after the first message 6080 exchange the remaining message should not be delayed, if each message 6081 contains the chain of proxies that the requestor accepts. The 6082 procedure of including the credentials in each request rather than 6083 building state in each proxy, avoids the need for revocation 6084 procedures. 6086 21. Syntax 6088 The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF) 6089 as defined in RFC 4234 [RFC4234]. It uses the basic definitions 6090 present in RFC 4234. 6092 Please note that ABNF strings, e.g. "Accept", are case insensitive 6093 as specified in section 2.3 of RFC 4234. 6095 21.1. Base Syntax 6097 RTSP header field values can be folded onto multiple lines if the 6098 continuation line begins with a space or horizontal tab. All linear 6099 white space, including folding, has the same semantics as SP. A 6100 recipient MAY replace any linear white space with a single SP before 6101 interpreting the field value or forwarding the message downstream. 6102 This is intended to behave exactly as HTTP/1.1 as described in RFC 6103 2616 [RFC2616]. The SWS construct is used when linear white space is 6104 optional, generally between tokens and separators. 6106 To separate the header name from the rest of value, a colon is used, 6107 which, by the above rule, allows whitespace before, but no line 6108 break, and whitespace after, including a linebreak. The HCOLON 6109 defines this construct. 6111 OCTET = %x00-FF ; any 8-bit sequence of data 6112 CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127) 6113 UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z" 6114 LOALPHA = %x61-7A ;any US-ASCII lowercase letter "a".."z" 6115 ALPHA = UPALPHA / LOALPHA 6116 DIGIT = %x30-39 ; any US-ASCII digit "0".."9" 6117 CTL = %x00-1F / %x7F ; any US-ASCII control charac7ter 6118 ; (octets 0 - 31) and DEL (127) 6119 CR = %x0D ; US-ASCII CR, carriage return (13 6120 LF = %x0A ; US-ASCII LF, linefeed (10) 6121 SP = %x20 ; US-ASCII SP, space (32) 6122 HT = %x09 ; US-ASCII HT, horizontal-tab (9) 6123 DQ = %x22 ; US-ASCII double-quote mark (34) 6124 BACKSLASH = %x5C ; US-ASCII backslash (92) 6125 CRLF = CR LF 6126 LWS = [CRLF] 1*( SP / HT ) 6127 SWS = [LWS] ; sep whitespace 6128 HCOLON = *( SP / HT ) ":" SWS 6129 TEXT = %x20-7D / %x80-FF ; any OCTET except CTLs 6130 tspecials = "(" / ")" / "<" / ">" / "@" 6131 / "," / ";" / ":" / BACKSLASH / DQ 6132 / "/" / "[" / "]" / "?" / "=" 6133 / "{" / "}" / SP / HT 6134 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 6135 / %x41-5A / %x5E-7A / %x7C / %x7E) 6136 ; 1* 6137 quoted-string = ( DQ *qdtext DQ ) 6138 qdtext = %x20-21 / %x23-7D / %x80-FF ; any TEXT except <"> 6139 quoted-pair = BACKSLASH CHAR 6140 ctext = %x20-27 / %x2A-7D 6141 / %x80-FF ; any OCTET except CTLs, "(" and ")" 6142 generic-param = token [ EQUAL gen-value ] 6143 gen-value = token / host / quoted-string 6145 safe = "$" / "-" / "_" / "." / "+" 6146 extra = "!" / "*" / "'" / "(" / ")" / "," 6147 rtsp-extra = "!" / "*" / "'" / "(" / ")" 6149 HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 6150 / "a" / "b" / "c" / "d" / "e" / "f" 6151 LHEX = DIGIT / %x61-66 ;lowercase a-f 6152 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" 6154 unreserved = ALPHA / DIGIT / safe / extra 6155 rtsp-unreserved = ALPHA / DIGIT / safe / rtsp-extra 6157 base64 = *base64-unit [base64-pad] 6158 base64-unit = 4base64-char 6159 base64-pad = (2base64-char "==") / (3base64-char "=") 6160 base64-char = ALPHA / DIGIT / "+" / "/" 6161 SLASH = SWS "/" SWS ; slash 6162 EQUAL = SWS "=" SWS ; equal 6163 LPAREN = SWS "(" SWS ; left parenthesis 6164 RPAREN = SWS ")" SWS ; right parenthesis 6165 COMMA = SWS "," SWS ; comma 6166 SEMI = SWS ";" SWS ; semicolon 6167 COLON = SWS ":" SWS ; colon 6168 LDQUOT = SWS DQ ; open double quotation mark 6169 RDQUOT = DQ SWS ; close double quotation mark 6170 RAQUOT = ">" SWS ; right angle quote 6171 LAQUOT = SWS "<" ; left angle quote 6173 TEXT-UTF8char = %x21-7E / UTF8-NONASCII 6174 UTF8-NONASCII = %xC0-DF 1UTF8-CONT 6175 / %xE0-EF 2UTF8-CONT 6176 / %xF0-F7 3UTF8-CONT 6177 / %xF8-FB 4UTF8-CONT 6178 / %xFC-FD 5UTF8-CONT 6179 UTF8-CONT = %x80-BF 6181 21.2. RTSP Protocol Definition 6183 21.2.1. Generic Protocol elements 6184 RTSP-IRI = schemes ":" IRI-rest 6185 IRI-rest = ihier-part [ "?" iquery ] [ "#" ifragment ] 6186 ihier-part = "//" iauthority ipath-abempty 6187 RTSP-IRI-ref = RTSP-IRI / irelative-ref 6188 irelative-ref = irelative-part [ "?" iquery ] [ "#" ifragment ] 6189 irelative-part = "//" iauthority ipath-abempty 6190 / ipath-absolute 6191 / ipath-noscheme 6192 / ipath-empty 6194 iauthority = < As defined in RFC 3987> 6195 ipath = ipath-abempty ; begins with "/" or is empty 6196 / ipath-absolute ; begins with "/" but not "//" 6197 / ipath-noscheme ; begins with a non-colon segment 6198 / ipath-rootless ; begins with a segment 6199 / ipath-empty ; zero characters 6201 ipath-abempty = *( "/" isegment ) 6202 ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ] 6203 ipath-noscheme = isegment-nz-nc *( "/" isegment ) 6204 ipath-rootless = isegment-nz *( "/" isegment ) 6205 ipath-empty = 0 6207 isegment = *ipchar [";" *ipchar] 6208 isegment-nz = 1*ipchar [";" *ipchar] 6209 / ";" *ipchar 6210 isegment-nz-nc = (1*ipchar-nc [";" *ipchar-nc]) 6211 / ";" *ipchar-nc 6212 ; non-zero-length segment without any colon ":" 6214 ipchar = iunreserved / pct-encoded / sub-delims / ":" / "@" 6215 ipchar-nc = iunreserved / pct-encoded / sub-delims / "@" 6217 iquery = < As defined in RFC 3987> 6218 ifragment = < As defined in RFC 3987> 6219 iunreserved = < As defined in RFC 3987> 6220 pct-encoded = < As defined in RFC 3987> 6221 RTSP-URI = schemes ":" URI-rest 6222 RTSP-URI-Ref = RTSP-URI / RTSP-Relative 6223 schemes = "rtsp" / "rtsps" / scheme 6224 scheme = < As defined in RFC 3986> 6225 URI-rest = hier-part [ "?" query ] 6226 hier-part = "//" authority path-abempty 6228 RTSP-Relative = relative-part [ "?" query ] 6229 relative-part = "//" authority path-abempty 6230 / path-absolute 6231 / path-noscheme 6232 / path-empty 6234 authority = < As defined in RFC 3986> 6235 query = < As defined in RFC 3986> 6237 path = path-abempty ; begins with "/" or is empty 6238 / path-absolute ; begins with "/" but not "//" 6239 / path-noscheme ; begins with a non-colon segment 6240 / path-rootless ; begins with a segment 6241 / path-empty ; zero characters 6243 path-abempty = *( "/" segment ) 6244 path-absolute = "/" [ segment-nz *( "/" segment ) ] 6245 path-noscheme = segment-nz-nc *( "/" segment ) 6246 path-rootless = segment-nz *( "/" segment ) 6247 path-empty = 0 6249 segment = *pchar [";" *pchar] 6250 segment-nz = ( 1*pchar [";" *pchar]) / (";" *pchar) 6251 segment-nz-nc = ( 1*pchar-nc [";" *pchar-nc]) / (";" *pchar-nc) 6252 ; non-zero-length segment without any colon ":" 6254 pchar = unreserved / pct-encoded / sub-delims / ":" / "@" 6255 pchar-nc = unreserved / pct-encoded / sub-delims / "@" 6257 sub-delims = "!" / "$" / "&" / "'" / "(" / ")" 6258 / "*" / "+" / "," / "=" 6260 smpte-range = smpte-type "=" smpte-range-spec 6261 ; See section 3.4 6262 smpte-range-spec = ( smpte-time "-" [ smpte-time ] ) 6263 / ( "-" smpte-time ) 6264 smpte-type = "smpte" / "smpte-30-drop" 6265 / "smpte-25" / smpte-type-extension 6266 ; other timecodes may be added 6267 smpte-type-extension = token 6268 smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT 6269 [ ":" 1*2DIGIT [ "." 1*2DIGIT ] ] 6271 npt-range = "npt=" npt-range-spec 6272 npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time ) 6273 npt-time = "now" / npt-sec / npt-hhmmss 6274 npt-sec = 1*DIGIT [ "." *DIGIT ] 6275 npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] 6276 npt-hh = 1*DIGIT ; any positive number 6277 npt-mm = 1*2DIGIT ; 0-59 6278 npt-ss = 1*2DIGIT ; 0-59 6280 utc-range = "clock=" utc-range-spec 6281 utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time ) 6282 utc-time = utc-date "T" utc-clock "Z" 6283 utc-date = 8DIGIT 6284 utc-clock = 6DIGIT [ "." fraction ] 6285 fraction = 1*DIGIT 6287 feature-tag = token 6289 session-id = 1*256( ALPHA / DIGIT / safe ) 6291 extension-header = header-name HCOLON header-value 6292 header-name = token 6293 header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) 6295 21.2.2. Message Syntax 6296 RTSP-message = Request / Response ;RTSP/2.0 messages 6298 Request = Request-Line 6299 *(general-header 6300 / request-header 6301 / entity-header ) 6302 CRLF 6303 [ message-body ] 6305 Response = Status-Line 6306 *( general-header 6307 / response-header 6308 / entity-header ) 6309 CRLF 6310 [ message-body ] 6312 Request-Line = Method SP Request-URI SP RTSP-Version CRLF 6314 Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF 6316 Method = "DESCRIBE" 6317 / "GET_PARAMETER" 6318 / "OPTIONS" 6319 / "PAUSE" 6320 / "PLAY" 6321 / "REDIRECT" 6322 / "SETUP" 6323 / "SET_PARAMETER" 6324 / "TEARDOWN" 6325 / extension-method 6327 extension-method = token 6329 Request-URI = "*" / RTSP-URI 6330 RTSP-Version = "RTSP/" 1*DIGIT "." 1*DIGIT 6332 message-body = 1*OCTET 6334 Status-Code = "100" ; Continue 6335 / "200" ; OK 6336 / "300" ; Multiple Choices 6337 / "301" ; Moved Permanently 6338 / "302" ; Found 6339 / "303" ; See Other 6340 / "304" ; Not Modified 6341 / "305" ; Use Proxy 6342 / "400" ; Bad Request 6343 / "401" ; Unauthorized 6344 / "402" ; Payment Required 6345 / "403" ; Forbidden 6346 / "404" ; Not Found 6347 / "405" ; Method Not Allowed 6348 / "406" ; Not Acceptable 6349 / "407" ; Proxy Authentication Required 6350 / "408" ; Request Time-out 6351 / "410" ; Gone 6352 / "411" ; Length Required 6353 / "412" ; Precondition Failed 6354 / "413" ; Request Entity Too Large 6355 / "414" ; Request-URI Too Large 6356 / "415" ; Unsupported Media Type 6357 / "451" ; Parameter Not Understood 6358 / "452" ; reserved 6359 / "453" ; Not Enough Bandwidth 6360 / "454" ; Session Not Found 6361 / "455" ; Method Not Valid in This State 6362 / "456" ; Header Field Not Valid for Resource 6363 / "457" ; Invalid Range 6364 / "458" ; Parameter Is Read-Only 6365 / "459" ; Aggregate operation not allowed 6366 / "460" ; Only aggregate operation allowed 6367 / "461" ; Unsupported Transport 6368 / "462" ; Destination Unreachable 6369 / "463" ; Destination Prohibited 6370 / "464" ; Data Transport Not Ready Yet 6371 / "470" ; Connection Authorization Required 6372 / "471" ; Connection Credentials not accepted 6373 / "472" ; Failure to establish secure connection 6374 / "500" ; Internal Server Error 6375 / "501" ; Not Implemented 6376 / "502" ; Bad Gateway 6377 / "503" ; Service Unavailable 6378 / "504" ; Gateway Time-out 6379 / "505" ; RTSP Version not supported 6380 / "551" ; Option not supported 6381 / extension-code 6383 extension-code = 3DIGIT 6385 Reason-Phrase = *TEXT 6386 general-header = Cache-Control 6387 / Connection 6388 / CSeq 6389 / Date 6390 / Pipelined-Requests 6391 / Proxy-Supported 6392 / Supported 6393 / Timestamp 6394 / Via 6395 / extension-header 6397 request-header = Accept 6398 / Accept-Credentials 6399 / Accept-Encoding 6400 / Accept-Language 6401 / Authorization 6402 / Bandwidth 6403 / Blocksize 6404 / From 6405 / If-Match 6406 / If-Modified-Since 6407 / If-None-Match 6408 / Proxy-Require 6409 / Range 6410 / Referer 6411 / Require 6412 / Scale 6413 / Session 6414 / Speed 6415 / Supported 6416 / Transport 6417 / User-Agent 6418 / extension-header 6420 response-header = Accept-Credentials 6421 / Accept-Ranges 6422 / Connection-Credentials 6423 / ETag 6424 / Location 6425 / Proxy-Authenticate 6426 / Public 6427 / Range 6428 / Retry-After 6429 / RTP-Info 6430 / Scale 6431 / Session 6432 / Server 6433 / Speed 6434 / Transport 6435 / Unsupported 6436 / Vary 6437 / WWW-Authenticate 6438 / extension-header 6440 entity-header = Allow 6441 / Content-Base 6442 / Content-Encoding 6443 / Content-Language 6444 / Content-Length 6445 / Content-Location 6446 / Content-Type 6447 / Expires 6448 / Last-Modified 6449 / extension-header 6451 21.2.3. Header Syntax 6453 All header syntaxes not defined in this section are defined in 6454 section 14 of the HTTP 1.1 specification [RFC2616]. 6456 Accept = "Accept" HCOLON 6457 [ accept-range *(COMMA accept-range) ] 6458 accept-range = media-range *(SEMI accept-param) 6459 media-range = ( "*/*" 6460 / ( m-type SLASH "*" ) 6461 / ( m-type SLASH m-subtype ) 6462 ) *( SEMI m-parameter ) 6463 accept-param = ("q" EQUAL qvalue) / generic-param 6464 qvalue = ( "0" [ "." *3DIGIT ] ) 6465 / ( "1" [ "." *3("0") ] ) 6466 Accept-Credentials = "Accept-Credentials" HCOLON cred-decision CRLF 6467 cred-decision = ("User" [LWS cred-info]) 6468 / "Proxy" 6469 / "Any" 6470 / token [LWS 1*TEXT] ; For future extensions 6471 cred-info = cred-info-data *(COMMA cred-info-data) 6473 cred-info-data = DQ RTSP-URI DQ SEMI hash-alg SEMI base64 6474 hash-alg = "sha-256" / extension-alg 6475 extension-alg = token 6476 Accept-Encoding = "Accept-Encoding" HCOLON 6477 [ encoding *(COMMA encoding) ] 6478 encoding = codings *(SEMI accept-param) 6479 codings = content-coding / "*" 6480 content-coding = token 6481 Accept-Language = "Accept-Language" HCOLON 6482 [ language *(COMMA language) ] 6483 language = language-range *(SEMI accept-param) 6484 language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" ) 6485 Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges CRLF 6486 acceptable-ranges = (range-unit *(COMMA range-unit)) 6487 / "none" 6488 range-unit = "NPT" / "SMPTE" / "UTC" / extension-format 6489 extension-format = token 6490 Allow = "Allow" HCOLON [Method *(COMMA Method)] 6492 Authorization = "Authorization" HCOLON credentials 6493 credentials = ("Digest" LWS digest-response) 6494 / other-response 6495 digest-response = dig-resp *(COMMA dig-resp) 6496 dig-resp = username / realm / nonce / digest-uri 6497 / dresponse / algorithm / cnonce 6498 / opaque / message-qop 6499 / nonce-count / auth-param 6500 username = "username" EQUAL username-value 6501 username-value = quoted-string 6502 digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT 6503 digest-uri-value = Request-URI 6504 ; by HTTP/1.1 6505 message-qop = "qop" EQUAL qop-value 6506 cnonce = "cnonce" EQUAL cnonce-value 6507 cnonce-value = nonce-value 6508 nonce-count = "nc" EQUAL nc-value 6509 nc-value = 8LHEX 6510 dresponse = "response" EQUAL request-digest 6511 request-digest = LDQUOT 32LHEX RDQUOT 6512 auth-param = auth-param-name EQUAL 6513 ( token / quoted-string ) 6514 auth-param-name = token 6515 other-response = auth-scheme LWS auth-param 6516 *(COMMA auth-param) 6517 auth-scheme = token 6519 Bandwidth = "Bandwidth" HCOLON 1*DIGIT CRLF 6521 Blocksize = "Blocksize" HCOLON 1*DIGIT CRLF 6523 Cache-Control = "Cache-Control" HCOLON cache-directive CRLF 6524 *(COMMA cache-directive) 6525 cache-directive = cache-rqst-directive 6526 / cache-rspns-directive 6528 cache-rqst-directive = "no-cache" 6529 / "max-stale" [EQUAL delta-seconds] 6530 / "min-fresh" EQUAL delta-seconds 6531 / "only-if-cached" 6532 / cache-extension 6534 cache-rspns-directive = "public" 6535 / "private" 6536 / "no-cache" 6537 / "no-transform" 6538 / "must-revalidate" 6539 / "proxy-revalidate" 6540 / "max-age" EQUAL delta-seconds 6541 / cache-extension 6543 cache-extension = token [EQUAL (token / quoted-string)] 6544 delta-seconds = 1*DIGIT 6546 Connection-Credentials = "Connection-Credentials" HCOLON cred-chain CRLF 6548 cred-chain = DQ RTSP-URI DQ SEMI base64 6550 Connection = "Connection" HCOLON (connection-token) 6551 *(COMMA connection-token) CRLF 6552 connection-token = token 6554 Content-Base = "Content-Base" HCOLON RTSP-URI-Ref CRLF 6555 Content-Encoding = "Content-Encoding" HCOLON 6556 content-coding *(COMMA content-coding) 6557 Content-Language = "Content-Language" HCOLON 6558 language-tag *(COMMA language-tag) 6559 language-tag = primary-tag *( "-" subtag ) 6560 primary-tag = 1*8ALPHA 6561 subtag = 1*8ALPHA 6562 Content-Length = "Content-Length" HCOLON 1*DIGIT 6563 Content-Location = "Content-Location" HCOLON RTSP-URI-Ref 6564 Content-Type = ( "Content-Type" / "c" ) HCOLON media-type 6565 media-type = m-type SLASH m-subtype *(SEMI m-parameter) 6566 m-type = discrete-type / composite-type 6567 discrete-type = "text" / "image" / "audio" / "video" 6568 / "application" / extension-token 6569 composite-type = "message" / "multipart" / extension-token 6570 extension-token = ietf-token / x-token 6571 ietf-token = token 6572 x-token = "x-" token 6573 m-subtype = extension-token / iana-token 6574 iana-token = token 6575 m-parameter = m-attribute EQUAL m-value 6576 m-attribute = token 6577 m-value = token / quoted-string 6579 CSeq = "Cseq" HCOLON 1*DIGIT CRLF 6580 Date = "Date" HCOLON RTSP-date 6581 RTSP-date = rfc1123-date ; HTTP-date 6582 rfc1123-date = wkday "," SP date1 SP time SP "GMT" 6583 date1 = 2DIGIT SP month SP 4DIGIT 6584 ; day month year (e.g., 02 Jun 1982) 6585 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 6586 ; 00:00:00 - 23:59:59 6587 wkday = "Mon" / "Tue" / "Wed" 6588 / "Thu" / "Fri" / "Sat" / "Sun" 6589 month = "Jan" / "Feb" / "Mar" / "Apr" 6590 / "May" / "Jun" / "Jul" / "Aug" 6591 / "Sep" / "Oct" / "Nov" / "Dec" 6593 ETag = "ETag" HCOLON entity-tag 6594 Expires = "Expires" HCOLON delta-seconds 6595 From = "From" HCOLON from-spec 6596 from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) 6597 name-addr = [ display-name ] LAQUOT addr-spec RAQUOT 6598 addr-spec = RTSP-URI / absolute-URI 6599 absolute-URI = < As defined in RFC 3986> 6600 display-name = *(token LWS)/ quoted-string 6601 from-param = tag-param / generic-param 6602 tag-param = "tag" EQUAL token 6603 If-Match = "If-Match" HCOLON ( "*" / entity-tag-list) 6604 entity-tag-list = entity-tag *(COMMA entity-tag) 6605 entity-tag = [ weak ] opaque-tag 6606 weak = "W/" 6607 opaque-tag = quoted-string 6608 If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date 6609 If-None-Match = "If-None-Match" HCOLON ("*" / entity-tag-list) 6610 Last-Modified = "Last-Modified" HCOLON RTSP-date 6611 Location = "Location" HCOLON RTSP-URI 6612 Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id 6613 startup-id = 1*8DIGIT 6615 Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge 6616 challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) 6617 / other-challenge 6618 other-challenge = auth-scheme LWS auth-param 6619 *(COMMA auth-param) 6620 digest-cln = realm / domain / nonce 6621 / opaque / stale / algorithm 6622 / qop-options / auth-param 6623 realm = "realm" EQUAL realm-value 6624 realm-value = quoted-string 6625 domain = "domain" EQUAL LDQUOT URI 6626 *( 1*SP URI ) RDQUOT 6627 URI = RTSP-URI / RTSP-URI-Ref 6628 nonce = "nonce" EQUAL nonce-value 6629 nonce-value = quoted-string 6630 opaque = "opaque" EQUAL quoted-string 6631 stale = "stale" EQUAL ( "true" / "false" ) 6632 algorithm = "algorithm" EQUAL ("MD5" / "MD5-sess" / token) 6633 qop-options = "qop" EQUAL LDQUOT qop-value 6634 *("," qop-value) RDQUOT 6635 qop-value = "auth" / "auth-int" / token 6636 Proxy-Require = "Proxy-Require" HCOLON feature-tag CRLF 6637 *(COMMA feature-tag) 6639 Proxy-Supported = "Proxy-Supported" HCOLON feature-tag 6640 *(COMMA feature-tag) CRLF 6642 Public = "Public" HCOLON Method *(COMMA Method) CRLF 6644 Range = "Range" HCOLON ranges-list [exec-time] CRLF 6645 ranges-list = ranges-spec *(COMMA ranges-spec) 6646 exec-time = SEMI "time" EQUAL utc-time 6647 ranges-spec = npt-range / utc-range / smpte-range 6648 / range-ext 6649 range-ext = extension-format "=" range-value 6650 range-value = 1*(rtsp-unreserved / quoted-string / ":" ) 6652 Referer = "Referer" HCOLON RTSP-URI-Ref 6653 Require = "Require" HCOLON feature-tag-list CRLF 6654 feature-tag-list = feature-tag *(COMMA feature-tag) 6655 RTP-Info = "RTP-Info" HCOLON rtsp-info-spec 6656 *(COMMA rtsp-info-spec) CRLF 6657 rtsp-info-spec = stream-url 1*ssrc-parameter 6658 stream-url = "url" EQUAL DQ RTSP-URI-Ref DQ 6659 ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON 6660 ri-parameter *(SEMI ri-parameter) 6661 ri-parameter = "seq" EQUAL 1*DIGIT 6662 / "rtptime" EQUAL 1*DIGIT 6664 Retry-After = "Retry-After" HCOLON delta-seconds 6665 [ comment ] *( SEMI retry-param ) 6666 retry-param = ("duration" EQUAL delta-seconds) 6667 / generic-param 6669 Scale = "Scale" HCOLON ["-"] 1*DIGIT [ "." *DIGIT ] CRLF 6671 Speed = "Speed" HCOLON 1*DIGIT [ "." *DIGIT ] CRLF 6673 Server = "Server" HCOLON ( product / comment ) 6674 *(LWS (product / comment)) CRLF 6675 product = token [SLASH product-version] 6676 product-version = token 6677 comment = LPAREN *( ctext / quoted-pair) RPAREN 6679 Session = "Session" HCOLON session-id 6680 [ SEMI "timeout" EQUAL delta-seconds ] CRLF 6682 Supported = "Supported" HCOLON [feature-tag-list] CRLF 6684 Timestamp = "Timestamp" HCOLON timestamp-value LWS [delay] 6685 timestamp-value = *DIGIT [ "." *DIGIT ] 6686 delay = *DIGIT [ "." *DIGIT ] 6688 Transport = "Transport" HCOLON transport-spec 6689 *(COMMA transport-spec) CRLF 6690 transport-spec = transport-id *tr-parameter 6691 transport-id = trans-id-rtp / other-trans 6692 trans-id-rtp = "RTP/" profile ["/" lower-transport] 6693 ; no LWS is allowed inside transport-id 6694 other-trans = token *("/" token) 6696 profile = "AVP" / "SAVP" / "AVPF" / token 6697 lower-transport = "TCP" / "UDP" / token 6698 tr-parameter = SEMI ( "unicast" / "multicast" ) 6699 / SEMI "interleaved" EQUAL channel [ "-" channel ] 6700 / SEMI "append" 6701 / SEMI "ttl" EQUAL ttl 6702 / SEMI "layers" EQUAL 1*DIGIT 6703 / SEMI "ssrc" EQUAL ssrc *(SLASH ssrc) 6704 / SEMI "client_ssrc" EQUAL ssrc 6705 / SEMI "mode" EQUAL mode-spec 6706 / SEMI "dest_addr" EQUAL addr-list 6707 / SEMI "src_addr" EQUAL addr-list 6708 / SEMI trn-param-ext 6709 / SEMI "setup" EQUAL contrans-setup 6710 / SEMI "connection" EQUAL contrans-con 6711 contrans-setup = "active" / "passive" / "actpass" 6712 contrans-con = "new" / "existing" 6713 trn-param-ext = par-name EQUAL trn-par-value 6714 par-name = token 6715 trn-par-value = *(rtsp-unreserved / DQ *TEXT DQ) 6716 ttl = 1*3DIGIT ; 0 to 255 6717 ssrc = 8HEX 6718 channel = 1*3DIGIT 6719 mode-spec = ( DQ mode *(COMMA mode) DQ ) 6720 mode = "PLAY" / token 6721 addr-list = quoted-addr *(SLASH quoted-addr) 6722 quoted-addr = DQ (host-port / extension-addr) DQ 6723 host-port = host [":" port] 6724 / ":" port 6725 extension-addr = 1*qdtext 6726 host = < As defined in RFC 3986> 6727 port = < As defined in RFC 3986> 6728 Unsupported = "Unsupported" HCOLON feature-tag-list CRLF 6730 User-Agent = "User-Agent" HCOLON ( product / comment ) 6731 0*(LWS (product / comment)) CRLF 6733 Vary = "Vary" HCOLON ( "*" / field-name-list) 6734 field-name-list = field-name *(COMMA field-name) 6735 field-name = token 6736 Via = "Via" HCOLON via-parm *(COMMA via-parm) 6737 via-parm = sent-protocol LWS sent-by *( SEMI via-params ) 6738 via-params = via-ttl / via-maddr 6739 / via-received / via-branch 6740 / via-extension 6741 via-ttl = "ttl" EQUAL ttl 6742 via-maddr = "maddr" EQUAL host 6743 via-received = "received" EQUAL (IPv4address / IPv6address) 6744 IPv4address = < As defined in RFC 3986> 6745 IPv6address = < As defined in RFC 3986> 6746 via-branch = "branch" EQUAL token 6747 via-extension = generic-param 6748 sent-protocol = protocol-name SLASH protocol-version 6749 SLASH transport-prot 6750 protocol-name = "RTSP" / token 6751 protocol-version = token 6752 transport-prot = "UDP" / "TCP" / "TLS" / other-transport 6753 other-transport = token 6754 sent-by = host [ COLON port ] 6756 WWW-Authenticate = "WWW-Authenticate" HCOLON challenge 6758 21.3. SDP extension Syntax 6760 This section defines in ABNF the SDP extensions defined for RTSP. 6761 See Appendix C for the definition of the extensions in text. 6763 control-attribute = "a=control:" *SP RTSP-URI 6765 a-range-def = "a=range:" ranges-spec CRLF 6767 a-etag-def = "a=etag:" entity-tag CRLF 6769 22. Security Considerations 6771 Because of the similarity in syntax and usage between RTSP servers 6772 and HTTP servers, the security considerations outlined in [H15] 6773 apply. Specifically, please note the following: 6775 Abuse of Server Log Information: RTSP and HTTP servers will 6776 presumably have similar logging mechanisms, and thus should be 6777 equally guarded in protecting the contents of those logs, thus 6778 protecting the privacy of the users of the servers. See 6779 [H15.1.1] for HTTP server recommendations regarding server 6780 logs. 6782 Transfer of Sensitive Information: There is no reason to believe 6783 that information transferred or controlled via RTSP may be any 6784 less sensitive than that normally transmitted via HTTP. 6785 Therefore, all of the precautions regarding the protection of 6786 data privacy and user privacy apply to implementors of RTSP 6787 clients, servers, and proxies. See [H15.1.2] for further 6788 details. 6790 Attacks Based On File and Path Names: Though RTSP URIs are opaque 6791 handles that do not necessarily have file system semantics, it 6792 is anticipated that many implementations will translate 6793 portions of the Request-URIs directly to file system calls. In 6794 such cases, file systems SHOULD follow the precautions outlined 6795 in [H15.5], such as checking for ".." in path components. 6797 Personal Information: RTSP clients are often privy to the same 6798 information that HTTP clients are (user name, location, etc.) 6799 and thus should be equally sensitive. See [H15.1] for further 6800 recommendations. 6802 Privacy Issues Connected to Accept Headers: Since may of the same 6803 "Accept" headers exist in RTSP as in HTTP, the same caveats 6804 outlined in [H15.1.4] with regards to their use should be 6805 followed. 6807 DNS Spoofing: Presumably, given the longer connection times 6808 typically associated to RTSP sessions relative to HTTP 6809 sessions, RTSP client DNS optimizations should be less 6810 prevalent. Nonetheless, the recommendations provided in 6811 [H15.3] are still relevant to any implementation which attempts 6812 to rely on a DNS-to-IP mapping to hold beyond a single use of 6813 the mapping. 6815 Location Headers and Spoofing: If a single server supports multiple 6816 organizations that do not trust each another, then it needs to 6817 check the values of Location and Content-Location header fields 6818 in responses that are generated under control of said 6819 organizations to make sure that they do not attempt to 6820 invalidate resources over which they have no authority. 6821 ([H15.4]) 6823 In addition to the recommendations in the current HTTP specification 6824 (RFC 2616 [RFC2616], as of this writing) and also of the previous 6825 RFC2068 [RFC2068], future HTTP specifications may provide additional 6826 guidance on security issues. 6828 The following are added considerations for RTSP implementations. 6830 Concentrated denial-of-service attack: The protocol offers the 6831 opportunity for a remote-controlled denial-of-service attack. 6832 See Section 22.1. 6834 Session hijacking: Since there is no or little relation between a 6835 transport layer connection and an RTSP session, it is possible 6836 for a malicious client to issue requests with random session 6837 identifiers which would affect unsuspecting clients. The 6838 server SHOULD use a large, random and non-sequential session 6839 identifier to minimize the possibility of this kind of attack. 6840 However, unless the RTSP signalling always are confedentiality 6841 protected, e.g. using TLS, an on-path attacker will be able to 6842 hijack a session. For real session security, client 6843 authentication needs to be performed. 6845 Authentication: Servers SHOULD implement both basic and digest 6846 [RFC2617] authentication. In environments requiring tighter 6847 security for the control messages, the transport layer 6848 mechanism TLS (RFC 4346 [RFC4346]) SHOULD be used. 6850 Stream issues: RTSP only provides for stream control. Stream 6851 delivery issues are not covered in this section, nor in the 6852 rest of this draft. RTSP implementations will most likely rely 6853 on other protocols such as RTP, IP multicast, RSVP and IGMP, 6854 and should address security considerations brought up in those 6855 and other applicable specifications. 6857 Persistently suspicious behavior: RTSP servers SHOULD return error 6858 code 403 (Forbidden) upon receiving a single instance of 6859 behavior which is deemed a security risk. RTSP servers SHOULD 6860 also be aware of attempts to probe the server for weaknesses 6861 and entry points and MAY arbitrarily disconnect and ignore 6862 further requests clients which are deemed to be in violation of 6863 local security policy. 6865 Scope of Multicast: If RTSP is used to control the transmission of 6866 media onto a multicast network it is need to consider the scope 6867 that delivery has. RTSP supports the TTL Transport header 6868 parameter to indicate this scope. However such scope control 6869 is risk as it may be set to large and distribute media beyond 6870 the intended scope. 6872 TLS through proxies: If one uses the possibility to connect TLS in 6873 multiple legs (Section 20.3 one really needs to be aware of the 6874 trust model. That procedure requires full faith and trust in 6875 all proxies that one allows to connect through. They are man 6876 in the middle and has access to all that goes on over the TLS 6877 connection. Thus it is important to consider if that trust 6878 model is acceptable in the actual application. 6880 22.1. Remote denial of Service Attack 6882 The attacker may initiate traffic flows to one or more IP addresses 6883 by specifying them as the destination in SETUP requests. While the 6884 attacker's IP address may be known in this case, this is not always 6885 useful in prevention of more attacks or ascertaining the attackers 6886 identity. Thus, an RTSP server MUST only allow client-specified 6887 destinations for RTSP-initiated traffic flows if the server has 6888 ensured that the specified destination address accepts receiving 6889 media through different security mechanisms. Security mechanism that 6890 are acceptable in an increased generality are; verification of the 6891 client's identity, either against a database of known users using 6892 RTSP authentication mechanisms (preferably digest authentication or 6893 stronger); a list of addresses that accept to be media destinations, 6894 especially considering user identity; and media path based 6895 verification. 6897 The server SHOULD NOT allow the destination field to be set unless a 6898 mechanism exists in the system to authorize the request originator to 6899 direct streams to the recipient. It is preferred that this 6900 authorization be performed by the media recipient (destination) 6901 itself and the credentials passed along to the server. However, in 6902 certain cases, such as when recipient address is a multicast group, 6903 or when the recipient is unable to communicate with the server in an 6904 out-of-band manner, this may not be possible. In these cases server 6905 may chose another method such as a server-resident authorization list 6906 to ensure that the request originator has the proper credentials to 6907 request stream delivery to the recipient. 6909 One solution that performs the necessary verification of acceptance 6910 of media suitable for unicast based delivery is the ICE based NAT 6911 traversal method described in [I-D.ietf-mmusic-rtsp-nat]. By using 6912 random passwords and username the probability of unintended 6913 indication as a valid media destination is very low. If the server 6914 include in its STUN requests a cookie (consisting of random material) 6915 that is the destination echo back the solution is also safe against 6916 having a off-path attacker being able to spoof the STUN checks. 6917 Leaving this solution vulnerable only to on-path attackers that can 6918 see the STUN requests go to the target of attack. 6920 For delivery to multicast addresses there is need for another 6921 solution which is not specified here. 6923 23. IANA Considerations 6925 This section sets up a number of registries for RTSP 2.0 that should 6926 be maintained by IANA. For each registry there is a description on 6927 what it is required to contain, what specification is needed when 6928 adding a entry with IANA, and finally the entries that this document 6929 needs to register. See also the Section 2.2 "Extending RTSP". There 6930 is also an IANA registration of two SDP attributes. 6932 The sections describing how to register an item uses some of the 6933 requirements level described in RFC 2434 [RFC2434], namely "First 6934 Come, First Served", "Specification Required", and "Standards 6935 Action". 6937 A registration request to IANA MUST contain the following 6938 information: 6940 o A name of the item to register according to the rules specified by 6941 the intended registry. 6943 o Indication of who has change control over the feature (for 6944 example, IETF, ISO, ITU-T, other international standardization 6945 bodies, a consortium, a particular company or group of companies, 6946 or an individual); 6948 o A reference to a further description, if available, for example 6949 (in order of preference) an RFC, a published standard, a published 6950 paper, a patent filing, a technical report, documented source code 6951 or a computer manual; 6953 o For proprietary features, contact information (postal and email 6954 address); 6956 23.1. Feature-tags 6958 23.1.1. Description 6960 When a client and server try to determine what part and functionality 6961 of the RTSP specification and any future extensions that its counter 6962 part implements there is need for a namespace. This registry 6963 contains named entries representing certain functionality. 6965 The usage of feature-tags is explained in Section 11 and 6966 Section 13.1. 6968 23.1.2. Registering New Feature-tags with IANA 6970 The registering of feature-tags is done on a first come, first served 6971 basis. 6973 The name of the feature MUST follow these rules: The name may be of 6974 any length, but SHOULD be no more than twenty characters long. The 6975 name MUST NOT contain any spaces, or control characters. The 6976 registration SHALL indicate if the feature-tag applies to clients, 6977 servers, or proxies only or any combinations of these. Any 6978 proprietary feature SHALL have as the first part of the name a vendor 6979 tag, which identifies the organization. 6981 23.1.3. Registered entries 6983 The following feature-tags are in this specification defined and 6984 hereby registered. The change control belongs to the IETF. 6986 play.basic: The minimal implementation for playback operations 6987 according to Appendix D. Applies for both clients, servers and 6988 proxies. 6990 play.scale: Support of scale operations for media playback. Applies 6991 only for servers. 6993 play.speed: Support of the speed functionality for playback. 6994 Applies only for servers. 6996 23.2. RTSP Methods 6998 23.2.1. Description 7000 What a method is, is described in section Section 13. Extending the 7001 protocol with new methods allow for totally new functionality. 7003 23.2.2. Registering New Methods with IANA 7005 A new method MUST be registered through an IETF standard track 7006 document. The reason is that new methods may radically change the 7007 protocols behavior and purpose. 7009 A specification for a new RTSP method MUST consist of the following 7010 items: 7012 o A method name which follows the ABNF rules for methods. 7014 o A clear specification on what action and response a request with 7015 the method will result in. Which directions the method is used, 7016 C->S or S->C or both. How the use of headers, if any, modifies 7017 the behavior and effect of the method. 7019 o A list or table specifying which of the registered headers that 7020 are allowed to use with the method in request or/and response. 7022 o Describe how the method relates to network proxies. 7024 23.2.3. Registered Entries 7026 This specification, RFCXXXX, registers 9 methods: DESCRIBE, 7027 GET_PARAMETER, OPTIONS, PAUSE, PLAY, REDIRECT, SETUP, SETPARAMETER, 7028 and TEARDOWN. 7030 23.3. RTSP Status Codes 7032 23.3.1. Description 7034 A status code is the three digit numbers used to convey information 7035 in RTSP response messages, seeSection 8. The number space is limited 7036 and care should be taken not to fill the space. 7038 23.3.2. Registering New Status Codes with IANA 7040 A new status code can only be registered by an IETF standards track 7041 document. A specification for a new status code MUST specify the 7042 following: 7044 o The requested number. 7046 o A description what the status code means and the expected behavior 7047 of the sender and receiver of the code. 7049 23.3.3. Registered Entries 7051 RFCXXX, registers the numbered status code defined in the ABNF entry 7052 "Status-Code" except "extension-code" in Section 21.2.2. 7054 23.4. RTSP Headers 7056 23.4.1. Description 7058 By specifying new headers a method(s) can be enhanced in many 7059 different ways. An unknown header will be ignored by the receiving 7060 entity. If the new header is vital for a certain functionality, a 7061 feature-tag for the functionality can be created and demanded to be 7062 used by the counter-part with the inclusion of a Require header 7063 carrying the feature-tag. 7065 23.4.2. Registering New Headers with IANA 7067 A public available specification is required to register a header. 7068 The specification SHOULD be a standards document, preferable an IETF 7069 RFC. 7071 The specification MUST contain the following information: 7073 o The name of the header. 7075 o An ABNF specification of the header syntax. 7077 o A list or table specifying when the header may be used, 7078 encompassing all methods, their request or response, the direction 7079 (C->S or S->C). 7081 o How the header is to be handled by proxies. 7083 o A description of the purpose of the header. 7085 23.4.3. Registered entries 7087 All headers specified in Section 16 in RFCXXXX are to be registered. 7089 Furthermore the following RTSP headers defined in other 7090 specifications are registered: 7092 o x-wap-profile defined in [3gpp-26234]. 7094 o x-wap-profile-diff defined in [3gpp-26234]. 7096 o x-wap-profile-warning defined in [3gpp-26234]. 7098 o x-predecbufsize defined in [3gpp-26234]. 7100 o x-initpredecbufperiod defined in [3gpp-26234]. 7102 o x-initpostdecbufperiod defined in [3gpp-26234]. 7104 o 3gpp-videopostdecbufsize defined in [3gpp-26234]. 7106 o 3GPP-Link-Char defined in [3gpp-26234]. 7108 o 3GPP-Adaptation defined in [3gpp-26234]. 7110 o 3GPP-QoE-Metrics defined in [3gpp-26234]. 7112 o 3GPP-QoE-Feedback defined in [3gpp-26234]. 7114 The use of "X-" is NOT RECOMMENDED but the above headers in the 7115 register list was defined prior to the clarification. 7117 23.5. Transport Header Registries 7119 The transport header contains a number of parameters which have 7120 possibilities for future extensions. Therefore registries for these 7121 needs to be defined. 7123 23.5.1. Transport Protocol Specification 7125 A registry for the parameter transport-protocol specification SHALL 7126 be defined with the following rules: 7128 o Registering require an public available standards specification. 7130 o A contact person or organization with address and email. 7132 o A value definition that are following the ABNF syntax definition. 7134 o A describing text that explains how the registered value are used 7135 in RTSP. 7137 This specification registers the following values: 7139 RTP/AVP: Use of the RTP[RFC3550] protocol for media transport in 7140 combination with the "RTP profile for audio and video 7141 conferences with minimal control"[RFC3551] over UDP. The usage 7142 is explained in RFC XXXX, appendix Appendix B.1. 7144 RTP/AVP/UDP: the same as RTP/AVP. 7146 RTP/AVPF: Use of the RTP[RFC3550] protocol for media transport in 7147 combination with the "Extended RTP Profile for RTCP-based 7148 Feedback (RTP/AVPF)"[RFC4585] over UDP. The usage is explained 7149 in RFC XXXX, appendix Appendix B.1. 7151 RTP/AVPF/UDP: the same as RTP/AVPF. 7153 RTP/SAVP: Use of the RTP[RFC3550] protocol for media transport in 7154 combination with the "The Secure Real-time Transport Protocol 7155 (SRTP)" [RFC3711] over UDP. The usage is explained in RFC 7156 XXXX, appendix Appendix B.1. 7158 RTP/SAVP/UDP: the same as RTP/SAVP. 7160 RTP/SAVPF: Use of the RTP[RFC3550] protocol for media transport in 7161 combination with the "[I-D.ietf-avt-profile-savpf] over UDP. 7162 The usage is explained in RFC XXXX, appendix Appendix B.1. 7164 RTP/SAVPF/UDP: the same as RTP/SAVPF. 7166 RTP/AVP/TCP: Use of the RTP[RFC3550] protocol for media transport in 7167 combination with the "RTP profile for audio and video 7168 conferences with minimal control"[RFC3551] over TCP. The usage 7169 is explained in RFC XXXX, appendix Appendix B.2.2. 7171 RTP/AVPF/TCP: Use of the RTP[RFC3550] protocol for media transport 7172 in combination with the "Extended RTP Profile for RTCP-based 7173 Feedback (RTP/AVPF)"[RFC4585] over TCP. The usage is explained 7174 in RFC XXXX, appendix Appendix B.2.2. 7176 RTP/SAVP/TCP: Use of the RTP[RFC3550] protocol for media transport 7177 in combination with the "The Secure Real-time Transport 7178 Protocol (SRTP)" [RFC3711] over TCP. The usage is explained in 7179 RFC XXXX, appendix Appendix B.2.2. 7181 RTP/SAVPF/TCP: Use of the RTP[RFC3550] protocol for media transport 7182 in combination with the "[I-D.ietf-avt-profile-savpf] over TCP. 7183 The usage is explained in RFC XXXX, appendix Appendix B.2.2. 7185 23.5.2. Transport modes 7187 A registry for the transport parameter mode SHALL be defined with the 7188 following rules: 7190 o Registering requires an IETF standard tracks document. 7192 o A contact person or organization with address and email. 7194 o A value definition that are following the ABNF token definition. 7196 o A describing text that explains how the registered value are used 7197 in RTSP. 7199 This specification registers 1 value: 7201 PLAY: See RFC XXXX. 7203 23.5.3. Transport Parameters 7205 A registry for parameters that may be included in the Transport 7206 header SHALL be defined with the following rules: 7208 o Registering required a Open Standards document. 7210 o A value definition that are following the ABNF token definition. 7212 o A describing text that explains how the registered value are used 7213 in RTSP. 7215 This specification registers all the transport parameters defined in 7216 Section 16.46. 7218 23.6. Cache Directive Extensions 7220 There exist a number of cache directives which can be sent in the 7221 Cache-Control header. A registry for this cache directives SHALL be 7222 defined with the following rules: 7224 o Registering requires an IETF standard tracks document. 7226 o A registration is required to contain a contact person. 7228 o Name of the directive and a definition of the value, if any. 7230 o Specification if it is an request or response directive. 7232 o A describing text that explains how the cache directive is used 7233 for RTSP controlled media streams. 7235 This specification registers the following values: 7237 no-cache: 7239 public: 7241 private: 7243 no-transform: 7245 only-if-cached: 7247 max-stale: 7249 min-fresh: 7251 must-revalidate: 7253 proxy-revalidate: 7255 max-age: 7257 23.7. Accept-Credentials 7259 The security framework's TLS connection mechanism has two 7260 registerable entities. 7262 23.7.1. Accept-Credentials policies 7264 In Section 20.3.1 three policies for how to handle certificates. 7265 Further policies may be defined and SHALL be registered with IANA 7266 using the following rules: 7268 o Registering requires an IETF standard tracks document. 7270 o A registration is required name a contact person. 7272 o Name of the policy. 7274 o A describing text that explains how the policy works for handling 7275 the certificates. 7277 This specification registers the following values: 7279 Any 7281 Proxy 7283 User 7285 23.7.2. Accept-Credentials hash algorithms 7287 The Accept-Credentials header (See Section 16.2) allows for the usage 7288 of other algorithms for hashing the DER records of accepted entities. 7289 The registration of any future algorithm is expected to be extremely 7290 rare and could also be an interoperability problem. Therefore the 7291 XXX bare for registering new algorithms is placed intentional high. 7293 Any registration of a new hash algorithm SHALL meet the following 7294 requirement: 7296 o Registration requires an IETF standard track document. 7298 o A definition of the algorithm and its identifier meeting the 7299 "token" ABNF requirement. 7301 23.8. Range header formats 7303 The Range header allows for different range formats. New ones may be 7304 registered, but moderation should be applied as it makes 7305 interoperability more difficult. A registration SHALL fulfill the 7306 following requirements: 7308 o A publicly available standards document. 7310 o A ABNF definition of the range format that fulfils the "range-ext" 7311 definition. 7313 o A Contact person for the registration. 7315 o Rules for how one handles the range when using a negative Scale. 7317 23.9. URI Schemes 7319 This specification defines two URI schemes ("rtsp" and "rtsps") and 7320 reserves a third one ("rtspu"). Registrations are following RFC 7321 4395[RFC4395]. 7323 23.9.1. The rtsp URI Scheme 7325 URI scheme name: rtsp 7327 Status: Permanent 7329 URI scheme syntax: See Section 21.2.1 of RFC XXXX. 7331 URI scheme semantics: The rtsp scheme is used to indicate resources 7332 accessible through the usage of the Real-time Streaming 7333 Protocol (RTSP). RTSP allows different operations on the 7334 resource identified by the URI, but the primary purpose is the 7335 streaming delivery of the resource to a client. However the 7336 operations that are currently defined are: Describing the 7337 resource for the purpose of configuring the receiving entity 7338 (DESCRIBE), configuring the delivery method and its addressing 7339 (SETUP), controlling the delivery (PLAY and PAUSE), reading or 7340 setting of resource related parameters (SETPARAMETER and 7341 GET_PARAMETER, and termination of the session context created 7342 (TEARDOWN). 7344 Encoding considerations: IRIs in this scheme are defined and needs 7345 to be encoded as RTSP URIs when used within the RTSP protocol. 7346 That encoding is done according to RFC 3987 (XXX). 7348 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 7349 2326), RTSP 2.0 (RFC XXXX) 7351 Interoperability considerations: The change in URI syntax performed 7352 between RTSP 1.0 and 2.0 can create interoperability issues. 7354 Security considerations: All the security threats identified in 7355 Section 7 of RFC 3986 applies also to this scheme. They needs 7356 to be reviewed and considered in any implementation utilizing 7357 this scheme. 7359 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 7361 Author/Change controller: IETF MMUSIC WG 7363 References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX 7365 23.9.2. The rtsps URI Scheme 7367 URI scheme name: rtsps 7369 Status: Permanent 7371 URI scheme syntax: See Section 21.2.1 of RFC XXXX. 7373 URI scheme semantics: The rtsps scheme is used to indicate resources 7374 accessible through the usage of the Real-time Streaming 7375 Protocol (RTSP) over TLS. RTSP allows different operations on 7376 the resource identified by the URI, but the primary purpose is 7377 the streaming delivery of the resource to a client. However 7378 the operations that are currently defined are: Describing the 7379 resource for the purpose of configuring the receiving entity 7380 (DESCRIBE), configuring the delivery method and its addressing 7381 (SETUP), controlling the delivery (PLAY and PAUSE), reading or 7382 setting of resource related parameters (SETPARAMETER and 7383 GET_PARAMETER, and termination of the session context created 7384 (TEARDOWN). 7386 Encoding considerations: IRIs in this scheme are defined and needs 7387 to be encoded as RTSP URIs when used within the RTSP protocol. 7388 That encoding is done according to RFC 3987. 7390 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 7391 2326), RTSP 2.0 (RFC XXXX) 7393 Interoperability considerations: The change in URI syntax performed 7394 between RTSP 1.0 and 2.0 can create interoperability issues. 7396 Security considerations: All the security threats identified in 7397 Section 7 of RFC 3986 applies also to this scheme. They needs 7398 to be reviewed and considered in any implementation utilizing 7399 this scheme. 7401 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 7403 Author/Change controller: IETF MMUSIC WG 7405 References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX 7407 23.9.3. The rtspu URI Scheme 7409 URI scheme name: rtspu 7411 Status: Permanent 7413 URI scheme syntax: See Section 3.2 of RFC 2326. 7415 URI scheme semantics: The rtspu scheme is used to indicate resources 7416 accessible through the usage of the Real-time Streaming 7417 Protocol (RTSP) over unrelaible datagram transport. RTSP 7418 allows different operations on the resource identified by the 7419 URI, but the primary purpose is the streaming delivery of the 7420 resource to a client. However the operations that are 7421 currently defined are: Describing the resource for the purpose 7422 of configuring the receiving entity (DESCRIBE), configuring the 7423 delivery method and its addressing (SETUP), controlling the 7424 delivery (PLAY and PAUSE), reading or setting of resource 7425 related parameters (SETPARAMETER and GET_PARAMETER, and 7426 termination of the session context created (TEARDOWN). 7428 Encoding considerations: IRIs in this scheme are defined and needs 7429 to be encoded as RTSP URIs when used within the RTSP protocol. 7430 That encoding is done according to RFC 3987. 7432 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 7433 2326) 7435 Interoperability considerations: The definition of the transport 7436 mechanism of RTSP over UDP has interoperability issues. That 7437 makes the usage of this scheme problematic. 7439 Security considerations: All the security threats identified in 7440 Section 7 of RFC 3986 applies also to this scheme. They needs 7441 to be reviewed and considered in any implementation utilizing 7442 this scheme. 7444 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 7446 Author/Change controller: IETF MMUSIC WG 7448 References: RFC 2326, RFC 3986, RFC 3987 7450 23.10. SDP attributes 7452 This specification defines two SDP [RFC4566] attributes that it is 7453 requested that IANA register. 7455 SDP Attribute ("att-field"): 7457 Attribute name: range 7458 Long form: Media Range Attribute 7459 Type of name: att-field 7460 Type of attribute: Media and session level 7461 Subject to charset: No 7462 Purpose: RFC XXXX 7463 Reference: RFC XXXX 7464 Values: See ABNF definition. 7466 Attribute name: control 7467 Long form: RTSP control URI 7468 Type of name: att-field 7469 Type of attribute: Media and session level 7470 Subject to charset: No 7471 Purpose: RFC XXXX 7472 Reference: RFC XXXX 7473 Values: Absolute or Relative URIs. 7475 Attribute name: etag 7476 Long form: Entity Tag 7477 Type of name: att-field 7478 Type of attribute: Media and session level 7479 Subject to charset: No 7480 Purpose: RFC XXXX 7481 Reference: RFC XXXX 7482 Values: See ABNF definition 7484 24. References 7486 24.1. Normative References 7488 [3gpp-26234] 7489 Third Generation Partnership Project (3GPP), "Transparent 7490 end-to-end Packet-switched Streaming Service (PSS); 7491 Protocols and codecs; Technical Specification 26.234", 7492 December 2002. 7494 [FIPS-pub-180-2] 7495 National Institute of Standards and Technology (NIST), 7496 "Federal Information Processing Standards Publications 7497 (FIPS PUBS) 180-2: Secure Hash Standard", Augusti 2002. 7499 [I-D.ietf-avt-profile-savpf] 7500 Ott, J. and E. Carrara, "Extended Secure RTP Profile for 7501 RTCP-based Feedback (RTP/SAVPF)", 7502 draft-ietf-avt-profile-savpf-11 (work in progress), 7503 July 2007. 7505 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 7506 August 1980. 7508 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 7509 RFC 793, September 1981. 7511 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 7512 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 7513 RFC 2068, January 1997. 7515 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 7516 Requirement Levels", BCP 14, RFC 2119, March 1997. 7518 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 7519 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 7520 October 1998. 7522 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 7523 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 7524 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 7526 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 7527 Leach, P., Luotonen, A., and L. Stewart, "HTTP 7528 Authentication: Basic and Digest Access Authentication", 7529 RFC 2617, June 1999. 7531 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 7533 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 7534 X.509 Public Key Infrastructure Certificate and 7535 Certificate Revocation List (CRL) Profile", RFC 3280, 7536 April 2002. 7538 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 7539 (IPv6) Addressing Architecture", RFC 3513, April 2003. 7541 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 7542 Jacobson, "RTP: A Transport Protocol for Real-Time 7543 Applications", STD 64, RFC 3550, July 2003. 7545 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 7546 Video Conferences with Minimal Control", STD 65, RFC 3551, 7547 July 2003. 7549 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 7550 10646", STD 63, RFC 3629, November 2003. 7552 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 7553 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 7554 RFC 3711, March 2004. 7556 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 7557 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 7558 August 2004. 7560 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 7561 Resource Identifier (URI): Generic Syntax", STD 66, 7562 RFC 3986, January 2005. 7564 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 7565 Identifiers (IRIs)", RFC 3987, January 2005. 7567 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 7568 Requirements for Security", BCP 106, RFC 4086, June 2005. 7570 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 7571 Specifications: ABNF", RFC 4234, October 2005. 7573 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 7574 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 7576 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 7577 Registration Procedures for New URI Schemes", BCP 115, 7578 RFC 4395, February 2006. 7580 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 7581 Description Protocol", RFC 4566, July 2006. 7583 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 7584 Carrara, "Key Management Extensions for Session 7585 Description Protocol (SDP) and Real Time Streaming 7586 Protocol (RTSP)", RFC 4567, July 2006. 7588 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 7589 and RTP Control Protocol (RTCP) Packets over Connection- 7590 Oriented Transport", RFC 4571, July 2006. 7592 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 7593 "Extended RTP Profile for Real-time Transport Control 7594 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 7595 July 2006. 7597 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 7598 Encodings", RFC 4648, October 2006. 7600 24.2. Informative References 7602 [I-D.ietf-mmusic-rtsp-nat] 7603 Westerlund, M. and T. Zeng, "An Network Address Translator 7604 (NAT) Traversal mechanism for media controlled by Real- 7605 Time Streaming Protocol (RTSP)", 7606 draft-ietf-mmusic-rtsp-nat-05 (work in progress), 7607 July 2007. 7609 [ISO.13818-1.2000] 7610 International Organization for Standardization, 7611 "Information technology - Generic coding of moving 7612 pictures and associated audio information: Systems", ISO/ 7613 IEC 13818-1:2000, December 2000. 7615 [ISO.13818-6.1995] 7616 International Organization for Standardization, 7617 "Information technology - Generic coding of moving 7618 pictures and associated audio information - part 6: 7619 Extension for digital storage media and control", 7620 ISO Draft Standard 13818-6, November 1995. 7622 [ISO.8601.2000] 7623 International Organization for Standardization, "Data 7624 elements and interchange formats - Information interchange 7625 - Representation of dates and times", ISO/IEC Standard 7626 8601, December 2000. 7628 [ITU.H323.1996] 7629 International Telecommunications Union, "Visual telephone 7630 systems and equipment for local area networks which 7631 provide a non-guaranteed quality of service", ITU- 7632 T Recommendation H.323, May 1996. 7634 [NOSSDAV-1997-1] 7635 Schulzrinne, H., "A comprehensive multimedia control 7636 architecture for the Internet", May 1997. 7638 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 7639 and Support", STD 3, RFC 1123, October 1989. 7641 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 7642 Specification, Implementation", RFC 1305, March 1992. 7644 [RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions 7645 Functional Specification", RFC 1644, July 1994. 7647 [RFC1961] McMahon, P., "GSS-API Authentication Method for SOCKS 7648 Version 5", RFC 1961, June 1996. 7650 [RFC2070] Yergeau, F., Nicol, G., Adams, G., and M. Duerst, 7651 "Internationalization of the Hypertext Markup Language", 7652 RFC 2070, January 1997. 7654 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 7655 Streaming Protocol (RTSP)", RFC 2326, April 1998. 7657 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 7658 A., Peterson, J., Sparks, R., Handley, M., and E. 7659 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 7660 June 2002. 7662 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 7663 Schulzrinne, "Grouping of Media Lines in the Session 7664 Description Protocol (SDP)", RFC 3388, December 2002. 7666 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 7667 the Session Description Protocol (SDP)", RFC 4145, 7668 September 2005. 7670 [W3C.REC-PICS-labels] 7671 Miller, J., Krauskopf, T., Resnick, P., and W. Treese, 7672 "PICS label distribution label syntax and communication 7673 protocols", W3C REC-PICS-labels-961031. 7675 [W3C.REC-PICS-services] 7676 Miller, J., Resnick, P., and D. Singer, "Rating services 7677 and rating systems (and their machine readable 7678 descriptions)", W3C REC-PICS-services-961031, 7679 October 1996. 7681 Appendix A. RTSP Protocol State Machine 7683 The RTSP session state machine describes the behavior of the protocol 7684 from RTSP session initialization through RTSP session termination. 7686 The State machine is defined on a per session basis which is uniquely 7687 identified by the RTSP session identifier. The session may contain 7688 one or more media streams depending on state. If a single media 7689 stream is part of the session it is in non-aggregated control. If 7690 two or more is part of the session it is in aggregated control. 7692 The below state machine is a normative description of the protocols 7693 behavior. However, in case of ambiguity with the earlier parts of 7694 this specification, the description in the earlier parts SHALL take 7695 precedence. 7697 A.1. States 7699 The state machine contains three states, described below. For each 7700 state there exist a table which shows which requests and events that 7701 is allowed and if they will result in a state change. 7703 Init: Initial state no session exist. 7705 Ready: Session is ready to start playing. 7707 Play: Session is playing, i.e. sending media stream data in the 7708 direction S->C. 7710 A.2. State variables 7712 This representation of the state machine needs more than its state to 7713 work. A small number of variables are also needed and is explained 7714 below. 7716 NRM: The number of media streams part of this session. 7718 RP: Resume point, the point in the presentation time line at which 7719 a request to continue will resume from. A time format for the 7720 variable is not mandated. 7722 A.3. Abbreviations 7724 To make the state tables more compact a number of abbreviations are 7725 used, which are explained below. 7727 IFI: IF Implemented. 7729 md: Media 7731 PP: Pause Point, the point in the presentation time line at which 7732 the presentation was paused. 7734 Prs: Presentation, the complete multimedia presentation. 7736 RedP: Redirect Point, the point in the presentation time line at 7737 which a REDIRECT was specified to occur. 7739 SES: Session. 7741 A.4. State Tables 7743 This section contains a table for each state. The table contains all 7744 the requests and events that this state is allowed to act on. The 7745 events which is method names are, unless noted, requests with the 7746 given method in the direction client to server (C->S). In some cases 7747 there exist one or more requisite. The response column tells what 7748 type of response actions should be performed. Possible actions that 7749 is requested for an event includes: response codes, e.g. 200, headers 7750 that MUST be included in the response, setting of state variables, or 7751 setting of other session related parameters. The new state column 7752 tells which state the state machine changes to. 7754 The response to valid request meeting the requisites is normally a 7755 2xx (SUCCESS) unless other noted in the response column. The 7756 exceptions needs to be given a response according to the response 7757 column. If the request does not meet the requisite, is erroneous or 7758 some other type of error occur the appropriate response code MUST be 7759 sent. If the response code is a 4xx the session state is unchanged. 7760 A response code of 3rr will result in that the session is ended and 7761 its state is changed to Init. A response code of 304 results in no 7762 state change. However there exist restrictions to when a 3rr 7763 response may be used. A 5xx response SHALL not result in any change 7764 of the session state, except if the error is not possible to recover 7765 from. A unrecoverable error SHALL result the ending of the session. 7766 As it in the general case can't be determined if it was a 7767 unrecoverable error or not the client will be required to test. In 7768 the case that the next request after a 5xx is responded with 454 7769 (Session Not Found) the client knows that the session has ended. 7771 The server will timeout the session after the period of time 7772 specified in the SETUP response, if no activity from the client is 7773 detected. Therefore there exist a timeout event for all states 7774 except Init. 7776 In the case that NRM = 1 the presentation URI is equal to the media 7777 URI or a specified presentation URI. For NRM > 1 the presentation 7778 URI MUST be other than any of the medias that are part of the 7779 session. This applies to all states. 7781 +---------------+-----------------+---------------------------------+ 7782 | Event | Prerequisite | Response | 7783 +---------------+-----------------+---------------------------------+ 7784 | DESCRIBE | Needs REDIRECT | 3rr, Redirect | 7785 | | | | 7786 | DESCRIBE | | 200, Session description | 7787 | | | | 7788 | OPTIONS | Session ID | 200, Reset session timeout | 7789 | | | timer | 7790 | | | | 7791 | OPTIONS | | 200 | 7792 | | | | 7793 | SETPARAMETER | Valid parameter | 200, change value of parameter | 7794 | | | | 7795 | GET_PARAMETER | Valid parameter | 200, return value of parameter | 7796 +---------------+-----------------+---------------------------------+ 7798 Table 13: None state-machine changing events 7800 The methods in Table 13 do not have any effect on the state machine 7801 or the state variables. However some methods do change other session 7802 related parameters, for example SET_PARAMETER which will set the 7803 parameter(s) specified in its body. Also all of these methods that 7804 allows Session header will also update the keep-alive timer for the 7805 session. 7807 +------------------+----------------+-----------+-------------------+ 7808 | Action | Requisite | New State | Response | 7809 +------------------+----------------+-----------+-------------------+ 7810 | SETUP | | Ready | NRM=1, RP=0.0 | 7811 | | | | | 7812 | SETUP | Needs Redirect | Init | 3rr Redirect | 7813 | | | | | 7814 | S -> C: REDIRECT | No Session hdr | Init | Terminate all SES | 7815 +------------------+----------------+-----------+-------------------+ 7817 Table 14: State: Init 7819 The initial state of the state machine, see Table 14 can only be left 7820 by processing a correct SETUP request. As seen in the table the two 7821 state variables are also set by a correct request. This table also 7822 shows that a correct SETUP can in some cases be redirected to another 7823 URI and/or server by a 3rr response. 7825 +--------------+-----------------+-----------+----------------------+ 7826 | Action | Requisite | New State | Response | 7827 +--------------+-----------------+-----------+----------------------+ 7828 | SETUP | New URI | Ready | NRM +=1 | 7829 | | | | | 7830 | SETUP | URI Setup prior | Ready | Change transport | 7831 | | | | param | 7832 | | | | | 7833 | TEARDOWN | Prs URI, | Init | No session hdr, NRM | 7834 | | | | = 0 | 7835 | | | | | 7836 | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, NRM | 7837 | | | | = 0 | 7838 | | | | | 7839 | TEARDOWN | md URI,NRM>1 | Ready | Session hdr, NRM -= | 7840 | | | | 1 | 7841 | | | | | 7842 | PLAY | Prs URI, No | Play | Play from RP | 7843 | | range | | | 7844 | | | | | 7845 | PLAY | Prs URI, Range | Play | According to range | 7846 | | | | | 7847 | PAUSE | Prs URI | Ready | Return PP | 7848 | | | | | 7849 | SC:REDIRECT | Range hdr | Ready | Set RedP | 7850 | | | | | 7851 | SC:REDIRECT | no range hdr | Init | Session is removed | 7852 | | | | | 7853 | Timeout | | Init | | 7854 | | | | | 7855 | RedP reached | | Init | TEARDOWN of session | 7856 +--------------+-----------------+-----------+----------------------+ 7858 Table 15: State: Ready 7860 In the Ready state, see Table 15, some of the actions are depending 7861 on the number of media streams (NRM) in the session, i.e. aggregated 7862 or non-aggregated control. A setup request in the ready state can 7863 either add one more media stream to the session or if the media 7864 stream (same URI) already is part of the session change the transport 7865 parameters. TEARDOWN is depending on both the Request-URI and the 7866 number of media stream within the session. If the Request-URI is the 7867 presentations URI the whole session is torn down. If a media URI is 7868 used in the TEARDOWN request and more than one media exist in the 7869 session, the session will remain and a session header MUST be 7870 returned in the response. If only a single media stream remains in 7871 the session when performing a TEARDOWN with a media URI the session 7872 is removed. The number of media streams remaining after tearing down 7873 a media stream determines the new state. 7875 +--------------+-----------------+-----------+----------------------+ 7876 | Action | Requisite | New State | Response | 7877 +--------------+-----------------+-----------+----------------------+ 7878 | PAUSE | PrsURI | Ready | Set RP to present | 7879 | | | | point | 7880 | | | | | 7881 | PP reached | | Ready | RP = PP | 7882 | | | | | 7883 | End of media | All media | Play | Set RP = End of | 7884 | | | | media | 7885 | | | | | 7886 | End of range | | Play | Set RP = End of | 7887 | | | | range | 7888 | | | | | 7889 | PLAY | Prs URI, No | Play | Play from present | 7890 | | range | | point | 7891 | | | | | 7892 | PLAY | Prs URI, Range | Play | According to range | 7893 | | | | | 7894 | SETUP | New URI | Play | 455 | 7895 | | | | | 7896 | SETUP | Setuped URI | Play | 455 | 7897 | | | | | 7898 | SETUP | Setuped URI, | Play | Change transport | 7899 | | IFI | | param. | 7900 | | | | | 7901 | TEARDOWN | Prs URI | Init | No session hdr | 7902 | | | | | 7903 | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, | 7904 | | | | NRM=0 | 7905 | | | | | 7906 | TEARDOWN | md URI | Play | 455 | 7907 | | | | | 7908 | SC:REDIRECT | Range hdr | Play | Set RedP | 7909 | | | | | 7910 | SC:REDIRECT | no range hdr | Init | Session is removed | 7911 | | | | | 7912 | RedP reached | | Init | TEARDOWN of session | 7913 | | | | | 7914 | Timeout | | Init | Stop Media playout | 7915 +--------------+-----------------+-----------+----------------------+ 7917 Table 16: State: Play 7919 The Play state table, see Table 16, is the largest. The table 7920 contains an number of requests that has presentation URI as a 7921 prerequisite on the Request-URI, this is due to the exclusion of non- 7922 aggregated stream control in sessions with more than one media 7923 stream. 7925 To avoid inconsistencies between the client and server, automatic 7926 state transitions are avoided. This can be seen at for example "End 7927 of media" event when all media has finished playing, the session 7928 still remain in Play state. An explicit PAUSE request MUST be sent 7929 to change the state to Ready. It may appear that there exist an 7930 automatic transitions in "RedP reached" and "PP reached", however 7931 they are requested and acknowledge before they take place. The time 7932 at which the transition will happen is known by looking at the range 7933 header. If the client sends request close in time to these 7934 transitions it needs to be prepared for getting error message as the 7935 state may or may not have changed. 7937 Appendix B. Media Transport Alternatives 7939 This section defines how certain combinations of protocols, profiles 7940 and lower transports are used. This includes the usage of the 7941 Transport header's source and destination address parameters 7942 "src_addr" and "dest_addr". 7944 B.1. RTP 7946 This section defines the interaction of RTSP with respect to the RTP 7947 protocol [RFC3550]. It also defines any necessary media transport 7948 signalling with regards to RTP. 7950 The available RTP profiles and lower layer transports are described 7951 below along with rules on signalling the available combinations. 7953 B.1.1. AVP 7955 The usage of the "RTP Profile for Audio and Video Conferences with 7956 Minimal Control" [RFC3551] when using RTP for media transport over 7957 different lower layer transport protocols is defined below in regards 7958 to RTSP. 7960 One such case is defined within this document, the use of embedded 7961 (interleaved) binary data as defined in Section 14. The usage of 7962 this method is indicated by include the "interleaved" parameter. 7964 When using embedded binary data the "src_addr" and "dest_addr" SHALL 7965 NOT be used. This addressing and multiplexing is used as defined 7966 with use of channel numbers and the interleaved parameter. 7968 B.1.2. AVP/UDP 7970 This part describes sending of RTP [RFC3550] over lower transport 7971 layer UDP [RFC0768] according to the profile "RTP Profile for Audio 7972 and Video Conferences with Minimal Control" defined in RFC 3551 7973 [RFC3551]. This profiles requires one or two uni- or bi-directional 7974 UDP flows per media stream. The first UDP flow is for RTP and the 7975 second is for RTCP. Embedding of RTP data with the RTSP messages, in 7976 accordance with Section 14, SHOULD NOT be performed when RTSP 7977 messages are transported over unreliable transport protocols, like 7978 UDP [RFC0768]. 7980 The RTP/UDP and RTCP/UDP flows can be established using the Transport 7981 header's "src_addr", and "dest_addr" parameters. 7983 In RTSP PLAY mode, the transmission of RTP packets from client to 7984 server is unspecified. The behavior in regards to such RTP packets 7985 MAY be defined in future. 7987 The "src_addr" and "dest_addr" parameters are used in the following 7988 way for media playback, i.e. Mode=PLAY: 7990 o The "src_addr" and "dest_addr" parameters MUST contain either 1 or 7991 2 address specifications. 7993 o Each address specification for RTP/AVP/UDP or RTP/AVP/TCP MUST 7994 contain either: 7996 * both an address and a port number, or 7998 * a port number without an address. 8000 o The first address and port pair given in either of the parameters 8001 applies to the RTP stream. The second address and port pair if 8002 present applies to the RTCP stream. 8004 o The RTP/UDP packets from the server to the client SHALL be sent to 8005 the address and port given by first address and port pair of the 8006 "dest_addr" parameter. 8008 o The RTCP/UDP packets from the server to the client SHALL be sent 8009 to the address and port given by the second address and port pair 8010 of the "dest_addr" parameter. If no second pair is specified RTCP 8011 SHALL NOT be sent. 8013 o The RTCP/UDP packets from the client to the server SHALL be sent 8014 to the address and port given by the second address and port pair 8015 of the "src_addr" parameter. If no second pair is given RTCP 8016 SHALL NOT be sent. 8018 o The RTP/UDP packets from the client to the server SHALL be sent to 8019 the address and port given by the first address and port pair of 8020 the "src_addr" parameter. 8022 o RTP and RTCP Packets SHOULD be sent from the corresponding 8023 receiver port, i.e. RTCP packets from server should be sent from 8024 the "src_addr" parameters second address port pair. 8026 B.1.3. AVPF/UDP 8028 The RTP profile "Extended RTP Profile for RTCP-based Feedback (RTP/ 8029 AVPF)"[RFC4585] MAY be used as RTP profiles in session using RTP. 8030 All that is defined for AVP SHALL also apply for AVPF. 8032 The usage of AVPF is indicated by the media initialization protocol 8033 used. In the case of SDP it is indicated by media lines (m=) 8034 containing the profile RTP/AVPF. That SDP MAY also contain further 8035 AVPF related SDP attributes configuring the AVPF session regarding 8036 reporting interval and feedback messages that shall be used that 8037 SHALL be followed. 8039 B.1.4. SAVP/UDP 8041 The RTP profile "The Secure Real-time Transport Protocol (SRTP)" 8042 [RFC3711] is an RTP profile (SAVP) that MAY be used in RTSP sessions 8043 using RTP. All that is defined for AVP SHALL also apply for SAVP. 8045 The usage of SRTP requires that a security association is 8046 established. The RECOMMENDED mechanism for establishing that 8047 security association is to use MIKEY with RTSP as defined in RFC 4567 8048 [RFC4567]. 8050 B.1.5. SAVPF/UDP 8052 The RTP profile "Extended Secure RTP Profile for RTCP-based Feedback 8053 (RTP/SAVPF)" [I-D.ietf-avt-profile-savpf] is an RTP profile (SAVPF) 8054 that MAY be used in RTSP sessions using RTP. All that is defined for 8055 AVP SHALL also apply for SAVPF. 8057 The usage of SRTP requires that a security association is 8058 established. The RECOMMENDED mechanism for establishing that 8059 security association is to use MIKEY[RFC3830] with RTSP as defined in 8060 RFC 4567 [RFC4567]. 8062 B.1.6. RTCP usage with RTSP 8064 RTCP has several usages when RTP is used for media transport as 8065 explained below. Due to that RTCP SHALL be supported if an RTSP 8066 agent handles RTP. 8068 B.1.6.1. Media synchronization 8070 RTCP provides media synchronization and clock drift compensation. 8071 The first is available from RTP-Info header to accomplish the initial 8072 synchronization. But to be able to handle any clockdrift between the 8073 media streams, RTCP is needed. 8075 B.1.6.2. RTSP Session keep-alive 8077 RTCP traffic from the RTSP client to the RTSP server SHALL function 8078 as keep-alive. Which requires an RTSP server supporting RTP to use 8079 the received RTCP packets as indications that the client desires the 8080 related RTSP session to be kept alive. 8082 B.1.6.3. Bit-rate adapation 8084 RTCP Receiver Rerports and any additional feedback from the client 8085 SHALL be used adapt the bit-rate used over the transport for all 8086 cases when RTP is sent over UDP. A RTP sender without reserved 8087 resources SHALL NOT use more than its fair share of the available 8088 resources. This can be determined by comparing on short to medium 8089 term (some seconds) the used bit-rate and adapt it so that the RTP 8090 sender sends at a bit-rate comparable to what a TCP sender would 8091 achieve on average over the same path. 8093 B.2. RTP over TCP 8095 Transport of RTP over TCP can be done in two ways, over independent 8096 TCP connections using RFC 4571 [RFC4571] or interleaved in the RTSP 8097 control connection. In both cases the protocol SHALL be "rtp" and 8098 the lower layer SHALL be TCP. The profile may be any of the above 8099 specified ones; AVP, AVPF, SAVP or SAVPF. 8101 B.2.1. Interleaved RTP over TCP 8103 The use of embedded (interleaved) binary data transported on the RTSP 8104 connection is possible as specified in Section 14. When using this 8105 declared combination of interleaved binary data the RTSP messages 8106 MUST be transported over TCP. TLS may or may not be used. 8108 One should however consider that this will result that all media 8109 streams go through any proxy. Using independent TCP connections can 8110 avoid that issue. 8112 B.2.2. RTP over independent TCP 8114 In this Appendix, we describe the sending of RTP [RFC3550] over lower 8115 transport layer TCP [RFC0793] according to "Framing Real-time 8116 Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over 8117 Connection-Oriented Transport" [RFC4571]. This Appendix adapts the 8118 guidelines for using RTP over TCP within SIP/SDP [RFC4145] to work 8119 with RTSP. 8121 A client codes the support of RTP over independent TCP by specifying 8122 an RTP/AVP/TCP transport option without an interleaved parameter in 8123 the Transport line of a SETUP request. This transport option MUST 8124 include the "unicast" parameter. 8126 If the client wishes to use RTP with RTCP, two ports (or two address/ 8127 port pairs) are specified by the dest_addr parameter. If the client 8128 wishes to use RTP without RTCP, one port (or one address/port pair) 8129 is specified by the dest_addr parameter. Ordering rules of dest_addr 8130 ports follow the rules for RTP/AVP/UDP. 8132 If the client wishes to play the active role in initiating the TCP 8133 connection, it MAY set the "setup" parameter (See Section 16.46) on 8134 the Transport line to be "active", or it MAY omit the setup 8135 parameter, as active is the default. If the client signals the 8136 active role, the ports for all dest_addr values MUST be set to 9 (the 8137 discard port). 8139 If the client wishes to play the passive role in TCP connection 8140 initiation, it MUST set the "setup" parameter on the Transport line 8141 to be "passive". If the client is able to assume the active or the 8142 passive role, it MUST set the "setup" parameter on the Transport line 8143 to be "actpass". In either case, the dest_addr port value for RTP 8144 MUST be set to the TCP port number on which the client is expecting 8145 to receive the RTP stream connection, and the dest_addr port value 8146 for RTCP MUST be set to the TCP port number on which the client is 8147 expecting to receive the RTCP stream connection. 8149 If upon receipt of a non-interleaved RTP/AVP/TCP SETUP request, a 8150 server decides to accept this requested option, the 2xx reply MUST 8151 contain a Transport option that specifies RTP/AVP/TCP (without using 8152 the interleaved parameter, and with using the unicast parameter). 8153 The dest_addr parameter value MUST be echoed from the parameter value 8154 in the client request unless the destination address (only port) was 8155 not provided in which can the server MAY include the source address 8156 of the RTSP TCP connection with the port number unchanged. 8158 In addition, the server reply MUST set the setup parameter on the 8159 Transport line, to indicate the role the server will play in the 8160 connection setup. Permissible values are "active" (if a client set 8161 "setup" to "passive" or "actpass") and "passive" (if a client set 8162 "setup" to "active" or "actpass"). 8164 If a server sets "setup" to "passive", the "src_addr" in the reply 8165 MUST indicate the ports the server is willing to receive an RTP 8166 connection and (if the client requested an RTCP connection by 8167 specifying two dest_addr ports or address/port pairs) and RTCP 8168 connection. If a server sets "setup" to "active", the ports 8169 specified in "src_addr" MUST be set to 9. The server MAY use the 8170 "ssrc" parameter, following the guidance in Section 16.46. Port 8171 ordering for src_addr follows the rules for RTP/AVP/UDP. 8173 For cases when servers have a public IP-address it is RECOMMENDED 8174 that the server take the passive role and the client the active role. 8175 This help in cases when the client is behind a NAT. 8177 After sending (receiving) a 2xx reply for a SETUP method for a non- 8178 interleaved RTP/AVP/TCP media stream, the active party SHOULD 8179 initiate the TCP connection as soon as possible. The client SHALL 8180 NOT send a PLAY request prior to the establishment of all the TCP 8181 connections negotiated using SETUP for the session. In case the 8182 server receives a PLAY request in a session that has not yet 8183 established all the TCP connections, it SHALL respond using the 464 8184 "Data Transport Not Ready Yet" (Section 15.4.16) error code. 8186 Once the PLAY request for a media resource transported over non- 8187 interleaved RTP/AVP/TCP occurs, media begins to flow from server to 8188 client over the RTP TCP connection, and RTCP packets flow 8189 bidirectionally over the RTCP TCP connection. As in the RTP/UDP 8190 case, client to server traffic on the TCP port is unspecified by this 8191 memo. The packets that travel on these connections SHALL be framed 8192 using the protocol defined in [RFC4571], not by the framing defined 8193 for interleaving RTP over the RTSP control connection defined in 8194 Section 14. 8196 A successful PAUSE request for a media being transported over RTP/ 8197 AVP/TCP pauses the flow of packets over the connections, without 8198 closing the connections. A successful TEARDOWN request signals that 8199 the TCP connections for RTP and RTCP are to be closed as soon as 8200 possible. 8202 Subsequent SETUP requests on an already-SETUP RTP/AVP/TCP URI may be 8203 ambiguous in the following way: does the client wish to open up new 8204 TCP RTP and RTCP connections for the URI, or does the client wish to 8205 continue using the existing TCP RTP and RTCP connections? The client 8206 SHOULD use the "connection" parameter (defined in Section 16.46) on 8207 the Transport line to make its intention clear in the regard (by 8208 setting "connection" to "new" if new connections are needed, and by 8209 setting "connection" to "existing" if the existing connections are to 8210 be used). After a 2xx reply for a SETUP request for a new 8211 connection, parties should close the pre-existing connections, after 8212 waiting a suitable period for any stray RTP or RTCP packets to 8213 arrive. 8215 Below, we rewrite part of the example media on demand example shown 8216 in Section 19.1 to use RTP/AVP/TCP non-interleaved: 8218 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 8219 CSeq: 1 8220 User-Agent: PhonyClient/1.2 8222 M->C: RTSP/2.0 200 OK 8223 CSeq: 1 8224 Server: PhonyServer/1.0 8225 Date: 23 Jan 1997 15:35:06 GMT 8226 Content-Type: application/sdp 8227 Content-Length: 257 8228 Content-Base: rtsp://example.com/twister.3gp/ 8229 Expires: 24 Jan 1997 15:35:06 GMT 8231 v=0 8232 o=- 2890844256 2890842807 IN IP4 192.0.2.5 8233 s=RTSP Session 8234 i=An Example of RTSP Session Usage 8235 e=adm@example.com 8236 a=control: * 8237 a=range: npt=0-0:10:34.10 8238 t=0 0 8239 m=audio 0 RTP/AVP 0 8240 a=control: trackID=1 8242 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 8243 CSeq: 2 8244 User-Agent: PhonyClient/1.2 8245 Require: play.basic 8246 Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9" 8247 setup=active;connection=new 8249 Accept-Ranges: NPT, SMPTE, UTC 8251 M->C: RTSP/2.0 200 OK 8252 CSeq: 2 8253 Server: PhonyServer/1.0 8254 Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9"; 8255 src_addr="192.0.2.5:9000"/"192.0.2.5:9001" 8256 setup=passive;connection=new;ssrc=93CB001E 8257 Session: 12345678 8258 Expires: 24 Jan 1997 15:35:12 GMT 8259 Date: 23 Jan 1997 15:35:12 GMT 8260 Accept-Ranges: NPT 8262 C->M: TCP Connection Establishment 8264 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 8265 CSeq: 4 8266 User-Agent: PhonyClient/1.2 8267 Range: npt=0-10, npt=30- 8268 Session: 12345678 8270 M->C: RTSP/2.0 200 OK 8271 CSeq: 4 8272 Server: PhonyServer/1.0 8273 Date: 23 Jan 1997 15:35:14 GMT 8274 Session: 12345678 8275 Range: npt=0-10, npt=30-623.10 8276 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1"; 8277 ssrc=4F312DD8:seq=54321;rtptime=2876889 8279 B.2.3. Handling NPT Jumps in the RTP Media Layer 8281 RTSP allows media clients to control selected, non-contiguous 8282 sections of media presentations, rendering those streams with an RTP 8283 media layer[RFC3550]. Such control allows jumps to be created in NPT 8284 timeline of the RTSP session. For example, jumps in NPT can be 8285 caused by multiple ranges in the range specifier of a PLAY request or 8286 through a "seek" opertaion on an RTSP session which involves a PLAY, 8287 PAUSE, PLAY scenario where a new NPT is set for the session. The 8288 media layer rendering the RTP stream should not be affected by jumps 8289 in NPT. Thus, both RTP sequence numbers and RTP timestamps MUST be 8290 continuous and monotonic across jumps of NPT. 8292 We cannot assume that the RTSP client can communicate with the RTP 8293 media agent, as the two may be independent processes. If the RTP 8294 timestamp shows the same gap as the NPT, the media agent will 8295 assume that there is a pause in the presentation. If the jump in 8296 NPT is large enough, the RTP timestamp may roll over and the media 8297 agent may believe later packets to be duplicates of packets just 8298 played out. 8300 As an example, assume a clock frequency of 8000 Hz, a packetization 8301 interval of 100 ms and an initial sequence number and timestamp of 8302 zero. 8304 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 8305 CSeq: 4 8306 Session: abcdefg 8307 Range: npt=10-15 8308 User-Agent: PhonyClient/1.2 8310 S->C: RTSP/2.0 200 OK 8311 CSeq: 4 8312 Session: abcdefg 8313 Range: npt=10-15 8314 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 8315 ssrc=0D12F123:seq=0;rtptime=0 8317 The ensuing RTP data stream is depicted below: 8319 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 8320 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 8321 . . . 8322 S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s 8324 Immediately after the end of the play range, the client follows up 8325 with a request to PLAY from a new NPT. 8327 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 8328 CSeq: 5 8329 Session: abcdefg 8330 Range: npt=18-20 8331 User-Agent: PhonyClient/1.2 8333 S->C: RTSP/2.0 200 OK 8334 CSeq: 5 8335 Session: abcdefg 8336 Range: npt=18-20 8337 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 8338 ssrc=0D12F123:seq=50;rtptime=40100 8340 The ensuing RTP data stream is depicted below: 8342 S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s 8343 S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s 8344 . . . 8345 S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s 8347 In this example, first, NPT 10 through 15 is played, then the client 8348 request the server to skip ahead and play NPT 18 through 20. The 8349 first segment is presented as RTP packets with sequence numbers 0 8350 through 49 and timestamp 0 through 39,200. The second segment 8351 consists of RTP packets with sequence number 50 through 69, with 8352 timestamps 40,100 through 55,200. While there is a gap in the NPT, 8353 there is no gap in the sequence number space of the RTP data stream. 8355 The RTP timestamp gap is present in the above example due to the time 8356 it takes to perform the second play request, in this case 12.5 ms 8357 (100/8000). To avoid this gap in playback due to the time it takes 8358 to perform RTSP requests, a PLAY request with multiple ranges needs 8359 to be specified. That would result in the following example: 8361 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 8362 CSeq: 4 8363 Session: abcdefg 8364 Range: npt=10-15;npt=18-20 8365 User-Agent: PhonyClient/1.2 8367 S->C: RTSP/2.0 200 OK 8368 CSeq: 4 8369 Session: abcdefg 8370 Range: npt=10-15 8371 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 8372 ssrc=0D12F123:seq=0;rtptime=0 8374 The ensuing RTP data stream is depicted below: 8376 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 8377 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 8378 . . . 8379 S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s 8380 S -> C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s 8381 S -> C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s 8382 . . . 8383 S -> C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s 8385 B.2.4. Handling RTP Timestamps after PAUSE 8387 During a PAUSE / PLAY interaction in an RTSP session, the duration of 8388 time for which the RTP transmission was halted MUST be reflected in 8389 the RTP timestamp of each RTP stream. The duration can be calculated 8390 for each RTP stream as the time elapsed from when the last RTP packet 8391 was sent before the PAUSE request was received and when the first RTP 8392 packet was sent after the subsequent PLAY request was received. The 8393 duration includes all latency incurred and processing time required 8394 to complete the request. 8396 The RTP RFC [RFC3550] states that: The RTP timestamp for each 8397 unit[packet] would be related to the wallclock time at which the 8398 unit becomes current on the virtual presentation timeline. 8400 In order to satisfy the requirements of [RFC3550], the RTP 8401 timestamp space needs to increase continuously with real time. 8402 While this is not optimal for stored media, it is required for RTP 8403 and RTCP to function as intended. Using a continuous RTP 8404 timestamp space allows the same timestamp model for both stored 8405 and live media and allows better opportunity to integrate both 8406 types of media under a single control. 8408 As an example, assume a clock frequency of 8000 Hz, a packetization 8409 interval of 100 ms and an initial sequence number and timestamp of 8410 zero. 8412 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 8413 CSeq: 4 8414 Session: abcdefg 8415 Range: npt=10-15 8416 User-Agent: PhonyClient/1.2 8418 S->C: RTSP/2.0 200 OK 8419 CSeq: 4 8420 Session: abcdefg 8421 Range: npt=10-15 8422 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 8423 ssrc=0D12F123:seq=0;rtptime=0 8425 The ensuing RTP data stream is depicted below: 8427 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 8428 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 8429 S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s 8430 S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s 8432 The client then sends a PAUSE request: 8434 C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0 8435 CSeq: 5 8436 Session: abdcdefg 8437 User-Agent: PhonyClient/1.2 8439 S->C: RTSP/2.0 200 OK 8440 CSeq: 5 8441 Session: abcdefg 8442 Range: npt=10.4-15 8444 20 seconds elapse and then the client sends a PLAY request. In 8445 addition the server requires 15 ms to process the request: 8447 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 8448 CSeq: 6 8449 Session: abcdefg 8450 User-Agent: PhonyClient/1.2 8452 S->C: RTSP/2.0 200 OK 8453 CSeq: 6 8454 Session: abcdefg 8455 Range: npt=10.4-15 8456 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 8457 ssrc=0D12F123:seq=4;rtptime=164400 8459 The ensuing RTP data stream is depicted below: 8461 S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s 8462 S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s 8463 S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s 8465 First, NPT 10 through 10.3 is played, then a PAUSE is received by the 8466 server. After 20 seconds a PLAY is received by the server which take 8467 15ms to process. The duration of time for which the session was 8468 paused is reflected in the RTP timestamp of the RTP packets sent 8469 after this PLAY request. 8471 A client can use the RTSP range header and RTP-Info header to map NPT 8472 time of a presentation with the RTP timestamp. 8474 Note: In RFC 2326 [RFC2326], this matter was not clearly defined and 8475 was misunderstood commonly. However for RTSP 2.0 it is expected that 8476 this will be handled correctly and no exception handling will be 8477 required. 8479 B.2.5. RTSP / RTP Integration 8481 For certain datatypes, tight integration between the RTSP layer and 8482 the RTP layer will be necessary. This by no means precludes the 8483 above restrictions. Combined RTSP/RTP media clients should use the 8484 RTP-Info field to determine whether incoming RTP packets were sent 8485 before or after a seek or before or after a PAUSE. 8487 B.2.6. Scaling with RTP 8489 For scaling (see Section 16.40), RTP timestamps should correspond to 8490 the playback timing. For example, when playing video recorded at 30 8491 frames/second at a scale of two and speed (Section 16.41) of one, the 8492 server would drop every second frame to maintain and deliver video 8493 packets with the normal timestamp spacing of 3,000 per frame, but NPT 8494 would increase by 1/15 second for each video frame. 8496 Note: The above scaling puts requirements on the media codec or a 8497 media stream to support it. For example motion JPEG or other non- 8498 predictive video coding can easier handle the above example. 8500 B.2.7. Maintaining NPT synchronization with RTP timestamps 8502 The client can maintain a correct display of NPT (Normal Play Time) 8503 by noting the RTP timestamp value of the first packet arriving after 8504 repositioning. The sequence parameter of the RTP-Info 8505 (Section 16.39) header provides the first sequence number of the next 8506 segment. 8508 B.2.8. Continuous Audio 8510 For continuous audio, the server SHOULD set the RTP marker bit at the 8511 beginning of serving a new PLAY request or at jumps in timeline. 8512 This allows the client to perform playout delay adaptation. 8514 B.2.9. Multiple Sources in an RTP Session 8516 Note that more than one SSRC MAY be sent in the media stream. If it 8517 happens all sources are expected to be rendered simultaneously. 8519 B.2.10. Usage of SSRCs and the RTCP BYE Message During an RTSP Session 8521 The RTCP BYE message indicates the end of use of a given SSRC. If 8522 all sources leave an RTP session, it can, in most cases, be assumed 8523 to have ended. Therefore, a client or server SHALL NOT send a RTCP 8524 BYE message until it has finished using a SSRC. A server SHOULD keep 8525 using a SSRC until the RTP session is terminated. Prolonging the use 8526 of a SSRC allows the established synchronization context associated 8527 with that SSRC to be used to synchronize subsequent PLAY requests 8528 even if the PLAY response is late. 8530 An SSRC collision with the SSRC that transmits media does also have 8531 consequences, as it will force the media sender to change its SSRC in 8532 accordance with the RTP specification[RFC3550]. This will result in 8533 a loss of synchronization context, and require any receiver to wait 8534 for RTCP sender reports for all media requiring synchronization 8535 before being able to play out synchronized. Due to these reasons a 8536 client joining a session should take care to not select the same SSRC 8537 as the server. Any SSRC signalled in the Transport header SHOULD be 8538 avoided. A client detecting a collision prior to sending any RTP or 8539 RTCP messages can also select a new SSRC. 8541 B.3. Future Additions 8543 It is the intention that any future protocol or profile regarding 8544 both for media delivery and lower transport should be easy to add to 8545 RTSP. This section provides the necessary steps that needs to be 8546 meet. 8548 The following things needs to be considered when adding a new 8549 protocol of profile for use with RTSP: 8551 o The protocol or profile needs to define a name tag representing 8552 it. This tag is required to be a ABNF "token" to be possible to 8553 use in the Transport header specification. 8555 o The useful combinations of protocol/profile/lower-layer needs to 8556 be defined and for each combination declare the necessary 8557 parameters to use in the Transport header. 8559 o For new media protocols the interaction with RTSP needs to be 8560 addressed. One important factor will be the media 8561 synchronization. 8563 See the IANA section (Section 23) for information how to register new 8564 attributes. 8566 Appendix C. Use of SDP for RTSP Session Descriptions 8568 The Session Description Protocol (SDP, [RFC4566]) may be used to 8569 describe streams or presentations in RTSP. This description is 8570 typically returned in reply to a DESCRIBE request on an URI from a 8571 server to a client, or received via HTTP from a server to a client. 8573 This appendix describes how an SDP file determines the operation of 8574 an RTSP session. SDP as is provides no mechanism by which a client 8575 can distinguish, without human guidance, between several media 8576 streams to be rendered simultaneously and a set of alternatives 8577 (e.g., two audio streams spoken in different languages). However the 8578 SDP extension "Grouping of Media Lines in the Session Description 8579 Protocol (SDP)" [RFC3388] may provide such functionality depending on 8580 need. Also future grouping semantics may in the future be developed. 8582 C.1. Definitions 8584 The terms "session-level", "media-level" and other key/attribute 8585 names and values used in this appendix are to be used as defined in 8586 SDP (RFC 4566 [RFC4566]): 8588 C.1.1. Control URI 8590 The "a=control:" attribute is used to convey the control URI. This 8591 attribute is used both for the session and media descriptions. If 8592 used for individual media, it indicates the URI to be used for 8593 controlling that particular media stream. If found at the session 8594 level, the attribute indicates the URI for aggregate control 8595 (presentation URI). The session level URI SHALL be different from 8596 any media level URI. The presence of a session level control 8597 attribute SHALL be interpreted as support for aggregated control. 8598 The control attribute SHALL be present on media level unless the 8599 presentation only contains a single media stream, in which case the 8600 attribute MAY only be present on the session level. 8602 ABNF for the attribute is defined in Section 21.3. 8604 Example: 8606 a=control:rtsp://example.com/foo 8608 This attribute MAY contain either relative or absolute URIs, 8609 following the rules and conventions set out in RFC 3986 [RFC3986]. 8610 Implementations SHALL look for a base URI in the following order: 8612 1. the RTSP Content-Base field; 8613 2. the RTSP Content-Location field; 8615 3. the RTSP Request-URI. 8617 If this attribute contains only an asterisk (*), then the URI SHALL 8618 be treated as if it were an empty embedded URI, and thus inherit the 8619 entire base URI. 8621 The URI handling for SDPs from container files need special 8622 consideration. For example lets assume that a container file has the 8623 URI: "rtsp://example.com/container.mp4". Lets further assume this 8624 URI is the base URI, and that there is a absolute media level URI: 8625 "rtsp://example.com/container.mp4/trackID=2". A relative media level 8626 URI that resolves in accordance with RFC 3986 [RFC3986] to the above 8627 given media URI is: "container.mp4/trackID=2". It is usually not 8628 desirable to need to include in or modify the SDP stored within the 8629 container file with the server local name of the container file. To 8630 avoid this, one can modify the base URI used to include a trailing 8631 slash, e.g. "rtsp://example.com/container.mp4/". In this case the 8632 relative URI for the media will only need to be: "trackID=2". 8633 However this will also mean that using "*" in the SDP will result in 8634 control URI including the trailing slash, i.e. 8635 "rtsp://example.com/container.mp4/". 8637 Note: The usage of TrackID in the above is not an standardized 8638 form, but one example out of several similar strings such as 8639 TrackID, Track_ID, StreamID that is used by different server 8640 vendors to indicate a particular piece of media inside a container 8641 file. 8643 C.1.2. Media Streams 8645 The "m=" field is used to enumerate the streams. It is expected that 8646 all the specified streams will be rendered with appropriate 8647 synchronization. If the session is over multicast, the port number 8648 indicated SHOULD be used for reception. The client MAY try to 8649 override the destination port, through the Transport header. The 8650 servers MAY allow this, the response will indicate if allowed or not. 8651 If the session is unicast, the port number is the ones RECOMMENDED by 8652 the server to the client, about which receiver ports to use; the 8653 client MUST still include its receiver ports in its SETUP request. 8654 The client MAY ignore this recommendation. If the server has no 8655 preference, it SHOULD set the port number value to zero. 8657 The "m=" lines contain information about what transport protocol, 8658 profile, and possibly lower-layer is to be used for the media stream. 8659 The combination of transport, profile and lower layer, like RTP/AVP/ 8660 UDP needs to be defined for how to be used with RTSP. The currently 8661 defined combinations are defined in Appendix B, further combinations 8662 MAY be specified. 8664 Usage of grouping of media lines [RFC3388] to determine which media 8665 lines should or should not be included in a RTSP session is 8666 unspecified. 8668 Example: 8670 m=audio 0 RTP/AVP 31 8672 C.1.3. Payload Type(s) 8674 The payload type(s) are specified in the "m=" line. In case the 8675 payload type is a static payload type from RFC 3551 [RFC3551], no 8676 other information may be required. In case it is a dynamic payload 8677 type, the media attribute "rtpmap" is used to specify what the media 8678 is. The "encoding name" within the "rtpmap" attribute may be one of 8679 those specified in RFC 3551 (Sections 5 and 6), or an MIME type 8680 registered with IANA, or an experimental encoding as specified in SDP 8681 (RFC 4566 [RFC4566]). Codec-specific parameters are not specified in 8682 this field, but rather in the "fmtp" attribute described below. 8684 C.1.4. Format-Specific Parameters 8686 Format-specific parameters are conveyed using the "fmtp" media 8687 attribute. The syntax of the "fmtp" attribute is specific to the 8688 encoding(s) that the attribute refers to. Note that some of the 8689 format specific parameters may be specified outside of the fmtp 8690 parameters, like for example the "ptime" attribute for most audio 8691 encodings. 8693 C.1.5. Directionality of media stream 8695 The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly" 8696 provides instructions on which direction the media streams flow 8697 within a session. When using RTSP the SDP can be delivered to a 8698 client using either RTSP DESCRIBE or a number of RTSP external 8699 methods, like HTTP, FTP, and email. Based on this the SDP applies to 8700 how the RTSP client will see the complete session. Thus for media 8701 streams delivered from the RTSP server to the client would be given 8702 the "a=recvonly" attribute. 8704 The direction attributes are not commonly used in SDPs for RTSP, but 8705 may occur. "a=recvonly" in a SDP provided to the RTSP client SHALL 8706 indicate that media delivery will only occur in the direction from 8707 the RTSP server to the client. In SDP provided to the RTSP client 8708 that lacks any of the directionality attributes (a=recvonly, 8709 a=sendonly, a=sendrecv) SHALL behave as if the "a=recvonly" attribute 8710 was received. Note that this overrules the normal default rule 8711 defined in SDP[RFC4566]. The usage of "a=sendonly" or "a=sendrecv" 8712 is not defined, nor is the interpretation of SDP by other entities 8713 than the RTSP client. 8715 C.1.6. Range of Presentation 8717 The "a=range" attribute defines the total time range of the stored 8718 session or an individual media. Non-seekable live sessions can be 8719 indicated, while the length of live sessions can be deduced from the 8720 "t" and "r" SDP parameters. 8722 The attribute is both a session and a media level attribute. For 8723 presentations that contains media streams of the same durations, the 8724 range attribute SHOULD only be used at session-level. In case of 8725 different length the range attribute MUST be given at media level for 8726 all media, and SHOULD NOT be given at session level. If the 8727 attribute is present at both media level and session level the media 8728 level values SHALL be used. 8730 Note: Usually one will specify the same length for all media, even if 8731 there isn't media available for the full duration on all media. 8732 However that requires that the server accepts PLAY requests within 8733 that range. 8735 Servers SHALL take care to provide RTSP Range (see Section 16.35) 8736 values that are consistent with what is presented in the SDP for the 8737 content. There are no reason for non dynamic content, like media 8738 clips provided on demand to have inconsistent values. Inconsistent 8739 values between the SDP and the actual values for the content handled 8740 by the server is likely to generate some failure, like 457 "Invalid 8741 Range", in case the client uses PLAY requests with a Range header. 8742 In case the content is dynamic in length and it is infeasible to 8743 provide a correct value in the SDP the server is recommended to 8744 describe this as non-seekable content (see below). The server MAY 8745 override that property in the response to a PLAY request using the 8746 correct values in the Range header. 8748 The unit is specified first, followed by the value range. The units 8749 and their values are as defined in Section 4.4, Section 4.5 and 8750 Section 4.6 and MAY be extended with further formats. Any open ended 8751 range (start-), i.e. without stop range, is of unspecified duration 8752 and SHALL be considered as non-seekable content unless this property 8753 is overridden. Multiple instances carrying different clock formats 8754 MAY be included at either session or media level. 8756 ABNF for the attribute is defined in Section 21.3. 8758 Examples: 8760 a=range:npt=0-34.4368 8761 a=range:clock=19971113T2115-19971113T2203 8762 Non seekable stream of unknown duration: 8763 a=range:npt=0- 8765 C.1.7. Time of Availability 8767 The "t=" field MUST contain suitable values for the start and stop 8768 times for both aggregate and non-aggregate stream control. The 8769 server SHOULD indicate a stop time value for which it guarantees the 8770 description to be valid, and a start time that is equal to or before 8771 the time at which the DESCRIBE request was received. It MAY also 8772 indicate start and stop times of 0, meaning that the session is 8773 always available. 8775 For sessions that are of live type, i.e. specific start time, unknown 8776 stop time, likely unseekable, the "t=" and "r=" field SHOULD be used 8777 to indicate the start time of the event. The stop time SHOULD be 8778 given so that the live event will have ended at that time, while 8779 still not be unnecessary long into the future. 8781 C.1.8. Connection Information 8783 In SDP, the "c=" field contains the destination address for the media 8784 stream. For on-demand unicast streams and some multicast streams, 8785 the destination address MAY be specified by the client via the SETUP 8786 request, thus overriding any specified address. To identify streams 8787 without a fixed destination address, where the client is required to 8788 specify a destination address, the "c=" field SHOULD be set to a null 8789 value. For addresses of type "IP4", this value SHALL be "0.0.0.0", 8790 and for type "IP6", this value SHALL be "0:0:0:0:0:0:0:0", i.e. the 8791 unspecified address according to RFC 3513 [RFC3513]. 8793 C.1.9. Entity Tag 8795 The optional "a=etag" attribute identifies a version of the session 8796 description. It is opaque to the client. SETUP requests may include 8797 this identifier in the If-Match field (see Section 16.24) to only 8798 allow session establishment if this attribute value still corresponds 8799 to that of the current description. The attribute value is opaque 8800 and may contain any character allowed within SDP attribute values. 8802 ABNF for the attribute is defined in Section 21.3. 8804 Example: 8806 a=etag:158bb3e7c7fd62ce67f12b533f06b83a 8808 One could argue that the "o=" field provides identical 8809 functionality. However, it does so in a manner that would put 8810 constraints on servers that need to support multiple session 8811 description types other than SDP for the same piece of media 8812 content. 8814 C.2. Aggregate Control Not Available 8816 If a presentation does not support aggregate control no session level 8817 "a=control:" attribute is specified. For a SDP with multiple media 8818 sections specified, each section will have its own control URI 8819 specified via the "a=control:" attribute. 8821 Example: 8823 v=0 8824 o=- 2890844256 2890842807 IN IP4 192.0.2.56 8825 s=I came from a web page 8826 e=adm@example.com 8827 c=IN IP4 0.0.0.0 8828 t=0 0 8829 m=video 8002 RTP/AVP 31 8830 a=control:rtsp://audio.com/movie.aud 8831 m=audio 8004 RTP/AVP 3 8832 a=control:rtsp://video.com/movie.vid 8834 Note that the position of the control URI in the description implies 8835 that the client establishes separate RTSP control sessions to the 8836 servers audio.com and video.com. 8838 It is recommended that an SDP file contains the complete media 8839 initialization information even if it is delivered to the media 8840 client through non-RTSP means. This is necessary as there is no 8841 mechanism to indicate that the client should request more detailed 8842 media stream information via DESCRIBE. 8844 C.3. Aggregate Control Available 8846 In this scenario, the server has multiple streams that can be 8847 controlled as a whole. In this case, there are both a media-level 8848 "a=control:" attributes, which are used to specify the stream URIs, 8849 and a session-level "a=control:" attribute which is used as the 8850 Request-URI for aggregate control. If the media-level URI is 8851 relative, it is resolved to absolute URIs according to Appendix C.1.1 8852 above. 8854 Example: 8856 C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0 8857 CSeq: 1 8858 User-Agent: PhonyClient/1.2 8860 M->C: RTSP/2.0 200 OK 8861 CSeq: 1 8862 Date: 23 Jan 1997 15:35:06 GMT 8863 Content-Type: application/sdp 8864 Content-Base: rtsp://example.com/movie/ 8865 Content-Length: 228 8867 v=0 8868 o=- 2890844256 2890842807 IN IP4 192.0.2.211 8869 s=I contain 8870 i= 8871 e=adm@example.com 8872 c=IN IP4 0.0.0.0 8873 t=0 0 8874 a=control:* 8875 m=video 8002 RTP/AVP 31 8876 a=control:trackID=1 8877 m=audio 8004 RTP/AVP 3 8878 a=control:trackID=2 8880 In this example, the client is required to establish a single RTSP 8881 session to the server, and uses the URIs 8882 rtsp://example.com/movie/trackID=1 and 8883 rtsp://example.com/movie/trackID=2 to set up the video and audio 8884 streams, respectively. The URI rtsp://example.com/movie/, which is 8885 resolved from the "*", controls the whole presentation (movie). 8887 A client is not required to issues SETUP requests for all streams 8888 within an aggregate object. Servers should allow the client to ask 8889 for only a subset of the streams. 8891 C.4. RTSP external SDP delivery 8893 There are some considerations that needs to be made when the session 8894 description is delivered to client outside of RTSP, for example in 8895 HTTP or email. 8897 First of all the SDP needs to contain absolute URIs, relative will in 8898 most cases not work as the delivery will not correctly forward the 8899 base URI. And as SDP might be temporarily stored on file system 8900 before being loaded into an RTSP capable client, thus if possible to 8901 transport the base URI it still would need to be merged into the 8902 file. 8904 The writing of the SDP session availability information, i.e. "t=" 8905 and "r=", needs to be carefully considered. When the SDP is fetched 8906 by the DESCRIBE method, the probability that it is valid is very 8907 high. However the same are much less certain for SDPs distributed 8908 using other methods. Therefore the publisher of the SDP should take 8909 care to follow the recommendations about availability in the SDP 8910 specification [RFC4566]. 8912 Appendix D. Minimal RTSP Implementation 8914 This section defines the minimal implementation requirements for RTSP 8915 agents. 8917 D.1. Minimal Core Implementation 8919 The minimal core implementation is what is required to negotiate the 8920 usage of any other features. A minimal core implementation is not 8921 supporting any other feature set will be useless as the minimal 8922 implementation doesn't deliver any service. All feature sets SHALL 8923 include the minimal core. 8925 A minimal core implementation SHALL support the following 8926 functionalities: 8928 o Establishing a connection between RTSP agents using TCP. 8930 o Implement the reception and response to the OPTIONS method. 8932 o Implement the handling of all headers mandatory or conditional in 8933 regards to the usage of the OPTIONS method. See Table 9 and 8934 Table 10. This include at least the capability to ignore unknown 8935 headers. 8937 o Implement the headers related to capability negotiation and 8938 exchange: 8940 * Require 8942 * Supported 8944 * Proxy-Require 8946 * Proxy-Supported 8948 * Unsupported 8950 D.2. Recommended Core Implementation 8952 A RTSP Agent is also RECOMMENDED to support the following: 8954 o RTSP basic and digest authentication: The 401 response, the WWW- 8955 Authenticate and Authorization headers, and both Basic and Digest 8956 authentication methods as defined by [RFC2617]. 8958 o Secure RTSP message transport as specified by Appendix D.4. 8960 D.3. The Basic Playback Feature Support 8962 This section defines what is required to be supported for clients, 8963 proxies and servers to be supporting the "play.basic" feature-tag. 8965 D.3.1. Client 8967 A play.basic supporting client SHALL implement the following: 8969 o The RTSP methods as required by Table 7. 8971 o All the RTSP headers that are required required or conditional in 8972 requests or responses to method required to be supported according 8973 to Table 9, Table 10, Table 11, and Table 12 and in addition the 8974 following headers: 8976 * Content-Base 8978 * Content-Encoding and at least the Identity method. 8980 * Content-Location 8982 * Location 8984 * Range and the npt time format 8986 * RTP-Info 8988 o Handling of all Status code categories. 8990 o Media delivery using RTP/AVP over UDP. 8992 A play.basic supporting client is also RECOMMENDED to support the 8993 following: 8995 o Expires header 8997 o From header 8999 D.3.2. Server 9001 A play.basic supporting server SHALL implement the following: 9003 o The RTSP methods as required by Table 7. 9005 o Reception and responding to all headers specified in Section 16. 9006 The implementation of functionality provided by all these header 9007 with the following exceptions: 9009 * Scale 9011 * Speed 9013 * Blocksize 9015 o Media delivery using RTP/AVP over UDP. 9017 A play.basic supporting Server is also RECOMMENDED to support the 9018 following: 9020 o XXX Editor's note: empty element in minimal.text! 9022 D.3.3. Proxy 9024 A play.basic supporting proxy SHALL implement the following: 9026 o At least passing through all the methods listed in Table 7. 9028 o The handling of all RTSP headers that are required to be handled 9029 by the server and clients supporting "play.basic" and in addition 9030 the following headers: 9032 * Cache-Control 9034 * Expires 9036 * Via 9038 D.4. Secure Transport 9040 Any Client, Proxy or Server supporting secure transport of RTSP 9041 messages and usage of the "rtsps" URI scheme SHALL implement: 9043 o The Accept-Credentials and Connection-Credentials headers; 9045 o TLS over TCP. 9047 Appendix E. Requirements for Unreliable Transport of RTSP 9049 This section provides anyone intending to define how to transport of 9050 RTSP messages over a unreliable transport protocol with some 9051 information learned by the attempt in RFC 2326 [RFC2326]. RFC 2326 9052 define both an URI scheme and some basic functionality for transport 9053 of RTSP messages over UDP, however it was not sufficient for reliable 9054 usage and successful interoperability. 9056 The RTSP scheme defined for unreliable transport of RTSP messages was 9057 "rtspu". It has been reserved by this specification as at least one 9058 commercial implementation exist, thus avoiding any collisions in the 9059 name space. 9061 The following considerations should exist for operation of RTSP over 9062 an unreliable transport protocol: 9064 o Request shall be acknowledged by the receiver. If there is no 9065 acknowledgement, the sender may resend the same message after a 9066 timeout of one round-trip time (RTT). Any retransmissions due to 9067 lack of acknowledgement must carry the same sequence number as the 9068 original request. 9070 o The round-trip time can be estimated as in TCP (RFC 1123) 9071 [RFC1123], with an initial round-trip value of 500 ms. An 9072 implementation may cache the last RTT measurement as the initial 9073 value for future connections. 9075 o If RTSP is used over a small-RTT LAN, standard procedures for 9076 optimizing initial TCP round trip estimates, such as those used in 9077 T/TCP (RFC 1644) [RFC1644], can be beneficial. 9079 o The Timestamp header (Section 16.45) is used to avoid the 9080 retransmission ambiguity problem XXY Need ref for Stev94:TCP and 9081 obviates the need for Karn's algorithm. 9083 o The registered default port for RTSP over UDP for the server is 9084 554. 9086 o RTSP messages can be carried over any lower-layer transport 9087 protocol that is 8-bit clean. 9089 o RTSP messages are vulnerable to bit errors and should not be 9090 subjected to them. 9092 o Source authentication, or at least validation that RTSP messages 9093 comes from the same entity becomes extremely important, as session 9094 hijacking may be substantially easier for RTSP message transport 9095 using an unreliable protocol like UDP than for TCP. 9097 There exist two RTSP headers thats primarily are intended for being 9098 used by the unreliable handling of RTSP messages and which will be 9099 maintained: 9101 o [CSeq] See Section 16.19 9103 o [Timestamp] See Section 16.45 9105 Appendix F. Backwards Compatibility Considerations 9107 This section contains notes on issues about backwards compatibility 9108 with clients or servers being implemented according to RFC 2326 9109 [RFC2326]. Note that there exist no requirement to implement RTSP 9110 1.0, in fact we recommend against it as it is difficult to do in an 9111 interoperable way. 9113 A server implementing RTSP/2.0 MUST include a RTSP-Version of 9114 RTSP/2.0 in all responses to requests containing RTSP-Version 9115 RTSP/2.0. If a server receives a RTSP/1.0 request, it MAY respond 9116 with a RTSP/1.0 response if it chooses to support RFC 2326. If the 9117 server chooses not to support RFC 2326, it SHOULD respond with a 505 9118 (RTSP Version not supported) status code. A server MUST NOT respond 9119 to a RTSP-Version RTSP/1.0 request with a RTSP-Version RTSP/2.0 9120 response. 9122 Clients implementing RTSP/2.0 MAY use an OPTIONS request with a RTSP- 9123 Version of 2.0 to determine whether a server supports RTSP/2.0. If 9124 the server responds with either a RTSP-Version of 1.0 or a status 9125 code of 505 (RTSP Version not supported), the client will have to use 9126 RTSP/1.0 requests if it chooses to support RFC 2326. 9128 F.1. Play Request in Play mode 9130 The behavior in the server when a Play is received in Play mode has 9131 changed (Section 13.4). In RFC 2326, the new PLAY request would be 9132 queued until the current Play completed. Any new PLAY request now 9133 take effect immediately replacing the previous request. 9135 F.2. Using Persistent Connections 9137 Some server implementations of RFC 2326 maintain a one-to-one 9138 relationship between a connection and an RTSP session. Such 9139 implementations require clients to use a persistent connection to 9140 communicate with the server and when a client closes its connection, 9141 the server may remove the RTSP session. This is worth noting if a 9142 RTSP 2.0 client also supporting 1.0 connects to a 1.0 server. 9144 Appendix G. Open Issues 9146 This section contains a list of open issues that still needs to be 9147 resolved. However also any open issues in the bug tracker at 9148 http://rtspspec.sourceforge.net should also be considered. 9150 1. Should the SMPTE range format be updated to support the 50 and 9151 60 frames per second modes? 9153 2. Should we define a recommended format for error message bodies? 9155 3. Today there is no recommended or required format for 300 9156 response entities containing URI lists. Should one be defined? 9158 4. Should the dest_addr parameter in the Transport header in 9159 responses include the destination used by the server? 9161 5. Should a IPv6 multicast scope parameter for the Transport header 9162 be defined? This would be similar to TTL. 9164 6. The Expires header (Section 16.22 contains the below paragraph: 9166 Expires header field with a date value of some time in the 9167 future on a media stream that otherwise would by default be non- 9168 cacheable indicates that the media stream is cacheable, unless 9169 indicated otherwise by a Cache-Control header field 9170 (Section 16.10). 9172 Is there any purpose for this in RTSP, or could we remove this 9173 statement and instead rely on the Cache-Control header? 9175 7. Should proxies strip out the credentials for themselves when 9176 forwarding messages with Accept-Credentials? 9178 8. Is Session ID combined with TLS a sufficient mechanism to 9179 prevent hijacking? 9181 9. Move to start TLS mechanism like the one defined in RFC 2817? 9183 10. Look into the GRID communities proxy-certs and see how this 9184 relates to the current TLS proxy solution. 9186 11. Resolve Eric Rescorlas security comments on the Proxy TLS 9187 solution: 9189 1. There doesn't seem to be any way to communicate your cipher 9190 suite preferences. 9192 2. I don't see how certificate-based client authentication 9193 works. Is it supposed to? 9195 3. You need to provide the entire cert chain in Connection- 9196 Credentials, not just the certificate. 9198 12. Consider to switch to SHA256 instead of SHA1 for the digest over 9199 the DER encoded certs. 9201 13. Resolve the following Stephen Farrel issue: "C. I don't 9202 understand how the client-side proxies can be expected to know 9203 enough about proxies existing toward the server. If they don't 9204 then I'm not sure how they can be expected to make any decision 9205 that's better than would be the case were policy to be dealt 9206 with solely on a hop-by-hop basis. Maybe I'm missing something 9207 that can provide that information?" 9209 14. Resolve the following Stephen Farrel issue: "D. The "User" 9210 policy model is that a client presents acceptable name/URIs and 9211 digests to the proxy. TLS doesn't really provide a way for that 9212 proxy, as a client, to ask the server for the "right" 9213 certificate, so I suspect there's a gap here that'll be hard to 9214 fill. (If the client imposed a constraint as to the root-CA 9215 that had to be used then that'd map to the next TLS connection, 9216 but maybe it'd be too coarse-grained?)" 9218 Appendix H. Changes 9220 Compared to RTSP 1.0 (RFC 2326), the below changes has been made when 9221 defining RTSP 2.0. Note that this list does not reflect minor 9222 changes in wording or correction of typographical errors. 9224 o The Transport header has been changed in the following way: 9226 * The ABNF has been changed to define that extensions are 9227 possible, and that unknown extension parameters are to be 9228 ignored. 9230 * To prevent backwards compatibility issues, any extension or new 9231 parameter requires the usage of a feature-tag combined with the 9232 Require header. 9234 * Syntax unclarities with the Mode parameter has been resolved. 9236 * Syntax error with ";" for multicast and unicast has been 9237 resolved. 9239 * Two new addressing parameters has been defined, src_addr and 9240 dest_addr. These replaces the parameters "port", 9241 "client_port", "server_port", "destination", "source". 9243 * Support for IPv6 explicit addresses in all address fields has 9244 been included. 9246 * To handle URI definitions that contain ";" or "," a quoted URI 9247 format has been introduced and is required. 9249 * Defined IANA registries for the transport headers parameters, 9250 transport-protocol, profile, lower-transport, and mode. 9252 * The transport headers interleaved parameter's text was made 9253 more strict and use formal requirements levels. It was also 9254 clarified that the interleaved channels are symmetric and that 9255 it is the server that sets the channel numbers. 9257 * It has been clarified that the client can't request of the 9258 server to use a certain RTP SSRC, using a request with the 9259 transport parameter SSRC. 9261 * Syntax definition for SSRC has been clarified to require 8HEX. 9262 It has also been extend to allow multiple values for clients 9263 supporting this version. 9265 * Clarified the text on the transport headers "dest_addr" 9266 parameters regarding what security precautions the server is 9267 required to perform. 9269 o The Range formats has been changed in the following way: 9271 * The NPT format has been given a initial NPT identifier that 9272 must now be used. 9274 * All formats now support initial open ended formats of type 9275 "npt=-10". 9277 o RTSP message handling has been changed in the following way: 9279 * RTSP messages now uses URIs rather then URLs. 9281 * It has been clarified that a 4xx message due to missing CSeq 9282 header shall be returned without a CSeq header. 9284 * Rules for how to handle timing out RTSP messages has been 9285 added. 9287 * Extended Pipelining rules allowing for quick session startup. 9289 o The HTTP references has been updated to RFC 2616 and RFC 2617. 9290 This has resulted in that the Public, and the Content-Base header 9291 needed to be defined in the RTSP specification. Known effects on 9292 RTSP due to HTTP clarifications: 9294 * Content-Encoding header can include encoding of type 9295 "identity". 9297 o The state machine section has completely been rewritten. It 9298 includes now more details and are also more clear about the model 9299 used. 9301 o A IANA section has been included with contains a number of 9302 registries and their rules. This will allow us to use IANA to 9303 keep track of RTSP extensions. 9305 o Than transport of RTSP messages has seen the following changes: 9307 * The use of UDP for RTSP message transport has been deprecated 9308 due to missing interest and to broken specification. 9310 * The rules for how TCP connections is to be handled has been 9311 clarified. Now it is made clear that servers should not close 9312 the TCP connection unless they have been unused for significant 9313 time. 9315 * Strong recommendations why server and clients should use 9316 persistent connections has also been added. 9318 * There is now a requirement on the servers to handle non- 9319 persistent connections as this provides fault tolerance. 9321 * Added wording on the usage of Connection:Close for RTSP. 9323 * specified usage of TLS for RTSP messages, including a scheme to 9324 approve a proxies TLS connection to the next hop. 9326 o The following header related changes have been made: 9328 * Accept-Ranges response header is added. This header clarifies 9329 which range formats that can be used for a resource. 9331 * Changed the Range header to allow multiple ranges for creating 9332 editing list. 9334 * Fixed the missing definitions for the Cache-Control header. 9335 Also added to the syntax definition the missing delta-seconds 9336 for max-stale and min-fresh parameters. 9338 * Put requirement on CSeq header that the value is increased by 9339 one for each new RTSP request. A Recommendation to start at 1 9340 has also been added. 9342 * Added requirement that the Date header must be used for all 9343 messages with entity and the Server should always include it. 9345 * Removed possibility of using Range header with Scale header to 9346 indicate when it is to be activated, since it can't work as 9347 defined. Also added rule that lack of Scale header in response 9348 indicates lack of support for the header. Feature-tags for 9349 scaled playback has been defined. 9351 * The Speed header must now be responded to indicate support and 9352 the actual speed going to be used. A feature-tag is defined. 9353 Notes on congestion control was also added. 9355 * The Supported header was borrowed from SIP to help with the 9356 feature negotiation in RTSP. 9358 * Clarified that the Timestamp header can be used to resolve 9359 retransmission ambiguities. 9361 * The Session header text has been expanded with a explanation on 9362 keep alive and which methods to use. SET_PARAMETER is now 9363 recommended to use if only keep-alive within RTSP is desired. 9365 * It has been clarified how the Range header formats is used to 9366 indicate pause points in the PAUSE response. 9368 * Clarified that RTP-Info URIs that are relative, uses the 9369 Request-URI as base URI. Also clarified that used URI must be 9370 that one that was used in the SETUP request. They are now also 9371 required to be quoted. The header also expresses the SSRC for 9372 the provided RTP timestamp and sequence number values. 9374 * Added text that requires the Range to always be present in PLAY 9375 responses. Clarified what should be sent in case of live 9376 streams. 9378 * The headers table has been updated using a structured borrowed 9379 from SIP. Those tables carries much more information and 9380 should provide a good overview of the available headers. 9382 * It has been is clarified that any message with a message body 9383 is required to have a Content-Length header. This was the case 9384 in RFC 2326 but could be misinterpreted. 9386 * To resolve functionality around ETag. The ETag and If-None- 9387 Match header has been added from HTTP with necessary 9388 clarification in regards to RTSP operation. 9390 * Imported the Public header from HTTP RFC 2068 [RFC2068] since 9391 it has been removed from HTTP due to lack of use. Public is 9392 used quite frequently in RTSP. 9394 * Clarified rules for populating the Public header so that it is 9395 an intersection of the capabilities of all the RTSP agents in a 9396 chain. 9398 o The Protocol Syntax has been changed in the following way: 9400 * All BNF definitions are updated according to the rules defined 9401 in RFC 4234 [RFC4234] and has been gathered in a separate 9402 Section 21. 9404 * The BNF for the User-Agent and Server headers has been 9405 corrected so now only the description is in the HTTP 9406 specification. 9408 * Some definitions in the introduction regarding the RTSP session 9409 has been changed. 9411 * The protocol has been made fully IPv6 capable. Certain of the 9412 functionality, like using explicit IPv6 addresses in fields 9413 requires that the protocol support this updated specification. 9415 * Added a fragment part to the RTSP URI. This seem to be 9416 indicated by the note below the definition however it was not 9417 part of the BNF. 9419 * The CHAR rule has been changed to exclude NULL. 9421 o The Status codes has been changed in the following way: 9423 * The use of status code 303 "See Other" has been deprecated as 9424 it does not make sense to use in RTSP. 9426 * When sending response 451 and 458 the response body should 9427 contain the offending parameters. 9429 * Clarification on when a 3rr redirect status code can be 9430 received has been added. This includes receiving 3rr as a 9431 result of request within a established session. This provides 9432 clarification to a previous unspecified behavior. 9434 * Removed the 201 (Created) and 250 (Low On Storage Space) status 9435 codes as they are only relevant to recording, which is 9436 deprecated. 9438 o The following functionality has been deprecated from the protocol: 9440 * The use of Queued Play. 9442 * The use of PLAY method for keep-alive in play state. 9444 * The RECORD and ANNOUNCE methods and all related functionality. 9445 Some of the syntax has been removed. 9447 * The possibility to use timed execution of methods with the time 9448 parameter in the Range header. 9450 * The description on how rtspu works is not part of the core 9451 specification and will require external description. Only that 9452 it exist is defined here and some requirements for the the 9453 transport is provided. 9455 o The following changes has been made in relation to methods: 9457 * The OPTIONS method has been clarified with regards to the use 9458 of the Public and Allow headers. 9460 * The RECORD and ANNOUNCE methods are removed as they are lacking 9461 implementation and not considered necessary in the core 9462 specification. Any work on these methods should be done as a 9463 extension document to RTSP. 9465 * Added text clarifying the usage of SET_PARAMETER for keep-alive 9466 and usage without any body. 9468 * PLAY method is now allowed to be pipelined with the pipelining 9469 of one or more SETUP requests following the initial that 9470 generates the session for aggregated control. 9472 o Wrote a new section about how to setup different media transport 9473 alternatives and their profiles, and lower layer protocols. This 9474 resulted that the appendix on RTP interaction was moved there 9475 instead in the part describing RTP. The section also includes 9476 guidelines what to think of when writing usage guidelines for new 9477 protocols and profiles. 9479 o Setup and usage of independent TCP connections for transport of 9480 RTP has been specified. 9482 o Added a new section describing the available mechanisms to 9483 determine if functionality is supported, called "Capability 9484 Handling". Renamed option-tags to feature-tags. 9486 o Added a contributors section with people who have contributed 9487 actual text to the specification. 9489 o Added a section Use Cases that describes the major use cases for 9490 RTSP. 9492 o Clarified the usage of a=range and how to indicate live content 9493 that are not seekable with this header. 9495 o Text specifying the special behavior of PLAY for live content. 9497 H.1. Changes needing to be updated 9499 The minimal implementation specification has been changed: 9501 o Required Timestamp, Via, and Unsupported headers for a minimal 9502 server implementation. 9504 o Recommended that Cache-Control, Expires and Date headers be 9505 supported by server implementations. 9507 Appendix I. Acknowledgements 9509 This memorandum defines RTSP version 2.0 which is a revision of the 9510 Proposed Standard RTSP version 1.0 which is defined in [RFC2326]. 9511 The authors of this RFC are Henning Schulzrinne, Anup Rao, and Robert 9512 Lanphier. 9514 Both RTSP version 1.0 and RTSP versio 2.0 borrow format and 9515 descriptions from HTTP/1.1. 9517 This document has benefited greatly from the comments of all those 9518 participating in the MMUSIC-WG. In addition to those already 9519 mentioned, the following individuals have contributed to this 9520 specification: 9522 Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning, 9523 Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari, 9524 Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V. 9525 Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt, 9526 John K. Ho, Go Hori, Philipp Hoschka, Anne Jones, Anders Klemets, 9527 Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Thomas 9528 Marshall, Rob McCool, David Oran, Joerg Ott, Maria Papadopouli, Sujal 9529 Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Igor Plotnikov, 9530 Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff Smith, 9531 Alexander Sokolsky, Dale Stammen, John Francis Stracke, Maureen 9532 Chesire, David Walker, Geetha Srikantan, Stephan Wenger, Pekka Pessi, 9533 Jae-Hwan Kim, Holger Schmidt, Stephen Farrell, Xavier Marjou, Joe 9534 Pallas and Mela Martti. 9536 I.1. Contributors 9538 The following people have made written contributions that were 9539 included in the specification: 9541 o Tom Marshall contributed text on the usage of 3rr status codes. 9543 o Thomas Zheng contributed text on the usage of the Range in PLAY 9544 responses. 9546 o Sean Sheedy contributed text on the timeout behavior of RTSP 9547 messages and connections, and the 463 status code. 9549 o Fredrik Lindholm contributed text about the RTSP security 9550 framework. 9552 o John Lazzaro contributed the text for RTP over Independent TCP. 9554 o Aravind Narasimhan contributed by rewriting Media Transport 9555 Alternatives (Appendix B) and editorial improvements on a number 9556 of places in the specification. 9558 Appendix J. RFC Editor Consideration 9560 Please replace RFC XXXX with the RFC number this specification 9561 recieves. 9563 Please replace RFC YYYY with the RFC number that SAVPF 9564 [I-D.ietf-avt-profile-savpf] receives. 9566 Authors' Addresses 9568 Henning Schulzrinne 9569 Columbia University 9570 1214 Amsterdam Avenue 9571 New York, NY 10027 9572 USA 9574 Email: schulzrinne@cs.columbia.edu 9576 Anup Rao 9577 Cisco 9578 USA 9580 Email: anrao@cisco.com 9582 Rob Lanphier 9583 Real Networks 9584 Seattle, WA 9585 USA 9587 Email: robla@robla.net 9589 Magnus Westerlund 9590 Ericsson AB 9591 Torshamsgatan 23 9592 STOCKHOLM, SE-164 80 9593 SWEDEN 9595 Email: magnus.westerlund@ericsson.com 9597 Martin Stiemerling 9598 NEC Laboratories Europe, NEC Europe Ltd. 9599 Kurfuersten-Anlage 36 9600 Heidelberg 69115 9601 Germany 9603 Phone: +49 (0) 6221 4342 113 9604 Email: stiemerling@netlab.nec.de 9606 Full Copyright Statement 9608 Copyright (C) The IETF Trust (2007). 9610 This document is subject to the rights, licenses and restrictions 9611 contained in BCP 78, and except as set forth therein, the authors 9612 retain all their rights. 9614 This document and the information contained herein are provided on an 9615 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 9616 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 9617 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 9618 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 9619 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 9620 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 9622 Intellectual Property 9624 The IETF takes no position regarding the validity or scope of any 9625 Intellectual Property Rights or other rights that might be claimed to 9626 pertain to the implementation or use of the technology described in 9627 this document or the extent to which any license under such rights 9628 might or might not be available; nor does it represent that it has 9629 made any independent effort to identify any such rights. Information 9630 on the procedures with respect to rights in RFC documents can be 9631 found in BCP 78 and BCP 79. 9633 Copies of IPR disclosures made to the IETF Secretariat and any 9634 assurances of licenses to be made available, or the result of an 9635 attempt made to obtain a general license or permission for the use of 9636 such proprietary rights by implementers or users of this 9637 specification can be obtained from the IETF on-line IPR repository at 9638 http://www.ietf.org/ipr. 9640 The IETF invites any interested party to bring to its attention any 9641 copyrights, patents or patent applications, or other proprietary 9642 rights that may cover technology that may be required to implement 9643 this standard. Please address the information to the IETF at 9644 ietf-ipr@ietf.org. 9646 Acknowledgment 9648 Funding for the RFC Editor function is provided by the IETF 9649 Administrative Support Activity (IASA).