MMUSIC Working Group H. Schulzrinne Internet-Draft Columbia University Obsoletes: 2326 (if approved) A. Rao Intended status: Standards Track Cisco Expires: March 6, 2014 R. Lanphier M. Westerlund Ericsson AB M. Stiemerling (Ed.) NEC September 2, 2013 Real Time Streaming Protocol 2.0 (RTSP) draft-ietf-mmusic-rfc2326bis-35 Abstract This memorandum defines RTSP version 2.0 which obsoletes RTSP version 1.0 defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 6, 2014. Schulzrinne, et al. Expires March 6, 2014 [Page 1]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Schulzrinne, et al. Expires March 6, 2014 [Page 2]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 11 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 13 2.1. Presentation Description . . . . . . . . . . . . . . . . 13 2.2. Session Establishment . . . . . . . . . . . . . . . . . 14 2.3. Media Delivery Control . . . . . . . . . . . . . . . . . 15 2.4. Session Parameter Manipulations . . . . . . . . . . . . 17 2.5. Media Delivery . . . . . . . . . . . . . . . . . . . . . 18 2.5.1. Media Delivery Manipulations . . . . . . . . . . . . 18 2.6. Session Maintenance and Termination . . . . . . . . . . 20 2.7. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 21 3. Document Conventions . . . . . . . . . . . . . . . . . . . . 23 3.1. Notational Conventions . . . . . . . . . . . . . . . . . 23 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 23 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 27 4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 27 4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 27 4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 30 4.4. Media Time Formats . . . . . . . . . . . . . . . . . . . 30 4.4.1. SMPTE Relative Timestamps . . . . . . . . . . . . . 30 4.4.2. Normal Play Time . . . . . . . . . . . . . . . . . . 31 4.4.3. Absolute Time . . . . . . . . . . . . . . . . . . . 31 4.5. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 32 4.6. Message Body Tags . . . . . . . . . . . . . . . . . . . 32 4.7. Media Properties . . . . . . . . . . . . . . . . . . . . 33 4.7.1. Random Access and Seeking . . . . . . . . . . . . . 34 4.7.2. Retention . . . . . . . . . . . . . . . . . . . . . 34 4.7.3. Content Modifications . . . . . . . . . . . . . . . 34 4.7.4. Supported Scale Factors . . . . . . . . . . . . . . 35 4.7.5. Mapping to the Attributes . . . . . . . . . . . . . 35 5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 36 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 36 5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 37 5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 37 5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 38 6. General Header Fields . . . . . . . . . . . . . . . . . . . . 39 7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 41 7.2. Request Header Fields . . . . . . . . . . . . . . . . . 43 8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 45 8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 45 8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 49 9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 50 9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 50 9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 51 9.3. Message Body Format Negotiation . . . . . . . . . . . . 52 Schulzrinne, et al. Expires March 6, 2014 [Page 3]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 53 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 53 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 54 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 57 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 58 10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 59 10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 60 10.7. Overload Control . . . . . . . . . . . . . . . . . . . . 61 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 63 11.1. Feature Tag: play.basic . . . . . . . . . . . . . . . . 64 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 66 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 67 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 68 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 69 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 71 13.3.1. Changing Transport Parameters . . . . . . . . . . . 74 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 75 13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 75 13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 80 13.4.3. Updating current PLAY Requests . . . . . . . . . . . 81 13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 83 13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 84 13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 84 13.4.7. Playing Live with Recording . . . . . . . . . . . . 85 13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 85 13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 86 13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 87 13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 89 13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 90 13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 91 13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 94 13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 94 13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 95 13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 96 13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 98 13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 100 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 103 15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 15.1. Proxies and Protocol Extensions . . . . . . . . . . . . 106 15.2. Multiplexing and Demultiplexing of Messages . . . . . . 107 16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 16.1. Validation Model . . . . . . . . . . . . . . . . . . . . 108 16.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 110 16.1.2. Message Body Tag Cache Validators . . . . . . . . . 110 16.1.3. Weak and Strong Validators . . . . . . . . . . . . . 110 16.1.4. Rules for When to Use Message Body Tags and Last-Modified Dates . . . . . . . . . . . . . . . . 112 16.1.5. Non-validating Conditionals . . . . . . . . . . . . 114 Schulzrinne, et al. Expires March 6, 2014 [Page 4]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 16.2. Invalidation After Updates or Deletions . . . . . . . . 114 17. Status Code Definitions . . . . . . . . . . . . . . . . . . . 116 17.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 116 17.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 116 17.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 116 17.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 116 17.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 116 17.3.1. 300 . . . . . . . . . . . . . . . . . . . . . . . . 117 17.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 117 17.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 117 17.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 118 17.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 118 17.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 118 17.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 118 17.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 118 17.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 119 17.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 119 17.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 119 17.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 119 17.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 119 17.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 120 17.4.8. 407 Proxy Authentication Required . . . . . . . . . 120 17.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 120 17.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 120 17.4.11. 412 Precondition Failed . . . . . . . . . . . . . . 121 17.4.12. 413 Request Message Body Too Large . . . . . . . . . 121 17.4.13. 414 Request-URI Too Long . . . . . . . . . . . . . . 121 17.4.14. 415 Unsupported Media Type . . . . . . . . . . . . . 121 17.4.15. 451 Parameter Not Understood . . . . . . . . . . . . 121 17.4.16. 452 reserved . . . . . . . . . . . . . . . . . . . . 122 17.4.17. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 122 17.4.18. 454 Session Not Found . . . . . . . . . . . . . . . 122 17.4.19. 455 Method Not Valid in This State . . . . . . . . . 122 17.4.20. 456 Header Field Not Valid for Resource . . . . . . 122 17.4.21. 457 Invalid Range . . . . . . . . . . . . . . . . . 122 17.4.22. 458 Parameter Is Read-Only . . . . . . . . . . . . . 122 17.4.23. 459 Aggregate Operation Not Allowed . . . . . . . . 123 17.4.24. 460 Only Aggregate Operation Allowed . . . . . . . . 123 17.4.25. 461 Unsupported Transport . . . . . . . . . . . . . 123 17.4.26. 462 Destination Unreachable . . . . . . . . . . . . 123 17.4.27. 463 Destination Prohibited . . . . . . . . . . . . . 123 17.4.28. 464 Data Transport Not Ready Yet . . . . . . . . . . 123 17.4.29. 465 Notification Reason Unknown . . . . . . . . . . 124 17.4.30. 466 Key Management Error . . . . . . . . . . . . . . 124 17.4.31. 470 Connection Authorization Required . . . . . . . 124 17.4.32. 471 Connection Credentials not accepted . . . . . . 124 17.4.33. 472 Failure to establish secure connection . . . . . 124 17.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 124 Schulzrinne, et al. Expires March 6, 2014 [Page 5]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 17.5.1. 500 Internal Server Error . . . . . . . . . . . . . 124 17.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 125 17.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 125 17.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 125 17.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 125 17.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 125 17.5.7. 551 Option not supported . . . . . . . . . . . . . . 126 17.5.8. 553 Proxy Unavailable . . . . . . . . . . . . . . . 126 18. Header Field Definitions . . . . . . . . . . . . . . . . . . 127 18.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 137 18.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 138 18.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 138 18.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 139 18.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 140 18.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 141 18.7. Authentication-Info . . . . . . . . . . . . . . . . . . 141 18.8. Authorization . . . . . . . . . . . . . . . . . . . . . 141 18.9. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 142 18.10. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 143 18.11. Cache-Control . . . . . . . . . . . . . . . . . . . . . 143 18.12. Connection . . . . . . . . . . . . . . . . . . . . . . . 146 18.13. Connection-Credentials . . . . . . . . . . . . . . . . . 146 18.14. Content-Base . . . . . . . . . . . . . . . . . . . . . . 147 18.15. Content-Encoding . . . . . . . . . . . . . . . . . . . . 148 18.16. Content-Language . . . . . . . . . . . . . . . . . . . . 148 18.17. Content-Length . . . . . . . . . . . . . . . . . . . . . 149 18.18. Content-Location . . . . . . . . . . . . . . . . . . . . 149 18.19. Content-Type . . . . . . . . . . . . . . . . . . . . . . 150 18.20. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 151 18.21. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 152 18.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 153 18.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 154 18.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 155 18.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 155 18.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 155 18.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 156 18.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 157 18.29. Media-Properties . . . . . . . . . . . . . . . . . . . . 157 18.30. Media-Range . . . . . . . . . . . . . . . . . . . . . . 159 18.31. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 160 18.32. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 160 18.33. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 160 18.34. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 161 18.35. Proxy-Authentication-Info . . . . . . . . . . . . . . . 162 18.36. Proxy-Authorization . . . . . . . . . . . . . . . . . . 162 18.37. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 162 18.38. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 162 18.39. Public . . . . . . . . . . . . . . . . . . . . . . . . . 163 Schulzrinne, et al. Expires March 6, 2014 [Page 6]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 18.40. Range . . . . . . . . . . . . . . . . . . . . . . . . . 164 18.41. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 166 18.42. Request-Status . . . . . . . . . . . . . . . . . . . . . 166 18.43. Require . . . . . . . . . . . . . . . . . . . . . . . . 167 18.44. Retry-After . . . . . . . . . . . . . . . . . . . . . . 168 18.45. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 168 18.46. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 170 18.47. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 171 18.48. Server . . . . . . . . . . . . . . . . . . . . . . . . . 173 18.49. Session . . . . . . . . . . . . . . . . . . . . . . . . 173 18.50. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 175 18.51. Supported . . . . . . . . . . . . . . . . . . . . . . . 176 18.52. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 176 18.53. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 177 18.54. Transport . . . . . . . . . . . . . . . . . . . . . . . 177 18.55. Unsupported . . . . . . . . . . . . . . . . . . . . . . 184 18.56. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 185 18.57. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 185 18.58. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 186 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 187 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 187 19.1.1. Digest Authentication . . . . . . . . . . . . . . . 188 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 188 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 189 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 191 19.3.2. User approved TLS procedure . . . . . . . . . . . . 192 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 194 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 196 20.2.1. Generic Protocol elements . . . . . . . . . . . . . 196 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 199 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 203 20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 212 21. Security Considerations . . . . . . . . . . . . . . . . . . . 213 21.1. Signaling Protocol Threats . . . . . . . . . . . . . . . 213 21.2. Media Stream Delivery Threats . . . . . . . . . . . . . 216 21.2.1. Remote Denial of Service Attack . . . . . . . . . . 217 21.2.2. RTP Security analysis . . . . . . . . . . . . . . . 218 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 220 22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 221 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 221 22.1.2. Registering New Feature-tags with IANA . . . . . . . 221 22.1.3. Registered entries . . . . . . . . . . . . . . . . . 221 22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 222 22.2.1. Description . . . . . . . . . . . . . . . . . . . . 222 22.2.2. Registering New Methods with IANA . . . . . . . . . 222 22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 222 22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 223 Schulzrinne, et al. Expires March 6, 2014 [Page 7]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 1 . Introduction RFC2326] and obsoletes that specification. This protocol is based on RTSP 1.0 but is not backwards compatible other than in the basic version negotiation mechanism. The changes are documented in Appendix I. There are many reasons why RTSP 2.0 can't be backwards compatible with RTSP 1.0 but some of the main ones are: o Most headers that needed to be extensible did not define the allowed syntax, preventing safe deployment of extensions; o The changed behavior of the PLAY method when received in Play state; o Changed behavior of the extensibility model and its mechanism; o The change of syntax for some headers. In summary, there are so many small details that changing version became necessary to enable clarification and consistent behavior. This document is structured as follows. It begins with an overview of the protocol operations and its functions in an informal way. Then a set of definitions of terms used and document conventions is introduced. It is followed by the actual RTSP 2.0 core protocol specification. The appendixes describe and define some functionalities that are not part of the core RTSP specification, but Schulzrinne, et al. Expires March 6, 2014 [Page 11]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 which are still important to enable some usages. Among them, the RTP usage is defined in Appendix C, the Session Description Protocol (SDP) usage with RTSP is defined in Appendix D, and the text/ parameters file format Appendix F, are three normative specification appendixes. Others include a number of informational parts discussing the changes, use cases, different considerations or motivations. Schulzrinne, et al. Expires March 6, 2014 [Page 12]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 2 . Protocol Overview Appendix E. RTSP 2.0 is a bi-directional request and response protocol that first establishes a context including content resources (the media) and then controls the delivery of these content resources from the provider to the consumer. RTSP has three fundamental parts: Session Establishment, Media Delivery Control, and an extensibility model described below. The protocol is based on some assumptions about existing functionality to provide a complete solution for client controlled real-time media delivery. RTSP uses text-based messages, requests and responses, that may contain a binary message body. An RTSP request starts with a method line that identifies the method, the protocol and version and the resource to act on. The resource is identified by an URI and the hostname part of the URI is used by RTSP client to resolve the IPv4 or IPv6 address of the RTSP server. Following the method line are a number of RTSP headers. This part is ended by two consecutive carriage return line feed (CRLF) character pairs. The message body if present follows the two CRLF and the body's length is described by a message header. RTSP responses are similar, but start with a response line with the protocol and version, followed by a status code and a reason phrase. RTSP messages are sent over a reliable transport protocol between the client and server. RTSP 2.0 requires clients and servers to implement TCP, and TLS over TCP, as mandatory transports for RTSP messages. 2.1 . Presentation Description Section 13.2). Parameters that commonly have to be included in the Presentation Description are the following: Schulzrinne, et al. Expires March 6, 2014 [Page 13]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 o Number of media streams; o The resource identifier for each media stream/resource that is to be controlled by RTSP; o The protocol that each media stream is to be delivered over; o Transport protocol parameters that are not negotiated or vary with each client; o Media encoding information enabling a client to correctly decode the media upon reception; o An aggregate control resource identifier. RTSP uses its own URI schemes ("rtsp" and "rtsps") to reference media resources and aggregates under common control (See Section 4.2). This specification describes in Appendix D how one uses SDP [RFC4566] for Presentation Description 2.2 . Session Establishment Section 13.3) to the server. In the SETUP request the client also includes all the transport parameters necessary to enable the media delivery protocol to function in the "Transport" header (Section 18.54). This includes parameters that are pre-established by the presentation description but necessary for any middlebox to correctly handle the media delivery protocols. The Transport header in a request may contain multiple alternatives for media delivery in a prioritized list, which the server can select from. These alternatives are typically based on information in the presentation description. The server determines if the media resource is available upon receiving a SETUP request and if any of the transport parameter specifications are acceptable. If that is successful, an RTSP session context is created and the relevant parameters and state is stored. An identifier is created for the RTSP session and included Schulzrinne, et al. Expires March 6, 2014 [Page 14]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 in the response in the Session header (Section 18.49). The SETUP response includes a Transport header that specifies which of the alternatives has been selected and relevant parameters. A SETUP request that references an existing RTSP session but identifies a new media resource is a request to add that media resource under common control with the already present media resources in an aggregated session. A client can expect this to work for all media resources under RTSP control within a multi-media content. However, aggregating resources from different content are likely to be refused by the server. The RTSP session as aggregate is referenced by the aggregate control URI, even if the RTSP session only contains a single media. To avoid an extra round trip in the session establishment of aggregated RTSP sessions, RTSP 2.0 supports pipelined requests; i.e., the client can send multiple requests back-to-back without waiting first for the completion of any of them. The client uses a client- selected identifier in the Pipelined-Requests header (Section 18.33) to instruct the server to bind multiple requests together as if they included the session identifier. The SETUP response also provides additional information about the established sessions in a couple of different headers. The Media- Properties header (Section 18.29) includes a number of properties that apply for the aggregate that is valuable when doing media delivery control and configuring user interface. The Accept-Ranges header (Section 18.5) informs the client about which range formats that the server supports with these media resources. The Media-Range header (Section 18.30) informs the client about the time range of the media currently available. 2.3 . Media Delivery Control Section 13.4) and Halt by using the PAUSE method (Section 13.6). PLAY also allows for choosing the starting media position from which the server should deliver the media. The positioning is done by using the Range header (Section 18.40) that supports several different time formats: Normal Play Time (NPT) (Section 4.4.2), Society of Motion Picture and Television Engineers (SMPTE) Timestamps (Section 4.4.1) and absolute time (Section 4.4.3). The Range header does further allow the client to specify a position where delivery should end, thus allowing a specific interval to be delivered. The support for positioning/searching within a content depends on the Schulzrinne, et al. Expires March 6, 2014 [Page 15]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 content's media properties. Content exists in a number of different types, such as: on-demand, live, and live with simultaneous recording. Even within these categories there are differences in how the content is generated and distributed, which affect how it can be accessed for playback. The properties applicable for the RTSP session are provided by the server in the SETUP response using the Media-Properties header (Section 18.29). These are expressed using one or several independent attributes. A first attribute is Random Access, which expresses if positioning can be done, and with what granularity. Another aspect is whether the content will change during the lifetime of the session. While on-demand content will be provided in full from the beginning, a live stream being recorded results in the length of the accessible content growing as the session goes on. There also exists content that is dynamically built by another protocol than RTSP and thus also changes in steps during the session, but maybe not continuously. Furthermore, when content is recorded, there are cases where not the complete content is maintained, but, for example, only the last hour. All these properties result in the need for mechanisms that will be discussed below. When the client accesses on-demand content that allows random access, the client can issue the PLAY request for any point in the content between the start and the end. The server will deliver media from the closest random access point prior to the requested point and indicate that in its PLAY response. If the client issues a PAUSE, the delivery will be halted and the point at which the server stopped will be reported back in the response. The client can later resume by sending a PLAY request without a range header. When the server is about to complete the PLAY request by delivering the end of the content or the requested range, the server will send a PLAY_NOTIFY request (Section 13.5) indicating this. When playing live content with no extra functions, such as recording, the client will receive the live media from the server after having sent a PLAY request. Seeking in such content is not possible as the server does not store it, but only forwards it from the source of the session. Thus delivery continues until the client sends a PAUSE request, tears down the session, or the content ends. For live sessions that are being recorded the client will need to keep track of how the recording progresses. Upon session establishment the client will learn the current duration of the recording from the Media-Range header. As the recording is ongoing the content grows in direct relation to the passed time. Therefore, each server's response to a PLAY request will contain the current Media-Range header. The server should also regularly send approximately every 5 minutes the current media range in a Schulzrinne, et al. Expires March 6, 2014 [Page 16]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 PLAY_NOTIFY request (Section 13.5.2). If the live transmission ends, the server must send a PLAY_NOTIFY request with the updated Media- Properties indicating that the content stopped being a recorded live session and instead became on-demand content; the request also contains the final media range. While the live delivery continues the client can request to play the current live point by using the NPT timescale symbol "now", or it can request a specific point in the available content by an explicit range request for that point. If the requested point is outside of the available interval the server will adjust the position to the closest available point, i.e., either at the beginning or the end. A special case of recording is that where the recording is not retained longer than a specific time period, thus as the live delivery continues the client can access any media within a moving window that covers, for example, "now" to "now" minus 1 hour. A client that pauses on a specific point within the content may not be able to retrieve the content anymore. If the client waits too long before resuming the pause point, the content may no longer be available. In this case the pause point will be adjusted to the closest point in the available media. 2.4 . Session Parameter Manipulations Section 13.8) and SET_PARAMETER (Section 13.9). These methods carry the parameters in a message body of the appropriate format. One can also use headers to query state with the GET_PARAMETER method. As an example, clients needing to know the current media-range for a time-progressing session can use the GET_PARAMETER method and include the media-range. Furthermore, synchronization information can be requested by using a combination of RTP-Info (Section 18.45) and Range (Section 18.40). RTSP 2.0 does not have a strong mechanism for providing negotiation of the headers, or parameters and their formats, which can be used. However, responses will indicate request headers or parameters that are not supported. A priori determination of what features are available needs to be done through out-of-band mechanisms, like the session description, or through the usage of feature tags (Section 4.5). Schulzrinne, et al. Expires March 6, 2014 [Page 17]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 2.5 . Media Delivery RFC3550] over UDP [RFC0768], TCP [RFC0793] or the RTSP connection. Additional protocols may be specified in the future based on demand. The usage of RTP as media delivery protocol requires some additional information to function well. The PLAY response contains information to enable reliable and timely delivery of how a client should synchronize different sources in the different RTP sessions. It also provides a mapping between RTP timestamps and the content time scale. When the server wants to notify the client about the completion of the media delivery, it sends a PLAY_NOTIFY request to the client. The PLAY_NOTIFY request includes information about the stream end, including the last RTP sequence number for each stream, thus enabling the client to empty the buffer smoothly. 2.5.1 . Media Delivery Manipulations Section 18.46) is used for fast forward or slow motion control as it changes the amount of content timescale that should be played back per time unit. Scale > 1.0, means fast forward, e.g., Scale=2.0 results in that 2 seconds of content is played back every second of playback. Scale = 1.0 is the default value that is used if no Scale is specified, i.e., playback at the content's original rate. Scale values between 0 and 1.0 is providing for slow motion. Scale can be negative to allow for reverse playback in either regular pace (Scale = -1.0) or fast backwards (Scale < -1.0) or slow motion backwards (-1.0 < Scale < 0). Scale = 0 is equal to pause and is not allowed. Schulzrinne, et al. Expires March 6, 2014 [Page 18]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 In most cases the realization of scale means server side manipulation of the media to ensure that the client can actually play it back. The nature of these media manipulations and when they are needed is highly media-type dependent. Let's consider an example with two common media types audio and video. It is very difficult to modify the playback rate of audio. A maximum of 10-30% is possible by changing the pitch-rate of speech. Music goes out of tune if one tries to manipulate the playback rate by resampling it. This is a well known problem and audio is commonly muted or played back in short segments with skips to keep up with the current playback point. For video it is possible to manipulate the frame rate, although the rendering capabilities are often limited to certain frame rates. Also the allowed bitrates in decoding, the structure used in the encoding and the dependency between frames and other capabilities of the rendering device limits the possible manipulations. Therefore, the basic fast forward capabilities often are implemented by selecting certain subsets of frames. Due to the media restrictions, the possible scale values are commonly restricted to the set of realizable scale ratios. To enable the clients to select from the possible scale values, RTSP can signal the supported Scale ratios for the content. To support aggregated or dynamic content, where this may change during the ongoing session and dependent on the location within the content, a mechanism for updating the media properties and the scale factor currently in use, exists. Speed (Section 18.50) affects how much of the playback timeline is delivered in a given wallclock period. The default is Speed = 1 which means to deliver at the same rate the media is consumed. Speed > 1 means that the receiver will get content faster than it regularly would consume it. Speed < 1 means that delivery is slower than the regular media rate. Speed values of 0 or lower have no meaning and are not allowed. This mechanism enables two general functionalities. One is client side scale operations, i.e., the client receives all the frames and makes the adjustment to the playback locally. The second is delivery control for buffering of media. By specifying a speed over 1.0 the client can build up the amount of playback time it has present in its buffers to a level that is sufficient for its needs. A naive implementation of Speed would only affect the transmission schedule of the media and has a clear impact on the needed bandwidth. This would result in the data rate being proportional to the speed factor. Speed = 1.5, i.e., 50% faster than normal delivery, would Schulzrinne, et al. Expires March 6, 2014 [Page 19]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 result in a 50% increase in the data transport rate. If that can be supported or not depends solely on the underlying network path. Scale may also have some impact on the required bandwidth due to the manipulation of the content in the new playback schedule. An example is fast forward where only the independently decodable intra frames are included in the media stream. This usage of solely intra frames increases the data rate significantly compared to a normal sequence with the same number of frames, where most frames are encoded using prediction. This potential increase of the data rate needs to be handled by the media sender. The client has requested that the media will be delivered in a specific way, which should be honored. However, the media sender cannot ignore if the network path between the sender and the receiver can't handle the resulting media stream. In that case the media stream needs to be adapted to fit the available resources of the path. This can result in a reduced media quality. The need for bitrate adaptation becomes especially problematic in connection with the Speed semantics. If the goal is to fill up the buffer, the client may not want to do that at the cost of reduced quality. If the client wants to make local playout changes then it may actually require that the requested speed be honored. To resolve this issue, Speed uses a range so that both cases can be supported. The server is requested to use the highest possible speed value within the range which is compatible with the available bandwidth. As long as the server can maintain a speed value within the range it shall not change the media quality, but instead modify the actual delivery rate in response to available bandwidth and reflect this in the Speed value in the response. However, if this is not possible, the server should instead modify the media quality to respect the lowest speed value and the available bandwidth. This functionality enables the local scaling implementation to use a tight range, or even a range where the lower bound equals the upper bound, to identify that it requires the server to deliver the requested amount of media time per delivery time independent of how much it needs to adapt the media quality to fit within the available path bandwidth. For buffer filling, it is suitable to use a range with a reasonable span and with a lower bound at the nominal media rate 1.0, such as 1.0 - 2.5. If the client wants to reduce the buffer, it can specify an upper bound that is below 1.0 to force the server to deliver slower than the nominal media rate. 2.6 . Session Maintenance and Termination Schulzrinne, et al. Expires March 6, 2014 [Page 20]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 o Media transport protocol keep-alive. RTP Control Protocol (RTCP) may be used when using RTP. o Any RTSP request referencing the session context. Section 10.5 discusses the methods for showing liveness in more depth. If the client fails to show liveness for more than the established session timeout value (normally 60 seconds), the server may terminate the context. Other values may be selected by the server through the inclusion of the timeout parameter in the session header. The session context is normally terminated by the client sending a TEARDOWN request (Section 13.7) to the server referencing the aggregated control URI. An individual media resource can be removed from a session context by a TEARDOWN request referencing that particular media resource. If all media resources are removed from a session context, the session context is terminated. A client may keep the session alive indefinitely if allowed by the server; however, it is recommended to release the session context when an extended period of time without media delivery activity has passed. The client can re-establish the session context if required later. What constitutes an extended period of time is dependent on the server and its usage. It is recommended that the client terminates the session before ten times the session timeout value has passed. A server may terminate the session after one session timeout period without any client activity beyond keep-alive. When a server terminates the session context, it does that by sending a TEARDOWN request indicating the reason. A server can also request that the client tear down the session and re-establish it at an alternative server, as may be needed for maintenance. This is done by using the REDIRECT method (Section 13.10). The Terminate-Reason header (Section 18.52) is used to indicate when and why. The Location header indicates where it should connect if there is an alternative server available. When the deadline expires, the server simply stops providing the service. To achieve a clean closure, the client needs to initiate session termination prior to the deadline. In case the server has no other server to redirect to, and wants to close the session for maintenance, it shall use the TEARDOWN method with a Terminate-Reason header. 2.7 . Extending RTSP Schulzrinne, et al. Expires March 6, 2014 [Page 21]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 blocks of functionality that are optional to implement. The use case and need for the protocol deployment should determine what parts are implemented. Allowing for extensions makes it possible for RTSP to reach out to additional use cases. However, extensions will affect the interoperability of the protocol and therefore it is important that they can be added in a structured way. The client can learn the capability of a server by using the OPTIONS method (Section 13.1) and the Supported header (Section 18.51). It can also try and possibly fail using new methods, or require that particular features are supported using the Require (Section 18.43) or Proxy-Require (Section 18.37) header. The RTSP protocol in itself can be extended in three ways, listed here in increasing order of the magnitude of changes supported: o Existing methods can be extended with new parameters, for example, headers, as long as these parameters can be safely ignored by the recipient. If the client needs negative acknowledgment when a method extension is not supported, a tag corresponding to the extension may be added in the field of the Require or Proxy- Require headers. o New methods can be added. If the recipient of the message does not understand the request, it must respond with error code 501 (Not Implemented) so that the sender can avoid using this method again. A client may also use the OPTIONS method to inquire about methods supported by the server. The server must list the methods it supports using the Public response header. o A new version of the protocol can be defined, allowing almost all aspects (except the position of the protocol version number) to change. A new version of the protocol must be registered through an IETF standards track document. The basic capability discovery mechanism can be used to both discover support for a certain feature and to ensure that a feature is available when performing a request. For a detailed explanation of this see Section 11. New media delivery protocols may be added and negotiated at session establishment, in addition to extensions to the core protocol. Certain types of protocol manipulations can be done through parameter formats using SET_PARAMETER and GET_PARAMETER. Schulzrinne, et al. Expires March 6, 2014 [Page 22]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 3 . Document Conventions 3.1 . Notational Conventions RFC2616]). All the mechanisms specified in this document are described in both prose and the Augmented Backus-Naur form (ABNF) described in detail in [RFC5234]. Indented paragraphs are used to provide informative background and motivation. This is intended to give readers who were not involved with the formulation of the specification an understanding of why things are the way they are in RTSP. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The word, "unspecified" is used to indicate functionality or features that are not defined in this specification. Such functionality cannot be used in a standardized manner without further definition in an extension specification to RTSP. 3.2 . Terminology Section 13.3 for more information. Client: The client requests media service from the media server. Connection: A transport layer virtual circuit established between two programs for the purpose of communication. Schulzrinne, et al. Expires March 6, 2014 [Page 23]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 Container file: A file which may contain multiple media streams which often constitutes a presentation when played together. The concept of a container file is not embedded in the protocol. However, RTSP servers may offer aggregate control on the media streams within these files. Continuous media: Data where there is a timing relationship between source and sink; that is, the sink needs to reproduce the timing relationship that existed at the source. The most common examples of continuous media are audio and motion video. Continuous media can be real-time (interactive or conversational), where there is a "tight" timing relationship between source and sink, or streaming where the relationship is less strict. Feature-tag: A tag representing a certain set of functionality, i.e., a feature. IRI: Internationalized Resource Identifier, is the same as an URI, with the exception that it allows characters from the whole Universal Character Set (Unicode/ISO 10646), rather than the US- ASCII only. See [RFC3987] for more information. Live: Normally used to describe a presentation or session with media coming from an ongoing event. This generally results in the session having an unbound or only loosely defined duration, and sometimes no seek operations are possible. Media initialization: Datatype/codec specific initialization. This includes such things as clock rates, color tables, etc. Any transport-independent information which is required by a client for playback of a media stream occurs in the media initialization phase of stream setup. Media parameter: Parameter specific to a media type that may be changed before or during stream delivery. Media server: The server providing media delivery services for one or more media streams. Different media streams within a presentation may originate from different media servers. A media server may reside on the same host or on a different host from which the presentation is invoked. (Media) stream: A single media instance, e.g., an audio stream or a video stream as well as a single whiteboard or shared application group. When using RTP, a stream consists of all RTP and RTCP packets created by a source within an RTP session. Schulzrinne, et al. Expires March 6, 2014 [Page 24]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 Message: The basic unit of RTSP communication, consisting of a structured sequence of octets matching the syntax defined in Section 20 and transmitted over a connection-based transport. A message is either a Request or a Response. Message Body: The information transferred as the payload of a message (Request or response). A message body consists of meta- information in the form of message-body headers and content in the form of a message-body, as described in Section 9. Non-Aggregated Control: Control of a single media stream. Presentation: A set of one or more streams presented to the client as a complete media feed and described by a presentation description as defined below. Presentations with more than one media stream are often handled in RTSP under aggregate control. Presentation description: A presentation description contains information about one or more media streams within a presentation, such as the set of encodings, network addresses and information about the content. Other IETF protocols such as SDP ([RFC4566]) use the term "session" for a presentation. The presentation description may take several different formats, including but not limited to the session description protocol format, SDP. Response: An RTSP response to a Request. One type of RTSP message. If an HTTP response is meant, it is indicated explicitly. Request: An RTSP request. One type of RTSP message. If an HTTP request is meant, it is indicated explicitly. Request-URI: The URI used in a request to indicate the resource on which the request is to be performed. RTSP agent: Refers to either an RTSP client, an RTSP server, or an RTSP proxy. In this specification, there are many capabilities that are common to these three entities such as the capability to send requests or receive responses. This term will be used when describing functionality that is applicable to all three of these entities. RTSP session: A stateful abstraction upon which the main control methods of RTSP operate. An RTSP session is a common context; it is created and maintained on client's request and can be destroyed by either the client or server. It is established by an RTSP server upon the completion of a successful SETUP request (when a 200 OK response is sent) and is labeled with a session identifier at that time. The session exists until timed out by the server or Schulzrinne, et al. Expires March 6, 2014 [Page 25]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 explicitly removed by a TEARDOWN request. An RTSP session is a stateful entity; an RTSP server maintains an explicit session state machine (see Appendix B) where most state transitions are triggered by client requests. The existence of a session implies the existence of state about the session's media streams and their respective transport mechanisms. A given session can have one or more media streams associated with it. An RTSP server uses the session to aggregate control over multiple media streams. Origin Server: The server on which a given resource resides. Transport initialization: The negotiation of transport information (e.g., port numbers, transport protocols) between the client and the server. URI: Universal Resource Identifier, see [RFC3986]. The URIs used in RTSP are generally URLs as they give a location for the resource. As URLs are a subset of URIs, they will be referred to as URIs to cover also the cases when an RTSP URI would not be an URL. URL: Universal Resource Locator, is an URI which identifies the resource through its primary access mechanism, rather than identifying the resource by name or by some other attribute(s) of that resource. Schulzrinne, et al. Expires March 6, 2014 [Page 26]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 4 . Protocol Parameters 4.1 . RTSP Version 4.2 . RTSP IRI and URI RFC 3986 defined mechanism. o A new relative format to use in the RTSP protocol elements that is not required to start with "/". Neither should have any significant impact on interoperability. If one is required to use IPv6 literals to reach an RTSP server, then Schulzrinne, et al. Expires March 6, 2014 [Page 27]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 that RTSP server must be IPv6 capable, and RTSP 1.0 is not a fully IPv6 capable protocol. If an RTSP 1.0 client attempts to process the URI it will not match the allowed syntax and be considered invalid and processing will be stopped. This is clearly a failure to reach the resource, however it is not a signification issue as RTSP 2.0 support was needed anyway in both server and client. Thus failure will only occur in a later step when there is a RTSP version mismatch between client and server. The second change will only occur inside RTSP message headers, as the request URI must be an absolute URI. Thus such usages are occurring after agents has accepted processing RTSP 2.0 messages, and an RTSP 1.0 only agent will not be required to parse such types of relative URIs. This specification also defines the format of the RTSP IRI [RFC3987] that can be used as RTSP resource identifiers and locators, in web pages, user interfaces, on paper, etc. However, the RTSP request message format only allows usage of the absolute URI format. The RTSP IRI format MUST use the rules and transformation for IRIs to URIs, as defined in [RFC3987]. This allows a URI that matches the RTSP 2.0 specification, and so is suitable for use in a request, to be created from an RTSP IRI. The RTSP IRI and URI are both syntax restricted compared to the generic syntax defined in [RFC3986] and [RFC3987]: o An absolute URI requires the authority part; i.e., a host identity MUST be provided. o Parameters in the path element are prefixed with the reserved separator ";". The RTSP URI and IRI are case sensitive, with the exception of those parts that [RFC3986] and [RFC3987] define as case-insensitive; for example, the scheme and host part. The fragment identifier is used as defined in sections 3.5 and 4.3 of [RFC3986], i.e., the fragment is to be stripped from the IRI by the requester and not included in the request URI. The user agent needs to interpret the value of the fragment based on the media type the request relates to; i.e., the media type indicated in Content-Type header in the response to DESCRIBE. The syntax of any URI query string is unspecified and responder (usually the server) specific. The query is, from the requester's perspective, an opaque string and needs to be handled as such. Please note that relative URI with queries are difficult to handle due to the RFC 3986 relative URI handling rules. Any change of the path element using a relative URI results in the stripping of the Schulzrinne, et al. Expires March 6, 2014 [Page 28]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 query, which means the relative part needs to contain the query. The URI scheme "rtsp" requires that commands are issued via a reliable protocol (within the Internet, TCP), while the scheme "rtsps" identifies a reliable transport using secure transport (TLS [RFC5246], see (Section 19). For the scheme "rtsp", if no port number is provided in the authority part of the URI, the port number 554 MUST be used. For the scheme "rtsps", if no port number is provided in the authority part of the URI port number, the TCP port 322 MUST be used. A presentation or a stream is identified by a textual media identifier, using the character set and escape conventions of URIs [RFC3986]. URIs may refer to a stream or an aggregate of streams; i.e., a presentation. Accordingly, requests described in (Section 13) can apply to either the whole presentation or an individual stream within the presentation. Note that some request methods can only be applied to streams, not presentations, and vice versa. For example, the RTSP URI: rtsp://media.example.com:554/twister/audiotrack may identify the audio stream within the presentation "twister", which can be controlled via RTSP requests issued over a TCP connection to port 554 of host media.example.com. Also, the RTSP URI: rtsp://media.example.com:554/twister identifies the presentation "twister", which may be composed of audio and video streams, but could also be something else like a random media redirector. This does not imply a standard way to reference streams in URIs. The presentation description defines the hierarchical relationships in the presentation and the URIs for the individual streams. A presentation description may name a stream "a.mov" and the whole presentation "b.mov". The path components of the RTSP URI are opaque to the client and do not imply any particular file system structure for the server. Schulzrinne, et al. Expires March 6, 2014 [Page 29]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 This decoupling also allows presentation descriptions to be used with non-RTSP media control protocols simply by replacing the scheme in the URI. 4.3 . Session Identifiers RFC4086]). It is RECOMMENDED that it contains 128 bits of entropy, i.e., approximately 22 characters from a high quality generator (see Section 21). However, note that the session identifier does not provide any security against session hijacking unless it is kept confidential by the client, server and trusted proxies. 4.4 . Media Time Formats Section 18.40) to request playback and specify at which media position protocol requests actually will or has taken place. They are also used in description of the media's properties using the Media-Range header (Section 18.30). The format identifier only are used in Accept- Ranges header (Section 18.5) to declare supported time formats and also in the Range header (Section 18.40) to request the time format used in the response. 4.4.1 . SMPTE Relative Timestamps SMPTE_TC] for frame- level access accuracy. The time code has the format hours:minutes:seconds:frames.subframes, with the origin at the start of the clip. The default SMPTE format is "SMPTE 30 drop" format, with frame rate is 29.97 frames per second. Other SMPTE codes MAY be supported (such as "SMPTE 25") through the use of "smpte-type". For SMPTE 30, the "frames" field in the time value can assume the values 0 through 29. The difference between 30 and 29.97 frames per second is handled by dropping the first two frame indices (values 00 and 01) of every minute, except every tenth minute. If the frame and the subframe values are zero, they may be omitted. Subframes are measured in one-hundredth of a frame. Examples: Schulzrinne, et al. Expires March 6, 2014 [Page 30]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 smpte=10:12:33:20- smpte=10:07:33- smpte=10:07:00-10:07:33:05.01 smpte-25=10:07:00-10:07:33:05.01 4.4.2 . Normal Play Time RFC5905]. The timestamp consists of two parts: the mandatory first part may be expressed in either seconds or hours, minutes, and seconds. The optional second part consists of a decimal point and decimal figures and indicates fractions of a second. The beginning of a presentation corresponds to 0.0 seconds. Negative values are not defined. The special constant "now" is defined as the current instant of a live event. It MAY only be used for live events, and MUST NOT be used for on-demand (i.e., non-live) content. NPT is defined as in DSM-CC [ISO.13818-6.1995]: "Intuitively, NPT is the clock the viewer associates with a program. It is often digitally displayed on a VCR. NPT advances normally when in normal play mode (scale = 1), advances at a faster rate when in fast scan forward (high positive scale ratio), decrements when in scan reverse (negative scale ratio) and is fixed in pause mode. NPT is (logically) equivalent to SMPTE time codes." Examples: npt=123.45-125 npt=12:05:35.3- npt=now- The syntax conforms to ISO 8601 [ISO.8601.2000]. The npt-sec notation is optimized for automatic generation, the npt-hhmmss notation for consumption by human readers. The "now" constant allows clients to request to receive the live feed rather than the stored or time-delayed version. This is needed since neither absolute time nor zero time are appropriate for this case. 4.4.3 . Absolute Time ISO.8601.2000] timestamps, using UTC (GMT). Fractions of a second may be indicated. Schulzrinne, et al. Expires March 6, 2014 [Page 31]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 Example for clock format range request for a starting time of November 8, 1996 at 14h 37 min and 20 and a quarter seconds UTC playing for 10 min and 5 seconds, a Media-Properties header's "Time- Limited UTC property for 24th of December 2014 at 15 hours and 00 mins, and a Terminate-Readon headers "time" property for 18th of June 2013 at 16 hours, 12 minutes and 56 seconds: clock=19961108T143720.25Z-19961108T144725.25Z Time-Limited=20141224T1500Z time=20130618T161256Z 4.5 . Feature-Tags Section 18.43), Proxy-Require (Section 18.37), Proxy-Supported (Section 18.38), Supported (Section 18.51) and Unsupported (Section 18.55) header fields. A feature-tag definition MUST indicate which combination of clients, servers or proxies it applies to. The creator of a new RTSP feature-tag should either prefix the feature-tag with a reverse domain name (e.g., "com.example.mynewfeature" is an apt name for a feature whose inventor can be reached at "example.com"), or register the new feature-tag with the Internet Assigned Numbers Authority (IANA) (see IANA Section 22). The usage of feature-tags is further described in Section 11 that deals with capability handling. 4.6 . Message Body Tags Section 18.31) or in SDP (see Appendix D.1.9). MTag is similar to ETag in HTTP/1.1 (see Section 3.11 of [RFC2068]). A message body tag MUST be unique across all versions of all message bodies associated with a particular resource. A given message body tag value MAY be used for message bodies obtained by requests on different URIs. The use of the same message body tag value in conjunction with message bodies obtained by requests on different URIs does not imply the equivalence of those message bodies Message body tags are used in RTSP to make some methods conditional. The methods are made conditional through the inclusion of headers; Schulzrinne, et al. Expires March 6, 2014 [Page 32]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 see "If-Match" (Section 18.24) and "If-None-Match" (Section 18.26). Note that RTSP message body tags apply to the complete presentation; i.e., both the presentation description and the individual media streams. Thus message body tags can be used to verify at setup time after a redirect that the same session description applies to the media at the new location using the If-Match header. 4.7 . Media Properties Schulzrinne, et al. Expires March 6, 2014 [Page 33]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 4.7.1 . Random Access and Seeking Section 18.47). 4.7.2 . Retention 4.7.3 . Content Modifications Schulzrinne, et al. Expires March 6, 2014 [Page 34]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 Immutable: The content of the media will not change, even if the representation, i.e., encoding, quality, etc., may change. Dynamic: Between explicit updates the media content will not change, but the content may change due to external methods or triggers, such as playlists. Time-Progressing: As time progresses new content will become available. If the content also is retained it will become longer as everything between the start point and the point currently being made available can be accessed. If the media server uses a sliding window policy for retention, the start point will also change as time progresses. 4.7.4 . Supported Scale Factors 4.7.5 . Mapping to the Attributes Schulzrinne, et al. Expires March 6, 2014 [Page 35]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 5 . RTSP Message RFC 3629 [RFC3629]. Lines MUST be terminated by CRLF. Text-based protocols make it easier to add optional parameters in a self-describing manner. Since the number of parameters and the frequency of commands is low, processing efficiency is not a concern. Text-based protocols, if done carefully, also allow easy implementation of research prototypes in scripting languages such as TCL, Visual Basic and Perl. The ISO 10646 character set avoids character set switching, but is invisible to the application as long as US-ASCII is being used. This is also the encoding used for RTCP [RFC3550]. Requests contain methods, the object the method is operating upon and parameters to further describe the method. Methods are idempotent unless otherwise noted. Methods are also designed to require little or no state maintenance at the media server. 5.1 . Message Types Section 7) and Response (Section 8) messages use a format based on the generic message format of RFC 2822 [RFC2822] for transferring bodies (the payload of the message). Both types of messages consist of a start- line, zero or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the headers, and possibly the data of the message body. The below ABNF [RFC5234] is for information and the formal message specification is present in Section 20.2.2. generic-message = start-line *(message-header CRLF) CRLF [ message-body-data ] start-line = Request-Line | Status-Line In the interest of robustness, agents MUST ignore any empty line(s) received where a Request-Line or Response-Line is expected. In other words, if the agent is reading the protocol stream at the beginning of a message and receives a CRLF first, it MUST ignore the CRLF. Schulzrinne, et al. Expires March 6, 2014 [Page 36]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 5.2 . Message Headers Section 18) include general-header, request- header, response-header, and message-body header fields. The order in which header fields with differing field names are received is not significant. However, it is "good practice" to send general-header fields first, followed by request-header or response- header fields, and ending with the Message-body header fields. Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded. Unknown message headers MUST be ignored (skipping over the header to the next protocol element, and not causing an error) by a RTSP server or client. An RTSP Proxy MUST forward unknown message headers. Message headers defined outside of this specification that are required to be interpreted by the RTSP agent will need to use feature tags (Section 4.5) and include them in the appropriate Require (Section 18.43) or Proxy-Require (Section 18.37) header. 5.3 . Message Body Section 18.17) and Content-Type (see Section 18.19). A message body MUST NOT be included in a request or response if the specification of the particular method (see Method Definitions (Section 13)) does not allow sending a message body. In case a message body is received in a message when not expected the message body data SHOULD be discarded. This is to allow future extensions to define optional use of message body. Schulzrinne, et al. Expires March 6, 2014 [Page 37]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 5.4 . Message Length Section 18.17). The headers value represents the length of the message-body in octets. If this header field is not present, a value of zero is assumed, i.e. no message body present in message. Unlike an HTTP message, an RTSP message MUST contain a Content-Length header whenever it contains a message body. Note that RTSP does not support the HTTP/1.1 "chunked" transfer coding (see [H3.6.1]). Given the moderate length of presentation descriptions returned, the server should always be able to determine its length, even if it is generated dynamically, making the chunked transfer encoding unnecessary. Schulzrinne, et al. Expires March 6, 2014 [Page 38]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 | Via | Section 18.57 | +--------------------+--------------------+ Table 1: The general headers used in RTSP Schulzrinne, et al. Expires March 6, 2014 [Page 40]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 7 . Request Section 6), request headers (Section 7.2), or message body headers (Section 9.1); o One empty line (CRLF) to indicate the end of the header section; o Optionally a message-body, consisting of one or more lines. The length of the message body in octets is indicated by the Content- Length message header. 7.1 . Request Line Schulzrinne, et al. Expires March 6, 2014 [Page 41]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 +---------------+--------------------+ | Method | Defined in Section | +---------------+--------------------+ | DESCRIBE | Section 13.2 | | | | | GET_PARAMETER | Section 13.8 | | | | | OPTIONS | Section 13.1 | | | | | PAUSE | Section 13.6 | | | | | PLAY | Section 13.4 | | | | | PLAY_NOTIFY | Section 13.5 | | | | | REDIRECT | Section 13.10 | | | | | SETUP | Section 13.3 | | | | | SET_PARAMETER | Section 13.9 | | | | | TEARDOWN | Section 13.7 | +---------------+--------------------+ Table 2: The RTSP Methods The syntax of the RTSP request line is the following: <Method> SP <Request-URI> SP <RTSP-Version> CRLF Note: This syntax cannot be freely changed in future versions of RTSP. This line needs to remain parsable by older RTSP implementations since it indicates the RTSP version of the message. In contrast to HTTP/1.1 [RFC2616], RTSP requests identify the resource through an absolute RTSP URI (including scheme, host, and port) (see Section 4.2) rather than just the absolute path. HTTP/1.1 requires servers to understand the absolute URI, but clients are supposed to use the Host request header. This is purely needed for backward-compatibility with HTTP/1.0 servers, a consideration that does not apply to RTSP. An asterisk "*" can be used instead of an absolute URI in the Request-URI part to indicate that the request does not apply to a particular resource, but to the server or proxy itself, and is only allowed when the request method does not necessarily apply to a resource. Schulzrinne, et al. Expires March 6, 2014 [Page 42]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 For example: OPTIONS * RTSP/2.0 An OPTIONS in this form will determine the capabilities of the server or the proxy that first receives the request. If the capability of the specific server needs to be determined, without regard to the capability of an intervening proxy, the server should be addressed explicitly with an absolute URI that contains the server's address. For example: OPTIONS rtsp://example.com RTSP/2.0 7.2 . Request Header Fields Schulzrinne, et al. Expires March 6, 2014 [Page 43]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 8 . Response 8.1 . Status-Line 8.1.1 . Status Code and Reason Phrase Section 17. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason- Phrase. The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. There are 5 values for the first digit: 1xx: Informational - Request received, continuing process 2xx: Success - The action was successfully received, understood, and accepted 3rr: Redirection - Further action needs to be taken in order to complete the request (3rr rather than 3xx is used as 304 is excluded, see Section 17.3) 4xx: Client Error - The request contains bad syntax or cannot be fulfilled Schulzrinne, et al. Expires March 6, 2014 [Page 45]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 5xx: Server Error - The server failed to fulfill an apparently valid request The individual values of the numeric status codes defined for RTSP/2.0, and an example set of corresponding Reason-Phrases, are presented in Table 4. The reason phrases listed here are only recommended; they may be replaced by local equivalents without affecting the protocol. Note that RTSP adopts most HTTP/1.1 [RFC2616] status codes and adds RTSP-specific status codes starting at x50 to avoid conflicts with future HTTP status codes that are desirable to import into RTSP. All these codes are RTSP specific and RTSP has its own registry separate from HTTP for status codes. RTSP status codes are extensible. RTSP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with an exception for unknown 3xx codes, which MUST be treated as a 302 (Found). The reason being that no 300 (Multiple Choices in HTTP) is defined for RTSP. An response with unrecognized status code MUST NOT be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents SHOULD present to the user the message body returned with the response, since that message body is likely to include human-readable information which will explain the unusual status. +--------------------------------+-------------------------+--------+ | Code | Reason | Method | +--------------------------------+-------------------------+--------+ | 100 | Continue | all | | | | | | | | | | 200 | OK | all | | | | | | | | | | 301 | Moved Permanently | all | | | | | | 302 | Found | all | | | | | | 303 | reserved | n/a | | | | | | 304 | Not Modified | all | | | | | | 305 | Use Proxy | all | Schulzrinne, et al. Expires March 6, 2014 [Page 46]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 | 400 | Bad Request | all | | | | | | 401 | Unauthorized | all | | | | | | 402 | Payment Required | all | | | | | | 403 | Forbidden | all | | | | | | 404 | Not Found | all | | | | | | 405 | Method Not Allowed | all | | | | | | 406 | Not Acceptable | all | | | | | | 407 | Proxy Authentication | all | | | Required | | | | | | | 408 | Request Timeout | all | | | | | | 410 | Gone | all | | | | | | Precondition Failed | DESCRIBE, SETUP | 413 | | | | | | Request Message Body Too Large | all | 414 | | | | | | Request-URI Too Long | all | 415 | | | | | | Unsupported Media Type | all | 451 | | | | | | Parameter Not Understood | SET_PARAMETER, | 452 | | | GET_PARAMETER | | | | | | | reserved | n/a | 453 | | | | | | Not Enough Bandwidth | SETUP | 454 | | | | | | Session Not Found | all | 455 | | | | | | Method Not Valid In This State | all | 456 | | | | | | Header Field Not Valid | all | 457 | | | | | | Invalid Range | PLAY, PAUSE | 458 | | | | | | Parameter Is Read-Only | SET_PARAMETER | 459 | | | | | | Aggregate Operation Not | all | 460 | | Allowed | | | Schulzrinne, et al. Expires March 6, 2014 [Page 47]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 | Only Aggregate Operation | all | 461 | | Allowed | | | | | | | | Unsupported Transport | all | 462 | | | | | | Destination Unreachable | all | 463 | | | | | | Destination Prohibited | SETUP | 464 | | | | | | Data Transport Not Ready Yet | PLAY | 465 | | | | | | Notification Reason Unknown | PLAY_NOTIFY | 466 | | | | | | Key Management Error | all | 470 | | | | | | Connection Authorization | all | 471 | | Required | | | | | | | | Connection Credentials not | all | 472 | | accepted | | | | | | | | Failure to establish secure | all | | | connection | | | | | | | | | | 500 | | | | | | Internal Server Error | all | 501 | | | | | | Not Implemented | all | 502 | | | | | | Bad Gateway | all | 503 | | | | | | Service Unavailable | all | 504 | | | | | | Gateway Timeout | all | 505 | | | | | | RTSP Version Not Supported | all | 551 | | | | | | Option Not Supported | all | 553 | | | | | | Proxy Unavailable | all | | +--------------------------------+-------------------------+--------+ Table 4: Status codes and their usage with RTSP methods Schulzrinne, et al. Expires March 6, 2014 [Page 48]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 9 . Message Body Section 5.3). The SET_PARAMETER and GET_PARAMETER requests and responses, and the DESCRIBE response as defined by this specification MAY have a message body; the purpose of the message body is defined in each case. All 4xx and 5xx responses MAY also have a message body to carry additional response information. Generally a message body MAY be attached to any RTSP 2.0 request or response, but the content of the message body MAY be ignored by the receiver. Extensions to this specification can specify the purpose and content of message bodies, including requiring their inclusion. In this section, both sender and recipient refer to either the client or the server, depending on who sends and who receives the message body. 9.1 . Message-Body Header Fields Schulzrinne, et al. Expires March 6, 2014 [Page 50]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 9.3 . Message Body Format Negotiation Section 18.19). To enable the responder of a request to determine which media type it should use, the requestor may include the Accept header (Section 18.1) in a request to identify supported media types or media type ranges suitable to the response. In cases the responder is not supporting any of the specified formats, then the request response will be a 406 (Not Acceptable) error code. The media types that may be used on requests with message bodies needs to be determined through the use of feature-tags, specification requirement or trial and error. Trial and error works in the regards that in case the responder is not supporting the media type of the message body it will respond with a 415 (Unsupported Media Type). The formats supported and their negotiation is done individually on a per method and direction (request or response body) direction. Requirements on supporting particular media types for use as message bodies in requests and response SHALL also be specified on per method and direction basis. Schulzrinne, et al. Expires March 6, 2014 [Page 52]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 10 . Connections RFC 2326 attempted to specify an optional mechanism for transmitting RTSP messages in connectionless mode over a transport protocol such as UDP. However, it was not specified in sufficient detail to allow for interoperable implementations. In an attempt to reduce complexity and scope, and due to lack of interest, RTSP 2.0 does not attempt to define a mechanism for supporting RTSP over UDP or other connectionless transport protocols. A side-effect of this is that RTSP requests MUST NOT be sent to multicast groups since no connection can be established with a specific receiver in multicast environments. Certain RTSP headers, such as the CSeq header (Section 18.20), which may appear to be relevant only to connectionless transport scenarios are still retained and MUST be implemented according to the specification. In the case of CSeq, it is quite useful for matching responses to requests if the requests are pipelined (see Section 12). It is also useful in proxies for keeping track of the different requests when aggregating several client requests on a single TCP connection. 10.1 . Reliability and Acknowledgements Schulzrinne, et al. Expires March 6, 2014 [Page 53]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 If both the underlying reliable transport such as TCP and the RTSP application retransmit requests, each packet loss or message loss may result in two retransmissions. The receiver typically cannot take advantage of the application-layer retransmission since the transport stack will not deliver the application-layer retransmission before the first attempt has reached the receiver. If the packet loss is caused by congestion, multiple retransmissions at different layers will exacerbate the congestion. Lack of acknowledgment of an RTSP request should be handled within the constraints of the connection timeout considerations described below (Section 10.4). 10.2 . Using Connections Section 4.2) indicates the default port that the server will listen on if the port is not explicitly given. In addition to the registered default ports, i.e., 554 (rtsp) and 322 (rtsps), there is an alternative port 8554 registered. This port may provide some benefits from non-registered ports if a RTSP server is unable to use the default ports. The benefits may include pre- configured security policies as well as classifiers in network monitoring tools. A RTSP client opening a TCP connection for accessing a particular resource as identified by a URI uses the IP address and port derived from the host and port parts of the URI. The IP address is either the explicit address provided in the URI or any of the addresses provided when performing A and AAAA record DNS lookups of the host name in the URI. A server MUST handle both persistent and transient connections. Transient connections facilitate mechanisms for fault tolerance. They also allow for application layer mobility. A server and client pair that support transient connections can survive the loss of a TCP connection; e.g., due to a NAT timeout. When the client has discovered that the TCP connection has been lost, it can set up a new one when there is need to communicate again. A persistent connection is RECOMMENDED to be used for all transactions between the server and client, including messages for Schulzrinne, et al. Expires March 6, 2014 [Page 54]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 multiple RTSP sessions. However, a persistent connection MAY be closed after a few message exchanges. For example, a client may use a persistent connection for the initial SETUP and PLAY message exchanges in a session and then close the connection. Later, when the client wishes to send a new request, such as a PAUSE for the session, a new connection would be opened. This connection may either be transient or persistent. An RTSP agent MAY use one connection to handle multiple RTSP sessions on the same server. The RTSP agent SHALL NOT use more than one connection per RTSP session at any given point. Using a single connection for multiple RTSP session saves connection resources on the server. Not using more than one connection at a time for a particular RTSP session avoids wasting connection resources and allows the server to track only for the latest in client to server used connection for each RTSP session as being the currently valid server to client connection. RTSP allows a server to send requests to a client. However, this can be supported only if a client establishes a persistent connection with the server. In cases where a persistent connection does not exist between a server and its client, due to the lack of a signaling channel the server may be forced to silently discard RTSP messages, and may even drop an RTSP session without notifying the client. An example of such a case is when the server desires to send a REDIRECT request for an RTSP session to the client but is not able to do so because it cannot reach the client. A server that attempts to send a request to a client that has no connection currently to the server SHALL discard the request directly. Without a persistent connection between the client and the server, the media server has no reliable way of reaching the client. Because the likely failure of server to client established connections the server will not even attempt establishing any connection. Queuing of server to client requests has been considered. However a security issue exist in how one authorizes a client establishing a new connection as being a legit receiver of request related to a particular RTSP session without the client first issuing requests related to the request. Thus, likely making any such requests even more delayed and less useful. The sending of client and server requests can be asynchronous events. To avoid deadlock situations both client and server MUST be able to send and receive requests simultaneously. As an RTSP response may be queued up for transmission, reception or processing behind the peer Schulzrinne, et al. Expires March 6, 2014 [Page 55]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 RTSP agent's own requests, all RTSP agents are required to have a certain capability of handling outstanding messages. A potential issue is that outstanding requests may timeout despite them being processed by the peer due to the response being caught in the queue behind a number of requests that the RTSP agent is processing but that take some time to complete. To avoid this problem an RTSP agent is recommended to buffer incoming messages locally so that any response messages can be processed immediately upon reception. If responses are separated from requests and directly forwarded for processing, not only can the result be used immediately, the state associated with that outstanding request can also be released. However, buffering a number of requests on the receiving RTSP agent consumes resources and enables a resource exhaustion attack on the agent. Therefore this buffer should be limited so that an unreasonable number of requests or total message size is not allowed to consume the receiving agent's resources. In most APIs, having the receiving agent stop reading from the TCP socket will result in TCP's window being clamped. Thus forcing the buffering onto the sending agent when the load is larger than expected. However, as both RTSP message sizes and frequency may be changed in the future by protocol extensions, an agent should be careful against taking harsher measurements against a potential attack. When under attack an RTSP agent can close TCP connections and release state associated with that TCP connection. To provide some guidance on what is reasonable the following guidelines are given. It is RECOMMENDED that: o an RTSP agent should not have more than 10 outstanding requests per RTSP session; o an RTSP agent should not have more than 10 outstanding requests that are not related to an RTSP session or that are requesting to create an RTSP session. In light of the above, it is RECOMMENDED that clients use persistent connections whenever possible. A client that supports persistent connections MAY "pipeline" its requests (see Section 12). RTSP Agents can send requests to multiple different destinations, either servers or client contexts over the same connection to a proxy. Then the proxy forks the message to the different destinations over proxy to agent connections. In these cases when multiple requests are outstanding the requesting agent MUST be ready to receive the responses out of order compared to the order they where sent on the connection. The order between multiple messages for each destination will be maintained, however, the order between response from different destinations can be different. Schulzrinne, et al. Expires March 6, 2014 [Page 56]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 The reason for this is to avoid a head of line blocking. In a sequence of request an early outstanding request may take time to be processed at one destination. Simultaneously a responses from any other destinations, that was later in the sequence of requests may have arrived at the proxy. Thus allowing out-of-order responses avoid forcing the proxy to buffer this response and instead deliver it as soon as possible. Note, this will not affect the order they where processed at request destination. This scenario can occur in two cases involving proxies. The first is a client issuing requests for sessions on different servers using a common client to proxy connection. The second is for server to client requests, like REDIRECT being sent by the server over a common transport connection the proxy created for its different connecting clients. 10.3 . Closing Connections Section 18.49). A server SHOULD NOT close a connection immediately after responding to a session-level TEARDOWN request for the last RTSP session being controlled through the connection. Instead, the server should wait for a reasonable amount of time for the client to receive and act upon the TEARDOWN response, and initiate the connection closing. The server SHOULD wait at least 10 seconds after sending the TEARDOWN response before closing the connection. This is to ensure that the client has time to issue a SETUP for a new session on the existing connection after having torn the last one down. 10 seconds should give the client ample opportunity to get its message to the server. A server SHOULD NOT close the connection directly as a result of responding to a request with an error code. Certain error responses such as "460 Only Aggregate Operation Allowed" (Section 17.4.24) are used for negotiating capabilities of a server with respect to content or other factors. In such cases, it is inefficient for the server to close a connection on an error response. Also, such behavior would prevent implementation of advanced/special types of requests or result in extra overhead for the client when testing for new features. On the other hand, keeping connections open after sending an error response poses a Denial of Service security risk (Section 21). Schulzrinne, et al. Expires March 6, 2014 [Page 57]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 The server MAY close a connection if it receives an incomplete message and if the message is not completed within a reasonable amount of time. It is RECOMMENDED that the server waits at least 10 seconds for the completion of a message or for the next part of the message to arrive (which is an indication that the transport and the client are still alive). Servers believing they are under attack or otherwise starved for resources during that event MAY consider using a shorter timeout. If a server closes a connection while the client is attempting to send a new request, the client will have to close its current connection, establish a new connection and send its request over the new connection. An RTSP message SHOULD NOT be terminated by closing the connection. Such a message MAY be considered to be incomplete by the receiver and discarded. An RTSP message is properly terminated as defined in Section 5. 10.4 . Timing Out Connections and RTSP Messages Schulzrinne, et al. Expires March 6, 2014 [Page 58]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 receive server to client requests. To mitigate that situation the RTSP agent should establish a new connection and send any queued up and non-responded requests on this new connection. Secondly, to ensure that the RTSP server knows which connection that is valid for a particular RTSP session, the RTSP agent should send a keep-alive request, if no other request will be sent immediately for that RTSP session, for each RTSP session on the old connection. The keep-alive request will normally be a GET_PARAMETER with a session header to inform the server that this agent cares about this RTSP session. A requester SHOULD wait longer than 10 seconds for a response if it is experiencing significant transport delays on its connection to the responder. The requester is capable of determining the round trip time (RTT) of the request/response cycle using the Timestamp header (Section 18.53) in any RTSP request. 10 seconds was chosen for the following reasons. It gives TCP time to perform a couple of retransmissions, even if operating on default values. It is short enough that users may not abandon the process themselves. However, it should be noted that 10 seconds can be aggressive on certain type of networks. The 5 seconds value for 1xx messages is half the timeout giving a reasonable chance of successful delivery before timeout happens on the requester side. 10.5 . Showing Liveness Schulzrinne, et al. Expires March 6, 2014 [Page 59]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 session with 60 seconds timeout and enough bitrate assigned to RTCP messages to send a message from client to server on average every 5 seconds. That client has, for a network with 5% packet loss, a probability of failing to confirm liveness within the timeout interval for that session of 2.4*E-16. Sessions with shorter timeouts, or much higher packet loss, or small RTCP bandwidths SHOULD also implement one or more of the mechanisms below. SET_PARAMETER: When using SET_PARAMETER for keep-alive, a body SHOULD NOT be included. This method is the RECOMMENDED RTSP method to use for a request intended only to perform keep- alive. Support of SET_PARAMETER is mandatory for RTSP Servers to ensure clients can use this method. GET_PARAMETER: When using GET_PARAMETER for keep-alive, no body SHOULD be included. Dependent on implementation support in server. OPTIONS: This method is also usable, but it causes the server to perform more unnecessary processing and results in bigger responses than necessary for the task. The reason is that the server needs to determine the capabilities associated with the media resource to correctly populate the Public and Allow headers. The timeout parameter of the Session header (Section 18.49) MAY be included in a SETUP response, and MUST NOT be included in requests. The server uses it to indicate to the client how long the server is prepared to wait between RTSP commands or other signs of life before closing the session due to lack of activity (see Appendix B). The timeout is measured in seconds, with a default of 60 seconds. The length of the session timeout MUST NOT be changed in an established session. 10.6 . Use of IPv6 RFC2460] support was not present in RTSP 1.0 (RFC 2326). RTSP 2.0 has been updated for explicit IPv6 support. Implementations of RTSP 2.0 MUST understand literal IPv6 addresses in URIs and RTSP headers. Although the general URI format envisages potential future new versions of the literal IP address, usage of any such new version would require other modifications to the RTSP specification (e.g. address fields in the Transport header (Section 18.54)). Schulzrinne, et al. Expires March 6, 2014 [Page 60]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 10.7 . Overload Control Section 17.5.4) to let servers and proxies notify requesting proxies and RTSP clients about an overload situation. In conjunction with the Retry-After header (Section 18.44) the server or proxy can indicate the time after the requesting entity can send another request to the proxy or server. There are two scopes of such 503 answers, one for established RTSP sessions, where the request resulting in the 503 response as well as the response carries a Session header identifying the session which is suffering overload. This response only applies to this particular session. The other scope is the general RTSP server as identified by the host in the request URL. Such a 503 answer with any Retyr-After header applies to all non-session specific requests to that server, including SETUP request intended to create a new RTSP session. Another scope for overload situation exists, which is the RTSP proxy. To enable an RTSP proxy to signal that it is overloaded, or otherwise unavailable and can't handle the request, a 553 response code has been defined with the meaning "Proxy Unavailable". Also for proxies there is a separation in response scopes between requests associated with existing RTSP sessions, and requests to create new sessions or general proxy requests. Simply implementing and using the 503 (Service Unavailable) and 553 (Proxy Unavailable) is not sufficient for properly handling overload situations. For instance, a simplistic approach would be to send the 503 response with a Retry-After header set to a fixed value. However, this can cause the situation where multiple RTSP clients again send requests to a proxy or server at roughly the same time which may again cause an overload situation, or if the "old" overload situation is not yet solved, i.e., the length indicated in the Retry- After header was too short. An RTSP server or proxy in an overload situation must select the value of the Retry-After header carefully and bearing in mind its current load situation. It is REQUIRED to increase the timeout period in proportion to the current load on the server, i.e., an increasing workload should result in an increased length of the indicated unavailability. It is REQUIRED to not send the same value in the Retry-After header to all requesting proxies and clients, but to add a variation to the mean value of the Retry-After header. Schulzrinne, et al. Expires March 6, 2014 [Page 61]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 A more complex case may arise when a load balancing RTSP proxy is in use, i.e., where an RTSP proxy is used to select amongst a set of RTSP servers to handle the requests, or when multiple server addresses are available for a given server name. The proxy or client may receive a 503 (Service Unavailable) or 553 (Proxy Unavailable) from one of its RTSP servers or proxies, or a TCP timeout (if the server is even unable to handle the request message). The proxy or client simply retries the other addresses or configured proxies, but may also receive a 503 (Service Unavailable) or 553 (Proxy Unavailable) response or TCP timeouts from those addresses. In such a situation, where none of the RTSP servers/proxies/addresses can handle the request, the RTSP agent has to wait before it can send any new requests to the RTSP server. Any additional request to a specific address MUST be delayed according to the Retry-After headers received. For addresses where no response was received or TCP timeout occurred, an initial wait timer SHOULD be set to 5 seconds. That timer MUST be doubled for each additional failure to connect or receive response until the value exceeds 30 minutes when the timers mean value may be set to 30 minutes. It is REQUIRED to not set the same value in the timer for each scheduling, but instead to add a variation to the mean value, resulting in picking a random value within the range of 0.5 to 1.5 of the mean value. Schulzrinne, et al. Expires March 6, 2014 [Page 62]

Internet-Draft Real Time Streaming Protocol 2.0 (RTSP) September 2013 11 . Capability Handling Section 11.1) which represents the minimal media delivery for playback implementation. Feature-tags are used to determine whether the client, server or proxy supports the functionality that is necessary to achieve the desired service. To determine support of a feature-tag, several different headers can be used, each explained below: Supported: This header is used to determine the complete set of functionality that both client and server have i