draft-ietf-mmusic-rfc2326bis-28.txt   draft-ietf-mmusic-rfc2326bis-29.txt 
MMUSIC Working Group H. Schulzrinne MMUSIC Working Group H. Schulzrinne
Internet-Draft Columbia University Internet-Draft Columbia University
Obsoletes: 2326 (if approved) A. Rao Obsoletes: 2326 (if approved) A. Rao
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: April 30, 2012 R. Lanphier Expires: September 13, 2012 R. Lanphier
M. Westerlund M. Westerlund
Ericsson AB Ericsson AB
M. Stiemerling (Ed.) M. Stiemerling (Ed.)
NEC NEC
October 28, 2011 March 12, 2012
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-28 draft-ietf-mmusic-rfc2326bis-29
Abstract Abstract
This memorandum defines RTSP version 2.0 which obsoletes RTSP version This memorandum defines RTSP version 2.0 which obsoletes RTSP version
1.0 which is defined in RFC 2326. 1.0 defined in RFC 2326.
The Real Time Streaming Protocol, or RTSP, is an application-level The Real Time Streaming Protocol, or RTSP, is an application-level
protocol for setup and control of the delivery of data with real-time protocol for setup and control of the delivery of data with real-time
properties. RTSP provides an extensible framework to enable properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and controlled, on-demand delivery of real-time data, such as audio and
video. Sources of data can include both live data feeds and stored video. Sources of data can include both live data feeds and stored
clips. This protocol is intended to control multiple data delivery clips. This protocol is intended to control multiple data delivery
sessions, provide a means for choosing delivery channels such as UDP, sessions, provide a means for choosing delivery channels such as UDP,
multicast UDP and TCP, and provide a means for choosing delivery multicast UDP and TCP, and provide a means for choosing delivery
mechanisms based upon RTP (RFC 3550). mechanisms based upon RTP (RFC 3550).
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2012. This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 38 skipping to change at page 4, line 38
13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 82 13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 82
13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 83 13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 83
13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 84 13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 84
13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 87 13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 87
13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 87 13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 87
13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 88 13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 88
13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 89 13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 89
13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 91 13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 91
13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 92 13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 92
14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 95 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 95
15. Status Code Definitions . . . . . . . . . . . . . . . . . . . 97 15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
15.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 97 15.1. Proxies and Protocol Extensions . . . . . . . . . . . . 98
15.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 97 15.2. Multiplexing and Demultiplexing of Messages . . . . . . 99
15.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 97 16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
15.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 97 16.1. Validation Model . . . . . . . . . . . . . . . . . . . . 100
15.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 97 16.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 102
15.3.1. 301 Moved Permanently . . . . . . . . . . . . . . . 98 16.1.2. Message Body Tag Cache Validators . . . . . . . . . 102
15.3.2. 302 Found . . . . . . . . . . . . . . . . . . . . . 98 16.1.3. Weak and Strong Validators . . . . . . . . . . . . . 102
15.3.3. 303 See Other . . . . . . . . . . . . . . . . . . . 98 16.1.4. Rules for When to Use Message Body Tags and
15.3.4. 304 Not Modified . . . . . . . . . . . . . . . . . . 98 Last-Modified Dates . . . . . . . . . . . . . . . . 104
15.3.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 99 16.1.5. Non-validating Conditionals . . . . . . . . . . . . 106
15.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 99 16.2. Invalidation After Updates or Deletions . . . . . . . . 106
15.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 99 17. Status Code Definitions . . . . . . . . . . . . . . . . . . . 108
15.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 99 17.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 108
15.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 100 17.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 108
15.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 100 17.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 108
15.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 100 17.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 108
15.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 100 17.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 108
15.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 100 17.3.1. 301 Moved Permanently . . . . . . . . . . . . . . . 109
15.4.8. 407 Proxy Authentication Required . . . . . . . . . 101 17.3.2. 302 Found . . . . . . . . . . . . . . . . . . . . . 109
15.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 101 17.3.3. 303 See Other . . . . . . . . . . . . . . . . . . . 109
15.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 101 17.3.4. 304 Not Modified . . . . . . . . . . . . . . . . . . 109
15.4.11. 411 Length Required . . . . . . . . . . . . . . . . 101 17.3.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 110
15.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 102 17.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 110
15.4.13. 413 Request Message Body Too Large . . . . . . . . . 102 17.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 110
15.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 102 17.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 110
15.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 102 17.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 111
15.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 102 17.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 111
15.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 102 17.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 111
15.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 103 17.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 111
15.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 103 17.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 111
15.4.20. 455 Method Not Valid in This State . . . . . . . . . 103 17.4.8. 407 Proxy Authentication Required . . . . . . . . . 112
15.4.21. 456 Header Field Not Valid for Resource . . . . . . 103 17.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 112
15.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 103 17.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 112
15.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 103 17.4.11. 411 Length Required . . . . . . . . . . . . . . . . 112
15.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 103 17.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 113
15.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 103 17.4.13. 413 Request Message Body Too Large . . . . . . . . . 113
15.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 104 17.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 113
15.4.27. 462 Destination Unreachable . . . . . . . . . . . . 104 17.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 113
15.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 104 17.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 113
15.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 104 17.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 114
15.4.30. 465 Notification Reason Unknown . . . . . . . . . . 104 17.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 114
15.4.31. 466 Key Management Error . . . . . . . . . . . . . . 104 17.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 114
15.4.32. 470 Connection Authorization Required . . . . . . . 105 17.4.20. 455 Method Not Valid in This State . . . . . . . . . 114
15.4.33. 471 Connection Credentials not accepted . . . . . . 105 17.4.21. 456 Header Field Not Valid for Resource . . . . . . 114
15.4.34. 472 Failure to establish secure connection . . . . . 105 17.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 114
15.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 105 17.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 114
15.5.1. 500 Internal Server Error . . . . . . . . . . . . . 105 17.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 114
15.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 105 17.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 115
15.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 105 17.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 115
15.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 106 17.4.27. 462 Destination Unreachable . . . . . . . . . . . . 115
15.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 106 17.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 115
15.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 106 17.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 115
15.5.7. 551 Option not supported . . . . . . . . . . . . . . 106 17.4.30. 465 Notification Reason Unknown . . . . . . . . . . 115
16. Header Field Definitions . . . . . . . . . . . . . . . . . . 107 17.4.31. 466 Key Management Error . . . . . . . . . . . . . . 116
16.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 117 17.4.32. 470 Connection Authorization Required . . . . . . . 116
16.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 117 17.4.33. 471 Connection Credentials not accepted . . . . . . 116
16.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 118 17.4.34. 472 Failure to establish secure connection . . . . . 116
16.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 119 17.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 116
16.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 120 17.5.1. 500 Internal Server Error . . . . . . . . . . . . . 116
16.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 120 17.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 116
16.7. Authorization . . . . . . . . . . . . . . . . . . . . . 120 17.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 117
16.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 121 17.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 117
16.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 122 17.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 117
16.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 122 17.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 117
16.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 125 17.5.7. 551 Option not supported . . . . . . . . . . . . . . 117
16.12. Connection-Credentials . . . . . . . . . . . . . . . . . 125 18. Header Field Definitions . . . . . . . . . . . . . . . . . . 118
16.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 126 18.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 128
16.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 126 18.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 128
16.15. Content-Language . . . . . . . . . . . . . . . . . . . . 127 18.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 129
16.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 128 18.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 130
16.17. Content-Location . . . . . . . . . . . . . . . . . . . . 128 18.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 131
16.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 129 18.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 131
16.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 129 18.7. Authorization . . . . . . . . . . . . . . . . . . . . . 131
16.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 130 18.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 132
16.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 131 18.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 133
16.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 131 18.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 133
16.23. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 132 18.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 136
16.24. If-Modified-Since . . . . . . . . . . . . . . . . . . . 132 18.12. Connection-Credentials . . . . . . . . . . . . . . . . . 136
16.25. If-None-Match . . . . . . . . . . . . . . . . . . . . . 133 18.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 137
16.26. Last-Modified . . . . . . . . . . . . . . . . . . . . . 134 18.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 137
16.27. Location . . . . . . . . . . . . . . . . . . . . . . . . 134 18.15. Content-Language . . . . . . . . . . . . . . . . . . . . 138
16.28. Media-Properties . . . . . . . . . . . . . . . . . . . . 134 18.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 139
16.29. Media-Range . . . . . . . . . . . . . . . . . . . . . . 136 18.17. Content-Location . . . . . . . . . . . . . . . . . . . . 139
16.30. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 137 18.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 140
16.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 137 18.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 140
16.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 137 18.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 141
16.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 139 18.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 142
16.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 139 18.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 143
16.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 139 18.23. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 143
16.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 140 18.24. If-Modified-Since . . . . . . . . . . . . . . . . . . . 144
16.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 141 18.25. If-None-Match . . . . . . . . . . . . . . . . . . . . . 144
16.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 141 18.26. Last-Modified . . . . . . . . . . . . . . . . . . . . . 145
16.39. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 143 18.27. Location . . . . . . . . . . . . . . . . . . . . . . . . 145
16.40. Request-Status . . . . . . . . . . . . . . . . . . . . . 144 18.28. Media-Properties . . . . . . . . . . . . . . . . . . . . 146
16.41. Require . . . . . . . . . . . . . . . . . . . . . . . . 144 18.29. Media-Range . . . . . . . . . . . . . . . . . . . . . . 148
16.42. Retry-After . . . . . . . . . . . . . . . . . . . . . . 145 18.30. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 148
16.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 145 18.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 149
16.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 148 18.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 149
16.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 149 18.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 150
16.46. Server . . . . . . . . . . . . . . . . . . . . . . . . . 150 18.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 150
16.47. Session . . . . . . . . . . . . . . . . . . . . . . . . 151 18.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 151
16.48. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 152 18.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 151
16.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 153 18.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 152
16.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 153 18.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 153
16.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 154 18.39. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 154
16.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 154 18.40. Request-Status . . . . . . . . . . . . . . . . . . . . . 155
16.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 161 18.41. Require . . . . . . . . . . . . . . . . . . . . . . . . 155
16.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 161 18.42. Retry-After . . . . . . . . . . . . . . . . . . . . . . 156
16.55. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 162 18.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 157
16.56. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 162 18.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 159
16.57. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 163 18.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 160
17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 18.46. Server . . . . . . . . . . . . . . . . . . . . . . . . . 162
17.1. Proxies and Protocol Extensions . . . . . . . . . . . . 165 18.47. Session . . . . . . . . . . . . . . . . . . . . . . . . 162
17.2. Multiplexing and Demultiplexing of Messages . . . . . . 166 18.48. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 163
18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 18.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 164
18.1. Validation Model . . . . . . . . . . . . . . . . . . . . 167 18.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 165
18.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 169 18.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 165
18.1.2. Message Body Tag Cache Validators . . . . . . . . . 169 18.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 166
18.1.3. Weak and Strong Validators . . . . . . . . . . . . . 169 18.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 173
18.1.4. Rules for When to Use Message Body Tags and 18.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 173
Last-Modified Dates . . . . . . . . . . . . . . . . 171 18.55. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 173
18.1.5. Non-validating Conditionals . . . . . . . . . . . . 173 18.56. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 174
18.2. Invalidation After Updates or Deletions . . . . . . . . 173
19. Security Framework . . . . . . . . . . . . . . . . . . . . . 175 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 175
19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 175 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 175
19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 175 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 175
19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 176 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 176
19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 177 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 177
19.3.2. User approved TLS procedure . . . . . . . . . . . . 178 19.3.2. User approved TLS procedure . . . . . . . . . . . . 178
20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 181 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 181
20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 183 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 183
20.2.1. Generic Protocol elements . . . . . . . . . . . . . 183 20.2.1. Generic Protocol elements . . . . . . . . . . . . . 183
20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 186 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 186
20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 190 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 190
20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 199 20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 199
21. Security Considerations . . . . . . . . . . . . . . . . . . . 200 21. Security Considerations . . . . . . . . . . . . . . . . . . . 200
21.1. Remote denial of Service Attack . . . . . . . . . . . . 202 21.1. Signaling Protocol Threats . . . . . . . . . . . . . . . 200
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 204 21.2. Media Stream Delivery Threats . . . . . . . . . . . . . 203
22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 204 21.2.1. Remote denial of Service Attack . . . . . . . . . . 204
22.1.1. Description . . . . . . . . . . . . . . . . . . . . 205 21.2.2. RTP Security analysis . . . . . . . . . . . . . . . 205
22.1.2. Registering New Feature-tags with IANA . . . . . . . 205 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 207
22.1.3. Registered entries . . . . . . . . . . . . . . . . . 205 22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 207
22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 206 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 208
22.2.1. Description . . . . . . . . . . . . . . . . . . . . 206 22.1.2. Registering New Feature-tags with IANA . . . . . . . 208
22.2.2. Registering New Methods with IANA . . . . . . . . . 206 22.1.3. Registered entries . . . . . . . . . . . . . . . . . 208
22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 206 22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 209
22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 207 22.2.1. Description . . . . . . . . . . . . . . . . . . . . 209
22.3.1. Description . . . . . . . . . . . . . . . . . . . . 207 22.2.2. Registering New Methods with IANA . . . . . . . . . 209
22.3.2. Registering New Status Codes with IANA . . . . . . . 207 22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 209
22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 207 22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 210
22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 207 22.3.1. Description . . . . . . . . . . . . . . . . . . . . 210
22.4.1. Description . . . . . . . . . . . . . . . . . . . . 207 22.3.2. Registering New Status Codes with IANA . . . . . . . 210
22.4.2. Registering New Headers with IANA . . . . . . . . . 208 22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 210
22.4.3. Registered entries . . . . . . . . . . . . . . . . . 208 22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 210
22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 209 22.4.1. Description . . . . . . . . . . . . . . . . . . . . 210
22.5.1. Accept-Credentials policies . . . . . . . . . . . . 209 22.4.2. Registering New Headers with IANA . . . . . . . . . 211
22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 209 22.4.3. Registered entries . . . . . . . . . . . . . . . . . 211
22.6. Cache-Control Cache Directive Extensions . . . . . . . . 210
22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 211 22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 212
22.7.1. Description . . . . . . . . . . . . . . . . . . . . 211 22.5.1. Accept-Credentials policies . . . . . . . . . . . . 212
22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 211 22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 213
22.7.3. Registered Values . . . . . . . . . . . . . . . . . 211 22.6. Cache-Control Cache Directive Extensions . . . . . . . . 213
22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 211 22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 214
22.8.1. Description . . . . . . . . . . . . . . . . . . . . 211 22.7.1. Description . . . . . . . . . . . . . . . . . . . . 214
22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 212 22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 215
22.8.3. Registered Values . . . . . . . . . . . . . . . . . 212 22.7.3. Registered Values . . . . . . . . . . . . . . . . . 215
22.9. Range header formats . . . . . . . . . . . . . . . . . . 212 22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 215
22.9.1. Description . . . . . . . . . . . . . . . . . . . . 212 22.8.1. Description . . . . . . . . . . . . . . . . . . . . 215
22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 212 22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 215
22.9.3. Registered Values . . . . . . . . . . . . . . . . . 213 22.8.3. Registered Values . . . . . . . . . . . . . . . . . 216
22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 213 22.9. Range header formats . . . . . . . . . . . . . . . . . . 216
22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 213 22.9.1. Description . . . . . . . . . . . . . . . . . . . . 216
22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 213 22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 216
22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 214 22.9.3. Registered Values . . . . . . . . . . . . . . . . . 216
22.11.1. Description . . . . . . . . . . . . . . . . . . . . 214 22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 217
22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 214 22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 217
22.11.3. Registered Values . . . . . . . . . . . . . . . . . 214 22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 217
22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 215 22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 217
22.12.1. Description . . . . . . . . . . . . . . . . . . . . 215 22.11.1. Description . . . . . . . . . . . . . . . . . . . . 217
22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 215 22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 218
22.12.3. Registered Values . . . . . . . . . . . . . . . . . 215 22.11.3. Registered Values . . . . . . . . . . . . . . . . . 218
22.13. Transport Header Registries . . . . . . . . . . . . . . 215 22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 218
22.13.1. Transport Protocol Specification . . . . . . . . . . 216 22.12.1. Description . . . . . . . . . . . . . . . . . . . . 218
22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 217 22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 218
22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 217 22.12.3. Registered Values . . . . . . . . . . . . . . . . . 219
22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 218 22.13. Transport Header Registries . . . . . . . . . . . . . . 219
22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 218 22.13.1. Transport Protocol Specification . . . . . . . . . . 219
22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 219 22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 221
22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 220 22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 221
22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 221 22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 222
22.16. Media Type Registration for text/parameters . . . . . . 222 22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 222
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 224 22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 223
23.1. Normative References . . . . . . . . . . . . . . . . . . 224 22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 224
23.2. Informative References . . . . . . . . . . . . . . . . . 226 22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 224
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 229 22.16. Media Type Registration for text/parameters . . . . . . 225
A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 229 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 227
A.2. Media on Demand using Pipelining . . . . . . . . . . . . 233 23.1. Normative References . . . . . . . . . . . . . . . . . . 227
A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 235 23.2. Informative References . . . . . . . . . . . . . . . . . 229
A.4. Single Stream Container Files . . . . . . . . . . . . . 239 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 232
A.5. Live Media Presentation Using Multicast . . . . . . . . 241 A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 232
A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 242 A.2. Media on Demand using Pipelining . . . . . . . . . . . . 236
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 244 A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 238
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 244 A.4. Single Stream Container Files . . . . . . . . . . . . . 242
B.2. State variables . . . . . . . . . . . . . . . . . . . . 244 A.5. Live Media Presentation Using Multicast . . . . . . . . 244
B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 244 A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 245
B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 245 Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 247
Appendix C. Media Transport Alternatives . . . . . . . . . . . . 251 B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 247
C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 251 B.2. State variables . . . . . . . . . . . . . . . . . . . . 247
C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 251 B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 247
C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 251 B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 248
C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 252 Appendix C. Media Transport Alternatives . . . . . . . . . . . . 254
C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 253 C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 254
C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 255 C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 254
C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 255 C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 254
C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 257 C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 255
C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 257 C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 256
C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 257 C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 258
C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 261 C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 258
C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 265 C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 260
C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 267 C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 260
C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 267 C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 260
C.7. Maintaining NPT synchronization with RTP timestamps . . 267 C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 264
C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 267 C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 268
C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 267 C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 270
C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 270
C.7. Maintaining NPT synchronization with RTP timestamps . . 270
C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 270
C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 270
C.10. Usage of SSRCs and the RTCP BYE Message During an C.10. Usage of SSRCs and the RTCP BYE Message During an
RTSP Session . . . . . . . . . . . . . . . . . . . . . . 267 RTSP Session . . . . . . . . . . . . . . . . . . . . . . 270
C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 268 C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 271
Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 269 Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 272
D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 269 D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 272
D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 269 D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 272
D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 270 D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 273
D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 271 D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 274
D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 271 D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 274
D.1.5. Directionality of media stream . . . . . . . . . . . 271 D.1.5. Directionality of media stream . . . . . . . . . . . 274
D.1.6. Range of Presentation . . . . . . . . . . . . . . . 272 D.1.6. Range of Presentation . . . . . . . . . . . . . . . 275
D.1.7. Time of Availability . . . . . . . . . . . . . . . . 273 D.1.7. Time of Availability . . . . . . . . . . . . . . . . 276
D.1.8. Connection Information . . . . . . . . . . . . . . . 273 D.1.8. Connection Information . . . . . . . . . . . . . . . 276
D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 273 D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 277
D.2. Aggregate Control Not Available . . . . . . . . . . . . 274 D.2. Aggregate Control Not Available . . . . . . . . . . . . 277
D.3. Aggregate Control Available . . . . . . . . . . . . . . 275 D.3. Aggregate Control Available . . . . . . . . . . . . . . 278
D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 276 D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 279
D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 276 D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 279
Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 277 Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 280
E.1. On-demand Playback of Stored Content . . . . . . . . . . 277 E.1. On-demand Playback of Stored Content . . . . . . . . . . 280
E.2. Unicast Distribution of Live Content . . . . . . . . . . 278 E.2. Unicast Distribution of Live Content . . . . . . . . . . 281
E.3. On-demand Playback using Multicast . . . . . . . . . . . 279 E.3. On-demand Playback using Multicast . . . . . . . . . . . 282
E.4. Inviting an RTSP server into a conference . . . . . . . 279 E.4. Inviting an RTSP server into a conference . . . . . . . 282
E.5. Live Content using Multicast . . . . . . . . . . . . . . 280 E.5. Live Content using Multicast . . . . . . . . . . . . . . 283
Appendix F. Text format for Parameters . . . . . . . . . . . . . 282 Appendix F. Text format for Parameters . . . . . . . . . . . . . 285
Appendix G. Requirements for Unreliable Transport of RTSP . . . 283 Appendix G. Requirements for Unreliable Transport of RTSP . . . 286
Appendix H. Backwards Compatibility Considerations . . . . . . . 285 Appendix H. Backwards Compatibility Considerations . . . . . . . 288
H.1. Play Request in Play State . . . . . . . . . . . . . . . 285 H.1. Play Request in Play State . . . . . . . . . . . . . . . 288
H.2. Using Persistent Connections . . . . . . . . . . . . . . 285 H.2. Using Persistent Connections . . . . . . . . . . . . . . 288
Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 286 Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 289
I.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 286 I.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 289
I.2. Detailed List of Changes . . . . . . . . . . . . . . . . 287 I.2. Detailed List of Changes . . . . . . . . . . . . . . . . 290
Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 294 Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 297
J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 294 J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 297
Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 296 Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 299
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 297 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 300
1. Introduction 1. Introduction
This memo defines version 2.0 of the Real Time Streaming Protocol This memo defines version 2.0 of the Real Time Streaming Protocol
(RTSP 2.0). RTSP 2.0 is an application-level protocol for setup and (RTSP 2.0). RTSP 2.0 is an application-level protocol for setup and
control over the delivery of data with real-time properties, control over the delivery of data with real-time properties,
typically streaming media. Streaming media is, for instance, video typically streaming media. Streaming media is, for instance, video
on demand or audio live streaming. Put simply, RTSP acts as a on demand or audio live streaming. Put simply, RTSP acts as a
"network remote control" for multimedia servers, similar to the "network remote control" for multimedia servers, similar to the
remote control for a DVD player. remote control for a DVD player.
skipping to change at page 14, line 37 skipping to change at page 14, line 37
media streams are available, and also which media delivery protocol media streams are available, and also which media delivery protocol
is used and their particular resource identifiers. The RTSP session is used and their particular resource identifiers. The RTSP session
is a common context between the client and the server that consists is a common context between the client and the server that consists
of one or more media resources that are to be under common media of one or more media resources that are to be under common media
delivery control. delivery control.
The client creates an RTSP session by sending a request using the The client creates an RTSP session by sending a request using the
SETUP method (Section 13.3) to the server. In the SETUP request the SETUP method (Section 13.3) to the server. In the SETUP request the
client also includes all the transport parameters necessary to enable client also includes all the transport parameters necessary to enable
the media delivery protocol to function in the "Transport" header the media delivery protocol to function in the "Transport" header
(Section 16.52). This includes parameters that are pre-established (Section 18.52). This includes parameters that are pre-established
by the presentation description but necessary for any middlebox to by the presentation description but necessary for any middlebox to
correctly handle the media delivery protocols. The Transport header correctly handle the media delivery protocols. The Transport header
in a request may contain multiple alternatives for media delivery in in a request may contain multiple alternatives for media delivery in
a prioritized list, which the server can select from. These a prioritized list, which the server can select from. These
alternatives are typically based on information in the presentation alternatives are typically based on information in the presentation
description. description.
The server determines if the media resource is available upon The server determines if the media resource is available upon
receiving a SETUP request and if any of the transport parameter receiving a SETUP request and if any of the transport parameter
specifications are acceptable. If that is successful, an RTSP specifications are acceptable. If that is successful, an RTSP
session context is created and the relevant parameters and state is session context is created and the relevant parameters and state is
stored. An identifier is created for the RTSP session and included stored. An identifier is created for the RTSP session and included
in the response in the Session header (Section 16.47). The SETUP in the response in the Session header (Section 18.47). The SETUP
response includes a Transport header that specifies which of the response includes a Transport header that specifies which of the
alternatives has been selected and relevant parameters. alternatives has been selected and relevant parameters.
A SETUP request that references an existing RTSP session but A SETUP request that references an existing RTSP session but
identifies a new media resource is a request to add that media identifies a new media resource is a request to add that media
resource under common control with the already present media resource under common control with the already present media
resources in an aggregated session. A client can expect this to work resources in an aggregated session. A client can expect this to work
for all media resources under RTSP control within a multi-media for all media resources under RTSP control within a multi-media
content. However, aggregating resources from different content are content. However, aggregating resources from different content are
likely to be refused by the server. The RTSP session as aggregate is likely to be refused by the server. The RTSP session as aggregate is
skipping to change at page 15, line 40 skipping to change at page 15, line 40
media resources. The Media-Range header inform the client about the media resources. The Media-Range header inform the client about the
time range of the media currently available. time range of the media currently available.
2.3. Media Delivery Control 2.3. Media Delivery Control
After having established an RTSP session, the client can start After having established an RTSP session, the client can start
controlling the media delivery. The basic operations are Start by controlling the media delivery. The basic operations are Start by
using the PLAY method (Section 13.4) and Halt by using the PAUSE using the PLAY method (Section 13.4) and Halt by using the PAUSE
method (Section 13.6). PLAY also allows for choosing the starting method (Section 13.6). PLAY also allows for choosing the starting
media position from which the server should deliver the media. The media position from which the server should deliver the media. The
positioning is done by using the Range header (Section 16.38) that positioning is done by using the Range header (Section 18.38) that
supports several different time formats: Normal Play Time (NPT) supports several different time formats: Normal Play Time (NPT)
(Section 4.5), SMPTE Timestamps (Section 4.4) and absolute time (Section 4.5), SMPTE Timestamps (Section 4.4) and absolute time
(Section 4.6). The Range header does further allow the client to (Section 4.6). The Range header does further allow the client to
specify a position where delivery should end, thus allowing a specify a position where delivery should end, thus allowing a
specific interval to be delivered. specific interval to be delivered.
The support for positioning/searching within a content depends on the The support for positioning/searching within a content depends on the
content's media properties. Content exists in a number of different content's media properties. Content exists in a number of different
types, such as: on-demand, live, and live with simultaneous types, such as: on-demand, live, and live with simultaneous
recording. Even within these categories there are differences in how recording. Even within these categories there are differences in how
the content is generated and distributed, which affect how it can be the content is generated and distributed, which affect how it can be
accessed for playback. The properties applicable for the RTSP accessed for playback. The properties applicable for the RTSP
session are provided by the server in the SETUP response using the session are provided by the server in the SETUP response using the
Media-Properties header (Section 16.28). These are expressed using Media-Properties header (Section 18.28). These are expressed using
one or several independent attributes. A first attribute is Random one or several independent attributes. A first attribute is Random
Access, which expresses if positioning can be done, and with what Access, which expresses if positioning can be done, and with what
granularity. Another aspect is whether the content will change granularity. Another aspect is whether the content will change
during the lifetime of the session. While on-demand content will during the lifetime of the session. While on-demand content will
provided in full from the beginning, a live stream being recorded provided in full from the beginning, a live stream being recorded
results in the length of the accessible content growing as the results in the length of the accessible content growing as the
session goes on. There also exist content that is dynamically built session goes on. There also exist content that is dynamically built
by another protocol than RTSP and thus also changes in steps during by another protocol than RTSP and thus also changes in steps during
the session, but maybe not continuously. Furthermore, when content the session, but maybe not continuously. Furthermore, when content
is recorded, there are cases where not the complete content is is recorded, there are cases where not the complete content is
skipping to change at page 17, line 50 skipping to change at page 17, line 50
are not supported. A priori determination of what features are are not supported. A priori determination of what features are
available needs to be done through out-of-band mechanisms, like the available needs to be done through out-of-band mechanisms, like the
session description, or through the usage of feature tags session description, or through the usage of feature tags
(Section 4.7). (Section 4.7).
2.5. Media Delivery 2.5. Media Delivery
The delivery of media to the RTSP client is done with a protocol The delivery of media to the RTSP client is done with a protocol
outside of RTSP and this protocol is determined during the session outside of RTSP and this protocol is determined during the session
establishment. This document specifies how media is delivered with establishment. This document specifies how media is delivered with
RTP over UDP, TCP or the RTSP control connection. Additional RTP [RFC3550] over UDP [RFC0768], TCP [RFC0793] or the RTSP control
protocols may be specified in the future based on demand. connection. Additional protocols may be specified in the future
based on demand.
The usage of RTP as media delivery protocol requires some additional The usage of RTP as media delivery protocol requires some additional
information to function well. The PLAY response contains information information to function well. The PLAY response contains information
to enable reliable and timely delivery of how a client should to enable reliable and timely delivery of how a client should
synchronize different sources in the different RTP sessions. It also synchronize different sources in the different RTP sessions. It also
provides a mapping between RTP timestamps and the content time scale. provides a mapping between RTP timestamps and the content time scale.
When the server wants to notify the client about the completion of 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 media delivery, it sends a PLAY_NOTIFY request to the client.
The PLAY_NOTIFY request includes information about the stream end, The PLAY_NOTIFY request includes information about the stream end,
including the last RTP sequence number for each stream, thus enabling including the last RTP sequence number for each stream, thus enabling
skipping to change at page 21, line 50 skipping to change at page 22, line 4
RTSP is quite a versatile protocol which supports extensions in many RTSP is quite a versatile protocol which supports extensions in many
different directions. Even this core specification contains several different directions. Even this core specification contains several
blocks of functionality that are optional to implement. The use case blocks of functionality that are optional to implement. The use case
and need for the protocol deployment should determine what parts are and need for the protocol deployment should determine what parts are
implemented. Allowing for extensions makes it possible for RTSP to implemented. Allowing for extensions makes it possible for RTSP to
reach out to additional use cases. However, extensions will affect reach out to additional use cases. However, extensions will affect
the interoperability of the protocol and therefore it is important the interoperability of the protocol and therefore it is important
that they can be added in a structured way. that they can be added in a structured way.
The client can learn the capability of a server by using the OPTIONS The client can learn the capability of a server by using the OPTIONS
method (Section 13.1) and the Supported header (Section 16.49). It method (Section 13.1) and the Supported header (Section 18.49). It
can also try and possibly fail using new methods, or require that can also try and possibly fail using new methods, or require that
particular features are supported using the Require or Proxy-Require particular features are supported using the Require or Proxy-Require
header. header.
The RTSP protocol in itself can be extended in three ways, listed The RTSP protocol in itself can be extended in three ways, listed
here in order of the magnitude of changes supported: here in order of the magnitude of changes supported:
o Existing methods can be extended with new parameters, for example, o Existing methods can be extended with new parameters, for example,
headers, as long as these parameters can be safely ignored by the headers, as long as these parameters can be safely ignored by the
recipient. If the client needs negative acknowledgment when a recipient. If the client needs negative acknowledgment when a
method extension is not supported, a tag corresponding to the method extension is not supported, a tag corresponding to the
extension may be added in the field of the Require or Proxy- extension may be added in the field of the Require or Proxy-
Require headers (see Section 16.35). Require headers (see Section 18.35).
o New methods can be added. If the recipient of the message does 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 understand the request, it must respond with error code 501
(Not Implemented) so that the sender can avoid using this method (Not Implemented) so that the sender can avoid using this method
again. A client may also use the OPTIONS method to inquire about again. A client may also use the OPTIONS method to inquire about
methods supported by the server. The server must list the methods methods supported by the server. The server must list the methods
it supports using the Public response header. it supports using the Public response header.
o A new version of the protocol can be defined, allowing almost all o A new version of the protocol can be defined, allowing almost all
aspects (except the position of the protocol version number) to aspects (except the position of the protocol version number) to
skipping to change at page 31, line 24 skipping to change at page 31, line 24
using UTC (GMT). Fractions of a second may be indicated. using UTC (GMT). Fractions of a second may be indicated.
Example for November 8, 1996 at 14h 37 min and 20 and a quarter Example for November 8, 1996 at 14h 37 min and 20 and a quarter
seconds UTC: seconds UTC:
19961108T143720.25Z 19961108T143720.25Z
4.7. Feature-Tags 4.7. Feature-Tags
Feature-tags are unique identifiers used to designate features in Feature-tags are unique identifiers used to designate features in
RTSP. These tags are used in Require (Section 16.41), Proxy-Require RTSP. These tags are used in Require (Section 18.41), Proxy-Require
(Section 16.35), Proxy-Supported (Section 16.36), Supported (Section 18.35), Proxy-Supported (Section 18.36), Supported
(Section 16.49) and Unsupported (Section 16.53) header fields. (Section 18.49) and Unsupported (Section 18.53) header fields.
A feature-tag definition MUST indicate which combination of clients, A feature-tag definition MUST indicate which combination of clients,
servers or proxies it applies to. servers or proxies it applies to.
The creator of a new RTSP feature-tag should either prefix the The creator of a new RTSP feature-tag should either prefix the
feature-tag with a reverse domain name (e.g., feature-tag with a reverse domain name (e.g.,
"com.example.mynewfeature" is an apt name for a feature whose "com.example.mynewfeature" is an apt name for a feature whose
inventor can be reached at "example.com"), or register the new inventor can be reached at "example.com"), or register the new
feature-tag with the Internet Assigned Numbers Authority (IANA) (see feature-tag with the Internet Assigned Numbers Authority (IANA) (see
IANA Section 22). IANA Section 22).
The usage of feature-tags is further described in Section 11 that The usage of feature-tags is further described in Section 11 that
deals with capability handling. deals with capability handling.
4.8. Message Body Tags 4.8. Message Body Tags
Message body tags are opaque strings that are used to compare two Message body tags are opaque strings that are used to compare two
message bodies from the same resource, for example in caches or to message bodies from the same resource, for example in caches or to
optimize setup after a redirect. Message body tags can be carried in optimize setup after a redirect. Message body tags can be carried in
the MTag header (see Section 16.30) or in SDP (see Appendix D.1.9). the MTag header (see Section 18.30) or in SDP (see Appendix D.1.9).
MTag is similar to ETag in HTTP/1.1. MTag is similar to ETag in HTTP/1.1.
A message body tag MUST be unique across all versions of all message A message body tag MUST be unique across all versions of all message
bodies associated with a particular resource. A given message body bodies associated with a particular resource. A given message body
tag value MAY be used for message bodies obtained by requests on tag value MAY be used for message bodies obtained by requests on
different URIs. The use of the same message body tag value in different URIs. The use of the same message body tag value in
conjunction with message bodies obtained by requests on different conjunction with message bodies obtained by requests on different
URIs does not imply the equivalence of those message bodies URIs does not imply the equivalence of those message bodies
Message body tags are used in RTSP to make some methods conditional. Message body tags are used in RTSP to make some methods conditional.
The methods are made conditional through the inclusion of headers; The methods are made conditional through the inclusion of headers;
see "If-Match" (Section 16.23) and "If-None-Match" (Section 16.25). see "If-Match" (Section 18.23) and "If-None-Match" (Section 18.25).
Note that RTSP message body tags apply to the complete presentation; Note that RTSP message body tags apply to the complete presentation;
i.e., both the presentation description and the individual media i.e., both the presentation description and the individual media
streams. Thus message body tags can be used to verify at setup time streams. Thus message body tags can be used to verify at setup time
after a redirect that the same session description applies to the after a redirect that the same session description applies to the
media at the new location using the If-Match header. media at the new location using the If-Match header.
4.9. Media Properties 4.9. Media Properties
When an RTSP server handles media, it is important to consider the When an RTSP server handles media, it is important to consider the
different properties a media instance for delivery and playback can different properties a media instance for delivery and playback can
skipping to change at page 33, line 15 skipping to change at page 33, line 15
data is discarded. data is discarded.
To cover the above usages, the following media properties with To cover the above usages, the following media properties with
appropriate values are specified: appropriate values are specified:
4.9.1. Random Access and Seeking 4.9.1. Random Access and Seeking
Random Access is the ability to specify and get media delivered from Random Access is the ability to specify and get media delivered from
any point inside the content, an operation called seeking. This any point inside the content, an operation called seeking. This
possibility is signaled using the Seek-Style header (see possibility is signaled using the Seek-Style header (see
Section 16.45) which can take the following different values: Section 18.45) which can take the following different values:
Random Access: The media is seekable to any out of a large number of Random Access: The media is seekable to any out of a large number of
points within the media. Due to media encoding limitations, a points within the media. Due to media encoding limitations, a
particular point may not be reachable, but seeking to a point particular point may not be reachable, but seeking to a point
close by is enabled. A floating point number of seconds may be close by is enabled. A floating point number of seconds may be
provided to express the worst case distance between random access provided to express the worst case distance between random access
points. points.
Conditional Random Access: Based on the above Random Access but Conditional Random Access: Based on the above Random Access but
intended to handle a case where the distance in the media between intended to handle a case where the distance in the media between
skipping to change at page 35, line 50 skipping to change at page 35, line 49
[ message-body-data ] [ message-body-data ]
start-line = Request-Line | Status-Line start-line = Request-Line | Status-Line
In the interest of robustness, agents MUST ignore any empty line(s) In the interest of robustness, agents MUST ignore any empty line(s)
received where a Request-Line or Response-Line is expected. In other received where a Request-Line or Response-Line is expected. In other
words, if the agent is reading the protocol stream at the beginning 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. of a message and receives a CRLF first, it MUST ignore the CRLF.
5.2. Message Headers 5.2. Message Headers
RTSP header fields (see Section 16) include general-header, request- RTSP header fields (see Section 18) include general-header, request-
header, response-header, and message-body header fields. header, response-header, and message-body header fields.
The order in which header fields with differing field names are The order in which header fields with differing field names are
received is not significant. However, it is "good practice" to send received is not significant. However, it is "good practice" to send
general-header fields first, followed by request-header or response- general-header fields first, followed by request-header or response-
header fields, and ending with the Message-body header fields. header fields, and ending with the Message-body header fields.
Multiple message-header fields with the same field-name MAY be 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 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 header field is defined as a comma-separated list. It MUST be
skipping to change at page 36, line 27 skipping to change at page 36, line 25
are received is therefore significant to the interpretation of the are received is therefore significant to the interpretation of the
combined field value, and thus a proxy MUST NOT change the order of combined field value, and thus a proxy MUST NOT change the order of
these field values when a message is forwarded. these field values when a message is forwarded.
Unknown message headers MUST be ignored (skipping over the header to Unknown message headers MUST be ignored (skipping over the header to
the next protocol element, and not causing an error) by a RTSP server the next protocol element, and not causing an error) by a RTSP server
or client. An RTSP Proxy MUST forward unknown message headers. or client. An RTSP Proxy MUST forward unknown message headers.
Message headers defined outside of this specification that are Message headers defined outside of this specification that are
required to be interpreted by the RTSP agent will need to use feature required to be interpreted by the RTSP agent will need to use feature
tags (Section 4.7) and include them in the appropriate Require tags (Section 4.7) and include them in the appropriate Require
(Section 16.41) or Proxy-Require (Section 16.35) header. (Section 18.41) or Proxy-Require (Section 18.35) header.
5.3. Message Body 5.3. Message Body
The message body (if any) of an RTSP message is used to carry further The message body (if any) of an RTSP message is used to carry further
information for a particular resource associated with the request or information for a particular resource associated with the request or
response. An example of a message body is the Session Description response. An example of a message body is the Session Description
Protocol (SDP). Protocol (SDP).
The presence of a message body in either a request or a response MUST The presence of a message body in either a request or a response MUST
be signaled by the inclusion of a Content-Length header (see be signaled by the inclusion of a Content-Length header (see
Section 16.16). A message body MUST NOT be included in a request or Section 18.16). A message body MUST NOT be included in a request or
response if the specification of the particular method (see Method response if the specification of the particular method (see Method
Definitions (Section 13)) does not allow sending a message body. Definitions (Section 13)) does not allow sending a message body.
5.4. Message Length 5.4. Message Length
When a message body is included in a message, the length of that body When a message body is included in a message, the length of that body
is determined by one of the following (in order of precedence): is determined by one of the following (in order of precedence):
1. Any response message which MUST NOT include a message body (such 1. Any response message which MUST NOT include a message body (such
as the 1xx, 204, and 304 responses) is always terminated by the as the 1xx, 204, and 304 responses) is always terminated by the
first empty line after the header fields, regardless of the first empty line after the header fields, regardless of the
message-header fields present in the message. (Note: An empty message-header fields present in the message. (Note: An empty
line is a line with nothing preceding the CRLF.) line is a line with nothing preceding the CRLF.)
2. If a Content-Length header(Section 16.16) is present, its value 2. If a Content-Length header(Section 18.16) is present, its value
in bytes represents the length of the message-body. If this in bytes represents the length of the message-body. If this
header field is not present, a value of zero is assumed. header field is not present, a value of zero is assumed.
Unlike an HTTP message, an RTSP message MUST contain a Content-Length Unlike an HTTP message, an RTSP message MUST contain a Content-Length
header whenever it contains a message body. Note that RTSP does not header whenever it contains a message body. Note that RTSP does not
support the HTTP/1.1 "chunked" transfer coding (see [H3.6.1]). support the HTTP/1.1 "chunked" transfer coding (see [H3.6.1]).
Given the moderate length of presentation descriptions returned, Given the moderate length of presentation descriptions returned,
the server should always be able to determine its length, even if the server should always be able to determine its length, even if
it is generated dynamically, making the chunked transfer encoding it is generated dynamically, making the chunked transfer encoding
unnecessary. unnecessary.
6. General Header Fields 6. General Header Fields
General headers are headers that may be used in both requests and General headers are headers that may be used in both requests and
responses. The general headers are listed in Table 1: responses. The general headers are listed in Table 1:
+--------------------+--------------------+ +--------------------+--------------------+
| Header Name | Defined in Section | | Header Name | Defined in Section |
+--------------------+--------------------+ +--------------------+--------------------+
| Accept-Ranges | Section 16.5 | | Accept-Ranges | Section 18.5 |
| | | | | |
| Cache-Control | Section 16.10 | | Cache-Control | Section 18.10 |
| | | | | |
| Connection | Section 16.11 | | Connection | Section 18.11 |
| | | | | |
| CSeq | Section 16.19 | | CSeq | Section 18.19 |
| | | | | |
| Date | Section 16.20 | | Date | Section 18.20 |
| | | | | |
| Media-Properties | Section 16.28 | | Media-Properties | Section 18.28 |
| | | | | |
| Media-Range | Section 16.29 | | Media-Range | Section 18.29 |
| | | | | |
| Pipelined-Requests | Section 16.32 | | Pipelined-Requests | Section 18.32 |
| | | | | |
| Proxy-Supported | Section 16.36 | | Proxy-Supported | Section 18.36 |
| | | | | |
| RTP-Info | Section 16.43 | | RTP-Info | Section 18.43 |
| | | | | |
| Seek-Style | Section 16.45 | | Seek-Style | Section 18.45 |
| | | | | |
| Supported | Section 16.49 | | Supported | Section 18.49 |
| | | | | |
| Timestamp | Section 16.51 | | Timestamp | Section 18.51 |
| | | | | |
| Via | Section 16.56 | | Via | Section 18.55 |
+--------------------+--------------------+ +--------------------+--------------------+
Table 1: The general headers used in RTSP Table 1: The general headers used in RTSP
7. Request 7. Request
A request message uses the format outlined below regardless of the A request message uses the format outlined below regardless of the
direction of a request, client to server or server to client: direction of a request, client to server or server to client:
o Request line, containing the method to be applied to the resource, o Request line, containing the method to be applied to the resource,
skipping to change at page 41, line 29 skipping to change at page 41, line 29
7.2. Request Header Fields 7.2. Request Header Fields
The RTSP headers in Table 3 can be included in a request, as request The RTSP headers in Table 3 can be included in a request, as request
headers, to modify the specifics of the request. Some of these headers, to modify the specifics of the request. Some of these
headers may also be used in the response to a request, as response headers may also be used in the response to a request, as response
headers, to modify the specifics of a response (Section 8.2). headers, to modify the specifics of a response (Section 8.2).
+--------------------+--------------------+ +--------------------+--------------------+
| Header | Defined in Section | | Header | Defined in Section |
+--------------------+--------------------+ +--------------------+--------------------+
| Accept | Section 16.1 | | Accept | Section 18.1 |
| | | | | |
| Accept-Credentials | Section 16.2 | | Accept-Credentials | Section 18.2 |
| | | | | |
| Accept-Encoding | Section 16.3 | | Accept-Encoding | Section 18.3 |
| | | | | |
| Accept-Language | Section 16.4 | | Accept-Language | Section 18.4 |
| | | | | |
| Authorization | Section 16.7 | | Authorization | Section 18.7 |
| | | | | |
| Bandwidth | Section 16.8 | | Bandwidth | Section 18.8 |
| | | | | |
| Blocksize | Section 16.9 | | Blocksize | Section 18.9 |
| | | | | |
| From | Section 16.22 | | From | Section 18.22 |
| | | | | |
| If-Match | Section 16.23 | | If-Match | Section 18.23 |
| | | | | |
| If-Modified-Since | Section 16.24 | | If-Modified-Since | Section 18.24 |
| | | | | |
| If-None-Match | Section 16.25 | | If-None-Match | Section 18.25 |
| | | | | |
| Notify-Reason | Section 16.31 | | Notify-Reason | Section 18.31 |
| | | | | |
| Proxy-Require | Section 16.35 | | Proxy-Require | Section 18.35 |
| | | | | |
| Range | Section 16.38 | | Range | Section 18.38 |
| | | | | |
| Referrer | Section 16.39 | | Referrer | Section 18.39 |
| | | | | |
| Request-Status | Section 16.40 | | Request-Status | Section 18.40 |
| | | | | |
| Require | Section 16.41 | | Require | Section 18.41 |
| | | | | |
| Scale | Section 16.44 | | Scale | Section 18.44 |
| | | | | |
| Session | Section 16.47 | | Session | Section 18.47 |
| | | | | |
| Speed | Section 16.48 | | Speed | Section 18.48 |
| | | | | |
| Supported | Section 16.49 | | Supported | Section 18.49 |
| | | | | |
| Terminate-Reason | Section 16.50 | | Terminate-Reason | Section 18.50 |
| | | | | |
| Transport | Section 16.52 | | Transport | Section 18.52 |
| | | | | |
| User-Agent | Section 16.54 | | User-Agent | Section 18.54 |
+--------------------+--------------------+ +--------------------+--------------------+
Table 3: The RTSP request headers Table 3: The RTSP request headers
Detailed header definition are provided in Section 16. Detailed header definition are provided in Section 18
New request headers may be defined. If the receiver of the request New request headers may be defined. If the receiver of the request
is required to understand the request header, the request MUST is required to understand the request header, the request MUST
include a corresponding feature tag in a Require or Proxy-Require include a corresponding feature tag in a Require or Proxy-Require
header to ensure the processing of the header. header to ensure the processing of the header.
8. Response 8. Response
After receiving and interpreting a request message, the recipient After receiving and interpreting a request message, the recipient
responds with an RTSP response message. Normally, there is only one, responds with an RTSP response message. Normally, there is only one,
skipping to change at page 43, line 30 skipping to change at page 43, line 30
textual phrase associated with the status code, with each element textual phrase associated with the status code, with each element
separated by SP characters. No CR or LF is allowed except in the separated by SP characters. No CR or LF is allowed except in the
final CRLF sequence. final CRLF sequence.
<RTSP-Version> SP <Status-Code> SP <Reason-Phrase> CRLF <RTSP-Version> SP <Status-Code> SP <Reason-Phrase> CRLF
8.1.1. Status Code and Reason Phrase 8.1.1. Status Code and Reason Phrase
The Status-Code element is a 3-digit integer result code of the The Status-Code element is a 3-digit integer result code of the
attempt to understand and satisfy the request. These codes are fully attempt to understand and satisfy the request. These codes are fully
defined in Section 15. The Reason-Phrase is intended to give a short defined in Section 17. The Reason-Phrase is intended to give a short
textual description of the Status-Code. The Status-Code is intended textual description of the Status-Code. The Status-Code is intended
for use by automata and the Reason-Phrase is intended for the human 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- user. The client is not required to examine or display the Reason-
Phrase. Phrase.
The first digit of the Status-Code defines the class of response. 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 The last two digits do not have any categorization role. There are 5
values for the first digit: values for the first digit:
1xx: Informational - Request received, continuing process 1xx: Informational - Request received, continuing process
skipping to change at page 47, line 10 skipping to change at page 47, line 10
The response-header allows the request recipient to pass additional The response-header allows the request recipient to pass additional
information about the response which cannot be placed in the Status- information about the response which cannot be placed in the Status-
Line. This header gives information about the server and about Line. This header gives information about the server and about
further access to the resource identified by the Request-URI. All further access to the resource identified by the Request-URI. All
headers currently classified as response headers are listed in headers currently classified as response headers are listed in
Table 5. Table 5.
+------------------------+--------------------+ +------------------------+--------------------+
| Header | Defined in Section | | Header | Defined in Section |
+------------------------+--------------------+ +------------------------+--------------------+
| Connection-Credentials | Section 16.12 | | Connection-Credentials | Section 18.12 |
| | |
| Location | Section 16.27 |
| | | | | |
| MTag | Section 16.30 | | Location | Section 18.27 |
| | | | | |
| Proxy-Authenticate | Section 16.33 | | MTag | Section 18.30 |
| | | | | |
| Public | Section 16.37 | | Proxy-Authenticate | Section 18.33 |
| | | | | |
| Range | Section 16.38 | | Public | Section 18.37 |
| | | | | |
| Retry-After | Section 16.42 | | Range | Section 18.38 |
| | | | | |
| Scale | Section 16.44 | | Retry-After | Section 18.42 |
| | | | | |
| Session | Section 16.47 | | Scale | Section 18.44 |
| | | | | |
| Server | Section 16.46 | | Session | Section 18.47 |
| | | | | |
| Speed | Section 16.48 | | Server | Section 18.46 |
| | | | | |
| Transport | Section 16.52 | | Speed | Section 18.48 |
| | | | | |
| Unsupported | Section 16.53 | | Transport | Section 18.52 |
| | | | | |
| Vary | Section 16.55 | | Unsupported | Section 18.53 |
| | | | | |
| WWW-Authenticate | Section 16.57 | | WWW-Authenticate | Section 18.56 |
+------------------------+--------------------+ +------------------------+--------------------+
Table 5: The RTSP response headers Table 5: The RTSP response headers
Response-header names can be extended reliably only in combination Response-header names can be extended reliably only in combination
with a change in the protocol version. However, the usage of with a change in the protocol version. However, the usage of
feature-tags in the request allows the responding party to learn the feature-tags in the request allows the responding party to learn the
capability of the receiver of the response. A new or experimental capability of the receiver of the response. A new or experimental
header MAY be given the semantics of response-header if all parties header MAY be given the semantics of response-header if all parties
in the communication recognize them to be response-header. in the communication recognize them to be response-header.
skipping to change at page 48, line 29 skipping to change at page 48, line 29
9.1. Message-Body Header Fields 9.1. Message-Body Header Fields
Message-body header fields define meta-information about the content Message-body header fields define meta-information about the content
data in the message body. The message-body header fields are listed data in the message body. The message-body header fields are listed
in Table 6. in Table 6.
+------------------+--------------------+ +------------------+--------------------+
| Header | Defined in Section | | Header | Defined in Section |
+------------------+--------------------+ +------------------+--------------------+
| Allow | Section 16.6 | | Allow | Section 18.6 |
| | | | | |
| Content-Base | Section 16.13 | | Content-Base | Section 18.13 |
| | | | | |
| Content-Encoding | Section 16.14 | | Content-Encoding | Section 18.14 |
| | | | | |
| Content-Language | Section 16.15 | | Content-Language | Section 18.15 |
| | | | | |
| Content-Length | Section 16.16 | | Content-Length | Section 18.16 |
| | | | | |
| Content-Location | Section 16.17 | | Content-Location | Section 18.17 |
| | | | | |
| Content-Type | Section 16.18 | | Content-Type | Section 18.18 |
| | | | | |
| Expires | Section 16.21 | | Expires | Section 18.21 |
| | | | | |
| Last-Modified | Section 16.26 | | Last-Modified | Section 18.26 |
+------------------+--------------------+ +------------------+--------------------+
Table 6: The RTSP message-body headers Table 6: The RTSP message-body headers
The extension-header mechanism allows additional message-body header The extension-header mechanism allows additional message-body header
fields to be defined without changing the protocol, but these fields fields to be defined without changing the protocol, but these fields
cannot be assumed to be recognizable by the recipient. Unrecognized cannot be assumed to be recognizable by the recipient. Unrecognized
header fields MUST be ignored by the recipient and forwarded by header fields MUST be ignored by the recipient and forwarded by
proxies. proxies.
skipping to change at page 50, line 27 skipping to change at page 50, line 27
RTSP messages in connectionless mode over a transport protocol such RTSP messages in connectionless mode over a transport protocol such
as UDP. However, it was not specified in sufficient detail to allow as UDP. However, it was not specified in sufficient detail to allow
for interoperable implementations. In an attempt to reduce for interoperable implementations. In an attempt to reduce
complexity and scope, and due to lack of interest, RTSP 2.0 does not 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 attempt to define a mechanism for supporting RTSP over UDP or other
connectionless transport protocols. A side-effect of this is that connectionless transport protocols. A side-effect of this is that
RTSP requests MUST NOT be sent to multicast groups since no RTSP requests MUST NOT be sent to multicast groups since no
connection can be established with a specific receiver in multicast connection can be established with a specific receiver in multicast
environments. environments.
Certain RTSP headers, such as the CSeq header (Section 16.19), which Certain RTSP headers, such as the CSeq header (Section 18.19), which
may appear to be relevant only to connectionless transport scenarios may appear to be relevant only to connectionless transport scenarios
are still retained and MUST be implemented according to the are still retained and MUST be implemented according to the
specification. In the case of CSeq, it is quite useful for matching specification. In the case of CSeq, it is quite useful for matching
responses to requests if the requests are pipelined (see Section 12). responses to requests if the requests are pipelined (see Section 12).
It is also useful in proxies for keeping track of the different It is also useful in proxies for keeping track of the different
requests when aggregating several client requests on a single TCP requests when aggregating several client requests on a single TCP
connection. connection.
10.1. Reliability and Acknowledgements 10.1. Reliability and Acknowledgements
skipping to change at page 53, line 22 skipping to change at page 53, line 22
In light of the above, it is RECOMMENDED that clients use persistent In light of the above, it is RECOMMENDED that clients use persistent
connections whenever possible. A client that supports persistent connections whenever possible. A client that supports persistent
connections MAY "pipeline" its requests (see Section 12). connections MAY "pipeline" its requests (see Section 12).
10.3. Closing Connections 10.3. Closing Connections
The client MAY close a connection at any point when no outstanding The client MAY close a connection at any point when no outstanding
request/response transactions exist for any RTSP session being request/response transactions exist for any RTSP session being
managed through the connection. The server, however, SHOULD NOT managed through the connection. The server, however, SHOULD NOT
close a connection until all RTSP sessions being managed through the close a connection until all RTSP sessions being managed through the
connection have been timed out (Section 16.47). A server SHOULD NOT connection have been timed out (Section 18.47). A server SHOULD NOT
close a connection immediately after responding to a session-level close a connection immediately after responding to a session-level
TEARDOWN request for the last RTSP session being controlled through TEARDOWN request for the last RTSP session being controlled through
the connection. Instead, it should wait for a reasonable amount of the connection. Instead, it should wait for a reasonable amount of
time for the client to receive the TEARDOWN response, take time for the client to receive the TEARDOWN response, take
appropriate action, and initiate the connection closing. The server appropriate action, and initiate the connection closing. The server
SHOULD wait at least 10 seconds after sending the TEARDOWN response SHOULD wait at least 10 seconds after sending the TEARDOWN response
before closing the connection. before closing the connection.
This is to ensure that the client has time to issue a SETUP for a 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 new session on the existing connection after having torn the last
one down. 10 seconds should give the client ample opportunity to one down. 10 seconds should give the client ample opportunity to
get its message to the server. get its message to the server.
A server SHOULD NOT close the connection directly as a result of A server SHOULD NOT close the connection directly as a result of
responding to a request with an error code. responding to a request with an error code.
Certain error responses such as "460 Only Aggregate Operation Certain error responses such as "460 Only Aggregate Operation
Allowed" (Section 15.4.25) are used for negotiating capabilities Allowed" (Section 17.4.25) are used for negotiating capabilities
of a server with respect to content or other factors. In such of a server with respect to content or other factors. In such
cases, it is inefficient for the server to close a connection on cases, it is inefficient for the server to close a connection on
an error response. Also, such behavior would prevent an error response. Also, such behavior would prevent
implementation of advanced/special types of requests or result in implementation of advanced/special types of requests or result in
extra overhead for the client when testing for new features. On extra overhead for the client when testing for new features. On
the flip side, keeping connections open after sending an error the flip side, keeping connections open after sending an error
response poses a Denial of Service security risk (Section 21). response poses a Denial of Service security risk (Section 21).
The server MAY close a connection if it receives an incomplete The server MAY close a connection if it receives an incomplete
message and if the message is not completed within a reasonable message and if the message is not completed within a reasonable
skipping to change at page 54, line 45 skipping to change at page 54, line 45
A requester SHOULD wait at least 10 seconds for a response before A requester SHOULD wait at least 10 seconds for a response before
concluding that the responder will not be responding to its request. concluding that the responder will not be responding to its request.
After receiving a 100 response, the requester SHOULD continue waiting After receiving a 100 response, the requester SHOULD continue waiting
for further responses. If more than 10 seconds elapses without for further responses. If more than 10 seconds elapses without
receiving any response, the requester MAY assume that the responder receiving any response, the requester MAY assume that the responder
is unresponsive and abort the connection. is unresponsive and abort the connection.
A requester SHOULD wait longer than 10 seconds for a response if it A requester SHOULD wait longer than 10 seconds for a response if it
is experiencing significant transport delays on its connection to the is experiencing significant transport delays on its connection to the
responder. The requester is capable of determining the RTT of the responder. The requester is capable of determining the RTT of the
request/response cycle using the Timestamp header (Section 16.51) in request/response cycle using the Timestamp header (Section 18.51) in
any RTSP request. any RTSP request.
10 seconds was chosen for the following reasons. It gives TCP 10 seconds was chosen for the following reasons. It gives TCP
time to perform a couple of retransmissions, even if operating on time to perform a couple of retransmissions, even if operating on
default values. It is short enough that users may not abandon the default values. It is short enough that users may not abandon the
process themselves. However, it should be noted that 10 seconds process themselves. However, it should be noted that 10 seconds
can be aggressive on certain type of networks. The 5 seconds can be aggressive on certain type of networks. The 5 seconds
value for 1xx messages is half the timeout giving a reasonable value for 1xx messages is half the timeout giving a reasonable
change of successful delivery before timeout happens on the change of successful delivery before timeout happens on the
requester side. requester side.
skipping to change at page 56, line 15 skipping to change at page 56, line 15
The timeout parameter MAY be included in a SETUP response, and MUST The timeout parameter MAY be included in a SETUP response, and MUST
NOT be included in requests. The server uses it to indicate to the 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 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 or other signs of life before closing the session due to lack of
activity (see Appendix B). The timeout is measured in seconds, with activity (see Appendix B). The timeout is measured in seconds, with
a default of 60 seconds. The length of the session timeout MUST NOT a default of 60 seconds. The length of the session timeout MUST NOT
be changed in an established session. be changed in an established session.
10.6. Use of IPv6 10.6. Use of IPv6
Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP Explicit IPv6 [RFC2460] support was not present in RTSP 1.0 (RFC
2.0 has been updated for explicit IPv6 support. Implementations of 2326). RTSP 2.0 has been updated for explicit IPv6 support.
RTSP 2.0 MUST understand literal IPv6 addresses in URIs and headers. Implementations of RTSP 2.0 MUST understand literal IPv6 addresses in
URIs and headers.
10.7. Overload Control 10.7. Overload Control
Overload in RTSP can occur when servers and proxies have insufficient Overload in RTSP can occur when servers and proxies have insufficient
resources to complete the processing of a request. An improper resources to complete the processing of a request. An improper
handling of such an overload situation at proxies and servers can handling of such an overload situation at proxies and servers can
impact the operation of the RTSP deployment, and probably worsen the impact the operation of the RTSP deployment, and probably worsen the
situation. RTSP defines the 503 (Service Unavailable) response situation. RTSP defines the 503 (Service Unavailable) response
(Section 15.5.4) to let servers and proxies notify requesting proxies (Section 17.5.4) to let servers and proxies notify requesting proxies
and RTSP clients about an overload situation. In conjunction with and RTSP clients about an overload situation. In conjunction with
the Retry-After header (Section 16.42) the server or proxy can the Retry-After header (Section 18.42) the server or proxy can
indicate the time after the requesting entity can send another indicate the time after the requesting entity can send another
request to the proxy or server. request to the proxy or server.
Simply implementing and using the 503 (Service Unavailable) is not Simply implementing and using the 503 (Service Unavailable) is not
sufficient for properly handling overload situations. For instance, sufficient for properly handling overload situations. For instance,
a simplistic approach would be to send the 503 response with a Retry- 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 After header set to a fixed value. However, this can cause the
situation where multiple RTSP clients again send requests to a proxy situation where multiple RTSP clients again send requests to a proxy
or server at roughly the same time which may again cause an overload or server at roughly the same time which may again cause an overload
situation, or if the "old" overload situation is not yet solved, situation, or if the "old" overload situation is not yet solved,
skipping to change at page 60, line 24 skipping to change at page 60, line 24
by the CSeq header and its sequence number. For TCP the delivery by the CSeq header and its sequence number. For TCP the delivery
order will be the same as the sending order. The processing of the order will be the same as the sending order. The processing of the
request MUST also have been finished before processing the next request MUST also have been finished before processing the next
request from the same agent. The responses MUST be sent in the order request from the same agent. The responses MUST be sent in the order
the requests were processed. the requests were processed.
RTSP 2.0 has extended support for pipelining compared to RTSP 1.0. RTSP 2.0 has extended support for pipelining compared to RTSP 1.0.
The major improvement is to allow all requests to setup and initiate The major improvement is to allow all requests to setup and initiate
media delivery to be pipelined after each other. This is media delivery to be pipelined after each other. This is
accomplished by the utilization of the Pipelined-Requests header (see accomplished by the utilization of the Pipelined-Requests header (see
Section 16.32). This header allows a client to request that two or Section 18.32). This header allows a client to request that two or
more requests are processed in the same RTSP session context which more requests are processed in the same RTSP session context which
the first request creates. In other words, a client can request that the first request creates. In other words, a client can request that
two or more media streams are set-up and then played without needing two or more media streams are set-up and then played without needing
to wait for a single response. This speeds up the initial startup to wait for a single response. This speeds up the initial startup
time for an RTSP session with at least one RTT. time for an RTSP session with at least one RTT.
If a pipelined request builds on the successful completion of one or If a pipelined request builds on the successful completion of one or
more prior requests the requester must verify that all requests were more prior requests the requester must verify that all requests were
executed as expected. A common example will be two SETUP requests executed as expected. A common example will be two SETUP requests
and a PLAY request. In case one of the SETUP fails unexpectedly, the and a PLAY request. In case one of the SETUP fails unexpectedly, the
skipping to change at page 63, line 8 skipping to change at page 63, line 8
included in the response to enumerate the set of methods that are included in the response to enumerate the set of methods that are
allowed for that resource unless the set of methods completely allowed for that resource unless the set of methods completely
matches the set in the Public header. If the given resource is not matches the set in the Public header. If the given resource is not
available, the RTSP agent SHOULD return an appropriate response code available, the RTSP agent SHOULD return an appropriate response code
such as 3rr or 4xx. The Supported header MAY be included in the such as 3rr or 4xx. The Supported header MAY be included in the
request to query the set of features that are supported by the request to query the set of features that are supported by the
responding RTSP agent. responding RTSP agent.
The OPTIONS method can be used to keep an RTSP session alive. The OPTIONS method can be used to keep an RTSP session alive.
However, this is not the preferred way of session keep-alive However, this is not the preferred way of session keep-alive
signaling, see Section 16.47. An OPTIONS request intended for signaling, see Section 18.47. An OPTIONS request intended for
keeping alive an RTSP session MUST include the Session header with keeping alive an RTSP session MUST include the Session header with
the associated session ID. Such a request SHOULD also use the media the associated session ID. Such a request SHOULD also use the media
or the aggregated control URI as the Request-URI. or the aggregated control URI as the Request-URI.
Example: Example:
C->S: OPTIONS rtsp://server.example.com RTSP/2.0 C->S: OPTIONS rtsp://server.example.com RTSP/2.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Proxy-Require: gzipped-messages Proxy-Require: gzipped-messages
skipping to change at page 65, line 29 skipping to change at page 65, line 29
The SETUP request for an URI specifies the transport mechanism to be The SETUP request for an URI specifies the transport mechanism to be
used for the streamed media. The SETUP method may be used in two used for the streamed media. The SETUP method may be used in two
different cases; Create an RTSP session and change the transport different cases; Create an RTSP session and change the transport
parameters of already set up media stream. SETUP can be used in all parameters of already set up media stream. SETUP can be used in all
three states; Init, and Ready, for both purposes and in PLAY to three states; Init, and Ready, for both purposes and in PLAY to
change the transport parameters. There is also a third possible change the transport parameters. There is also a third possible
usage for the SETUP method which is not specified in this memo: usage for the SETUP method which is not specified in this memo:
adding a media to a session. Using SETUP to add media to an existing adding a media to a session. Using SETUP to add media to an existing
session, when the session is in Play state, is unspecified. session, when the session is in Play state, is unspecified.
The Transport header, see Section 16.52, specifies the media The Transport header, see Section 18.52, specifies the media
transport parameters acceptable to the client for data transmission; transport parameters acceptable to the client for data transmission;
the response will contain the transport parameters selected by the the response will contain the transport parameters selected by the
server. This allows the client to enumerate in descending order of server. This allows the client to enumerate in descending order of
preference the transport mechanisms and parameters acceptable to it, preference the transport mechanisms and parameters acceptable to it,
while the server can select the most appropriate. It is expected while the server can select the most appropriate. It is expected
that the session description format used will enable the client to that the session description format used will enable the client to
select a limited number of possible configurations that are offered select a limited number of possible configurations that are offered
to the server to choose from. All transport related parameters SHALL to the server to choose from. All transport related parameters SHALL
be included in the Transport header; the use of other headers for be included in the Transport header; the use of other headers for
this purpose is NOT RECOMMENDED due to middleboxes, such as firewalls this purpose is NOT RECOMMENDED due to middleboxes, such as firewalls
skipping to change at page 66, line 15 skipping to change at page 66, line 15
The client MUST include the Accept-Ranges header in the request The client MUST include the Accept-Ranges header in the request
indicating all supported unit formats in the Range header. This indicating all supported unit formats in the Range header. This
allows the server to know which formats it may use in future session allows the server to know which formats it may use in future session
related responses, such as a PLAY response without any range in the related responses, such as a PLAY response without any range in the
request. If the client does not support a time format necessary for request. If the client does not support a time format necessary for
the presentation the server MUST respond using 456 (Header Field Not the presentation the server MUST respond using 456 (Header Field Not
Valid for Resource) and include the Accept-Ranges header with the Valid for Resource) and include the Accept-Ranges header with the
range unit formats supported for the resource. range unit formats supported for the resource.
In a SETUP response the server MUST include the Accept-Ranges header In a SETUP response the server MUST include the Accept-Ranges header
(see Section 16.5) to indicate which time formats are acceptable to (see Section 18.5) to indicate which time formats are acceptable to
use for this media resource. use for this media resource.
The SETUP response 200 OK MUST include the Media-Properties header The SETUP response 200 OK MUST include the Media-Properties header
(see Section 16.28 ). The combination of the parameters of the (see Section 18.28 ). The combination of the parameters of the
Media-Properties header indicates the nature of the content present Media-Properties header indicates the nature of the content present
in the session (see also Section 4.9). For example, a live stream in the session (see also Section 4.9). For example, a live stream
with time shifting is indicated by with time shifting is indicated by
o Random Access set to Random-Access, o Random Access set to Random-Access,
o Content Modifications set to Time Progressing, o Content Modifications set to Time Progressing,
o Retention set to Time-Duration (with specific recording window o Retention set to Time-Duration (with specific recording window
time value). time value).
The SETUP response 200 OK MUST include the Media-Range header (see The SETUP response 200 OK MUST include the Media-Range header (see
Section 16.29) if the media is Time-Progressing. Section 18.29) if the media is Time-Progressing.
A basic example for SETUP: A basic example for SETUP:
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302 CSeq: 302
Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589", Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589",
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, UTC Accept-Ranges: NPT, UTC
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
skipping to change at page 67, line 41 skipping to change at page 67, line 41
AVP/UDP transport and adds the address and ports it will send and AVP/UDP transport and adds the address and ports it will send and
receive RTP and RTCP from, and the RTP SSRC that will be used by the receive RTP and RTCP from, and the RTP SSRC that will be used by the
server. server.
The server MUST generate a session identifier in response to a The server MUST generate a session identifier in response to a
successful SETUP request, unless a SETUP request to a server includes successful SETUP request, unless a SETUP request to a server includes
a session identifier or a Pipelined-Requests header referencing an a session identifier or a Pipelined-Requests header referencing an
existing session context, in which case the server MUST bundle this existing session context, in which case the server MUST bundle this
setup request into the existing session (aggregated session) or setup request into the existing session (aggregated session) or
return error 459 (Aggregate Operation Not Allowed) (see return error 459 (Aggregate Operation Not Allowed) (see
Section 15.4.24). An Aggregate control URI MUST be used to control Section 17.4.24). An Aggregate control URI MUST be used to control
an aggregated session. This URI MUST be different from the stream an aggregated session. This URI MUST be different from the stream
control URIs of the individual media streams included in the control URIs of the individual media streams included in the
aggregate (see Section 13.4.2 for aggregated sessions and for the aggregate (see Section 13.4.2 for aggregated sessions and for the
particular URIs see Appendix D.1.1). The Aggregate control URI is to particular URIs see Appendix D.1.1). The Aggregate control URI is to
be specified by the session description if the server supports be specified by the session description if the server supports
aggregated control and aggregated control is desired for the session. aggregated control and aggregated control is desired for the session.
However, even if aggregated control is offered the client MAY chose However, even if aggregated control is offered the client MAY chose
to not set up the session in aggregated control. If an Aggregate to not set up the session in aggregated control. If an Aggregate
control URI is not specified in the session description, it is control URI is not specified in the session description, it is
normally an indication that non-aggregated control should be used. normally an indication that non-aggregated control should be used.
skipping to change at page 68, line 21 skipping to change at page 68, line 21
route the request to the appropriate server, and for logging, route the request to the appropriate server, and for logging,
where it is useful to note the actual resource that a request was where it is useful to note the actual resource that a request was
operating on. operating on.
A session will exist until it is either removed by a TEARDOWN request A session will exist until it is either removed by a TEARDOWN request
or is timed-out by the server. The server MAY remove a session that or is timed-out by the server. The server MAY remove a session that
has not demonstrated liveness signs from the client(s) within a has not demonstrated liveness signs from the client(s) within a
certain timeout period. The default timeout value is 60 seconds; the certain timeout period. The default timeout value is 60 seconds; the
server MAY set this to a different value and indicate so in the server MAY set this to a different value and indicate so in the
timeout field of the Session header in the SETUP response. For timeout field of the Session header in the SETUP response. For
further discussion see Section 16.47. Signs of liveness for an RTSP further discussion see Section 18.47. Signs of liveness for an RTSP
session are: session are:
o Any RTSP request from a client which includes a Session header o Any RTSP request from a client which includes a Session header
with that session's ID. with that session's ID.
o If RTP is used as a transport for the underlying media streams, an o If RTP is used as a transport for the underlying media streams, an
RTCP sender or receiver report from the client(s) for any of the RTCP sender or receiver report from the client(s) for any of the
media streams in that RTSP session. RTCP Sender Reports may for media streams in that RTSP session. RTCP Sender Reports may for
example be received in sessions where the server is invited into a example be received in sessions where the server is invited into a
conference session and is valid for keep-alive. conference session and is valid for keep-alive.
skipping to change at page 70, line 17 skipping to change at page 70, line 17
retention, if the pause point represents a position that is older retention, if the pause point represents a position that is older
than what is retained by the server, the pause point will be moved to than what is retained by the server, the pause point will be moved to
the oldest retained. the oldest retained.
What range values are valid depends on the type of content. For What range values are valid depends on the type of content. For
content that isn't time progressing the range value is valid if the content that isn't time progressing the range value is valid if the
given range is part of any media within the aggregate. In other given range is part of any media within the aggregate. In other
words the valid media range for the aggregate is the union of all of words the valid media range for the aggregate is the union of all of
the media components in the aggregate. If a given range value points the media components in the aggregate. If a given range value points
outside of the media, the response MUST be the 457 (Invalid Range) outside of the media, the response MUST be the 457 (Invalid Range)
error code and include the Media-Range header (Section 16.29) with error code and include the Media-Range header (Section 18.29) with
the valid range for the media. Except for time progressing content the valid range for the media. Except for time progressing content
where the client requests a start point prior to what is retained, where the client requests a start point prior to what is retained,
the start point is adjusted to the oldest retained content. For a the start point is adjusted to the oldest retained content. For a
start point that is beyond the media front edge, i.e. beyond the start point that is beyond the media front edge, i.e. beyond the
current value for "now", the server SHALL adjust the start value to current value for "now", the server SHALL adjust the start value to
the current front edge. The Range header's stop point value may the current front edge. The Range header's stop point value may
point beyond the current media edge. In that case, the server SHALL point beyond the current media edge. In that case, the server SHALL
deliver media from the requested (and possibly adjusted) start point deliver media from the requested (and possibly adjusted) start point
until the provided stop point, or the end of the media is reached until the provided stop point, or the end of the media is reached
prior to the specified stop point. Please note that if one simply prior to the specified stop point. Please note that if one simply
wants to play from a particular start point until the end of media wants to play from a particular start point until the end of media
using a Range header with an implicit stop point is RECOMMENDED. using a Range header with an implicit stop point is RECOMMENDED.
If a client requests to start playing at the end of media, either If a client requests to start playing at the end of media, either
explicitly with a Range header or implicitly with a pause point that explicitly with a Range header or implicitly with a pause point that
is at the end of media, a 457 (Invalid Range) error MUST be sent and is at the end of media, a 457 (Invalid Range) error MUST be sent and
include the Media-Range header (Section 16.29). It is specified include the Media-Range header (Section 18.29). It is specified
below that the Range header also must be included in the response and below that the Range header also must be included in the response and
that it will carry the pause point in the media, in the case of the that it will carry the pause point in the media, in the case of the
session being in Ready State. Note that this also applies if the session being in Ready State. Note that this also applies if the
pause point or requested start point is at the beginning of the media pause point or requested start point is at the beginning of the media
and a Scale header (Section 16.44) is included with a negative value and a Scale header (Section 18.44) is included with a negative value
(playing backwards). (playing backwards).
For media with random access properties a client may express its For media with random access properties a client may express its
preference on which policy for start point selection the server shall preference on which policy for start point selection the server shall
use. This is done by including the Seek-Style header (Section 16.45) use. This is done by including the Seek-Style header (Section 18.45)
in the PLAY request. The Seek-Style applied will effect the content in the PLAY request. The Seek-Style applied will effect the content
of the Range header as it will be adjusted to indicate from what of the Range header as it will be adjusted to indicate from what
point the media actually is delivered. point the media actually is delivered.
A client desiring to play the media from the beginning MUST send a A client desiring to play the media from the beginning MUST send a
PLAY request with a Range header pointing at the beginning, e.g. PLAY request with a Range header pointing at the beginning, e.g.
npt=0-. If a PLAY request is received without a Range header and npt=0-. If a PLAY request is received without a Range header and
media delivery has stopped at the end, the server SHOULD respond with media delivery has stopped at the end, the server SHOULD respond with
a 457 "Invalid Range" error response. In that response, the current a 457 "Invalid Range" error response. In that response, the current
pause point MUST be included in a Range header. pause point MUST be included in a Range header.
skipping to change at page 71, line 51 skipping to change at page 71, line 51
real-time due to limited retention, the current pause point is real-time due to limited retention, the current pause point is
returned. For sessions in Play state, the current playout point and returned. For sessions in Play state, the current playout point and
the remaining parts of the range request is returned. For any media the remaining parts of the range request is returned. For any media
with retention longer than 0 seconds the currently valid Media-Range with retention longer than 0 seconds the currently valid Media-Range
header SHALL also be included in the response. header SHALL also be included in the response.
A PLAY response MAY include a header carrying synchronization A PLAY response MAY include a header carrying synchronization
information. As the information necessary is dependent on the media information. As the information necessary is dependent on the media
transport format, further rules specifying the header and its usage transport format, further rules specifying the header and its usage
are needed. For RTP the RTP-Info header is specified, see are needed. For RTP the RTP-Info header is specified, see
Section 16.43, and used in the following example. Section 18.43, and used in the following example.
Here is a simple example for a single audio stream where the client Here is a simple example for a single audio stream where the client
requests the media starting from 3.52 seconds and to the end. The requests the media starting from 3.52 seconds and to the end. The
server sends a 200 OK response with the actual play time which is 10 server sends a 200 OK response with the actual play time which is 10
ms prior (3.51) and the RTP-Info header that contains the necessary ms prior (3.51) and the RTP-Info header that contains the necessary
parameters for the RTP stack. parameters for the RTP stack.
C->S: PLAY rtsp://example.com/audio RTSP/2.0 C->S: PLAY rtsp://example.com/audio RTSP/2.0
CSeq: 836 CSeq: 836
Session: 12345678 Session: 12345678
skipping to change at page 76, line 48 skipping to change at page 76, line 48
ssrc=0D12F123:seq=5712;rtptime=934239921, ssrc=0D12F123:seq=5712;rtptime=934239921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792842193 ssrc=789DAF12:seq=57654;rtptime=2792842193
A common use of a PLAY request while in Play state is changing the A common use of a PLAY request while in Play state is changing the
scale of the media, i.e., entering or leaving from fast forward or scale of the media, i.e., entering or leaving from fast forward or
fast rewind. The client can issue an updating PLAY request that is fast rewind. The client can issue an updating PLAY request that is
either a continuation or a complete replacement, as discussed above either a continuation or a complete replacement, as discussed above
this section. We give an example of a client that is requesting a this section. We give an example of a client that is requesting a
fast forward (scale=2) without giving a stop point and then change fast forward (scale=2) without giving a stop point and then change
from fast forward to regular playout (scale = 1). from fast forward to regular playout (scale = 1). In the second PLAY
request the time is set explicitly to be where ever the server
currently plays out (npt=now-) and the server responds with the
actual playback point where the new scale actually takes effect
(npt=2:17:27.144-).
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2034 CSeq: 2034
Session: 12345678 Session: 12345678
Range: npt=now- Range: npt=now-
Scale: 2.0 Scale: 2.0
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 2034 CSeq: 2034
skipping to change at page 77, line 48 skipping to change at page 77, line 48
Range: npt=2:17:27.144- Range: npt=2:17:27.144-
Seek-Style: Next Seek-Style: Next
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934239921, ssrc=0D12F123:seq=5712;rtptime=934239921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792842193 ssrc=789DAF12:seq=57654;rtptime=2792842193
13.4.4. Playing On-Demand Media 13.4.4. Playing On-Demand Media
On-demand media is indicated by the content of the Media-Properties On-demand media is indicated by the content of the Media-Properties
header in the SETUP response by (see also Section 16.28): header in the SETUP response by (see also Section 18.28):
o Random-Access property is set to Random Access; o Random-Access property is set to Random Access;
o Content Modifications set to Immutable; o Content Modifications set to Immutable;
o Retention set to Unlimited or Time-Limited. o Retention set to Unlimited or Time-Limited.
Playing on-demand media follows the general usage as described in Playing on-demand media follows the general usage as described in
Section 13.4.1. Section 13.4.1.
13.4.5. Playing Dynamic On-Demand Media 13.4.5. Playing Dynamic On-Demand Media
Dynamic on-demand media is indicated by the content of the Media- Dynamic on-demand media is indicated by the content of the Media-
Properties header in the SETUP response by (see also Section 16.28): Properties header in the SETUP response by (see also Section 18.28):
o RandomAccess set to Random-Access; o RandomAccess set to Random-Access;
o Content Modifications set to Dynamic; o Content Modifications set to Dynamic;
o Retention set to Unlimited or Time-Limited. o Retention set to Unlimited or Time-Limited.
Playing on-demand media follows the general usage as described in Playing on-demand media follows the general usage as described in
Section 13.4.1 as long as the media has not been changed. Section 13.4.1 as long as the media has not been changed.
There are two ways for the client to be informed about changes of There are two ways for the client to be informed about changes of
media resources in Play state. The client will receive a PLAY_NOTIFY media resources in Play state. The client will receive a PLAY_NOTIFY
request with Notify-Reason header set to media-properties-update (see request with Notify-Reason header set to media-properties-update (see
Section 13.5.2. The client can use the value of the Media-Range to Section 13.5.2. The client can use the value of the Media-Range to
decide further actions, if the Media-Range header is present in the decide further actions, if the Media-Range header is present in the
PLAY_NOTIFY request. The second way is that the client issues a PLAY_NOTIFY request. The second way is that the client issues a
GET_PARAMETER request without a body but including a Media-Range GET_PARAMETER request without a body but including a Media-Range
header. The 200 OK response MUST include the current Media-Range header. The 200 OK response MUST include the current Media-Range
header (see Section 16.29). header (see Section 18.29).
13.4.6. Playing Live Media 13.4.6. Playing Live Media
Live media is indicated by the content of the Media-Properties header Live media is indicated by the content of the Media-Properties header
in the SETUP response by (see also Section 16.28): in the SETUP response by (see also Section 18.28):
o Random-Access set to No-Seeking; o Random-Access set to No-Seeking;
o Content Modifications set to Time-Progressing; o Content Modifications set to Time-Progressing;
o Retention with Time-Duration set to 0.0. o Retention with Time-Duration set to 0.0.
For live media, the SETUP response 200 OK MUST include the Media- For live media, the SETUP response 200 OK MUST include the Media-
Range header (see Section 16.29). Range header (see Section 18.29).
A client MAY send PLAY requests without the Range header. If the A client MAY send PLAY requests without the Range header. If the
request includes the Range header it MUST use a symbolic value request includes the Range header it MUST use a symbolic value
representing "now". For NPT that range specification is "npt=now-". representing "now". For NPT that range specification is "npt=now-".
The server MUST include the Range header in the response and it MUST The server MUST include the Range header in the response and it MUST
indicate an explicit time value and not a symbolic value. In other indicate an explicit time value and not a symbolic value. In other
words, "npt=now-" is not valid to be used in the response. Instead words, "npt=now-" is not valid to be used in the response. Instead
the time since session start is recommended expressed as an open the time since session start is recommended expressed as an open
interval, e.g. "npt=96.23-". An absolute time value (clock) for the interval, e.g. "npt=96.23-". An absolute time value (clock) for the
skipping to change at page 79, line 21 skipping to change at page 79, line 21
UTC clock format can only be used if client has shown support for it UTC clock format can only be used if client has shown support for it
using the Accept-Ranges header. using the Accept-Ranges header.
13.4.7. Playing Live with Recording 13.4.7. Playing Live with Recording
Certain media servers may offer recording services of live sessions Certain media servers may offer recording services of live sessions
to their clients. This recording would normally be from the to their clients. This recording would normally be from the
beginning of the media session. Clients can randomly access the beginning of the media session. Clients can randomly access the
media between now and the beginning of the media session. This live media between now and the beginning of the media session. This live
media with recording is indicated by the content of the Media- media with recording is indicated by the content of the Media-
Properties header in the SETUP response by (see also Section 16.28): Properties header in the SETUP response by (see also Section 18.28):
o Random-Access set to Random-Access; o Random-Access set to Random-Access;
o Content Modifications set to Time-Progressing; o Content Modifications set to Time-Progressing;
o Retention set to Time-limited or Unlimited o Retention set to Time-limited or Unlimited
The SETUP response 200 OK MUST include the Media-Range header (see The SETUP response 200 OK MUST include the Media-Range header (see
Section 16.29) for this type of media. For live media with Section 18.29) for this type of media. For live media with
recording, the Range header indicates the current delivery point in recording, the Range header indicates the current delivery point in
the media and the Media-Range header indicates the currently the media and the Media-Range header indicates the currently
available media window around the current time. This window can available media window around the current time. This window can
cover recorded content in the past (seen from current time in the cover recorded content in the past (seen from current time in the
media) or recorded content in the future (seen from current time in media) or recorded content in the future (seen from current time in
the media). The server adjusts the delivery point to the requested the media). The server adjusts the delivery point to the requested
border of the window, if the client requests a delivery point that is border of the window, if the client requests a delivery point that is
located outside the recording windows, e.g., if requested to far in located outside the recording windows, e.g., if requested to far in
the past, the server selects the oldest range in the recording. The the past, the server selects the oldest range in the recording. The
considerations in Section 13.5.3 apply, if a client requests delivery considerations in Section 13.5.3 apply, if a client requests delivery
with Scale (Section 16.44) values other than 1.0 (Normal playback with Scale (Section 18.44) values other than 1.0 (Normal playback
rate) while delivering live media with recording. rate) while delivering live media with recording.
13.4.8. Playing Live with Time-Shift 13.4.8. Playing Live with Time-Shift
Certain media servers may offer time-shift services to their clients. Certain media servers may offer time-shift services to their clients.
This time shift records a fixed interval in the past, i.e., a sliding This time shift records a fixed interval in the past, i.e., a sliding
window recording mechanism, but not past this interval. Clients can window recording mechanism, but not past this interval. Clients can
randomly access the media between now and the interval. This live randomly access the media between now and the interval. This live
media with recording is indicated by the content of the Media- media with recording is indicated by the content of the Media-
Properties header in the SETUP response by (see also Section 16.28): Properties header in the SETUP response by (see also Section 18.28):
o Random-Access set to Random-Access; o Random-Access set to Random-Access;
o Content Modifications set to Time-Progressing; o Content Modifications set to Time-Progressing;
o Retention set to Time-Duration and a value indicating the o Retention set to Time-Duration and a value indicating the
recording interval (>0). recording interval (>0).
The SETUP response 200 OK MUST include the Media-Range header (see The SETUP response 200 OK MUST include the Media-Range header (see
Section 16.29) for this type of media. For live media with recording Section 18.29) for this type of media. For live media with recording
the Range header indicates the current time in the media and the the Range header indicates the current time in the media and the
Media Range indicates a window around the current time. This window Media Range indicates a window around the current time. This window
can cover recorded content in the past (seen from current time in the can cover recorded content in the past (seen from current time in the
media) or recorded content in the future (seen from current time in media) or recorded content in the future (seen from current time in
the media). The server adjusts the play point to the requested the media). The server adjusts the play point to the requested
border of the window, if the client requests a play point that is border of the window, if the client requests a play point that is
located outside the recording windows, e.g., if requested too far in located outside the recording windows, e.g., if requested too far in
the past, the server selects the oldest range in the recording. The the past, the server selects the oldest range in the recording. The
considerations in Section 13.5.3 apply, if a client requests delivery considerations in Section 13.5.3 apply, if a client requests delivery
using a Scale (Section 16.44) value other than 1.0 (Normal playback using a Scale (Section 18.44) value other than 1.0 (Normal playback
rate) while delivering live media with time-shift. rate) while delivering live media with time-shift.
13.5. PLAY_NOTIFY 13.5. PLAY_NOTIFY
The PLAY_NOTIFY method is issued by a server to inform a client about The PLAY_NOTIFY method is issued by a server to inform a client about
an asynchronous event for a session in Play state. The Session an asynchronous event for a session in Play state. The Session
header MUST be presented in a PLAY_NOTIFY request and indicates the header MUST be presented in a PLAY_NOTIFY request and indicates the
scope of the request. Sending of PLAY_NOTIFY requests requires a scope of the request. Sending of PLAY_NOTIFY requests requires a
persistent connection between server and client, otherwise there is persistent connection between server and client, otherwise there is
no way for the server to send this request method to the client. no way for the server to send this request method to the client.
skipping to change at page 81, line 5 skipping to change at page 81, line 5
However, currently there is no Notify-Reason that allows using a However, currently there is no Notify-Reason that allows using a
message body. In this case, there is a need to obey some limitations message body. In this case, there is a need to obey some limitations
when adding new Notify-Reasons that intend to use a message body: the when adding new Notify-Reasons that intend to use a message body: the
server can send any type of message body, but it is not ensured that server can send any type of message body, but it is not ensured that
the client can understand the received message body. This is related the client can understand the received message body. This is related
to DESCRIBE (see Section 13.2 ), but in this particular case the to DESCRIBE (see Section 13.2 ), but in this particular case the
client can state its acceptable message bodies by using the Accept client can state its acceptable message bodies by using the Accept
header. In the case of PLAY_NOTIFY, the server does not know which header. In the case of PLAY_NOTIFY, the server does not know which
message bodies are understood by the client. message bodies are understood by the client.
The Notify-Reason header (see Section 16.31) specifies the reason why The Notify-Reason header (see Section 18.31) specifies the reason why
the server sends the PLAY_NOTIFY request. This is extensible and new the server sends the PLAY_NOTIFY request. This is extensible and new
reasons MAY be added in the future (see Section 22.8). In case the reasons MAY be added in the future (see Section 22.8). In case the
client does not understand the reason for the notification it MUST client does not understand the reason for the notification it MUST
respond with an 465 (Notification Reason Unknown) (Section 15.4.30) respond with an 465 (Notification Reason Unknown) (Section 17.4.30)
error code. Servers can send PLAY_NOTIFY with these types: error code. Servers can send PLAY_NOTIFY with these types:
o end-of-stream (see Section 13.5.1); o end-of-stream (see Section 13.5.1);
o media-properties-update (see Section 13.5.2); o media-properties-update (see Section 13.5.2);
o scale-change (see Section 13.5.3). o scale-change (see Section 13.5.3).
13.5.1. End-of-Stream 13.5.1. End-of-Stream
A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream
indicates the completion or near completion of the PLAY request and indicates the completion or near completion of the PLAY request and
the ending delivery of the media stream(s). The request MUST NOT be the ending delivery of the media stream(s). The request MUST NOT be
issued unless the server is in the Play state. The end of the media issued unless the server is in the Play state. The end of the media
stream delivery notification may be used to indicate either a stream delivery notification may be used to indicate either a
successful completion of the PLAY request currently being served, or successful completion of the PLAY request currently being served, or
to indicate some error resulting in failure to complete the request. to indicate some error resulting in failure to complete the request.
The Request-Status header (Section 16.40) MUST be included to The Request-Status header (Section 18.40) MUST be included to
indicate which request the notification is for and its completion indicate which request the notification is for and its completion
status. The message response status codes (Section 8.1.1) are used status. The message response status codes (Section 8.1.1) are used
to indicate how the PLAY request concluded. The sender of a to indicate how the PLAY request concluded. The sender of a
PLAY_NOTIFY can issue an updated PLAY_NOTIFY, in the case of a PLAY_NOTIFY can issue an updated PLAY_NOTIFY, in the case of a
PLAY_NOTIFY sent with wrong information. For instance, a PLAY_NOTIFY PLAY_NOTIFY sent with wrong information. For instance, a PLAY_NOTIFY
was issued before reaching the end-of-stream, but some error occurred was issued before reaching the end-of-stream, but some error occurred
resulting in that the previously sent PLAY_NOTIFY contained a wrong resulting in that the previously sent PLAY_NOTIFY contained a wrong
time when the stream will end. In this case a new PLAY_NOTIFY MUST time when the stream will end. In this case a new PLAY_NOTIFY MUST
be sent including the correct status for the completion and all be sent including the correct status for the completion and all
additional information. additional information.
skipping to change at page 82, line 35 skipping to change at page 82, line 34
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 854 CSeq: 854
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
13.5.2. Media-Properties-Update 13.5.2. Media-Properties-Update
A PLAY_NOTIFY request with Notify-Reason header set to media- A PLAY_NOTIFY request with Notify-Reason header set to media-
properties-update indicates an update of the media properties for the properties-update indicates an update of the media properties for the
given session (see Section 16.28) and/or the available media range given session (see Section 18.28) and/or the available media range
that can be played as indicated by Media-Range (Section 16.29). that can be played as indicated by Media-Range (Section 18.29).
PLAY_NOTIFY requests with Notify-Reason header set to media- PLAY_NOTIFY requests with Notify-Reason header set to media-
properties-update MUST include a Media-Properties and Date header and properties-update MUST include a Media-Properties and Date header and
SHOULD include a Media-Range header. SHOULD include a Media-Range header.
This notification MUST be sent for media that are time-progressing This notification MUST be sent for media that are time-progressing
every time an event happens that changes the basis for making every time an event happens that changes the basis for making
estimates on how the media range progress. In addition it is estimates on how the media range progress. In addition it is
RECOMMENDED that the server sends these notifications every 5 minutes RECOMMENDED that the server sends these notifications every 5 minutes
for time-progressing content to ensure the long-term stability of the for time-progressing content to ensure the long-term stability of the
client estimation and allowing for clock skew detection by the client estimation and allowing for clock skew detection by the
skipping to change at page 83, line 32 skipping to change at page 83, line 31
Range: npt=1:15:49.873- Range: npt=1:15:49.873-
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 854 CSeq: 854
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
13.5.3. Scale-Change 13.5.3. Scale-Change
The server may be forced to change the rate, when a client request The server may be forced to change the rate, when a client request
delivery using a Scale (Section 16.44) value other than 1.0 (normal delivery using a Scale (Section 18.44) value other than 1.0 (normal
playback rate). For time progressing media with some retention, i.e. playback rate). For time progressing media with some retention, i.e.
the server stores already sent content, a client requesting to play the server stores already sent content, a client requesting to play
with Scale values larger than 1 may catch up with the front end of with Scale values larger than 1 may catch up with the front end of
the media. The server will then be unable to continue to provide the media. The server will then be unable to continue to provide
content at Scale larger than 1 as content is only made available by content at Scale larger than 1 as content is only made available by
the server at Scale=1. Another case is when Scale < 1 and the media the server at Scale=1. Another case is when Scale < 1 and the media
retention is time-duration limited. In this case the delivery point retention is time-duration limited. In this case the delivery point
can reach the oldest media unit available, and further playback at can reach the oldest media unit available, and further playback at
this scale becomes impossible as there will be no media available. this scale becomes impossible as there will be no media available.
To avoid having the client lose any media, the scale will need to be To avoid having the client lose any media, the scale will need to be
skipping to change at page 88, line 24 skipping to change at page 88, line 24
CSeq: 892 CSeq: 892
Server: PhonyServer/1.0 Server: PhonyServer/1.0
13.7.2. Server to Client 13.7.2. Server to Client
The server can send TEARDOWN requests in the server to client The server can send TEARDOWN requests in the server to client
direction to indicate that the server has been forced to terminate direction to indicate that the server has been forced to terminate
the ongoing session. This may happen for several reasons, such as the ongoing session. This may happen for several reasons, such as
server maintenance without available backup, or that the session has server maintenance without available backup, or that the session has
been inactive for extended periods of time. The reason is provided been inactive for extended periods of time. The reason is provided
in the Terminate-Reason header (Section 16.50). in the Terminate-Reason header (Section 18.50).
When a RTSP client has maintained a RTSP session that otherwise is When a RTSP client has maintained a RTSP session that otherwise is
inactive for an extended period of time the server may reclaim the inactive for an extended period of time the server may reclaim the
resources. That is done by issuing a TEARDOWN request with the resources. That is done by issuing a TEARDOWN request with the
Terminate-Reason set to "Session-Timeout". This MAY be done when the Terminate-Reason set to "Session-Timeout". This MAY be done when the
client has been inactive in the RTSP session for more than one client has been inactive in the RTSP session for more than one
Session Timeout period (Section 16.47). However, the server is Session Timeout period (Section 18.47). However, the server is
RECOMMENDED to not perform this operation until an extended period of RECOMMENDED to not perform this operation until an extended period of
inactivity has passed. The time period is considered extended when inactivity has passed. The time period is considered extended when
it is 10 times the Session Timeout period. Consideration of the it is 10 times the Session Timeout period. Consideration of the
application of the server and its content should be performed when application of the server and its content should be performed when
configuring what is considered as extended period of time. configuring what is considered as extended period of time.
In case the server needs to stop providing service to the established In case the server needs to stop providing service to the established
sessions and there is no server to point at in a REDIRECT request, sessions and there is no server to point at in a REDIRECT request,
then TEARDOWN SHALL be used to terminate the session. This method then TEARDOWN SHALL be used to terminate the session. This method
can also be used when non-recoverable internal errors have happened can also be used when non-recoverable internal errors have happened
skipping to change at page 89, line 37 skipping to change at page 89, line 37
The GET_PARAMETER request retrieves the value of any specified The GET_PARAMETER request retrieves the value of any specified
parameter or parameters for a presentation or stream specified in the parameter or parameters for a presentation or stream specified in the
URI. If the Session header is present in a request, the value of a URI. If the Session header is present in a request, the value of a
parameter MUST be retrieved in the specified session context. There parameter MUST be retrieved in the specified session context. There
are two ways of specifying the parameters to be retrieved. The first are two ways of specifying the parameters to be retrieved. The first
is by including headers which have been defined such that you can use is by including headers which have been defined such that you can use
them for this purpose. Headers for this purpose should allow empty, them for this purpose. Headers for this purpose should allow empty,
or stripped value parts to avoid having to specify bogus data when or stripped value parts to avoid having to specify bogus data when
indicating the desire to retrieve a value. The successful completion indicating the desire to retrieve a value. The successful completion
of the request should also be evident from any filled out values in of the request should also be evident from any filled out values in
the response. The Media-Range header (Section 16.29) is one such the response. The Media-Range header (Section 18.29) is one such
header. The other way is to specify a message body that lists the header. The other way is to specify a message body that lists the
parameter(s) that are desired to be retrieved. The Content-Type parameter(s) that are desired to be retrieved. The Content-Type
header (Section 16.18) is used to specify which format the message header (Section 18.18) is used to specify which format the message
body has. body has.
The headers that MAY be used for retrieving their current value using The headers that MAY be used for retrieving their current value using
GET_PARAMETER are: GET_PARAMETER are:
o Accept-Ranges o Accept-Ranges
o Media-Range o Media-Range
o Media-Properties o Media-Properties
skipping to change at page 92, line 35 skipping to change at page 92, line 35
13.10. REDIRECT 13.10. REDIRECT
The REDIRECT method is issued by a server to inform a client that the The REDIRECT method is issued by a server to inform a client that the
service provided will be terminated and where a corresponding service service provided will be terminated and where a corresponding service
can be provided instead. This may happen for different reasons. One can be provided instead. This may happen for different reasons. One
is that the server is being administered such that it must stop is that the server is being administered such that it must stop
providing service. Thus the client is required to connect to another providing service. Thus the client is required to connect to another
server location to access the resource indicated by the Request-URI. server location to access the resource indicated by the Request-URI.
The REDIRECT request SHALL contain a Terminate-Reason header The REDIRECT request SHALL contain a Terminate-Reason header
(Section 16.50) to inform the client of the reason for the request. (Section 18.50) to inform the client of the reason for the request.
Additional parameters related to the reason may also be included. Additional parameters related to the reason may also be included.
The intention here is to allow a server administrator to do a The intention here is to allow a server administrator to do a
controlled shutdown of the RTSP server. That requires sufficient controlled shutdown of the RTSP server. That requires sufficient
time to inform all entities having associated state with the server time to inform all entities having associated state with the server
and for them to perform a controlled migration from this server to a and for them to perform a controlled migration from this server to a
fall back server. fall back server.
A REDIRECT request with a Session header has end-to-end (i.e. server A REDIRECT request with a Session header has end-to-end (i.e. server
to client) scope and applies only to the given session. Any to client) scope and applies only to the given session. Any
intervening proxies SHOULD NOT disconnect the control channel while intervening proxies SHOULD NOT disconnect the control channel while
skipping to change at page 95, line 33 skipping to change at page 95, line 33
protocol data unit, e.g., one RTP packet. protocol data unit, e.g., one RTP packet.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "$" = 36 | Channel ID | Length in bytes | | "$" = 36 | Channel ID | Length in bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Length number of bytes of binary data : : Length number of bytes of binary data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The channel identifier is defined in the Transport header with the The channel identifier is defined in the Transport header with the
interleaved parameter (Section 16.52). interleaved parameter (Section 18.52).
When the transport choice is RTP, RTCP messages are also interleaved When the transport choice is RTP, RTCP messages are also interleaved
by the server over the TCP connection. The usage of RTCP messages is by the server over the TCP connection. The usage of RTCP messages is
indicated by including an interval containing a second channel in the indicated by including an interval containing a second channel in the
interleaved parameter of the Transport header, see Section 16.52. If interleaved parameter of the Transport header, see Section 18.52. If
RTCP is used, packets MUST be sent on the first available channel RTCP is used, packets MUST be sent on the first available channel
higher than the RTP channel. The channels are bi-directional, using higher than the RTP channel. The channels are bi-directional, using
the same ChannelD in both directions, and therefore RTCP traffic are the same ChannelD in both directions, and therefore RTCP traffic are
sent on the second channel in both directions. sent on the second channel in both directions.
RTCP is sometimes needed for synchronization when two or more RTCP is sometimes needed for synchronization when two or more
streams are interleaved in such a fashion. Also, this provides a streams are interleaved in such a fashion. Also, this provides a
convenient way to tunnel RTP/RTCP packets through the TCP control convenient way to tunnel RTP/RTCP packets through the TCP control
connection when required by the network configuration and transfer connection when required by the network configuration and transfer
them onto UDP when possible. them onto UDP when possible.
skipping to change at page 97, line 5 skipping to change at page 97, line 5
Date: Thu, 05 Jun 1997 18:57:19 GMT Date: Thu, 05 Jun 1997 18:57:19 GMT
RTP-Info: url="rtsp://example.com/bar.file" RTP-Info: url="rtsp://example.com/bar.file"
ssrc=0D12F123:seq=232433;rtptime=972948234 ssrc=0D12F123:seq=232433;rtptime=972948234
Range: npt=0-56.8 Range: npt=0-56.8
Seek-Style: RAP Seek-Style: RAP
S->C: $005{2 byte length}{"length" bytes data, w/RTP header} S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
S->C: $005{2 byte length}{"length" bytes data, w/RTP header} S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
S->C: $006{2 byte length}{"length" bytes RTCP packet} S->C: $006{2 byte length}{"length" bytes RTCP packet}
15. Status Code Definitions 15. Proxies
RTSP Proxies are RTSP agents that are located in between a client and
a server. A proxy can take on both the role as a client and as
server depending on what it tries to accomplish. Proxies are also
introduced for several different reasons and the below listed are
often combined.
In general there are two categories of RTSP proxies, transparent (of
which the client is not aware) and the non-transparent proxies (of
which the client is aware). Transparent proxies are not visible to
the client in terms of that the transport layer connection, e.g., TCP
for RTSP, as there is only a single transport connection which is
terminated at the RTSP client and the RTSP server. In the case of
non-transparent proxies, there are two transport layer connections,
one from the RTSP client to the RTSP proxy and a second from the RTSP
proxy to the RTSP server.
There are these types of RTSP proxies:
Caching Proxy: This type of proxy is used to reduce the workload on
servers and connections. By caching the description and media
streams, i.e., the presentation, the proxy can serve a client
with content, but without requesting it from the server once it
has been cached and has not become stale. See the caching
Section 16. This type of proxy is also expected to understand
RTSP end-point functionality, i.e., functionality identified in
the Require header in addition to what Proxy-Require demands.
Translator Proxy: This type of proxy is used to ensure that an RTSP
client gets access to servers and content on an external
network or using content encodings not supported by the client.
The proxy performs the necessary translation of addresses,
protocols or encodings. This type of proxy is expected to also
understand RTSP end-point functionality, i.e. functionality
identified in the Require header in addition to what Proxy-
Require demands.
Access Proxy: This type of proxy is used to ensure that an RTSP
clients get access to servers on an external network. Thus
this proxy is placed on the border between two domains, e.g. a
private address space and the public Internet. The proxy
performs the necessary translation, usually addresses. This
type of proxy is required to redirect the media to itself or a
controlled gateway that performs the translation before the
media can reach the client.
Security Proxy: This type of proxy is used to help facilitate
security functions around RTSP. For example when having a
firewalled network, the security proxy request that the
necessary pinholes in the firewall are opened when a client in
the protected network wants to access media streams on the
external side. This proxy can also limit the clients access to
certain types of content. This proxy can perform its function
without redirecting the media between the server and client.
However, in deployments with private address spaces this proxy
is likely to be combined with the access proxy. Anyway, the
functionality of this proxy is usually closely tied into
understanding all aspects of the media transport.
Auditing Proxy: RTSP proxies can also provide network owners with a
logging and audit point for RTSP sessions, e.g. for
corporations that track their employees usage of the network.
This type of proxy can perform its function without inserting
itself or any other node in the media transport. This proxy
type can also accept unknown methods as it doesn't interfere
with the clients' requests.
All types of proxies can be used also when using secured
communication with TLS as RTSP 2.0 allows the client to approve
certificate chains used for connection establishment from a proxy,
see Section 19.3.2. However, that trust model may not be suitable
for all types of deployment. In those cases, the secured sessions do
by-pass of the proxies.
Access proxies SHOULD NOT be used in equipment like NATs and
firewalls that aren't expected to be regularly maintained, like home
or small office equipment. In these cases it is better to use the
NAT traversal procedures defined for RTSP 2.0
[I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is
that any extensions of RTSP resulting in new media transport
protocols or profiles, new parameters, etc. may fail in a proxy that
isn't maintained. This would impede RTSP's future development and
usage.
15.1. Proxies and Protocol Extensions
The existence of proxies must always be considered when developing
new RTSP extensions. Most types of proxies will need to implement
any new method to operate correctly in the presence of that
extension. New headers can be introduced and will not be blocked by
older proxies. However, it is important to consider if this header
and its function is required to be understood by the proxy or can be
forwarded. If the header needs to be understood, a feature-tag
representing the functionality MUST be included in the Proxy-Require
header. Below are guidelines for analysis if the header needs to be
understood. The transport header and its parameters also shows that
headers that are extensible and require correct interpretation in the
proxy also require handling rules.
Whether a proxy needs to understand a header is not easy to
determine, as they serve a broad variety of functions. When
evaluating if a header needs to be understood, one can divide the
functionality into three main categories:
Media modifying: The caching and translator proxies are modifying
the actual media and therefore needs to understand also request
directed to the server that affects how the media is rendered.
Thus, this type of proxy needs to also understand the server side
functionality.
Transport modifying: The access and the security proxy both need to
understand how the transport is performed, either for opening
pinholes or to translate the outer headers, e.g. IP and UDP.
Non-modifying: The audit proxy is special in that it does not modify
the messages in other ways than to insert the Via header. That
makes it possible for this type to forward RTSP messages that
contain different types of unknown methods, headers or header
parameters.
Based on the above classification, one should evaluate if the new
functionality requires the Transport modifying type of proxies to
understand it or not.
15.2. Multiplexing and Demultiplexing of Messages
RTSP proxies may have to multiplex multiple RTSP sessions from their
clients towards RTSP servers. This requires that RTSP requests from
multiple clients are multiplexed onto a common connection for
requests outgoing to an RTSP server and on the way back the responses
are demultiplexed from the server to per client responses. On the
protocol level this requires that request and response messages are
handled in both ways, requiring that there is a mechanism to
correlate what request/response pair exchanged between proxy and
server is mapped to what client (or client request).
This multiplexing of requests and demultiplexing of responses is done
by using the CSeq header field (see Section 18.19). The proxy has to
rewrite the CSeq in requests to the server and responses from the
server and remember what CSeq is mapped to what client.
16. Caching
In HTTP, request-response pairs are cached. RTSP differs
significantly in that respect. Responses are not cacheable, with the
exception of the presentation description returned by DESCRIBE.
(Since the responses for anything but DESCRIBE and GET_PARAMETER do
not return any data, caching is not really an issue for these
requests.) However, it is desirable for the continuous media data,
typically delivered out-of-band with respect to RTSP, to be cached,
as well as the session description.
On receiving a SETUP or PLAY request, a proxy ascertains whether it
has an up-to-date copy of the continuous media content and its
description. It can determine whether the copy is up-to-date by
issuing a SETUP or DESCRIBE request, respectively, and comparing the
Last-Modified header with that of the cached copy. If the copy is
not up-to-date, it modifies the SETUP transport parameters as
appropriate and forwards the request to the origin server.
Subsequent control commands such as PLAY or PAUSE then pass the proxy
unmodified. The proxy delivers the continuous media data to the
client, while possibly making a local copy for later reuse. The
exact allowed behavior of the cache is given by the cache-response
directives described in Section 18.10. A cache MUST answer any
DESCRIBE requests if it is currently serving the stream to the
requester, as it is possible that low-level details of the stream
description may have changed on the origin-server.
Note that an RTSP cache, is of the "cut-through" variety. Rather
than retrieving the whole resource from the origin server, the cache
simply copies the streaming data as it passes by on its way to the
client. Thus, it does not introduce additional latency.
To the client, an RTSP proxy cache appears like a regular media
server, to the media origin server like a client. Just as an HTTP
cache has to store the content type, content language, and so on for
the objects it caches, a media cache has to store the presentation
description. Typically, a cache eliminates all transport-references
(e.g., multicast information) from the presentation description,
since these are independent of the data delivery from the cache to
the client. Information on the encodings remains the same. If the
cache is able to translate the cached media data, it would create a
new presentation description with all the encoding possibilities it
can offer.
16.1. Validation Model
When a cache has a stale entry that it would like to use as a
response to a client's request, it first has to check with the origin
server (or possibly an intermediate cache with a fresh response) to
see if its cached entry is still usable. We call this "validating"
the cache entry. Since we do not want to have to pay the overhead of
retransmitting the full response if the cached entry is good, and we
do not want to pay the overhead of an extra round trip if the cached
entry is invalid, the RTSP protocol supports the use of conditional
methods.
The key protocol features for supporting conditional methods are
those concerned with "cache validators." When an origin server
generates a full response, it attaches some sort of validator to it,
which is kept with the cache entry. When a client (user agent or
proxy cache) makes a conditional request for a resource for which it
has a cache entry, it includes the associated validator in the
request.
The server then checks that validator against the current validator
for the requested resource, and, if they match (see Section 16.1.3),
it responds with a special status code (usually, 304 (Not Modified))
and no message body. Otherwise, it returns a full response
(including message body). Thus, we avoid transmitting the full
response if the validator matches, and we avoid an extra round trip
if it does not match.
In RTSP, a conditional request looks exactly the same as a normal
request for the same resource, except that it carries a special
header (which includes the validator) that implicitly turns the
method (usually DESCRIBE or SETUP) into a conditional.
The protocol includes both positive and negative senses of cache-
validating conditions. That is, it is possible to request either
that a method be performed if and only if a validator matches or if
and only if no validators match.
Note: a response that lacks a validator may still be cached, and
served from cache until it expires, unless this is explicitly
prohibited by a cache-control directive (see Section 18.10).
However, a cache cannot do a conditional retrieval if it does not
have a validator for the resource, which means it will not be
refreshable after it expires.
Media streams that are being adapted based on the transport capacity
between the server and the cache makes caching more difficult. A
server needs to consider how it views caching of media streams that
it adapts and potentially instruct any caches to not cache such
streams.
16.1.1. Last-Modified Dates
The Last-Modified header (Section 18.26) value is often used as a
cache validator. In simple terms, a cache entry is considered to be
valid if the content has not been modified since the Last-Modified
value.
16.1.2. Message Body Tag Cache Validators
The MTag response-header field value, a message body tag, provides
for an "opaque" cache validator. This might allow more reliable
validation in situations where it is inconvenient to store
modification dates, where the one-second resolution of RTSP-date
values is not sufficient, or where the origin server wishes to avoid
certain paradoxes that might arise from the use of modification
dates.
Message body tags are described in Section 4.8
16.1.3. Weak and Strong Validators
Since both origin servers and caches will compare two validators to
decide if they represent the same or different entities, one normally
would expect that if the message body (i.e., the presentation
description) or any associated message body headers changes in any
way, then the associated validator would change as well. If this is
true, then we call this validator a "strong validator." We call
message body (i.e., the presentation description) or any associated
message body headers an entity for a better understanding.
However, there might be cases when a server prefers to change the
validator only on semantically significant changes, and not when
insignificant aspects of the entity change. A validator that does
not always change when the resource changes is a "weak validator."
Message body tags are normally "strong validators," but the protocol
provides a mechanism to tag a message body tag as "weak." One can
think of a strong validator as one that changes whenever the bits of
an entity changes, while a weak value changes whenever the meaning of
an entity changes. Alternatively, one can think of a strong
validator as part of an identifier for a specific entity, while a
weak validator is part of an identifier for a set of semantically
equivalent entities.
Note: One example of a strong validator is an integer that is
incremented in stable storage every time an entity is changed.
An entity's modification time, if represented with one-second
resolution, could be a weak validator, since it is possible that
the resource might be modified twice during a single second.
Support for weak validators is optional. However, weak validators
allow for more efficient caching of equivalent objects.
A "use" of a validator is either when a client generates a request
and includes the validator in a validating header field, or when a
server compares two validators.
Strong validators are usable in any context. Weak validators are
only usable in contexts that do not depend on exact equality of an
entity. For example, either kind is usable for a conditional
DESCRIBE of a full entity. However, only a strong validator is
usable for a sub-range retrieval, since otherwise the client might
end up with an internally inconsistent entity.
Clients MAY issue DESCRIBE requests with either weak validators or
strong validators. Clients MUST NOT use weak validators in other
forms of requests.
The only function that the RTSP protocol defines on validators is
comparison. There are two validator comparison functions, depending
on whether the comparison context allows the use of weak validators
or not:
o The strong comparison function: in order to be considered equal,
both validators MUST be identical in every way, and both MUST NOT
be weak.
o The weak comparison function: in order to be considered equal,
both validators MUST be identical in every way, but either or both
of them MAY be tagged as "weak" without affecting the result.
A message body tag is strong unless it is explicitly tagged as weak.
A Last-Modified time, when used as a validator in a request, is
implicitly weak unless it is possible to deduce that it is strong,
using the following rules:
o The validator is being compared by an origin server to the actual
current validator for the entity and,
o That origin server reliably knows that the associated entity did
not change more than once during the second covered by the
presented validator.
OR
o The validator is about to be used by a client in an If-Modified-
Since, because the client has a cache entry for the associated
entity, and
o That cache entry includes a Date value, which gives the time when
the origin server sent the original response, and
o The presented Last-Modified time is at least 60 seconds before the
Date value.
OR
o The validator is being compared by an intermediate cache to the
validator stored in its cache entry for the entity, and
o That cache entry includes a Date value, which gives the time when
the origin server sent the original response, and
o The presented Last-Modified time is at least 60 seconds before the
Date value.
This method relies on the fact that if two different responses were
sent by the origin server during the same second, but both had the
same Last-Modified time, then at least one of those responses would
have a Date value equal to its Last-Modified time. The arbitrary 60-
second limit guards against the possibility that the Date and Last-
Modified values are generated from different clocks, or at somewhat
different times during the preparation of the response. An
implementation MAY use a value larger than 60 seconds, if it is
believed that 60 seconds is too short.
If a client wishes to perform a sub-range retrieval on a value for
which it has only a Last-Modified time and no opaque validator, it
MAY do this only if the Last-Modified time is strong in the sense
described here.
16.1.4. Rules for When to Use Message Body Tags and Last-Modified Dates
We adopt a set of rules and recommendations for origin servers,
clients, and caches regarding when various validator types ought to
be used, and for what purposes.
RTSP origin servers:
o SHOULD send a message body tag validator unless it is not feasible
to generate one.
o MAY send a weak message body tag instead of a strong message body
tag, if performance considerations support the use of weak message
body tags, or if it is unfeasible to send a strong message body
tag.
o SHOULD send a Last-Modified value if it is feasible to send one,
unless the risk of a breakdown in semantic transparency that could
result from using this date in an If-Modified-Since header would
lead to serious problems.
In other words, the preferred behavior for an RTSP origin server is
to send both a strong message body tag and a Last-Modified value.
In order to be legal, a strong message body tag MUST change whenever
the associated entity value changes in any way. A weak message body
tag SHOULD change whenever the associated entity changes in a
semantically significant way.
Note: in order to provide semantically transparent caching, an
origin server MUST avoid reusing a specific strong message body
tag value for two different entities, or reusing a specific weak
message body tag value for two semantically different entities.
Cache entries might persist for arbitrarily long periods,
regardless of expiration times, so it might be inappropriate to
expect that a cache will never again attempt to validate an entry
using a validator that it obtained at some point in the past.
RTSP clients:
o If a message body tag has been provided by the origin server, MUST
use that message body tag in any cache-conditional request (using
If-Match or If-None-Match).
o If only a Last-Modified value has been provided by the origin
server, SHOULD use that value in non-subrange cache-conditional
requests (using If-Modified-Since).
o If both a message body tag and a Last-Modified value have been
provided by the origin server, SHOULD use both validators in
cache-conditional requests.
An RTSP origin server, upon receiving a conditional request that
includes both a Last-Modified date (e.g., in an If-Modified-Since
header) and one or more message body tags (e.g., in an If-Match, If-
None-Match, or If-Range header field) as cache validators, MUST NOT
return a response status of 304 (Not Modified) unless doing so is
consistent with all of the conditional header fields in the request.
Note: The general principle behind these rules is that RTSP
servers and clients should transmit as much non-redundant
information as is available in their responses and requests. RTSP
systems receiving this information will make the most conservative
assumptions about the validators they receive.
16.1.5. Non-validating Conditionals
The principle behind message body tags is that only the service
author knows the semantics of a resource well enough to select an
appropriate cache validation mechanism, and the specification of any
validator comparison function more complex than byte-equality would
open up a can of worms. Thus, comparisons of any other headers are
never used for purposes of validating a cache entry.
16.2. Invalidation After Updates or Deletions
The effect of certain methods performed on a resource at the origin
server might cause one or more existing cache entries to become non-
transparently invalid. That is, although they might continue to be
"fresh," they do not accurately reflect what the origin server would
return for a new request on that resource.
There is no way for the RTSP protocol to guarantee that all such
cache entries are marked invalid. For example, the request that
caused the change at the origin server might not have gone through
the proxy where a cache entry is stored. However, several rules help
reduce the likelihood of erroneous behavior.
In this section, the phrase "invalidate an entity" means that the
cache will either remove all instances of that entity from its
storage, or will mark these as "invalid" and in need of a mandatory
revalidation before they can be returned in response to a subsequent
request.
Some RTSP methods MUST cause a cache to invalidate an entity. This
is either the entity referred to by the Request-URI, or by the
Location or Content-Location headers (if present). These methods
are:
o DESCRIBE
o SETUP
In order to prevent denial of service attacks, an invalidation based
on the URI in a Location or Content-Location header MUST only be
performed if the host part is the same as in the Request-URI.
A cache that passes through requests for methods it does not
understand SHOULD invalidate any entities referred to by the Request-
URI.
17. Status Code Definitions
Where applicable, HTTP status [H10] codes are reused. Status codes Where applicable, HTTP status [H10] codes are reused. Status codes
that have the same meaning are not repeated here. See Table 4 in that have the same meaning are not repeated here. See Table 4 in
Section 8.1 for a listing of which status codes may be returned by Section 8.1 for a listing of which status codes may be returned by
which requests. All error messages, 4xx and 5xx MAY return a body which requests. All error messages, 4xx and 5xx MAY return a body
containing further information about the error. containing further information about the error.
15.1. Success 1xx 17.1. Success 1xx
15.1.1. 100 Continue 17.1.1. 100 Continue
The client SHOULD continue with its request. This interim response The client SHOULD continue with its request. This interim response
is used to inform the client that the initial part of the request has is used to inform the client that the initial part of the request has
been received and has not yet been rejected by the server. The been received and has not yet been rejected by the server. The
client SHOULD continue by sending the remainder of the request or, if client SHOULD continue by sending the remainder of the request or, if
the request has already been completed, ignore this response. The the request has already been completed, ignore this response. The
server MUST send a final response after the request has been server MUST send a final response after the request has been
completed. completed.
15.2. Success 2xx 17.2. Success 2xx
This class of status code indicates that the client's request was This class of status code indicates that the client's request was
successfully received, understood, and accepted. successfully received, understood, and accepted.
15.2.1. 200 OK 17.2.1. 200 OK
The request has succeeded. The information returned with the The request has succeeded. The information returned with the
response is dependent on the method used in the request. response is dependent on the method used in the request.
15.3. Redirection 3xx 17.3. Redirection 3xx
The notation "3rr" indicates response codes from 300 to 399 inclusive The notation "3rr" indicates response codes from 300 to 399 inclusive
which are meant for redirection. The response code 304 is excluded which are meant for redirection. The response code 304 is excluded
from this set, as it is not used for redirection. from this set, as it is not used for redirection.
Within RTSP, redirection may be used for load balancing or Within RTSP, redirection may be used for load balancing or
redirecting stream requests to a server topologically closer to the redirecting stream requests to a server topologically closer to the
client. Mechanisms to determine topological proximity are beyond the client. Mechanisms to determine topological proximity are beyond the
scope of this specification. scope of this specification.
skipping to change at page 98, line 12 skipping to change at page 109, line 12
with an established session about the need for redirecting the with an established session about the need for redirecting the
session. If a 3rr response is received for a request in relation to session. If a 3rr response is received for a request in relation to
an established session, the client SHOULD send a TEARDOWN request for an established session, the client SHOULD send a TEARDOWN request for
the session, and MAY reestablish the session using the resource the session, and MAY reestablish the session using the resource
indicated by the Location. indicated by the Location.
If the Location header is used in a response it MUST contain an If the Location header is used in a response it MUST contain an
absolute URI pointing out the media resource the client is redirected absolute URI pointing out the media resource the client is redirected
to, the URI MUST NOT only contain the host name. to, the URI MUST NOT only contain the host name.
15.3.1. 301 Moved Permanently 17.3.1. 301 Moved Permanently
The requested resource is moved permanently and resides now at the The requested resource is moved permanently and resides now at the
URI given by the location header. The user client SHOULD redirect URI given by the location header. The user client SHOULD redirect
automatically to the given URI. This response MUST NOT contain a automatically to the given URI. This response MUST NOT contain a
message-body. The Location header MUST be included in the response. message-body. The Location header MUST be included in the response.
15.3.2. 302 Found 17.3.2. 302 Found
The requested resource resides temporarily at the URI given by the The requested resource resides temporarily at the URI given by the
Location header. The Location header MUST be included in the Location header. The Location header MUST be included in the
response. This response is intended to be used for many types of response. This response is intended to be used for many types of
temporary redirects; e.g., load balancing. It is RECOMMENDED that temporary redirects; e.g., load balancing. It is RECOMMENDED that
the server set the reason phrase to something more meaningful than the server set the reason phrase to something more meaningful than
"Found" in these cases. The user client SHOULD redirect "Found" in these cases. The user client SHOULD redirect
automatically to the given URI. This response MUST NOT contain a automatically to the given URI. This response MUST NOT contain a
message-body. message-body.
skipping to change at page 98, line 42 skipping to change at page 109, line 42
C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0 C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2 CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1 Transport: RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 302 Try Other Server S->C: RTSP/2.0 302 Try Other Server
CSeq: 2 CSeq: 2
Location: rtsp://s2.example.com:8001/fizzle/foo Location: rtsp://s2.example.com:8001/fizzle/foo
15.3.3. 303 See Other 17.3.3. 303 See Other
This status code MUST NOT be used in RTSP 2.0. However, it was This status code MUST NOT be used in RTSP 2.0. However, it was
allowed to use in RTSP 1.0 (RFC 2326). allowed to use in RTSP 1.0 (RFC 2326).
15.3.4. 304 Not Modified 17.3.4. 304 Not Modified
If the client has performed a conditional DESCRIBE or SETUP (see If the client has performed a conditional DESCRIBE or SETUP (see
Section 16.24) and the requested resource has not been modified, the Section 18.24) and the requested resource has not been modified, the
server SHOULD send a 304 response. This response MUST NOT contain a server SHOULD send a 304 response. This response MUST NOT contain a
message-body. message-body.
The response MUST include the following header fields: The response MUST include the following header fields:
o Date o Date
o MTag and/or Content-Location, if the header(s) would have been o MTag and/or Content-Location, if the header(s) would have been
sent in a 200 response to the same request. sent in a 200 response to the same request.
o Expires, Cache-Control, and/or Vary, if the field-value might o Expires and Cache-Control if the field-value might differ from
differ from that sent in any previous response for the same that sent in any previous response for the same variant.
variant.
This response is independent for the DESCRIBE and SETUP requests. This response is independent for the DESCRIBE and SETUP requests.
That is, a 304 response to DESCRIBE does NOT imply that the resource That is, a 304 response to DESCRIBE does NOT imply that the resource
content is unchanged (only the session description) and a 304 content is unchanged (only the session description) and a 304
response to SETUP does NOT imply that the resource description is response to SETUP does NOT imply that the resource description is
unchanged. The MTag and If-Match headers may be used to link the unchanged. The MTag and If-Match headers may be used to link the
DESCRIBE and SETUP in this manner. DESCRIBE and SETUP in this manner.
15.3.5. 305 Use Proxy 17.3.5. 305 Use Proxy
The requested resource MUST be accessed through the proxy given by The requested resource MUST be accessed through the proxy given by
the Location field. The Location field gives the URI of the proxy. the Location field. The Location field gives the URI of the proxy.
The recipient is expected to repeat this single request via the The recipient is expected to repeat this single request via the
proxy. 305 responses MUST only be generated by origin servers. proxy. 305 responses MUST only be generated by origin servers.
15.4. Client Error 4xx 17.4. Client Error 4xx
15.4.1. 400 Bad Request 17.4.1. 400 Bad Request
The request could not be understood by the server due to malformed The request could not be understood by the server due to malformed
syntax. The client SHOULD NOT repeat the request without syntax. The client SHOULD NOT repeat the request without
modifications. If the request does not have a CSeq header, the modifications. If the request does not have a CSeq header, the
server MUST NOT include a CSeq in the response. server MUST NOT include a CSeq in the response.
15.4.2. 401 Unauthorized 17.4.2. 401 Unauthorized
The request requires user authentication. The response MUST include The request requires user authentication. The response MUST include
a WWW-Authenticate header (Section 16.57) field containing a a WWW-Authenticate header (Section 18.56) field containing a
challenge applicable to the requested resource. The client MAY challenge applicable to the requested resource. The client MAY
repeat the request with a suitable Authorization header field. If repeat the request with a suitable Authorization header field. If
the request already included Authorization credentials, then the 401 the request already included Authorization credentials, then the 401
response indicates that authorization has been refused for those response indicates that authorization has been refused for those
credentials. If the 401 response contains the same challenge as the credentials. If the 401 response contains the same challenge as the
prior response, and the user agent has already attempted prior response, and the user agent has already attempted
authentication at least once, then the user SHOULD be presented the authentication at least once, then the user SHOULD be presented the
message body that was given in the response, since that message body message body that was given in the response, since that message body
might include relevant diagnostic information. HTTP access might include relevant diagnostic information. HTTP access
authentication is explained in [RFC2617]. authentication is explained in [RFC2617].
15.4.3. 402 Payment Required 17.4.3. 402 Payment Required
This code is reserved for future use. This code is reserved for future use.
15.4.4. 403 Forbidden 17.4.4. 403 Forbidden
The server understood the request, but is refusing to fulfill it. The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated. Authorization will not help and the request SHOULD NOT be repeated.
If the server wishes to make public why the request has not been If the server wishes to make public why the request has not been
fulfilled, it SHOULD describe the reason for the refusal in the fulfilled, it SHOULD describe the reason for the refusal in the
message body. If the server does not wish to make this information message body. If the server does not wish to make this information
available to the client, the status code 404 (Not Found) can be used available to the client, the status code 404 (Not Found) can be used
instead. instead.
15.4.5. 404 Not Found 17.4.5. 404 Not Found
The server has not found anything matching the Request-URI. No The server has not found anything matching the Request-URI. No
indication is given of whether the condition is temporary or indication is given of whether the condition is temporary or
permanent. The 410 (Gone) status code SHOULD be used if the server permanent. The 410 (Gone) status code SHOULD be used if the server
knows, through some internally configurable mechanism, that an old knows, through some internally configurable mechanism, that an old
resource is permanently unavailable and has no forwarding address. resource is permanently unavailable and has no forwarding address.
This status code is commonly used when the server does not wish to This status code is commonly used when the server does not wish to
reveal exactly why the request has been refused, or when no other reveal exactly why the request has been refused, or when no other
response is applicable. response is applicable.
15.4.6. 405 Method Not Allowed 17.4.6. 405 Method Not Allowed
The method specified in the request is not allowed for the resource The method specified in the request is not allowed for the resource
identified by the Request-URI. The response MUST include an Allow identified by the Request-URI. The response MUST include an Allow
header containing a list of valid methods for the requested resource. header containing a list of valid methods for the requested resource.
This status code is also to be used if a request attempts to use a This status code is also to be used if a request attempts to use a
method not indicated during SETUP. method not indicated during SETUP.
15.4.7. 406 Not Acceptable 17.4.7. 406 Not Acceptable
The resource identified by the request is only capable of generating The resource identified by the request is only capable of generating
response message bodies which have content characteristics not response message bodies which have content characteristics not
acceptable according to the Accept headers sent in the request. acceptable according to the Accept headers sent in the request.
The response SHOULD include a message body containing a list of The response SHOULD include a message body containing a list of
available message body characteristics and location(s) from which the available message body characteristics and location(s) from which the
user or user agent can choose the one most appropriate. The message user or user agent can choose the one most appropriate. The message
body format is specified by the media type given in the Content-Type body format is specified by the media type given in the Content-Type
header field. Depending upon the format and the capabilities of the header field. Depending upon the format and the capabilities of the
user agent, selection of the most appropriate choice MAY be performed user agent, selection of the most appropriate choice MAY be performed
automatically. However, this specification does not define any automatically. However, this specification does not define any
standard for such automatic selection. standard for such automatic selection.
If the response could be unacceptable, a user agent SHOULD If the response could be unacceptable, a user agent SHOULD
temporarily stop receipt of more data and query the user for a temporarily stop receipt of more data and query the user for a
decision on further actions. decision on further actions.
15.4.8. 407 Proxy Authentication Required 17.4.8. 407 Proxy Authentication Required
This code is similar to 401 (Unauthorized) (Section 15.4.2), but This code is similar to 401 (Unauthorized) (Section 17.4.2), but
indicates that the client must first authenticate itself with the indicates that the client must first authenticate itself with the
proxy. The proxy MUST return a Proxy-Authenticate header field proxy. The proxy MUST return a Proxy-Authenticate header field
(Section 16.33) containing a challenge applicable to the proxy for (Section 18.33) containing a challenge applicable to the proxy for
the requested resource. the requested resource.
15.4.9. 408 Request Timeout 17.4.9. 408 Request Timeout
The client did not produce a request within the time that the server The client did not produce a request within the time that the server
was prepared to wait. The client MAY repeat the request without was prepared to wait. The client MAY repeat the request without
modifications at any later time. modifications at any later time.
15.4.10. 410 Gone 17.4.10. 410 Gone
The requested resource is no longer available at the server and the The requested resource is no longer available at the server and the
forwarding address is not known. This condition is expected to be forwarding address is not known. This condition is expected to be
considered permanent. If the server does not know, or has no considered permanent. If the server does not know, or has no
facility to determine, whether or not the condition is permanent, the facility to determine, whether or not the condition is permanent, the
status code 404 (Not Found) SHOULD be used instead. This response is status code 404 (Not Found) SHOULD be used instead. This response is
cacheable unless indicated otherwise. cacheable unless indicated otherwise.
The 410 response is primarily intended to assist the task of The 410 response is primarily intended to assist the task of
repository maintenance by notifying the recipient that the resource repository maintenance by notifying the recipient that the resource
is intentionally unavailable and that the server owners desire that is intentionally unavailable and that the server owners desire that
remote links to that resource be removed. Such an event is common remote links to that resource be removed. Such an event is common
for limited-time, promotional services and for resources belonging to for limited-time, promotional services and for resources belonging to
individuals no longer working at the server's site. It is not individuals no longer working at the server's site. It is not
necessary to mark all permanently unavailable resources as "gone" or necessary to mark all permanently unavailable resources as "gone" or
to keep the mark for any length of time -- that is left to the to keep the mark for any length of time -- that is left to the
discretion of the owner of the server. discretion of the owner of the server.
15.4.11. 411 Length Required 17.4.11. 411 Length Required
The server refuses to accept the request without a defined Content- The server refuses to accept the request without a defined Content-
Length. The client MAY repeat the request if it adds a valid Length. The client MAY repeat the request if it adds a valid
Content-Length header field containing the length of the message-body Content-Length header field containing the length of the message-body
in the request message. in the request message.
15.4.12. 412 Precondition Failed 17.4.12. 412 Precondition Failed
The precondition given in one or more of the request-header fields The precondition given in one or more of the 'if-' request-header
evaluated to false when it was tested on the server. This response fields evaluated to false when it was tested on the server. See
code allows the client to place preconditions on the current resource these sections for the 'if-' headers: If-Match Section 18.23, If-
meta information (header field data) and thus prevent the requested Modified-Since Section 18.24, and If-None-Match Section 18.25. This
method from being applied to a resource other than the one intended. response code allows the client to place preconditions on the current
resource meta information (header field data) and thus prevent the
requested method from being applied to a resource other than the one
intended.
15.4.13. 413 Request Message Body Too Large 17.4.13. 413 Request Message Body Too Large
The server is refusing to process a request because the request The server is refusing to process a request because the request
message body is larger than the server is willing or able to process. message body is larger than the server is willing or able to process.
The server MAY close the connection to prevent the client from The server MAY close the connection to prevent the client from
continuing the request. continuing the request.
If the condition is temporary, the server SHOULD include a Retry- If the condition is temporary, the server SHOULD include a Retry-
After header field to indicate that it is temporary and after what After header field to indicate that it is temporary and after what
time the client MAY try again. time the client MAY try again.
15.4.14. 414 Request-URI Too Long 17.4.14. 414 Request-URI Too Long
The server is refusing to service the request because the Request-URI The server is refusing to service the request because the Request-URI
is longer than the server is willing to interpret. This rare is longer than the server is willing to interpret. This rare
condition is only likely to occur when a client has used a request condition is only likely to occur when a client has used a request
with long query information, when the client has descended into a URI with long query information, when the client has descended into a URI
"black hole" of redirection (e.g., a redirected URI prefix that "black hole" of redirection (e.g., a redirected URI prefix that
points to a suffix of itself), or when the server is under attack by points to a suffix of itself), or when the server is under attack by
a client attempting to exploit security holes present in some servers a client attempting to exploit security holes present in some servers
using fixed-length buffers for reading or manipulating the Request- using fixed-length buffers for reading or manipulating the Request-
URI. URI.
15.4.15. 415 Unsupported Media Type 17.4.15. 415 Unsupported Media Type
The server is refusing to service the request because the message The server is refusing to service the request because the message
body of the request is in a format not supported by the requested body of the request is in a format not supported by the requested
resource for the requested method. resource for the requested method.
15.4.16. 451 Parameter Not Understood 17.4.16. 451 Parameter Not Understood
The recipient of the request does not support one or more parameters The recipient of the request does not support one or more parameters
contained in the request. When returning this error message the contained in the request. When returning this error message the
sender SHOULD return a message body containing the offending sender SHOULD return a message body containing the offending
parameter(s). parameter(s).
15.4.17. 452 reserved 17.4.17. 452 reserved
This error code was removed from RFC 2326 [RFC2326] as it is This error code was removed from RFC 2326 [RFC2326] as it is
obsolete. This error code MUST NOT be used anymore. obsolete. This error code MUST NOT be used anymore.
15.4.18. 453 Not Enough Bandwidth 17.4.18. 453 Not Enough Bandwidth
The request was refused because there was insufficient bandwidth. The request was refused because there was insufficient bandwidth.
This may, for example, be the result of a resource reservation This may, for example, be the result of a resource reservation
failure. failure.
15.4.19. 454 Session Not Found 17.4.19. 454 Session Not Found
The RTSP session identifier in the Session header is missing, The RTSP session identifier in the Session header is missing,
invalid, or has timed out. invalid, or has timed out.
15.4.20. 455 Method Not Valid in This State 17.4.20. 455 Method Not Valid in This State
The client or server cannot process this request in its current The client or server cannot process this request in its current
state. The response MUST contain an Allow header to make error state. The response MUST contain an Allow header to make error
recovery possible. recovery possible.
15.4.21. 456 Header Field Not Valid for Resource 17.4.21. 456 Header Field Not Valid for Resource
The server could not act on a required request header. For example, The server could not act on a required request header. For example,
if PLAY contains the Range header field but the stream does not allow if PLAY contains the Range header field but the stream does not allow
seeking. This error message may also be used for specifying when the seeking. This error message may also be used for specifying when the
time format in Range is impossible for the resource. In that case time format in Range is impossible for the resource. In that case
the Accept-Ranges header MUST be returned to inform the client of the Accept-Ranges header MUST be returned to inform the client of
which format(s) that are allowed. which format(s) that are allowed.
15.4.22. 457 Invalid Range 17.4.22. 457 Invalid Range
The Range value given is out of bounds, e.g., beyond the end of the The Range value given is out of bounds, e.g., beyond the end of the
presentation. presentation.
15.4.23. 458 Parameter Is Read-Only 17.4.23. 458 Parameter Is Read-Only
The parameter to be set by SET_PARAMETER can be read but not The parameter to be set by SET_PARAMETER can be read but not
modified. When returning this error message the sender SHOULD return modified. When returning this error message the sender SHOULD return
a message body containing the offending parameter(s). a message body containing the offending parameter(s).
15.4.24. 459 Aggregate Operation Not Allowed 17.4.24. 459 Aggregate Operation Not Allowed
The requested method may not be applied on the URI in question since The requested method may not be applied on the URI in question since
it is an aggregate (presentation) URI. The method may be applied on it is an aggregate (presentation) URI. The method may be applied on
a media URI. a media URI.
15.4.25. 460 Only Aggregate Operation Allowed 17.4.25. 460 Only Aggregate Operation Allowed
The requested method may not be applied on the URI in question since The requested method may not be applied on the URI in question since
it is not an aggregate control (presentation) URI. The method may be it is not an aggregate control (presentation) URI. The method may be
applied on the aggregate control URI. applied on the aggregate control URI.
15.4.26. 461 Unsupported Transport 17.4.26. 461 Unsupported Transport
The Transport field did not contain a supported transport The Transport field did not contain a supported transport
specification. specification.
15.4.27. 462 Destination Unreachable 17.4.27. 462 Destination Unreachable
The data transmission channel could not be established because the The data transmission channel could not be established because the
client address could not be reached. This error will most likely be client address could not be reached. This error will most likely be
the result of a client attempt to place an invalid dest_addr the result of a client attempt to place an invalid dest_addr
parameter in the Transport field. parameter in the Transport field.
15.4.28. 463 Destination Prohibited 17.4.28. 463 Destination Prohibited
The data transmission channel was not established because the server The data transmission channel was not established because the server
prohibited access to the client address. This error is most likely prohibited access to the client address. This error is most likely
the result of a client attempt to redirect media traffic to another the result of a client attempt to redirect media traffic to another
destination with a dest_addr parameter in the Transport header. destination with a dest_addr parameter in the Transport header.
15.4.29. 464 Data Transport Not Ready Yet 17.4.29. 464 Data Transport Not Ready Yet
The data transmission channel to the media destination is not yet The data transmission channel to the media destination is not yet
ready for carrying data. However, the responding agent still expects ready for carrying data. However, the responding agent still expects
that the data transmission channel will be established at some point that the data transmission channel will be established at some point
in time. Note, however, that this may result in a permanent failure in time. Note, however, that this may result in a permanent failure
like 462 "Destination Unreachable". like 462 "Destination Unreachable".
An example when this error may occur is in the case a client sends a An example when this error may occur is in the case a client sends a
PLAY request to a server prior to ensuring that the TCP connections PLAY request to a server prior to ensuring that the TCP connections
negotiated for carrying media data was successfully established (In negotiated for carrying media data was successfully established (In
violation of this specification). The server would use this error violation of this specification). The server would use this error
code to indicate that the requested action could not be performed due code to indicate that the requested action could not be performed due
to the failure of completing the connection establishment. to the failure of completing the connection establishment.
15.4.30. 465 Notification Reason Unknown 17.4.30. 465 Notification Reason Unknown
This indicates that the client has received a PLAY_NOTIFY This indicates that the client has received a PLAY_NOTIFY
(Section 13.5) with a Notify-Reason header (Section 16.31) unknown to (Section 13.5) with a Notify-Reason header (Section 18.31) unknown to
the client. the client.
15.4.31. 466 Key Management Error 17.4.31. 466 Key Management Error
This indicates that there has been an error in a Key Management This indicates that there has been an error in a Key Management
function used in conjunction with a request. For example usage of function used in conjunction with a request. For example usage of
MIKEY according to Appendix C.1.4.1 may result in this error. MIKEY [RFC3830] according to Appendix C.1.4.1 may result in this
error.
15.4.32. 470 Connection Authorization Required 17.4.32. 470 Connection Authorization Required
The secured connection attempt needs user or client authorization The secured connection attempt needs user or client authorization
before proceeding. The next hops certificate is included in this before proceeding. The next hops certificate is included in this
response in the Accept-Credentials header. response in the Accept-Credentials header.
15.4.33. 471 Connection Credentials not accepted 17.4.33. 471 Connection Credentials not accepted
When performing a secure connection over multiple connections, an When performing a secure connection over multiple connections, an
intermediary has refused to connect to the next hop and carry out the intermediary has refused to connect to the next hop and carry out the
request due to unacceptable credentials for the used policy. request due to unacceptable credentials for the used policy.
15.4.34. 472 Failure to establish secure connection 17.4.34. 472 Failure to establish secure connection
A proxy fails to establish a secure connection to the next hop RTSP A proxy fails to establish a secure connection to the next hop RTSP
agent. This is primarily caused by a fatal failure at the TLS agent. This is primarily caused by a fatal failure at the TLS
handshake, for example due to server not accepting any cipher suites. handshake, for example due to server not accepting any cipher suites.
15.5. Server Error 5xx 17.5. Server Error 5xx
Response status codes beginning with the digit "5" indicate cases in Response status codes beginning with the digit "5" indicate cases in
which the server is aware that it has erred or is incapable of which the server is aware that it has erred or is incapable of
performing the request The server SHOULD include a message body performing the request The server SHOULD include a message body
containing an explanation of the error situation, and whether it is a containing an explanation of the error situation, and whether it is a
temporary or permanent condition. User agents SHOULD display any temporary or permanent condition. User agents SHOULD display any
included message body to the user. These response codes are included message body to the user. These response codes are
applicable to any request method. applicable to any request method.
15.5.1. 500 Internal Server Error 17.5.1. 500 Internal Server Error
The server encountered an unexpected condition which prevented it The server encountered an unexpected condition which prevented it
from fulfilling the request. from fulfilling the request.
15.5.2. 501 Not Implemented 17.5.2. 501 Not Implemented
The server does not support the functionality required to fulfill the The server does not support the functionality required to fulfill the
request. This is the appropriate response when the server does not request. This is the appropriate response when the server does not
recognize the request method and is not capable of supporting it for recognize the request method and is not capable of supporting it for
any resource. any resource.
15.5.3. 502 Bad Gateway 17.5.3. 502 Bad Gateway
The server, while acting as a gateway or proxy, received an invalid The server, while acting as a gateway or proxy, received an invalid
response from the upstream server it accessed in attempting to response from the upstream server it accessed in attempting to
fulfill the request. fulfill the request.
15.5.4. 503 Service Unavailable 17.5.4. 503 Service Unavailable
The server is currently unable to handle the request due to a The server is currently unable to handle the request due to a
temporary overloading or maintenance of the server. The implication temporary overloading or maintenance of the server. The implication
is that this is a temporary condition which will be alleviated after is that this is a temporary condition which will be alleviated after
some delay. If known, the length of the delay MAY be indicated in a some delay. If known, the length of the delay MAY be indicated in a
Retry-After header. If no Retry-After is given, the client SHOULD Retry-After header. If no Retry-After is given, the client SHOULD
handle the response as it would for a 500 response. The client MUST handle the response as it would for a 500 response. The client MUST
honor the length, if given in the Retry-After header. honor the length, if given in the Retry-After header.
Note: The existence of the 503 status code does not imply that Note: The existence of the 503 status code does not imply that
a server must use it when becoming overloaded. Some servers a server must use it when becoming overloaded. Some servers
may wish to simply refuse the connection. may wish to simply refuse the connection.
15.5.5. 504 Gateway Timeout 17.5.5. 504 Gateway Timeout
The server, while acting as a proxy, did not receive a timely The server, while acting as a proxy, did not receive a timely
response from the upstream server specified by the URI or some other response from the upstream server specified by the URI or some other
auxiliary server (e.g., DNS) it needed to access in attempting to auxiliary server (e.g., DNS) it needed to access in attempting to
complete the request. complete the request.
15.5.6. 505 RTSP Version Not Supported 17.5.6. 505 RTSP Version Not Supported
The server does not support, or refuses to support, the RTSP protocol The server does not support, or refuses to support, the RTSP protocol
version that was used in the request message. The server is version that was used in the request message. The server is
indicating that it is unable or unwilling to complete the request indicating that it is unable or unwilling to complete the request
using the same major version as the client other than with this error using the same major version as the client other than with this error
message. The response SHOULD contain a message body describing why message. The response SHOULD contain a message body describing why
that version is not supported and what other protocols are supported that version is not supported and what other protocols are supported
by that server. by that server.
15.5.7. 551 Option not supported 17.5.7. 551 Option not supported
A feature-tag given in the Require or the Proxy-Require fields was A feature-tag given in the Require or the Proxy-Require fields was
not supported. The Unsupported header MUST be returned stating the not supported. The Unsupported header MUST be returned stating the
feature for which there is no support. feature for which there is no support.
16. Header Field Definitions 18. Header Field Definitions
+---------------+----------------+--------+---------+------+ +---------------+----------------+--------+---------+------+
| method | direction | object | acronym | Body | | method | direction | object | acronym | Body |
+---------------+----------------+--------+---------+------+ +---------------+----------------+--------+---------+------+
| DESCRIBE | C -> S | P,S | DES | r | | DESCRIBE | C -> S | P,S | DES | r |
| | | | | | | | | | | |
| GET_PARAMETER | C -> S, S -> C | P,S | GPR | R,r | | GET_PARAMETER | C -> S, S -> C | P,S | GPR | R,r |
| | | | | | | | | | | |
| OPTIONS | C -> S, S -> C | P,S | OPT | | | OPTIONS | C -> S, S -> C | P,S | OPT | |
| | | | | | | | | | | |
skipping to change at page 108, line 45 skipping to change at page 119, line 45
context of the message. context of the message.
m: The header field is mandatory. m: The header field is mandatory.
m*: The header field SHOULD be sent, but clients/servers need to be m*: The header field SHOULD be sent, but clients/servers need to be
prepared to receive messages without that header field. prepared to receive messages without that header field.
o: The header field is optional. o: The header field is optional.
*: The header field MUST be present if the message body is not *: The header field MUST be present if the message body is not
empty. See Section 16.16, Section 16.18 and Section 5.3 for empty. See Section 18.16, Section 18.18 and Section 5.3 for
details. details.
-: The header field is not applicable. -: The header field is not applicable.
"Optional" means that a Client/Server MAY include the header field in "Optional" means that a Client/Server MAY include the header field in
a request or response. The Client/Server behavior when receiving a request or response. The Client/Server behavior when receiving
such headers varies, for some it may ignore the header field, in such headers varies, for some it may ignore the header field, in
other cases it is a request to process the header. This is regulated other cases it is a request to process the header. This is regulated
by the method and header descriptions. Example of headers that by the method and header descriptions. Example of headers that
require processing are the Require and Proxy-Require header fields require processing are the Require and Proxy-Require header fields
discussed in Section 16.41 and Section 16.35. A "mandatory" header discussed in Section 18.41 and Section 18.35. A "mandatory" header
field MUST be present in a request, and MUST be understood by the field MUST be present in a request, and MUST be understood by the
Client/Server receiving the request. A mandatory response header Client/Server receiving the request. A mandatory response header
field MUST be present in the response, and the header field MUST be field MUST be present in the response, and the header field MUST be
understood by the Client/Server processing the response. "Not understood by the Client/Server processing the response. "Not
applicable" means that the header field MUST NOT be present in a applicable" means that the header field MUST NOT be present in a
request. If one is placed in a request by mistake, it MUST be request. If one is placed in a request by mistake, it MUST be
ignored by the Client/Server receiving the request. Similarly, a ignored by the Client/Server receiving the request. Similarly, a
header field labeled "not applicable" for a response means that the header field labeled "not applicable" for a response means that the
Client/Server MUST NOT place the header field in the response, and Client/Server MUST NOT place the header field in the response, and
the Client/Server MUST ignore the header field in the response. the Client/Server MUST ignore the header field in the response.
skipping to change at page 111, line 7 skipping to change at page 122, line 7
| Content-Type | r | r | * | - | - | - | - | - | | Content-Type | r | r | * | - | - | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Content-Type | 4xx,5 | ar | * | * | * | * | * | * | | Content-Type | 4xx,5 | ar | * | * | * | * | * | * |
| | xx | | | | | | | | | | xx | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| CSeq | Rc | rm | m | m | m | m | m | m | | CSeq | Rc | rm | m | m | m | m | m | m |
| | | | | | | | | | | | | | | | | | | |
| Date | | am | o/ | o/* | o/* | o/* | o/* | o/* | | Date | | am | o/ | o/* | o/* | o/* | o/* | o/* |
| | | | * | | | | | | | | | | * | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Expires | r | r | o | - | - | - | - | - | | Expires | r | r | o | - | o | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| From | R | r | o | o | o | o | o | o | | From | R | r | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| If-Match | R | r | - | - | o | - | - | - | | If-Match | R | r | - | - | o | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| If-Modified-Sinc | R | r | o | - | o | - | - | - | | If-Modified-Sinc | R | r | o | - | o | - | - | - |
| e | | | | | | | | | | e | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| If-None-Match | R | r | o | - | o | - | - | - | | If-None-Match | R | r | o | - | o | - | - | - |
| | | | | | | | | | | | | | | | | | | |
skipping to change at page 113, line 17 skipping to change at page 124, line 17
| Timestamp | R | admr | o | o | o | o | o | o | | Timestamp | R | admr | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Timestamp | c | admr | m | m | m | m | m | m | | Timestamp | c | admr | m | m | m | m | m | m |
| | | | | | | | | | | | | | | | | | | |
| Transport | | mr | - | - | m | - | - | - | | Transport | | mr | - | - | m | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Unsupported | r | | c | c | c | c | c | c | | Unsupported | r | | c | c | c | c | c | c |
| | | | | | | | | | | | | | | | | | | |
| User-Agent | R | | m* | m* | m* | m* | m* | m* | | User-Agent | R | | m* | m* | m* | m* | m* | m* |
| | | | | | | | | | | | | | | | | | | |
| Vary | r | | c | c | c | c | c | c |
| | | | | | | | | |
| Via | R | amr | o | o | o | o | o | o | | Via | R | amr | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Via | c | dr | m | m | m | m | m | m | | Via | c | dr | m | m | m | m | m | m |
| | | | | | | | | | | | | | | | | | | |
| WWW- | 401 | | m | m | m | m | m | m | | WWW- | 401 | | m | m | m | m | m | m |
| Authenticate | | | | | | | | | | Authenticate | | | | | | | | |
+----------------+-------+------+-----+-----+-----+-----+-----+-----+ +----------------+-------+------+-----+-----+-----+-----+-----+-----+
Table 10: Overview of RTSP header fields (M-W) related to methods Table 10: Overview of RTSP header fields (M-W) related to methods
DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.
+------------------------+---------+-------+-----+-----+-----+-----+ +------------------------+---------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY | | Header | Where | Proxy | GPR | SPR | RDR | PNY |
+------------------------+---------+-------+-----+-----+-----+-----+ +------------------------+---------+-------+-----+-----+-----+-----+
| Accept | R | arm | o | o | - | - | | Accept | R | arm | o | o | - | - |
| | | | | | | | | | | | | | | |
| Accept-Credentials | R | rm | o | o | o | - | | Accept-Credentials | R | rm | o | o | o | - |
| | | | | | | | | | | | | | | |
| Accept-Encoding | TBD | TBD | TBD | TBD | TBD | TBD | | Accept-Encoding | R | r | o | o | o | - |
| | | | | | | | | | | | | | | |
| Accept-Language | TBD | TBD | TBD | TBD | TBD | TBD | | Accept-Language | R | r | o | o | o | - |
| | | | | | | | | | | | | | | |
| Accept-Ranges | | rm | o | - | - | - | | Accept-Ranges | | rm | o | - | - | - |
| | | | | | | | | | | | | | | |
| Allow | 405 | amr | m | m | m | - | | Allow | 405 | amr | m | m | m | - |
| | | | | | | | | | | | | | | |
| Authorization | R | | o | o | o | - | | Authorization | R | | o | o | o | - |
| | | | | | | | | | | | | | | |
| Bandwidth | R | | - | o | - | - | | Bandwidth | R | | - | o | - | - |
| | | | | | | | | | | | | | | |
| Blocksize | R | | - | o | - | - | | Blocksize | R | | - | o | - | - |
| | | | | | | | | | | | | | | |
| Cache-Control | | r | o | o | - | - | | Cache-Control | | r | o | o | - | - |
| Connection | | | o | o | o | o |
| | | | | | | | | | | | | | | |
| Connection | | | o | o | o | o |
| Connection-Credentials | 470,407 | ar | o | o | o | - | | Connection-Credentials | 470,407 | ar | o | o | o | - |
| | | | | | | | | | | | | | | |
| Content-Base | R | | o | o | - | - | | Content-Base | R | | o | o | - | - |
| | | | | | | | | | | | | | | |
| Content-Base | r | | o | o | - | - | | Content-Base | r | | o | o | - | - |
| | | | | | | | | | | | | | | |
| Content-Base | 4xx,5xx | | o | o | o | o | | Content-Base | 4xx,5xx | | o | o | o | o |
| | | | | | | | | | | | | | | |
| Content-Encoding | R | r | o | o | - | - | | Content-Encoding | R | r | o | o | - | - |
| | | | | | | | | | | | | | | |
skipping to change at page 114, line 50 skipping to change at page 125, line 48
| Content-Type | r | | * | * | - | - | | Content-Type | r | | * | * | - | - |
| | | | | | | | | | | | | | | |
| Content-Type | 4xx,5xx | | * | * | * | * | | Content-Type | 4xx,5xx | | * | * | * | * |
| | | | | | | | | | | | | | | |
| CSeq | R,c | mr | m | m | m | m | | CSeq | R,c | mr | m | m | m | m |
| | | | | | | | | | | | | | | |
| Date | R | a | o | o | m | o | | Date | R | a | o | o | m | o |
| | | | | | | | | | | | | | | |
| Date | r | am | o | o | o | o | | Date | r | am | o | o | o | o |
| | | | | | | | | | | | | | | |
| Expires | TBD | TBD | TBD | TBD | TBD | TBD | | Expires | r | r | - | - | - | - |
| | | | | | | | | | | | | | | |
| From | R | r | o | o | o | - | | From | R | r | o | o | o | - |
| | | | | | | | | | | | | | | |
| If-Match | TBD | TBD | TBD | TBD | TBD | TBD | | If-Match | R | r | - | - | - | - |
| | | | | | | | | | | | | | | |
| If-Modified-Since | R | am | o | - | - | - | | If-Modified-Since | R | am | o | - | - | - |
| | | | | | | | | | | | | | | |
| If-None-Match | R | am | o | - | - | - | | If-None-Match | R | am | o | - | - | - |
| | | | | | | | | | | | | | | |
| Last-Modified | R | r | - | - | - | - | | Last-Modified | R | r | - | - | - | - |
| | | | | | | | | | | | | | | |
| Last-Modified | r | r | o | - | - | - | | Last-Modified | r | r | o | - | - | - |
| | | | | | | | | | | | | | | |
| Location | 3rr | | o | o | o | - | | Location | 3rr | | o | o | o | - |
skipping to change at page 115, line 28 skipping to change at page 126, line 26
| Location | R | | - | - | m | - | | Location | R | | - | - | m | - |
| | | | | | | | | | | | | | | |
| Media-Properties | R | amr | o | - | - | c | | Media-Properties | R | amr | o | - | - | c |
| | | | | | | | | | | | | | | |
| Media-Properties | r | mr | c | - | - | - | | Media-Properties | r | mr | c | - | - | - |
| | | | | | | | | | | | | | | |
| Media-Range | R | | o | - | - | c | | Media-Range | R | | o | - | - | c |
| | | | | | | | | | | | | | | |
| Media-Range | r | | c | - | - | - | | Media-Range | r | | c | - | - | - |
| | | | | | | | | | | | | | | |
| MTag | TBD | TBD | TBD | TBD | TBD | TBD | | MTag | r | r | o | - | - | - |
| | | | | | | | | | | | | | | |
| Notify-Reason | R | | - | - | - | m | | Notify-Reason | R | | - | - | - | m |
| | | | | | | | | | | | | | | |
| Pipelined-Requests | R | amdr | o | o | - | - | | Pipelined-Requests | R | amdr | o | o | - | - |
| | | | | | | | | | | | | | | |
| Proxy-Authenticate | 407 | amr | m | m | m | - | | Proxy-Authenticate | 407 | amr | m | m | m | - |
| | | | | | | | | | | | | | | |
| Proxy-Authorization | R | rd | o | o | o | - | | Proxy-Authorization | R | rd | o | o | o | - |
| | | | | | | | | | | | | | | |
| Proxy-Require | R | ar | o | o | o | - | | Proxy-Require | R | ar | o | o | o | - |
skipping to change at page 116, line 48 skipping to change at page 127, line 48
| Supported | R | adrm | o | o | o | - | | Supported | R | adrm | o | o | o | - |
| | | | | | | | | | | | | | | |
| Supported | r | adrm | c | c | c | - | | Supported | r | adrm | c | c | c | - |
| | | | | | | | | | | | | | | |
| Terminate-Reason | R | r | - | - | m | - | | Terminate-Reason | R | r | - | - | m | - |
| | | | | | | | | | | | | | | |
| Timestamp | R | adrm | o | o | o | - | | Timestamp | R | adrm | o | o | o | - |
| | | | | | | | | | | | | | | |
| Timestamp | c | adrm | m | m | m | - | | Timestamp | c | adrm | m | m | m | - |
| | | | | | | | | | | | | | | |
| Transport | TBD | TBD | TBD | TBD | TBD | TBD | | Transport | | mr | - | - | - | - |
| | | | | | | | | | | | | | | |
| Unsupported | r | arm | c | c | c | - | | Unsupported | r | arm | c | c | c | - |
| | | | | | | | | | | | | | | |
| User-Agent | R | r | m* | m* | - | - | | User-Agent | R | r | m* | m* | - | - |
| User-Agent | r | r | m* | m* | m* | m* | | User-Agent | r | r | m* | m* | m* | m* |
| | | | | | | | | | | | | | | |
| Vary | r | | c | c | - | - |
| | | | | | | |
| Via | R | amr | o | o | o | - | | Via | R | amr | o | o | o | - |
| | | | | | | | | | | | | | | |
| Via | c | dr | m | m | m | - | | Via | c | dr | m | m | m | - |
| | | | | | | | | | | | | | | |
| WWW-Authenticate | 401 | | m | m | m | - | | WWW-Authenticate | 401 | | m | m | m | - |
+------------------+---------+-------+-----+-----+-----+-----+ +------------------+---------+-------+-----+-----+-----+-----+
Table 12: Overview of RTSP header fields (R-W) related to methods Table 12: Overview of RTSP header fields (R-W) related to methods
GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY. GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY.
16.1. Accept 18.1. Accept
The Accept request-header field can be used to specify certain The Accept request-header field can be used to specify certain
presentation description and parameter media types [RFC4288] which presentation description and parameter media types [RFC4288] which
are acceptable for the response to DESCRIBE and GET_PARAMETER are acceptable for the response to DESCRIBE and GET_PARAMETER
requests. requests.
See Section 20.2.3 for the syntax. See Section 20.2.3 for the syntax.
Example of use: Example of use:
Accept: application/example ;q=1.0, application/sdp Accept: application/example ;q=1.0, application/sdp
16.2. Accept-Credentials 18.2. Accept-Credentials
The Accept-Credentials header is a request header used to indicate to The Accept-Credentials header is a request header used to indicate to
any trusted intermediary how to handle further secured connections to any trusted intermediary how to handle further secured connections to
proxies or servers. See Section 19 for the usage of this header. It proxies or servers. See Section 19 for the usage of this header. It
MUST NOT be included in server to client requests. MUST NOT be included in server to client requests.
In a request the header MUST contain the method (User, Proxy, or Any) In a request the header MUST contain the method (User, Proxy, or Any)
for approving credentials selected by the requester. The method MUST for approving credentials selected by the requester. The method MUST
NOT be changed by any proxy, unless it is "Proxy" when a proxy MAY NOT be changed by any proxy, unless it is "Proxy" when a proxy MAY
change it to "user" to take the role of user approving each further change it to "user" to take the role of user approving each further
skipping to change at page 118, line 17 skipping to change at page 129, line 15
somewhere else than here. Thus the definition of future algorithms somewhere else than here. Thus the definition of future algorithms
for this purpose is intended to be extremely limited. A feature tag for this purpose is intended to be extremely limited. A feature tag
can be used to ensure that support for the replacement algorithm can be used to ensure that support for the replacement algorithm
exist. exist.
Example: Example:
Accept-Credentials:User Accept-Credentials:User
"rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=, "rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=,
"rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M= "rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M=
16.3. Accept-Encoding 18.3. Accept-Encoding
The Accept-Encoding request-header field is similar to Accept, but The Accept-Encoding request-header field is similar to Accept, but
restricts the content-codings (see Section 16.14),i.e. transformation restricts the content-codings (see Section 18.14),i.e. transformation
codings of the message body, such as gzip compression, that are codings of the message body, such as gzip compression, that are
acceptable in the response. acceptable in the response.
A server tests whether a content-coding is acceptable, according to A server tests whether a content-coding is acceptable, according to
an Accept-Encoding field, using these rules: an Accept-Encoding field, using these rules:
1. If the content-coding is one of the content-codings listed in the 1. If the content-coding is one of the content-codings listed in the
Accept-Encoding field, then it is acceptable, unless it is Accept-Encoding field, then it is acceptable, unless it is
accompanied by a qvalue of 0. (As defined in [H3.9], a qvalue of accompanied by a qvalue of 0. (As defined in [H3.9], a qvalue of
0 means "not acceptable.") 0 means "not acceptable.")
skipping to change at page 119, line 9 skipping to change at page 130, line 8
Accept-Encoding header, then the server SHOULD send an error response Accept-Encoding header, then the server SHOULD send an error response
with the 406 (Not Acceptable) status code. with the 406 (Not Acceptable) status code.
If no Accept-Encoding field is present in a request, the server MAY If no Accept-Encoding field is present in a request, the server MAY
assume that the client will accept any content coding. In this case, assume that the client will accept any content coding. In this case,
if "identity" is one of the available content-codings, then the if "identity" is one of the available content-codings, then the
server SHOULD use the "identity" content-coding, unless it has server SHOULD use the "identity" content-coding, unless it has
additional information that a different content-coding is meaningful additional information that a different content-coding is meaningful
to the client. to the client.
16.4. Accept-Language 18.4. Accept-Language
The Accept-Language request-header field is similar to Accept, but The Accept-Language request-header field is similar to Accept, but
restricts the set of natural languages that are preferred as a restricts the set of natural languages that are preferred as a
response to the request. Note that the language specified applies to response to the request. Note that the language specified applies to
the presentation description and any reason phrases, but not the the presentation description and any reason phrases, but not the
media content. media content.
A language tag identifies a natural language spoken, written, or A language tag identifies a natural language spoken, written, or
otherwise conveyed by human beings for communication of information otherwise conveyed by human beings for communication of information
to other human beings. Computer languages are explicitly excluded. to other human beings. Computer languages are explicitly excluded.
skipping to change at page 119, line 50 skipping to change at page 130, line 49
always true that if a user understands a language with a certain always true that if a user understands a language with a certain
tag, then this user will also understand all languages with tags tag, then this user will also understand all languages with tags
for which this tag is a prefix. The prefix rule simply allows the for which this tag is a prefix. The prefix rule simply allows the
use of prefix tags if this is the case. use of prefix tags if this is the case.
In the process of selecting a language, each language-tag is assigned In the process of selecting a language, each language-tag is assigned
a qualification factor, i.e., if a language being supported by the a qualification factor, i.e., if a language being supported by the
client is actually supported by the server and what "preference" client is actually supported by the server and what "preference"
level the language achieves. The quality value (q-value) of the level the language achieves. The quality value (q-value) of the
longest language-range in the field that matches the language-tag is longest language-range in the field that matches the language-tag is
assigned as the qualification factor for a particalr language-tag. assigned as the qualification factor for a particular language-tag.
If no language-range in the field matches the tag, the language If no language-range in the field matches the tag, the language
qualification factor assigned is 0. If no Accept-Language header is qualification factor assigned is 0. If no Accept-Language header is
present in the request, the server SHOULD assume that all languages present in the request, the server SHOULD assume that all languages
are equally acceptable. If an Accept-Language header is present, are equally acceptable. If an Accept-Language header is present,
then all languages which are assigned a qualification factor greater then all languages which are assigned a qualification factor greater
than 0 are acceptable. than 0 are acceptable.
16.5. Accept-Ranges 18.5. Accept-Ranges
The Accept-Ranges general-header field allows indication of the The Accept-Ranges general-header field allows indication of the
format supported in the Range header. The client MUST include the format supported in the Range header. The client MUST include the
header in SETUP requests to indicate which formats it support to header in SETUP requests to indicate which formats it support to
receive in PLAY and PAUSE responses, and REDIRECT requests. The receive in PLAY and PAUSE responses, and REDIRECT requests. The
server MUST include the header in SETUP and 456 error responses to server MUST include the header in SETUP and 456 error responses to
indicate the formats supported for the resource indicated by the indicate the formats supported for the resource indicated by the
request URI. The header MAY be included in GET_PARAMETER request and request URI. The header MAY be included in GET_PARAMETER request and
response pairs. The GET_PARAMETER request MUST contain a Session response pairs. The GET_PARAMETER request MUST contain a Session
header to identify the session context the request is related to. header to identify the session context the request is related to.
The requester and responder will indicate their capabilities The requester and responder will indicate their capabilities
regarding Range formats respectively. regarding Range formats respectively.
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
The syntax is defined in Section 20.2.3. The syntax is defined in Section 20.2.3.
16.6. Allow 18.6. Allow
The Allow message-header field lists the methods supported by the The Allow message-header field lists the methods supported by the
resource identified by the Request-URI. The purpose of this field is resource identified by the Request-URI. The purpose of this field is
to strictly inform the recipient of valid methods associated with the to strictly inform the recipient of valid methods associated with the
resource. An Allow header field MUST be present in a 405 (Method Not resource. An Allow header field MUST be present in a 405 (Method Not
Allowed) response. The Allow header MUST also be present in all Allowed) response. The Allow header MUST also be present in all
OPTIONS responses where the content of the header will not include OPTIONS responses where the content of the header will not include
exactly the same methods as listed in the Public header. exactly the same methods as listed in the Public header.
The Allow MUST also be included in SETUP and DESCRIBE responses, if The Allow MUST also be included in SETUP and DESCRIBE responses, if
the methods allowed for the resource is different than the complete the methods allowed for the resource is different than the complete
set of methods defined in this memo. set of methods defined in this memo.
Example of use: Example of use:
Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE
16.7. Authorization 18.7. Authorization
An RTSP client that wishes to authenticate itself with a server using An RTSP client that wishes to authenticate itself with a server using
authentication mechanism from HTTP [RFC2617] , usually, but not authentication mechanism from HTTP [RFC2617] , usually, but not
necessarily, after receiving a 401 response, does so by including an necessarily, after receiving a 401 response, does so by including an
Authorization request-header field with the request. The Authorization request-header field with the request. The
Authorization field value consists of credentials containing the Authorization field value consists of credentials containing the
authentication information of the user agent for the realm of the authentication information of the user agent for the realm of the
resource being requested. resource being requested.
If a request is authenticated and a realm specified, the same If a request is authenticated and a realm specified, the same
credentials SHOULD be valid for all other requests within this realm credentials SHOULD be valid for all other requests within this realm
(assuming that the authentication scheme itself does not require (assuming that the authentication scheme itself does not require
otherwise, such as credentials that vary according to a challenge otherwise, such as credentials that vary according to a challenge
value or using synchronized clocks). value or using synchronized clocks).
When a shared cache (see Section 18) receives a request containing an When a shared cache (see Section 16) receives a request containing an
Authorization field, it MUST NOT return the corresponding response as Authorization field, it MUST NOT return the corresponding response as
a reply to any other request, unless one of the following specific a reply to any other request, unless one of the following specific
exceptions holds: exceptions holds:
1. If the response includes the "max-age" cache-control directive, 1. If the response includes the "max-age" cache-control directive,
the cache MAY use that response in replying to a subsequent the cache MAY use that response in replying to a subsequent
request. But (if the specified maximum age has passed) a proxy request. But (if the specified maximum age has passed) a proxy
cache MUST first revalidate it with the origin server, using the cache MUST first revalidate it with the origin server, using the
request-headers from the new request to allow the origin server request-headers from the new request to allow the origin server
to authenticate the new request. (This is the defined behavior to authenticate the new request. (This is the defined behavior
skipping to change at page 121, line 37 skipping to change at page 132, line 36
2. If the response includes the "must-revalidate" cache-control 2. If the response includes the "must-revalidate" cache-control
directive, the cache MAY use that response in replying to a directive, the cache MAY use that response in replying to a
subsequent request. But if the response is stale, all caches subsequent request. But if the response is stale, all caches
MUST first revalidate it with the origin server, using the MUST first revalidate it with the origin server, using the
request-headers from the new request to allow the origin server request-headers from the new request to allow the origin server
to authenticate the new request. to authenticate the new request.
3. If the response includes the "public" cache-control directive, it 3. If the response includes the "public" cache-control directive, it
MAY be returned in reply to any subsequent request. MAY be returned in reply to any subsequent request.
16.8. Bandwidth 18.8. Bandwidth
The Bandwidth request-header field describes the estimated bandwidth The Bandwidth request-header field describes the estimated bandwidth
available to the client, expressed as a positive integer and measured available to the client, expressed as a positive integer and measured
in kilobits per second. The bandwidth available to the client may in kilobits per second. The bandwidth available to the client may
change during an RTSP session, e.g., due to mobility, congestion, change during an RTSP session, e.g., due to mobility, congestion,
etc. etc.
Clients may not be able to accurately determine the available Clients may not be able to accurately determine the available
bandwidth, for example due to that first hop is not a bottleneck. bandwidth, for example due to that first hop is not a bottleneck.
For example most local area networks (LAN) will not be a bottleneck For example most local area networks (LAN) will not be a bottleneck
skipping to change at page 122, line 18 skipping to change at page 133, line 17
It is RECOMMENDED that only clients that has accurate and explicit It is RECOMMENDED that only clients that has accurate and explicit
information about bandwidth bottlenecks uses this header. information about bandwidth bottlenecks uses this header.
This header is not a substitute for proper congestion control. Only This header is not a substitute for proper congestion control. Only
a method providing an initial estimate and coarsely determine if the a method providing an initial estimate and coarsely determine if the
selected content can be delivered at all. selected content can be delivered at all.
Example: Example:
Bandwidth: 62360 Bandwidth: 62360
16.9. Blocksize 18.9. Blocksize
The Blocksize request-header field is sent from the client to the The Blocksize request-header field is sent from the client to the
media server asking the server for a particular media packet size. media server asking the server for a particular media packet size.
This packet size does not include lower-layer headers such as IP, This packet size does not include lower-layer headers such as IP,
UDP, or RTP. The server is free to use a blocksize which is lower UDP, or RTP. The server is free to use a blocksize which is lower
than the one requested. The server MAY truncate this packet size to than the one requested. The server MAY truncate this packet size to
the closest multiple of the minimum, media-specific block size, or the closest multiple of the minimum, media-specific block size, or
override it with the media-specific size if necessary. The block override it with the media-specific size if necessary. The block
size MUST be a positive decimal number, measured in octets. The size MUST be a positive decimal number, measured in octets. The
server only returns an error (4xx) if the value is syntactically server only returns an error (4xx) if the value is syntactically
invalid. invalid.
16.10. Cache-Control 18.10. Cache-Control
The Cache-Control general-header field is used to specify directives The Cache-Control general-header field is used to specify directives
that MUST be obeyed by all caching mechanisms along the request/ that MUST be obeyed by all caching mechanisms along the request/
response chain. response chain.
Cache directives MUST be passed through by a proxy or gateway Cache directives MUST be passed through by a proxy or gateway
application, regardless of their significance to that application, application, regardless of their significance to that application,
since the directives may be applicable to all recipients along the since the directives may be applicable to all recipients along the
request/response chain. It is not possible to specify a cache- request/response chain. It is not possible to specify a cache-
directive for a specific cache. directive for a specific cache.
Cache-Control should only be specified in a DESCRIBE, GET_PARAMETER, Cache-Control should only be specified in a DESCRIBE, GET_PARAMETER,
SET_PARAMETER and SETUP request and its response. Note: Cache- SET_PARAMETER and SETUP request and its response. Note: Cache-
Control does not govern only the caching of responses as for HTTP, Control does not govern only the caching of responses as for HTTP,
instead it also applies to the media stream identified by the SETUP instead it also applies to the media stream identified by the SETUP
request. The RTSP requests are generally not cacheable, for further request. The RTSP requests are generally not cacheable, for further
information see Section 18. Below is the description of the cache information see Section 16. Below is the description of the cache
directives that can be included in the Cache-Control header. directives that can be included in the Cache-Control header.
no-cache: Indicates that the media stream MUST NOT be cached no-cache: Indicates that the media stream MUST NOT be cached
anywhere. This allows an origin server to prevent caching even anywhere. This allows an origin server to prevent caching even
by caches that have been configured to return stale responses by caches that have been configured to return stale responses
to client requests. Note, there is no security function to client requests. Note, there is no security function
enforcing that the content can't be cached. enforcing that the content can't be cached.
public: Indicates that the media stream is cacheable by any cache. public: Indicates that the media stream is cacheable by any cache.
skipping to change at page 125, line 5 skipping to change at page 136, line 5
making its request. If the server replies with 304 (Not Modified), making its request. If the server replies with 304 (Not Modified),
then the cache can return its now validated copy to the client with a then the cache can return its now validated copy to the client with a
200 (OK) response. If the server replies with a new message body and 200 (OK) response. If the server replies with a new message body and
cache validator, however, the intermediate cache can compare the cache validator, however, the intermediate cache can compare the
returned validator with the one provided in the client's request, returned validator with the one provided in the client's request,
using the strong comparison function. If the client's validator is using the strong comparison function. If the client's validator is
equal to the origin server's, then the intermediate cache simply equal to the origin server's, then the intermediate cache simply
returns 304 (Not Modified). Otherwise, it returns the new message returns 304 (Not Modified). Otherwise, it returns the new message
body with a 200 (OK) response. body with a 200 (OK) response.
16.11. Connection 18.11. Connection
The Connection general-header field allows the sender to specify The Connection general-header field allows the sender to specify
options that are desired for that particular connection and MUST NOT options that are desired for that particular connection and MUST NOT
be communicated by proxies over further connections. be communicated by proxies over further connections.
RTSP 2.0 proxies MUST parse the Connection header field before a RTSP 2.0 proxies MUST parse the Connection header field before a
message is forwarded and, for each connection-token in this field, message is forwarded and, for each connection-token in this field,
remove any header field(s) from the message with the same name as the remove any header field(s) from the message with the same name as the
connection-token. Connection options are signaled by the presence of connection-token. Connection options are signaled by the presence of
a connection-token in the Connection header field, not by any a connection-token in the Connection header field, not by any
skipping to change at page 125, line 36 skipping to change at page 136, line 36
the response header fields indicates that the connection SHOULD NOT the response header fields indicates that the connection SHOULD NOT
be considered `persistent' (Section 10.2) after the current request/ be considered `persistent' (Section 10.2) after the current request/
response is complete. response is complete.
The use of the connection option "close" in RTSP messages SHOULD be The use of the connection option "close" in RTSP messages SHOULD be
limited to error messages when the server is unable to recover and limited to error messages when the server is unable to recover and
therefore see it necessary to close the connection. The reason is therefore see it necessary to close the connection. The reason is
that the client has the choice of continuing using a connection that the client has the choice of continuing using a connection
indefinitely, as long as it sends valid messages. indefinitely, as long as it sends valid messages.
16.12. Connection-Credentials 18.12. Connection-Credentials
The Connection-Credentials response header is used to carry the chain The Connection-Credentials response header is used to carry the chain
of credentials of any next hop that need to be approved by the of credentials of any next hop that need to be approved by the
requester. It MUST only be used in server to client responses. requester. It MUST only be used in server to client responses.
The Connection-Credentials header in an RTSP response MUST, if The Connection-Credentials header in an RTSP response MUST, if
included, contain the credential information (in form of a list of included, contain the credential information (in form of a list of
certificates providing the chain of certification) of the next hop certificates providing the chain of certification) of the next hop
that an intermediary needs to securely connect to. The header MUST that an intermediary needs to securely connect to. The header MUST
include the URI of the next hop (proxy or server) and a base64 include the URI of the next hop (proxy or server) and a base64
skipping to change at page 126, line 34 skipping to change at page 137, line 34
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size of certificate #2 | Size of certificate #3 | | Size of certificate #2 | Size of certificate #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DER Encoding of Certificate #1 : : DER Encoding of Certificate #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DER Encoding of Certificate #2 : : DER Encoding of Certificate #2 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DER Encoding of Certificate #3 : : DER Encoding of Certificate #3 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16.13. Content-Base 18.13. Content-Base
The Content-Base message-header field may be used to specify the base The Content-Base message-header field may be used to specify the base
URI for resolving relative URIs within the message body. URI for resolving relative URIs within the message body.
Content-Base: rtsp://media.example.com/movie/twister/ Content-Base: rtsp://media.example.com/movie/twister/
If no Content-Base field is present, the base URI of an message body If no Content-Base field is present, the base URI of an message body
is defined either by its Content-Location (if that Content-Location is defined either by its Content-Location (if that Content-Location
URI is an absolute URI) or the URI used to initiate the request, in URI is an absolute URI) or the URI used to initiate the request, in
that order of precedence. Note, however, that the base URI of the that order of precedence. Note, however, that the base URI of the
contents within the message-body may be redefined within that contents within the message-body may be redefined within that
message-body. message-body.
16.14. Content-Encoding 18.14. Content-Encoding
The Content-Encoding header field is used as a modifier to the media- The Content-Encoding header field is used as a modifier to the media-
type. When present, its value indicates what additional content type. When present, its value indicates what additional content
codings have been applied to the message body, and thus what decoding codings have been applied to the message body, and thus what decoding
mechanisms must be applied in order to obtain the media-type mechanisms must be applied in order to obtain the media-type
referenced by the Content-Type header field. Content-Encoding is referenced by the Content-Type header field. Content-Encoding is
primarily used to allow a document to be compressed without losing primarily used to allow a document to be compressed without losing
the identity of its underlying media type. the identity of its underlying media type.
The content-coding is a characteristic of the message body identified The content-coding is a characteristic of the message body identified
skipping to change at page 127, line 31 skipping to change at page 138, line 31
If the content-coding of a message body in a request message is not If the content-coding of a message body in a request message is not
acceptable to the origin server, the server SHOULD respond with a acceptable to the origin server, the server SHOULD respond with a
status code of 415 (Unsupported Media Type). status code of 415 (Unsupported Media Type).
If multiple encodings have been applied to a message body, the If multiple encodings have been applied to a message body, the
content codings MUST be listed in the order in which they were content codings MUST be listed in the order in which they were
applied, first to last from left to right. Additional information applied, first to last from left to right. Additional information
about the encoding parameters MAY be provided by other header fields about the encoding parameters MAY be provided by other header fields
not defined by this specification. not defined by this specification.
16.15. Content-Language 18.15. Content-Language
The Content-Language header field describes the natural language(s) The Content-Language header field describes the natural language(s)
of the intended audience for the enclosed message body. Note that of the intended audience for the enclosed message body. Note that
this might not be equivalent to all the languages used within the this might not be equivalent to all the languages used within the
message body. message body.
Language tags are mentioned in Section 16.4. The primary purpose of Language tags are mentioned in Section 18.4. The primary purpose of
Content-Language is to allow a user to identify and differentiate Content-Language is to allow a user to identify and differentiate
entities according to the user's own preferred language. Thus, if entities according to the user's own preferred language. Thus, if
the body content is intended only for a Danish-literate audience, the the body content is intended only for a Danish-literate audience, the
appropriate field is appropriate field is
Content-Language: da Content-Language: da
If no Content-Language is specified, the default is that the content If no Content-Language is specified, the default is that the content
is intended for all language audiences. This might mean that the is intended for all language audiences. This might mean that the
sender does not consider it to be specific to any natural language, sender does not consider it to be specific to any natural language,
skipping to change at page 128, line 20 skipping to change at page 139, line 20
However, just because multiple languages are present within a message However, just because multiple languages are present within a message
body does not mean that it is intended for multiple linguistic body does not mean that it is intended for multiple linguistic
audiences. An example would be a beginner's language primer, such as audiences. An example would be a beginner's language primer, such as
"A First Lesson in Latin," which is clearly intended to be used by an "A First Lesson in Latin," which is clearly intended to be used by an
English-literate audience. In this case, the Content-Language would English-literate audience. In this case, the Content-Language would
properly only include "en". properly only include "en".
Content-Language MAY be applied to any media type -- it is not Content-Language MAY be applied to any media type -- it is not
limited to textual documents. limited to textual documents.
16.16. Content-Length 18.16. Content-Length
The Content-Length general-header field contains the length of the The Content-Length general-header field contains the length of the
message body of the RTSP message (i.e. after the double CRLF message body of the RTSP message (i.e. after the double CRLF
following the last header). Unlike HTTP, it MUST be included in all following the last header). Unlike HTTP, it MUST be included in all
messages that carry a message body beyond the header portion of the messages that carry a message body beyond the header portion of the
RTSP message. If it is missing, a default value of zero is assumed. RTSP message. If it is missing, a default value of zero is assumed.
Any Content-Length greater than or equal to zero is a valid value. Any Content-Length greater than or equal to zero is a valid value.
16.17. Content-Location 18.17. Content-Location
The Content-Location header field MAY be used to supply the resource The Content-Location header field MAY be used to supply the resource
location for the message body enclosed in the message when that body location for the message body enclosed in the message when that body
is accessible from a location separate from the requested resource's is accessible from a location separate from the requested resource's
URI. A server SHOULD provide a Content-Location for the variant URI. A server SHOULD provide a Content-Location for the variant
corresponding to the response message body; especially in the case corresponding to the response message body; especially in the case
where a resource has multiple variants associated with it, and those where a resource has multiple variants associated with it, and those
entities actually have separate locations by which they might be entities actually have separate locations by which they might be
individually accessed, the server SHOULD provide a Content-Location individually accessed, the server SHOULD provide a Content-Location
for the particular variant which is returned. for the particular variant which is returned.
As example, if an RTSP client performs a DESCRIBE request on a given
resource, e.g., "rtsp://a.example.com/movie/Plan9FromOuterSpace",
then the server may use additional information, such as the User-
Agent header, to determine the capabilities of the agent. The server
will then return a media description tailored to that class of RTSP
agents. To indicate which specific description the agent receives
the resource identifier
("rtsp://a.example.com/movie/Plan9FromOuterSpace/FullHD.sdp") is
provided in Content-Location, while the description is still a valid
response for the generic resource identifier. Thus enabling both
debugging and cache operation as discussed below.
The Content-Location value is not a replacement for the original The Content-Location value is not a replacement for the original
requested URI; it is only a statement of the location of the resource requested URI; it is only a statement of the location of the resource
corresponding to this particular variant at the time of the request. corresponding to this particular variant at the time of the request.
Future requests MAY specify the Content-Location URI as the request Future requests MAY specify the Content-Location URI as the request
URI if the desire is to identify the source of that particular URI if the desire is to identify the source of that particular
variant. This is useful if the RTSP agent desires to verify if the variant. This is useful if the RTSP agent desires to verify if the
resource variant is current through a conditional request. resource variant is current through a conditional request.
A cache cannot assume that a message body with a Content-Location A cache cannot assume that a message body with a Content-Location
different from the URI used to retrieve it can be used to respond to different from the URI used to retrieve it can be used to respond to
skipping to change at page 129, line 27 skipping to change at page 140, line 39
it is important that the different versions have different MTags, it is important that the different versions have different MTags,
even if provided under different Content-Location URIs. This as they even if provided under different Content-Location URIs. This as they
have still been provided under the same request URI. have still been provided under the same request URI.
Note also, as in most cases the URI used in the DESCRIBE and the Note also, as in most cases the URI used in the DESCRIBE and the
SETUP requests are different, the URI provided in a DESCRIBE Content- SETUP requests are different, the URI provided in a DESCRIBE Content-
Location response can't directly be used in a SETUP request. Instead Location response can't directly be used in a SETUP request. Instead
the extra step of resolving URIs combined with the media descriptions the extra step of resolving URIs combined with the media descriptions
indication, like with SDP's a=control attribute. indication, like with SDP's a=control attribute.
16.18. Content-Type 18.18. Content-Type
The Content-Type header indicates the media type of the message body The Content-Type header indicates the media type of the message body
sent to the recipient. Note that the content types suitable for RTSP sent to the recipient. Note that the content types suitable for RTSP
are likely to be restricted in practice to presentation descriptions are likely to be restricted in practice to presentation descriptions
and parameter-value types. and parameter-value types.
16.19. CSeq 18.19. CSeq
The CSeq general-header field specifies the sequence number for an The CSeq general-header field specifies the sequence number for an
RTSP request-response pair. This field MUST be present in all RTSP request-response pair. This field MUST be present in all
requests and responses. For every RTSP request containing the given requests and responses. For every RTSP request containing the given
sequence number, the corresponding response will have the same sequence number, the corresponding response will have the same
number. Any retransmitted request MUST contain the same sequence number. Any retransmitted request MUST contain the same sequence
number as the original (i.e., the sequence number is not incremented number as the original (i.e., the sequence number is not incremented
for retransmissions of the same request). For each new RTSP request for retransmissions of the same request). For each new RTSP request
the CSeq value MUST be incremented by one. The initial sequence the CSeq value MUST be incremented by one. The initial sequence
number MAY be any number, however, it is RECOMMENDED to start at 0. number MAY be any number, however, it is RECOMMENDED to start at 0.
skipping to change at page 130, line 14 skipping to change at page 141, line 25
have to ensure that the requests sent towards a particular server have to ensure that the requests sent towards a particular server
have a joint sequence number space, i.e., they will regularly need to have a joint sequence number space, i.e., they will regularly need to
renumber the CSeq header field in requests (from proxy to server) and renumber the CSeq header field in requests (from proxy to server) and
responses (from server to proxy) to fulfill the rules for the header. responses (from server to proxy) to fulfill the rules for the header.
The proxy MUST increase the CSeq by one for each request it The proxy MUST increase the CSeq by one for each request it
transmits, without regard of different sessions. transmits, without regard of different sessions.
Example: Example:
CSeq: 239 CSeq: 239
16.20. Date 18.20. Date
The Date header field represents the date and time at which the The Date header field represents the date and time at which the
message was originated. The inclusion of the Date header in RTSP message was originated. The inclusion of the Date header in RTSP
message follows these rules: message follows these rules:
o An RTSP message, sent either by the client or the server, o An RTSP message, sent either by the client or the server,
containing a body MUST include a Date header, if the sending host containing a body MUST include a Date header, if the sending host
has a clock; has a clock;
o Clients and servers are RECOMMENDED to include a Date header in o Clients and servers are RECOMMENDED to include a Date header in
skipping to change at page 131, line 7 skipping to change at page 142, line 18
The RTSP-date sent in a Date header SHOULD NOT represent a date and The RTSP-date sent in a Date header SHOULD NOT represent a date and
time subsequent to the generation of the message. It SHOULD time subsequent to the generation of the message. It SHOULD
represent the best available approximation of the date and time of represent the best available approximation of the date and time of
message generation, unless the implementation has no means of message generation, unless the implementation has no means of
generating a reasonably accurate date and time. In theory, the date generating a reasonably accurate date and time. In theory, the date
ought to represent the moment just before the message body is ought to represent the moment just before the message body is
generated. In practice, the date can be generated at any time during generated. In practice, the date can be generated at any time during
the message origination without affecting its semantic value. the message origination without affecting its semantic value.
16.21. Expires 18.21. Expires
The Expires message-header field gives a date and time after which The Expires message-header field gives a date and time after which
the description or media-stream should be considered stale. The the description or media-stream should be considered stale. The
interpretation depends on the method: interpretation depends on the method:
DESCRIBE response: The Expires header indicates a date and time DESCRIBE response: The Expires header indicates a date and time
after which the presentation description (body) SHOULD be after which the presentation description (body) SHOULD be
considered stale. considered stale.
SETUP response: The Expires header indicate a date and time after SETUP response: The Expires header indicate a date and time after
which the media stream SHOULD be considered stale. which the media stream SHOULD be considered stale.
A stale cache entry may not normally be returned by a cache (either a A stale cache entry may not normally be returned by a cache (either a
proxy cache or an user agent cache) unless it is first validated with proxy cache or an user agent cache) unless it is first validated with
the origin server (or with an intermediate cache that has a fresh the origin server (or with an intermediate cache that has a fresh
copy of the message body). See Section 18 for further discussion of copy of the message body). See Section 16 for further discussion of
the expiration model. the expiration model.
The presence of an Expires field does not imply that the original The presence of an Expires field does not imply that the original
resource will change or cease to exist at, before, or after that resource will change or cease to exist at, before, or after that
time. time.
The format is an absolute date and time as defined by RTSP-date. An The format is an absolute date and time as defined by RTSP-date. An
example of its use is example of its use is
Expires: Thu, 01 Dec 1994 16:00:00 GMT Expires: Thu, 01 Dec 1994 16:00:00 GMT
skipping to change at page 131, line 45 skipping to change at page 143, line 8
especially including the value "0", as having occurred in the past especially including the value "0", as having occurred in the past
(i.e., already expired). (i.e., already expired).
To mark a response as "already expired," an origin server should use To mark a response as "already expired," an origin server should use
an Expires date that is equal to the Date header value. To mark a an Expires date that is equal to the Date header value. To mark a
response as "never expires," an origin server SHOULD use an Expires response as "never expires," an origin server SHOULD use an Expires
date approximately one year from the time the response is sent. date approximately one year from the time the response is sent.
RTSP/2.0 servers SHOULD NOT send Expires dates more than one year in RTSP/2.0 servers SHOULD NOT send Expires dates more than one year in
the future. the future.
16.22. From 18.22. From
The From request-header field, if given, SHOULD contain an Internet The From request-header field, if given, SHOULD contain an Internet
e-mail address for the human user who controls the requesting user e-mail address for the human user who controls the requesting user
agent. The address SHOULD be machine-usable, as defined by "mailbox" agent. The address SHOULD be machine-usable, as defined by "mailbox"
in [RFC1123]. in [RFC1123].
This header field MAY be used for logging purposes and as a means for This header field MAY be used for logging purposes and as a means for
identifying the source of invalid or unwanted requests. It SHOULD identifying the source of invalid or unwanted requests. It SHOULD
NOT be used as an insecure form of access protection. The NOT be used as an insecure form of access protection. The
interpretation of this field is that the request is being performed interpretation of this field is that the request is being performed
skipping to change at page 132, line 25 skipping to change at page 143, line 35
Internet host which issued the request. For example, when a request Internet host which issued the request. For example, when a request
is passed through a proxy the original issuer's address SHOULD be is passed through a proxy the original issuer's address SHOULD be
used. used.
The client SHOULD NOT send the From header field without the user's The client SHOULD NOT send the From header field without the user's
approval, as it might conflict with the user's privacy interests or approval, as it might conflict with the user's privacy interests or
their site's security policy. It is strongly recommended that the their site's security policy. It is strongly recommended that the
user be able to disable, enable, and modify the value of this field user be able to disable, enable, and modify the value of this field
at any time prior to a request. at any time prior to a request.
16.23. If-Match 18.23. If-Match
The If-Match request-header field is especially useful for ensuring The If-Match request-header field is especially useful for ensuring
the integrity of the presentation description, independent of how the the integrity of the presentation description, independent of how the
presentation description was received. The presentation description presentation description was received. The presentation description
can be fetched via means external to RTSP (such as HTTP) or via the can be fetched via means external to RTSP (such as HTTP) or via the
DESCRIBE message. In the case of retrieving the presentation DESCRIBE message. In the case of retrieving the presentation
description via RTSP, the server implementation is guaranteeing the description via RTSP, the server implementation is guaranteeing the
integrity of the description between the time of the DESCRIBE message integrity of the description between the time of the DESCRIBE message
and the SETUP message. By including the MTag given in or with the and the SETUP message. By including the MTag given in or with the
session description in an If-Match header part of the SETUP request, session description in an If-Match header part of the SETUP request,
the client ensures that resources set up are matching the the client ensures that resources set up are matching the
description. A SETUP request with the If-Match header for which the description. A SETUP request with the If-Match header for which the
MTag validation check fails, MUST response using 412 (Precondition MTag validation check fails, MUST response using 412 (Precondition
Failed). Failed).
This validation check is also very useful if a session has been This validation check is also very useful if a session has been
redirected from one server to another. redirected from one server to another.
16.24. If-Modified-Since 18.24. If-Modified-Since
The If-Modified-Since request-header field is used with the DESCRIBE The If-Modified-Since request-header field is used with the DESCRIBE
and SETUP methods to make them conditional. If the requested variant and SETUP methods to make them conditional. If the requested variant
has not been modified since the time specified in this field, a has not been modified since the time specified in this field, a
description will not be returned from the server (DESCRIBE) or a description will not be returned from the server (DESCRIBE) or a
stream will not be set up (SETUP). Instead, a 304 (Not Modified) stream will not be set up (SETUP). Instead, a 304 (Not Modified)
response MUST be returned without any message-body. response MUST be returned without any message-body.
An example of the field is: An example of the field is:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
16.25. If-None-Match 18.25. If-None-Match
This request header can be used with one or several message body tags This request header can be used with one or several message body tags
to make DESCRIBE requests conditional. A client that has one or more to make DESCRIBE requests conditional. A client that has one or more
message bodies previously obtained from the resource, can verify that message bodies previously obtained from the resource, can verify that
none of those entities is current by including a list of their none of those entities is current by including a list of their
associated message body tags in the If-None-Match header field. The associated message body tags in the If-None-Match header field. The
purpose of this feature is to allow efficient updates of cached purpose of this feature is to allow efficient updates of cached
information with a minimum amount of transaction overhead. As a information with a minimum amount of transaction overhead. As a
special case, the value "*" matches any current entity of the special case, the value "*" matches any current entity of the
resource. resource.
skipping to change at page 133, line 33 skipping to change at page 144, line 43
resource, or if "*" is given and any current entity exists for that resource, or if "*" is given and any current entity exists for that
resource, then the server MUST NOT perform the requested method, resource, then the server MUST NOT perform the requested method,
unless required to do so because the resource's modification date unless required to do so because the resource's modification date
fails to match that supplied in an If-Modified-Since header field in fails to match that supplied in an If-Modified-Since header field in
the request. Instead, if the request method was DESCRIBE, the server the request. Instead, if the request method was DESCRIBE, the server
SHOULD respond with a 304 (Not Modified) response, including the SHOULD respond with a 304 (Not Modified) response, including the
cache-related header fields (particularly MTag) of one of the message cache-related header fields (particularly MTag) of one of the message
bodies that matched. For all other request methods, the server MUST bodies that matched. For all other request methods, the server MUST
respond with a status of 412 (Precondition Failed). respond with a status of 412 (Precondition Failed).
See Section 18.1.3 for rules on how to determine if two message body See Section 16.1.3 for rules on how to determine if two message body
tags match. tags match.
If none of the message body tags match, then the server MAY perform If none of the message body tags match, then the server MAY perform
the requested method as if the If-None-Match header field did not the requested method as if the If-None-Match header field did not
exist, but MUST also ignore any If-Modified-Since header field(s) in exist, but MUST also ignore any If-Modified-Since header field(s) in
the request. That is, if no message body tags match, then the server the request. That is, if no message body tags match, then the server
MUST NOT return a 304 (Not Modified) response. MUST NOT return a 304 (Not Modified) response.
If the request would, without the If-None-Match header field, result If the request would, without the If-None-Match header field, result
in anything other than a 2xx or 304 status, then the If-None-Match in anything other than a 2xx or 304 status, then the If-None-Match
header MUST be ignored. (See Section 18.1.4 for a discussion of header MUST be ignored. (See Section 16.1.4 for a discussion of
server behavior when both If-Modified-Since and If-None-Match appear server behavior when both If-Modified-Since and If-None-Match appear
in the same request.) in the same request.)
The result of a request having both an If-None-Match header field and The result of a request having both an If-None-Match header field and
an If-Match header field is unspecified and MUST be considered an an If-Match header field is unspecified and MUST be considered an
illegal request. illegal request.
16.26. Last-Modified 18.26. Last-Modified
The Last-Modified message-header field indicates the date and time at The Last-Modified message-header field indicates the date and time at
which the origin server believes the presentation description or which the origin server believes the presentation description or
media stream was last modified. For the method DESCRIBE, the header media stream was last modified. For the method DESCRIBE, the header
field indicates the last modification date and time of the field indicates the last modification date and time of the
description, for SETUP that of the media stream. description, for SETUP that of the media stream.
An origin server MUST NOT send a Last-Modified date which is later An origin server MUST NOT send a Last-Modified date which is later
than the server's time of message origination. In such cases, where than the server's time of message origination. In such cases, where
the resource's last modification would indicate some time in the the resource's last modification would indicate some time in the
skipping to change at page 134, line 27 skipping to change at page 145, line 37
origination date. origination date.
An origin server SHOULD obtain the Last-Modified value of the message An origin server SHOULD obtain the Last-Modified value of the message
body as close as possible to the time that it generates the Date body as close as possible to the time that it generates the Date
value of its response. This allows a recipient to make an accurate value of its response. This allows a recipient to make an accurate
assessment of the message body's modification time, especially if the assessment of the message body's modification time, especially if the
message body changes near the time that the response is generated. message body changes near the time that the response is generated.
RTSP servers SHOULD send Last-Modified whenever feasible. RTSP servers SHOULD send Last-Modified whenever feasible.
16.27. Location 18.27. Location
The Location response-header field is used to redirect the recipient The Location response-header field is used to redirect the recipient
to a location other than the Request-URI for completion of the to a location other than the Request-URI for completion of the
request or identification of a new resource. For 3xx responses, the request or identification of a new resource. For 3xx responses, the
location SHOULD indicate the server's preferred URI for automatic location SHOULD indicate the server's preferred URI for automatic
redirection to the resource. The field value consists of a single redirection to the resource. The field value consists of a single
absolute URI. absolute URI.
Note: The Content-Location header field (Section 16.17) differs from Note: The Content-Location header field (Section 18.17) differs from
Location in that the Content-Location identifies the original Location in that the Content-Location identifies the original
location of the message body enclosed in the request. It is location of the message body enclosed in the request. It is
therefore possible for a response to contain header fields for both therefore possible for a response to contain header fields for both
Location and Content-Location. Also, see Section 18.2 for cache Location and Content-Location. Also, see Section 16.2 for cache
requirements of some methods. requirements of some methods.
16.28. Media-Properties 18.28. Media-Properties
This general header is used in SETUP response or PLAY_NOTIFY requests This general header is used in SETUP response or PLAY_NOTIFY requests
to indicate the media's properties that currently are applicable to to indicate the media's properties that currently are applicable to
the RTSP session. PLAY_NOTIFY MAY be used to modify these properties the RTSP session. PLAY_NOTIFY MAY be used to modify these properties
at any point. However, the client SHOULD have received the update at any point. However, the client SHOULD have received the update
prior to any action related to the new media properties take effect. prior to any action related to the new media properties take effect.
For aggregated sessions, the Media-Properties header will be returned For aggregated sessions, the Media-Properties header will be returned
in each SETUP response. The header received in the latest response in each SETUP response. The header received in the latest response
is the one that applies on the whole session from this point until is the one that applies on the whole session from this point until
any future update. The header MAY be included without value in any future update. The header MAY be included without value in
skipping to change at page 136, line 28 skipping to change at page 147, line 39
is a valid value as this indicates that no data is retained in is a valid value as this indicates that no data is retained in
a time-progressing session. a time-progressing session.
Supported Scale: Supported Scale:
Scales: A quoted comma separated list of one or more decimal Scales: A quoted comma separated list of one or more decimal
values or ranges of scale values supported by the content in values or ranges of scale values supported by the content in
arbitrary order. A range has a start and stop value separated arbitrary order. A range has a start and stop value separated
by a colon. A range indicates that the content supports fine by a colon. A range indicates that the content supports fine
grained selection of scale values. Fine grained allows for grained selection of scale values. Fine grained allows for
steps at least as small as one tenth of a scale value. steps at least as small as one tenth of a scale value. A
Negative values are supported. The value 0 has no meaning and content is considered to support fine grained selection when
MUST NOT be used. the server in response to a given scale value can produce
content with an actual scale that is less than 1 tenth of scale
unit, i.e., 0.1, from the requested value. Negative values are
supported. The value 0 has no meaning and MUST NOT be used.
Examples of this header for on-demand content and a live stream Examples of this header for on-demand content and a live stream
without recording are: without recording are:
On-demand: On-demand:
Media-Properties: Random-Access=2.5s, Unlimited, Immutable, Media-Properties: Random-Access=2.5s, Unlimited, Immutable,
Scales="-20, -10, -4, 0.5:1.5, 4, 8, 10, 15, 20" Scales="-20, -10, -4, 0.5:1.5, 4, 8, 10, 15, 20"
Live stream without recording/timeshifting: Live stream without recording/timeshifting:
Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0 Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0
16.29. Media-Range 18.29. Media-Range
The Media-Range general header is used to give the range of the media The Media-Range general header is used to give the range of the media
at the time of sending the RTSP message. This header MUST be at the time of sending the RTSP message. This header MUST be
included in SETUP response, and PLAY and PAUSE response for media included in SETUP response, and PLAY and PAUSE response for media
that are Time-Progressing, and PLAY and PAUSE response after any that are Time-Progressing, and PLAY and PAUSE response after any
change for media that are Dynamic, and in PLAY_NOTIFY request that change for media that are Dynamic, and in PLAY_NOTIFY request that
are sent due to Media-Property-Update. Media-Range header without are sent due to Media-Property-Update. Media-Range header without
any range specifications MAY be included in GET_PARAMETER requests to any range specifications MAY be included in GET_PARAMETER requests to
the server to request the current range. The server MUST in this the server to request the current range. The server MUST in this
case include the current range at the time of sending the response. case include the current range at the time of sending the response.
The header MUST include range specifications for all time formats The header MUST include range specifications for all time formats
supported for the media, as indicated in Accept-Ranges header supported for the media, as indicated in Accept-Ranges header
(Section 16.5) when setting up the media. The server MAY include (Section 18.5) when setting up the media. The server MAY include
more than one range specification of any given time format to more than one range specification of any given time format to
indicate media that has non-continuous range. indicate media that has non-continuous range.
For media that has the Time-Progressing property, the Media-Range For media that has the Time-Progressing property, the Media-Range
values will only be valid for the particular point in time when it values will only be valid for the particular point in time when it
was issued. As wallclock progresses so will also the media range. was issued. As wallclock progresses so will also the media range.
However, it shall be assumed that media time progresses in direct However, it shall be assumed that media time progresses in direct
relationship to wallclock time (with the exception of clock skew) so relationship to wallclock time (with the exception of clock skew) so
that a reasonably accurate estimation of the media range can be that a reasonably accurate estimation of the media range can be
calculated. calculated.
16.30. MTag 18.30. MTag
The MTag response header MAY be included in DESCRIBE, GET_PARAMETER The MTag response header MAY be included in DESCRIBE, GET_PARAMETER
or SETUP responses. The message body tags (Section 4.8) returned in or SETUP responses. The message body tags (Section 4.8) returned in
a DESCRIBE response, and the one in SETUP refers to the presentation, a DESCRIBE response, and the one in SETUP refers to the presentation,
i.e. both the returned session description and the media stream. i.e. both the returned session description and the media stream.
This allows for verification that one has the right session This allows for verification that one has the right session
description to a media resource at the time of the SETUP request. description to a media resource at the time of the SETUP request.
However, it has the disadvantage that a change in any of the parts However, it has the disadvantage that a change in any of the parts
results in invalidation of all the parts. results in invalidation of all the parts.
If the MTag is provided both inside the message body, e.g. within the If the MTag is provided both inside the message body, e.g. within the
"a=mtag" attribute in SDP, and in the response message, then both "a=mtag" attribute in SDP, and in the response message, then both
tags MUST be identical. It is RECOMMENDED that the MTag is primarily tags MUST be identical. It is RECOMMENDED that the MTag is primarily
given in the RTSP response message, to ensure that caches can use the given in the RTSP response message, to ensure that caches can use the
MTag without requiring content inspection. However, for session MTag without requiring content inspection. However, for session
descriptions that are distributed outside of RTSP, for example using descriptions that are distributed outside of RTSP, for example using
HTTP, etc. it will be necessary to include the message body tag in HTTP, etc. it will be necessary to include the message body tag in
the session description as specified in Appendix D.1.9. the session description as specified in Appendix D.1.9.
SETUP and DESCRIBE requests can be made conditional upon the MTag SETUP and DESCRIBE requests can be made conditional upon the MTag
using the headers If-Match (Section 16.23) and If-None-Match ( using the headers If-Match (Section 18.23) and If-None-Match (
Section 16.25). Section 18.25).
16.31. Notify-Reason 18.31. Notify-Reason
The Notify Reason header is solely used in the PLAY_NOTIFY method. The Notify Reason header is solely used in the PLAY_NOTIFY method.
It indicates the reason why the server has sent the asynchronous It indicates the reason why the server has sent the asynchronous
PLAY_NOTIFY request (see Section 13.5). PLAY_NOTIFY request (see Section 13.5).
16.32. Pipelined-Requests 18.32. Pipelined-Requests
The Pipelined-Requests general header is used to indicate that a The Pipelined-Requests general header is used to indicate that a
request is to be executed in the context created by a previous request is to be executed in the context created by a previous
request(s). The primary usage of this header is to allow pipelining request(s). The primary usage of this header is to allow pipelining
of SETUP requests so that any additional SETUP request after the of SETUP requests so that any additional SETUP request after the
first one does not need to wait for the session ID to be sent back to first one does not need to wait for the session ID to be sent back to
the requesting agent. The header contains a unique identifier that the requesting agent. The header contains a unique identifier that
is scoped by the persistent connection used to send the requests. is scoped by the persistent connection used to send the requests.
Upon receiving a request with the Pipelined-Requests the responding Upon receiving a request with the Pipelined-Requests the responding
skipping to change at page 139, line 5 skipping to change at page 150, line 22
connection is defined as such transport context. A server MUST connection is defined as such transport context. A server MUST
delete the Pipelined-Requests identifier and its binding to a session delete the Pipelined-Requests identifier and its binding to a session
upon the termination of that session. Despite the previous mandate, upon the termination of that session. Despite the previous mandate,
RTSP agents are RECOMMENDED to not reuse identifiers to allow for RTSP agents are RECOMMENDED to not reuse identifiers to allow for
better error handling and logging. better error handling and logging.
RTSP Proxies may need to translate Pipelined-Requests identifier RTSP Proxies may need to translate Pipelined-Requests identifier
values from incoming request to outgoing to allow for aggregation of values from incoming request to outgoing to allow for aggregation of
requests onto a persistent connection. requests onto a persistent connection.
16.33. Proxy-Authenticate 18.33. Proxy-Authenticate
The Proxy-Authenticate response-header field MUST be included as part The Proxy-Authenticate response-header field MUST be included as part
of a 407 (Proxy Authentication Required) response. The field value of a 407 (Proxy Authentication Required) response. The field value
consists of a challenge that indicates the authentication scheme and consists of a challenge that indicates the authentication scheme and
parameters applicable to the proxy for this Request-URI. parameters applicable to the proxy for this Request-URI.
The HTTP access authentication process is described in [RFC2617]. The HTTP access authentication process is described in [RFC2617].
Unlike WWW-Authenticate, the Proxy-Authenticate header field applies Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
only to the current connection and SHOULD NOT be passed on to only to the current connection and SHOULD NOT be passed on to
downstream agents. However, an intermediate proxy might need to downstream agents. However, an intermediate proxy might need to
obtain its own credentials by requesting them from the downstream obtain its own credentials by requesting them from the downstream
agent, which in some circumstances will appear as if the proxy is agent, which in some circumstances will appear as if the proxy is
forwarding the Proxy-Authenticate header field. forwarding the Proxy-Authenticate header field.
16.34. Proxy-Authorization 18.34. Proxy-Authorization
The Proxy-Authorization request-header field allows the client to The Proxy-Authorization request-header field allows the client to
identify itself (or its user) to a proxy which requires identify itself (or its user) to a proxy which requires
authentication. The Proxy-Authorization field value consists of authentication. The Proxy-Authorization field value consists of
credentials containing the authentication information of the user credentials containing the authentication information of the user
agent for the proxy and/or realm of the resource being requested. agent for the proxy and/or realm of the resource being requested.
The HTTP access authentication process is described in [RFC2617]. The HTTP access authentication process is described in [RFC2617].
Unlike Authorization, the Proxy-Authorization header field applies Unlike Authorization, the Proxy-Authorization header field applies
only to the next outbound proxy that demanded authentication using only to the next outbound proxy that demanded authentication using
the Proxy-Authenticate field. When multiple proxies are used in a the Proxy-Authenticate field. When multiple proxies are used in a
chain, the Proxy-Authorization header field is consumed by the first chain, the Proxy-Authorization header field is consumed by the first
outbound proxy that was expecting to receive credentials. A proxy outbound proxy that was expecting to receive credentials. A proxy
MAY relay the credentials from the client request to the next proxy MAY relay the credentials from the client request to the next proxy
if that is the mechanism by which the proxies cooperatively if that is the mechanism by which the proxies cooperatively
authenticate a given request. authenticate a given request.
16.35. Proxy-Require 18.35. Proxy-Require
The Proxy-Require request-header field is used to indicate proxy- The Proxy-Require request-header field is used to indicate proxy-
sensitive features that MUST be supported by the proxy. Any Proxy- sensitive features that MUST be supported by the proxy. Any Proxy-
Require header features that are not supported by the proxy MUST be Require header features that are not supported by the proxy MUST be
negatively acknowledged by the proxy to the client using the negatively acknowledged by the proxy to the client using the
Unsupported header. The proxy MUST use the 551 (Option Not Unsupported header. The proxy MUST use the 551 (Option Not
Supported) status code in the response. Any feature-tag included in Supported) status code in the response. Any feature-tag included in
the Proxy-Require does not apply to the end-point (server or client). the Proxy-Require does not apply to the end-point (server or client).
To ensure that a feature is supported by both proxies and servers the To ensure that a feature is supported by both proxies and servers the
tag needs to be included in also a Require header. tag needs to be included in also a Require header.
See Section 16.41 for more details on the mechanics of this message See Section 18.41 for more details on the mechanics of this message
and a usage example. See discussion in the proxies section and a usage example. See discussion in the proxies section
(Section 17.1) about when to consider that a feature requires proxy (Section 15.1) about when to consider that a feature requires proxy
support. support.
Example of use: Example of use:
Proxy-Require: play.basic Proxy-Require: play.basic
16.36. Proxy-Supported 18.36. Proxy-Supported
The Proxy-Supported header field enumerates all the extensions The Proxy-Supported header field enumerates all the extensions
supported by the proxy using feature-tags. The header carries the supported by the proxy using feature-tags. The header carries the
intersection of extensions supported by the forwarding proxies. The intersection of extensions supported by the forwarding proxies. The
Proxy-Supported header MAY be included in any request by a proxy. It Proxy-Supported header MAY be included in any request by a proxy. It
MUST be added by any proxy if the Supported header is present in a MUST be added by any proxy if the Supported header is present in a
request. When present in a request, the receiver MUST in the request. When present in a request, the receiver MUST in the
response copy the received Proxy-Supported header. response copy the received Proxy-Supported header.
The Proxy-Supported header field contains a list of feature-tags The Proxy-Supported header field contains a list of feature-tags
skipping to change at page 141, line 5 skipping to change at page 152, line 25
Supported: foo, bar, blech Supported: foo, bar, blech
Proxy-Supported: proxy-foo, proxy-blech Proxy-Supported: proxy-foo, proxy-blech
Via: 2.0 pro.example.com, 2.0 prox2.example.com Via: 2.0 pro.example.com, 2.0 prox2.example.com
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
Supported: foo, bar, baz Supported: foo, bar, baz
Proxy-Supported: proxy-foo, proxy-blech Proxy-Supported: proxy-foo, proxy-blech
Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
Via: 2.0 pro.example.com, 2.0 prox2.example.com Via: 2.0 pro.example.com, 2.0 prox2.example.com
16.37. Public 18.37. Public
The Public response header field lists the set of methods supported The Public response header field lists the set of methods supported
by the response sender. This header applies to the general by the response sender. This header applies to the general
capabilities of the sender and its only purpose is to indicate the capabilities of the sender and its only purpose is to indicate the
sender's capabilities to the recipient. The methods listed may or sender's capabilities to the recipient. The methods listed may or
may not be applicable to the Request-URI; the Allow header field may not be applicable to the Request-URI; the Allow header field
(Section 16.6) MAY be used to indicate methods allowed for a (Section 18.6) MAY be used to indicate methods allowed for a
particular URI. particular URI.
Example of use: Example of use:
Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
In the event that there are proxies between the sender and the In the event that there are proxies between the sender and the
recipient of a response, each intervening proxy MUST modify the recipient of a response, each intervening proxy MUST modify the
Public header field to remove any methods that are not supported via Public header field to remove any methods that are not supported via
that proxy. The resulting Public header field will contain an that proxy. The resulting Public header field will contain an
intersection of the sender's methods and the methods allowed through intersection of the sender's methods and the methods allowed through
by the intervening proxies. by the intervening proxies.
In general, proxies should allow all methods to transparently pass In general, proxies should allow all methods to transparently pass
through from the sending RTSP agent to the receiving RTSP agent, through from the sending RTSP agent to the receiving RTSP agent,
but there may be cases where this is not desirable for a given but there may be cases where this is not desirable for a given
proxy. Modification of the Public response header field by the proxy. Modification of the Public response header field by the
intervening proxies ensures that the request sender gets an intervening proxies ensures that the request sender gets an
accurate response indicating the methods that can be used on the accurate response indicating the methods that can be used on the
target agent via the proxy chain. target agent via the proxy chain.
16.38. Range 18.38. Range
The Range header specifies a time range in PLAY (Section 13.4), PAUSE The Range header specifies a time range in PLAY (Section 13.4), PAUSE
(Section 13.6), SETUP (Section 13.3), REDIRECT (Section 13.10), and (Section 13.6), SETUP (Section 13.3), REDIRECT (Section 13.10), and
PLAY_NOTIFY (Section 13.5) requests and responses. It MAY be PLAY_NOTIFY (Section 13.5) requests and responses. It MAY be
included in GET_PARAMETER requests from the client to the server with included in GET_PARAMETER requests from the client to the server with
only a Range format and no value to request the current media only a Range format and no value to request the current media
position, whether the session is in Play or Ready state in the position, whether the session is in Play or Ready state in the
included format. The server SHALL, if supporting the range format, included format. The server SHALL, if supporting the range format,
respond with the current playing point or pause point as the start of respond with the current playing point or pause point as the start of
the range. If an explicit stop point was used in the previous PLAY the range. If an explicit stop point was used in the previous PLAY
skipping to change at page 142, line 50 skipping to change at page 154, line 22
time) the pause point may be 2 min into the session while now time) the pause point may be 2 min into the session while now
could be 1 hour into the session. could be 1 hour into the session.
By default, range intervals increase, where the second point is By default, range intervals increase, where the second point is
larger than the first point. larger than the first point.
Example: Example:
Range: npt=10-15 Range: npt=10-15
However, range intervals can also decrease if the Scale header (see However, range intervals can also decrease if the Scale header (see
Section 16.44) indicates a negative scale value. For example, this Section 18.44) indicates a negative scale value. For example, this
would be the case when a playback in reverse is desired. would be the case when a playback in reverse is desired.
Example: Example:
Scale: -1 Scale: -1
Range: npt=15-10 Range: npt=15-10
Decreasing ranges are still half open intervals as described above. Decreasing ranges are still half open intervals as described above.
Thus, for range A-B, A is closed and B is open. In the above Thus, for range A-B, A is closed and B is open. In the above
example, 15 is closed and 10 is open. An exception to this rule is example, 15 is closed and 10 is open. An exception to this rule is
the case when B=0 in a decreasing range. In this case, the range is the case when B=0 in a decreasing range. In this case, the range is
skipping to change at page 143, line 26 skipping to change at page 154, line 46
Example: Example:
Scale: -1 Scale: -1
Range: npt=15-0 Range: npt=15-0
In this range both 15 and 0 are closed. In this range both 15 and 0 are closed.
A decreasing range interval without a corresponding negative Scale A decreasing range interval without a corresponding negative Scale
header is not valid. header is not valid.
16.39. Referrer 18.39. Referrer
The Referrer request-header field allows the client to specify, for The Referrer request-header field allows the client to specify, for
the server's benefit, the address (URI) of the resource from which the server's benefit, the address (URI) of the resource from which
the Request-URI was obtained. The URI refers to that of the the Request-URI was obtained. The URI refers to that of the
presentation description, typically retrieved via HTTP. The Referrer presentation description, typically retrieved via HTTP. The Referrer
request-header allows a server to generate lists of back-links to request-header allows a server to generate lists of back-links to
resources for interest, logging, optimized caching, etc. It also resources for interest, logging, optimized caching, etc. It also
allows obsolete or mistyped links to be traced for maintenance. The allows obsolete or mistyped links to be traced for maintenance. The
Referrer field MUST NOT be sent if the Request-URI was obtained from Referrer field MUST NOT be sent if the Request-URI was obtained from
a source that does not have its own URI, such as input from the user a source that does not have its own URI, such as input from the user
skipping to change at page 144, line 5 skipping to change at page 155, line 25
reveal an otherwise private information source, it is strongly reveal an otherwise private information source, it is strongly
recommended that the user be able to select whether or not the recommended that the user be able to select whether or not the
Referrer field is sent. For example, a streaming client could have a Referrer field is sent. For example, a streaming client could have a
toggle switch for openly/anonymously, which would respectively toggle switch for openly/anonymously, which would respectively
enable/disable the sending of Referrer and From information. enable/disable the sending of Referrer and From information.
Clients SHOULD NOT include a Referrer header field in a (non-secure) Clients SHOULD NOT include a Referrer header field in a (non-secure)
RTSP request if the referring page was transferred with a secure RTSP request if the referring page was transferred with a secure
protocol. protocol.
16.40. Request-Status 18.40. Request-Status
This request header is used to indicate the end result for requests This request header is used to indicate the end result for requests
that takes time to complete, such a PLAY (Section 13.4). It is sent that takes time to complete, such a PLAY (Section 13.4). It is sent
in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report
how the PLAY request concluded, either in success or in failure. The how the PLAY request concluded, either in success or in failure. The
header carries a reference to the request it reports on using the header carries a reference to the request it reports on using the
CSeq number for the session indicated by the Session header in the CSeq number for the session indicated by the Session header in the
request. It provides both a numerical status code (according to request. It provides both a numerical status code (according to
Section 8.1.1) and a human readable reason phrase. Section 8.1.1) and a human readable reason phrase.
Example: Example:
Request-Status: cseq=63 status=500 reason="Media data unavailable" Request-Status: cseq=63 status=500 reason="Media data unavailable"
16.41. Require 18.41. Require
The Require request-header field is used by clients or servers to The Require request-header field is used by clients or servers to
ensure that the other end-point supports features that are required ensure that the other end-point supports features that are required
in respect to this request. It can also be used to query if the in respect to this request. It can also be used to query if the
other end-point supports certain features, however, the use of the other end-point supports certain features, however, the use of the
Supported (Section 16.49) is much more effective in this purpose. Supported (Section 18.49) is much more effective in this purpose.
The server MUST respond to this header by using the Unsupported The server MUST respond to this header by using the Unsupported
header to negatively acknowledge those feature-tags which are NOT header to negatively acknowledge those feature-tags which are NOT
supported. The response MUST use the error code 551 (Option Not supported. The response MUST use the error code 551 (Option Not
Supported). This header does not apply to proxies, for the same Supported). This header does not apply to proxies, for the same
functionality in respect to proxies see Proxy-Require header functionality in respect to proxies see Proxy-Require header
(Section 16.35) with the exception of media modifying proxies. Media (Section 18.35) with the exception of media modifying proxies. Media
modifying proxies, due to their nature of handling media in a way modifying proxies, due to their nature of handling media in a way
that is very similar to a server, do need to understand also the that is very similar to a server, do need to understand also the
server features to correctly serve the client. server features to correctly serve the client.
This is to make sure that the client-server interaction will This is to make sure that the client-server interaction will
proceed without delay when all features are understood by both proceed without delay when all features are understood by both
sides, and only slow down if features are not understood (as in sides, and only slow down if features are not understood (as in
the example below). For a well-matched client-server pair, the the example below). For a well-matched client-server pair, the
interaction proceeds quickly, saving a round-trip often required interaction proceeds quickly, saving a round-trip often required
by negotiation mechanisms. In addition, it also removes state by negotiation mechanisms. In addition, it also removes state
skipping to change at page 145, line 24 skipping to change at page 156, line 37
In this example, "funky-feature" is the feature-tag which indicates In this example, "funky-feature" is the feature-tag which indicates
to the client that the fictional Funky-Parameter field is required. to the client that the fictional Funky-Parameter field is required.
The relationship between "funky-feature" and Funky-Parameter is not The relationship between "funky-feature" and Funky-Parameter is not
communicated via the RTSP exchange, since that relationship is an communicated via the RTSP exchange, since that relationship is an
immutable property of "funky-feature" and thus should not be immutable property of "funky-feature" and thus should not be
transmitted with every exchange. transmitted with every exchange.
Proxies and other intermediary devices MUST ignore this header. If a Proxies and other intermediary devices MUST ignore this header. If a
particular extension requires that intermediate devices support it, particular extension requires that intermediate devices support it,
the extension should be tagged in the Proxy-Require field instead the extension should be tagged in the Proxy-Require field instead
(see Section 16.35). See discussion in the proxies section (see Section 18.35). See discussion in the proxies section
(Section 17.1) about when to consider that a feature requires proxy (Section 15.1) about when to consider that a feature requires proxy
support. support.
16.42. Retry-After 18.42. Retry-After
The Retry-After response-header field can be used with a 503 (Service The Retry-After response-header field can be used with a 503 (Service
Unavailable) response to indicate how long the service is expected to Unavailable) response to indicate how long the service is expected to
be unavailable to the requesting client. This field MAY also be used be unavailable to the requesting client. This field MAY also be used
with any 3xx (Redirection) response to indicate the minimum time the with any 3xx (Redirection) response to indicate the minimum time the
user-agent is asked to wait before issuing the redirected request. user-agent is asked to wait before issuing the redirected request.
The value of this field can be either an RTSP-date or an integer The value of this field can be either an RTSP-date or an integer
number of seconds (in decimal) after the time of the response. number of seconds (in decimal) after the time of the response.
Example: Example:
skipping to change at page 145, line 39 skipping to change at page 157, line 4
The Retry-After response-header field can be used with a 503 (Service The Retry-After response-header field can be used with a 503 (Service
Unavailable) response to indicate how long the service is expected to Unavailable) response to indicate how long the service is expected to
be unavailable to the requesting client. This field MAY also be used be unavailable to the requesting client. This field MAY also be used
with any 3xx (Redirection) response to indicate the minimum time the with any 3xx (Redirection) response to indicate the minimum time the
user-agent is asked to wait before issuing the redirected request. user-agent is asked to wait before issuing the redirected request.
The value of this field can be either an RTSP-date or an integer The value of this field can be either an RTSP-date or an integer
number of seconds (in decimal) after the time of the response. number of seconds (in decimal) after the time of the response.
Example: Example:
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120 Retry-After: 120
In the latter example, the delay is 2 minutes. In the latter example, the delay is 2 minutes.
16.43. RTP-Info 18.43. RTP-Info
The RTP-Info general header field is used to set RTP-specific The RTP-Info general header field is used to set RTP-specific
parameters in the PLAY and GET_PARAMETER responses or a PLAY_NOTIFY parameters in the PLAY and GET_PARAMETER responses or a PLAY_NOTIFY
and GET_PARAMETER requests. For streams using RTP as transport and GET_PARAMETER requests. For streams using RTP as transport
protocol the RTP-Info header SHOULD be part of a 200 response to protocol the RTP-Info header SHOULD be part of a 200 response to
PLAY. PLAY.
The exclusion of the RTP-Info in a PLAY response for RTP The exclusion of the RTP-Info in a PLAY response for RTP
transported media will result in that a client needs to transported media will result in that a client needs to
synchronize the media streams using RTCP. This may have negative synchronize the media streams using RTCP. This may have negative
skipping to change at page 148, line 5 skipping to change at page 159, line 26
Video V PV Video V PV
X: NPT time value = 3.25, from Range header. X: NPT time value = 3.25, from Range header.
A: RTP timestamp value for Audio from RTP-Info header (12345678). A: RTP timestamp value for Audio from RTP-Info header (12345678).
V: RTP timestamp value for Video from RTP-Info header (29567112). V: RTP timestamp value for Video from RTP-Info header (29567112).
PA: RTP audio packet carrying an RTP timestamp of 12344878. Which PA: RTP audio packet carrying an RTP timestamp of 12344878. Which
corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2 corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2
PV: RTP video packet carrying an RTP timestamp of 29573412. Which PV: RTP video packet carrying an RTP timestamp of 29573412. Which
corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32 corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32
16.44. Scale 18.44. Scale
A scale value of 1 indicates normal play at the normal forward A scale value of 1 indicates normal play at the normal forward
viewing rate. If not 1, the value corresponds to the rate with viewing rate. If not 1, the value corresponds to the rate with
respect to normal viewing rate. For example, a ratio of 2 indicates respect to normal viewing rate. For example, a ratio of 2 indicates
twice the normal viewing rate ("fast forward") and a ratio of 0.5 twice the normal viewing rate ("fast forward") and a ratio of 0.5
indicates half the normal viewing rate. In other words, a ratio of 2 indicates half the normal viewing rate. In other words, a ratio of 2
has content time increase at twice the playback time. For every has content time increase at twice the playback time. For every
second of elapsed (wallclock) time, 2 seconds of content time will be second of elapsed (wallclock) time, 2 seconds of content time will be
delivered. A negative value indicates reverse direction. For delivered. A negative value indicates reverse direction. For
certain media transports this may require certain considerations to certain media transports this may require certain considerations to
skipping to change at page 148, line 31 skipping to change at page 159, line 52
close to the nominal bit-rate of the content for Scale = 1. The close to the nominal bit-rate of the content for Scale = 1. The
server has to actively manipulate the data when needed to meet the server has to actively manipulate the data when needed to meet the
bitrate constraints. Implementation of scale changes depends on the bitrate constraints. Implementation of scale changes depends on the
server and media type. For video, a server may, for example, deliver server and media type. For video, a server may, for example, deliver
only key frames or selected frames. For audio, it may time-scale the only key frames or selected frames. For audio, it may time-scale the
audio while preserving pitch or, less desirably, deliver fragments of audio while preserving pitch or, less desirably, deliver fragments of
audio, or completely mute the audio. audio, or completely mute the audio.
The server and content may restrict the range of scale values that it The server and content may restrict the range of scale values that it
supports. The supported values are indicated by the Media-Properties supports. The supported values are indicated by the Media-Properties
header (Section 16.28). The client SHOULD only indicate values header (Section 18.28). The client SHOULD only indicate values
indicated to be supported. However, as the values may change as the indicated to be supported. However, as the values may change as the
content progresses a requested value may no longer be valid when the content progresses a requested value may no longer be valid when the
request arrives. Thus, a non-supported value in a request does not request arrives. Thus, a non-supported value in a request does not
generate an error, only forces the server to choose the closest generate an error, only forces the server to choose the closest
value. The response MUST always contain the actual scale value value. The response MUST always contain the actual scale value
chosen by the server. chosen by the server.
If the server does not implement the possibility to scale, it will If the server does not implement the possibility to scale, it will
not return a Scale header. A server supporting Scale operations for not return a Scale header. A server supporting Scale operations for
PLAY MUST indicate this with the use of the "play.scale" feature-tag. PLAY MUST indicate this with the use of the "play.scale" feature-tag.
When indicating a negative scale for a reverse playback, the Range When indicating a negative scale for a reverse playback, the Range
header MUST indicate a decreasing range as described in header MUST indicate a decreasing range as described in
Section 16.38. Section 18.38.
Example of playing in reverse at 3.5 times normal rate: Example of playing in reverse at 3.5 times normal rate:
Scale: -3.5 Scale: -3.5
Range: npt=15-10 Range: npt=15-10
16.45. Seek-Style 18.45. Seek-Style
When a client sends a PLAY request with a Range header to perform a When a client sends a PLAY request with a Range header to perform a
random access to the media, the client does not know if the server random access to the media, the client does not know if the server
will pick the first media samples or the first random access point will pick the first media samples or the first random access point
prior to the request range. Depending on use case, the client may prior to the request range. Depending on use case, the client may
have a strong preference. To express this preference and provide the have a strong preference. To express this preference and provide the
client with information on how the server actually acted on that client with information on how the server actually acted on that
preference the Seek-Style header is defined. preference the Seek-Style header is defined.
Seek-Style is a general header that MAY be included in any PLAY Seek-Style is a general header that MAY be included in any PLAY
skipping to change at page 150, line 35 skipping to change at page 162, line 5
startup time or the media quality. The "Next" policy breaks the startup time or the media quality. The "Next" policy breaks the
normal definition of the Range header to enable a client to request normal definition of the Range header to enable a client to request
media with minimal overlap, although some may still occur for media with minimal overlap, although some may still occur for
aggregated sessions. RAP and First-Prior both fulfill the aggregated sessions. RAP and First-Prior both fulfill the
requirement of providing media from the requested range and forward. requirement of providing media from the requested range and forward.
However, unless RAP is used, the media quality for many media codecs However, unless RAP is used, the media quality for many media codecs
using predictive methods can be severely degraded unless additional using predictive methods can be severely degraded unless additional
data is available as, for example, already buffered, or through other data is available as, for example, already buffered, or through other
side channels. side channels.
16.46. Server 18.46. Server
The Server response-header field contains information about the The Server response-header field contains information about the
software used by the origin server to handle the request. The field software used by the origin server to handle the request. The field
can contain multiple product tokens and comments identifying the can contain multiple product tokens and comments identifying the
server and any significant subproducts. The product tokens are server and any significant subproducts. The product tokens are
listed in order of their significance for identifying the listed in order of their significance for identifying the
application. application.
Example: Example:
Server: PhonyServer/1.0 Server: PhonyServer/1.0
If the response is being forwarded through a proxy, the proxy If the response is being forwarded through a proxy, the proxy
application MUST NOT modify the Server response-header. Instead, it application MUST NOT modify the Server response-header. Instead, it
SHOULD include a Via field (Section 16.56). If the response is SHOULD include a Via field (Section 18.55). If the response is
generated by the proxy, the proxy application MUST return the Server generated by the proxy, the proxy application MUST return the Server
response-header as previously returned by the server. response-header as previously returned by the server.
16.47. Session 18.47. Session
The Session request-header and response-header field identifies an The Session request-header and response-header field identifies an
RTSP session. An RTSP session is created by the server as a result RTSP session. An RTSP session is created by the server as a result
of a successful SETUP request and in the response the session of a successful SETUP request and in the response the session
identifier is given to the client. The RTSP session exists until identifier is given to the client. The RTSP session exists until
destroyed by a TEARDOWN, REDIRECT or timed out by the server. destroyed by a TEARDOWN, REDIRECT or timed out by the server.
The session identifier is chosen by the server (see Section 4.3) and The session identifier is chosen by the server (see Section 4.3) and
MUST be returned in the SETUP response. Once a client receives a MUST be returned in the SETUP response. Once a client receives a
session identifier, it MUST be included in any request related to session identifier, it MUST be included in any request related to
skipping to change at page 152, line 13 skipping to change at page 163, line 29
longer time periods. longer time periods.
60 seconds was chosen as session timeout value due to: Resulting 60 seconds was chosen as session timeout value due to: Resulting
in not too frequent keep-alive messages and having low sensitivity in not too frequent keep-alive messages and having low sensitivity
to variations in request response timing. If one reduces the to variations in request response timing. If one reduces the
timeout value to below 30 seconds the corresponding request timeout value to below 30 seconds the corresponding request
response timeout becomes a significant part of the session response timeout becomes a significant part of the session
timeout. 60 seconds also allows for reasonably rapid recovery of timeout. 60 seconds also allows for reasonably rapid recovery of
committed server resources in case of client failure. committed server resources in case of client failure.
16.48. Speed 18.48. Speed
The Speed request-header field requests the server to deliver The Speed request-header field requests the server to deliver
specific amounts of nominal media time per unit of delivery time, specific amounts of nominal media time per unit of delivery time,
contingent on the server's ability and desire to serve the media contingent on the server's ability and desire to serve the media
stream at the given speed. The client requests the delivery speed to stream at the given speed. The client requests the delivery speed to
be within a given range with a lower and upper bound. The server be within a given range with a lower and upper bound. The server
SHALL deliver at the highest possible speed within the range, but not SHALL deliver at the highest possible speed within the range, but not
faster than the upper-bound, for which the underlying network path faster than the upper-bound, for which the underlying network path
can support the resulting transport data rates. As long as any speed can support the resulting transport data rates. As long as any speed
value within the given range can be provided the server SHALL NOT value within the given range can be provided the server SHALL NOT
skipping to change at page 153, line 10 skipping to change at page 164, line 27
is meant for use in specific circumstances where delivery of the is meant for use in specific circumstances where delivery of the
presentation at a higher or lower rate is desired. The main use presentation at a higher or lower rate is desired. The main use
cases are buffer operations or local scale operations. Implementors cases are buffer operations or local scale operations. Implementors
should keep in mind that bandwidth for the session may be negotiated should keep in mind that bandwidth for the session may be negotiated
beforehand (by means other than RTSP), and therefore re-negotiation beforehand (by means other than RTSP), and therefore re-negotiation
may be necessary. To perform Speed operations the server needs to may be necessary. To perform Speed operations the server needs to
ensure that the network path can support the resulting bit-rate. ensure that the network path can support the resulting bit-rate.
Thus the media transport needs to support feedback so that the server Thus the media transport needs to support feedback so that the server
can react and adapt to the available bitrate. can react and adapt to the available bitrate.
16.49. Supported 18.49. Supported
The Supported header enumerates all the extensions supported by the The Supported header enumerates all the extensions supported by the
client or server using feature tags. The header carries the client or server using feature tags. The header carries the
extensions supported by the message sending client or server. The extensions supported by the message sending client or server. The
Supported header MAY be included in any request. When present in a Supported header MAY be included in any request. When present in a
request, the receiver MUST respond with its corresponding Supported request, the receiver MUST respond with its corresponding Supported
header. Note that the Supported header is also included in 4xx and header. Note that the Supported header is also included in 4xx and
5xx responses. 5xx responses.
The Supported header contains a list of feature-tags, described in The Supported header contains a list of feature-tags, described in
skipping to change at page 153, line 32 skipping to change at page 165, line 5
Example: Example:
C->S: OPTIONS rtsp://example.com/ RTSP/2.0 C->S: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech Supported: foo, bar, blech
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
Supported: bar, blech, baz Supported: bar, blech, baz
16.50. Terminate-Reason 18.50. Terminate-Reason
The Terminate-Reason request header allows the server when sending a The Terminate-Reason request header allows the server when sending a
REDIRECT or TEARDOWN request to provide a reason for the session REDIRECT or TEARDOWN request to provide a reason for the session
termination and any additional information. This specification termination and any additional information. This specification
identifies three reasons for Redirections and may be extended in the identifies three reasons for Redirections and may be extended in the
future: future:
Server-Admin: The server needs to be shutdown for some Server-Admin: The server needs to be shutdown for some
administrative reason. administrative reason.
skipping to change at page 154, line 11 skipping to change at page 165, line 32
The Server may provide additional parameters containing information The Server may provide additional parameters containing information
around the redirect. This specification defines the following ones. around the redirect. This specification defines the following ones.
time: Provides a wallclock time when the server will stop provide time: Provides a wallclock time when the server will stop provide
any service. any service.
user-msg: An UTF-8 text string with a message from the server to the user-msg: An UTF-8 text string with a message from the server to the
user. This message SHOULD be displayed to the user. user. This message SHOULD be displayed to the user.
16.51. Timestamp 18.51. Timestamp
The Timestamp general-header describes when the agent sent the The Timestamp general-header describes when the agent sent the
request. The value of the timestamp is of significance only to the request. The value of the timestamp is of significance only to the
agent and may use any timescale. The responding agent MUST echo the agent and may use any timescale. The responding agent MUST echo the
exact same value and MAY, if it has accurate information about this, exact same value and MAY, if it has accurate information about this,
add a floating point number indicating the number of seconds that has add a floating point number indicating the number of seconds that has
elapsed since it has received the request. The timestamp can be used elapsed since it has received the request. The timestamp can be used
by the agent to compute the round-trip time to the responding agent by the agent to compute the round-trip time to the responding agent
so that it can adjust the timeout value for retransmissions when so that it can adjust the timeout value for retransmissions when
running over an unreliable protocol. It also resolves retransmission running over an unreliable protocol. It also resolves retransmission
ambiguities for unreliable transport of RTSP. ambiguities for unreliable transport of RTSP.
Note that the present specification provides only for reliable Note that the present specification provides only for reliable
transport of RTSP messages. The Timestamp general-header is transport of RTSP messages. The Timestamp general-header is
specified in case the protocol is extended in the future to use specified in case the protocol is extended in the future to use
unreliable transport. unreliable transport.
16.52. Transport 18.52. Transport
The Transport request and response header indicates which transport The Transport request and response header indicates which transport
protocol is to be used and configures its parameters such as protocol is to be used and configures its parameters such as
destination address, compression, multicast time-to-live and destination address, compression, multicast time-to-live and
destination port for a single stream. It sets those values not destination port for a single stream. It sets those values not
already determined by a presentation description. already determined by a presentation description.
A Transport request header MAY contain a list of transport options A Transport request header MAY contain a list of transport options
acceptable to the client, in the form of multiple transport acceptable to the client, in the form of multiple transport
specification entries. Transport specifications are comma separated, specification entries. Transport specifications are comma separated,
listed in decreasing order of preference. Parameters may be added to listed in decreasing order of preference. Parameters may be added to
each transport specification, separated by a semicolon. The server each transport specification, separated by a semicolon. The server
MUST return a Transport response-header in the response to indicate MUST return a Transport response-header in the response to indicate
the values actually chosen if any. If the transport specification is the values actually chosen if any. If the transport specification is
not supported, no transport header is returned and the request MUST not supported, no transport header is returned and the request MUST
be responded using the status code 461 (Unsupported Transport) be responded using the status code 461 (Unsupported Transport)
(Section 15.4.26). In case more than one transport specification was (Section 17.4.26). In case more than one transport specification was
present in the request, the server MUST return the single (transport- present in the request, the server MUST return the single (transport-
spec) which was actually chosen, if any. The number of transport- spec) which was actually chosen, if any. The number of transport-
spec entries is expected to be limited as the client will get spec entries is expected to be limited as the client will get
guidance on what configurations that are possible from the guidance on what configurations that are possible from the
presentation description. presentation description.
The Transport header MAY also be used in subsequent SETUP requests to The Transport header MAY also be used in subsequent SETUP requests to
change transport parameters. A server MAY refuse to change change transport parameters. A server MAY refuse to change
parameters of an existing stream. parameters of an existing stream.
A transport specification may only contain one of any given parameter A transport specification may only contain one of any given parameter
within it. Parameters MAY be given in any order. Additionally, it within it. Parameters MAY be given in any order. Additionally, it
may only contain either of the unicast or the multicast transport may only contain either of the unicast or the multicast transport
type parameter. All parameters need to be understood in a transport type parameter. All parameters need to be understood in a transport
specification, if not, the transport specification MUST be ignored. specification, if not, the transport specification MUST be ignored.
RTSP proxies of any type that uses or modifies the transport RTSP proxies of any type that uses or modifies the transport
specification, e.g. access proxy or security proxy, MUST remove specification, e.g. access proxy or security proxy, MUST remove
specifications with unknown parameters before forwarding the RTSP specifications with unknown parameters before forwarding the RTSP
message. If that result in no remaining transport specification the message. If that result in no remaining transport specification the
proxy SHALL send a 461 (Unsupported Transport) (Section 15.4.26) proxy SHALL send a 461 (Unsupported Transport) (Section 17.4.26)
response without any Transport header. response without any Transport header.
The Transport header is restricted to describing a single media The Transport header is restricted to describing a single media
stream. (RTSP can also control multiple streams as a single stream. (RTSP can also control multiple streams as a single
entity.) Making it part of RTSP rather than relying on a entity.) Making it part of RTSP rather than relying on a
multitude of session description formats greatly simplifies multitude of session description formats greatly simplifies
designs of firewalls. designs of firewalls.
The general syntax for the transport specifier is a list of slash The general syntax for the transport specifier is a list of slash
separated tokens: separated tokens:
skipping to change at page 157, line 12 skipping to change at page 168, line 37
destination parameter per transport spec is intended. The destination parameter per transport spec is intended. The
usage of multiple destinations to distribute a single media to usage of multiple destinations to distribute a single media to
multiple entities is unspecified. multiple entities is unspecified.
The client originating the RTSP request MAY specify the The client originating the RTSP request MAY specify the
destination address of the stream recipient with the host destination address of the stream recipient with the host
address part of the tuple. When the destination address is address part of the tuple. When the destination address is
specified, the recipient may be a different party than the specified, the recipient may be a different party than the
originator of the request. To avoid becoming the unwitting originator of the request. To avoid becoming the unwitting
perpetrator of a remote-controlled denial-of-service attack, a perpetrator of a remote-controlled denial-of-service attack, a
server MUST perform security checks (see Section 21.1) and server MUST perform security checks (see Section 21.2.1) and
SHOULD log such attempts before allowing the client to direct a SHOULD log such attempts before allowing the client to direct a
media stream to a recipient address not chosen by the server. media stream to a recipient address not chosen by the server.
Implementations cannot rely on TCP as reliable means of client Implementations cannot rely on TCP as reliable means of client
identification. If the server does not allow the host address identification. If the server does not allow the host address
part of the tuple to be set, it MUST return 463 (Destination part of the tuple to be set, it MUST return 463 (Destination
Prohibited). Prohibited).
The host address part of the tuple MAY be empty, for example The host address part of the tuple MAY be empty, for example
":58044", in cases when only destination port is desired to be ":58044", in cases when only destination port is desired to be
specified. Responses to requests including the Transport specified. Responses to requests including the Transport
skipping to change at page 158, line 38 skipping to change at page 170, line 13
bi-directional, so both end-parties MAY send data on the given bi-directional, so both end-parties MAY send data on the given
channel. One example of such usage is the second channel used channel. One example of such usage is the second channel used
for RTCP, where both server and client send RTCP packets on the for RTCP, where both server and client send RTCP packets on the
same channel. same channel.
This allows RTP/RTCP to be handled similarly to the way This allows RTP/RTCP to be handled similarly to the way
that it is done with UDP, i.e., one channel for RTP and that it is done with UDP, i.e., one channel for RTP and
the other for RTCP. the other for RTCP.
MIKEY: This parameter is used in conjunction with transport MIKEY: This parameter is used in conjunction with transport
specifications that can utilize MIKEY for security context specifications that can utilize MIKEY [RFC3830] for security
establishment. So far only the SRTP based RTP profiles SAVP context establishment. So far only the SRTP based RTP profiles
and SAVPF can utilize MIKEY and this is defined in SAVP and SAVPF can utilize MIKEY and this is defined in
Appendix C.1.4.1. This parameter can be included both in Appendix C.1.4.1. This parameter can be included both in
request and response messages. The binary MIKEY message SHALL request and response messages. The binary MIKEY message SHALL
be BASE64 [RFC4648] encoded before being included in the value be BASE64 [RFC4648] encoded before being included in the value
part of the parameter. part of the parameter.
Multicast-specific: Multicast-specific:
ttl: multicast time-to-live for IPv4. When included in requests the ttl: multicast time-to-live for IPv4. When included in requests the
value indicate the TTL value that the client request the server value indicate the TTL value that the client request the server
to use. In a response, the value actually being used by the to use. In a response, the value actually being used by the
server is returned. A server will need to consider what values server is returned. A server will need to consider what values
that are reasonable and also the authority of the user to set that are reasonable and also the authority of the user to set
this value. Corresponding functions are not needed for IPv6 as this value. Corresponding functions are not needed for IPv6 as
the scoping is part of the address. the scoping is part of the IPv6 multicast address [RFC4291].
RTP-specific: RTP-specific:
These parameters MAY only be used if the media transport protocol is These parameters MAY only be used if the media transport protocol is
RTP. RTP.
ssrc: The ssrc parameter, if included in a SETUP response, indicates ssrc: The ssrc parameter, if included in a SETUP response, indicates
the RTP SSRC [RFC3550] value(s) that will be used by the media the RTP SSRC [RFC3550] value(s) that will be used by the media
server for RTP packets within the stream. It is expressed as server for RTP packets within the stream. It is expressed as
an eight digit hexadecimal value. an eight digit hexadecimal value.
skipping to change at page 161, line 27 skipping to change at page 173, line 6
CSeq: 302 CSeq: 302
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: 47112344 Session: 47112344
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
"192.0.2.5:3457";src_addr="192.0.2.224:6256"/ "192.0.2.5:3457";src_addr="192.0.2.224:6256"/
"192.0.2.224:6257";mode="PLAY" "192.0.2.224:6257";mode="PLAY"
Accept-Ranges: NPT Accept-Ranges: NPT
Media-Properties: Random-Access=0.6, Dynamic, Media-Properties: Random-Access=0.6, Dynamic,
Time-Limited=20081128T165900 Time-Limited=20081128T165900
16.53. Unsupported 18.53. Unsupported
The Unsupported response-header lists the features not supported by The Unsupported response-header lists the features not supported by
the responding RTSP agent. In the case where the feature was the responding RTSP agent. In the case where the feature was
specified via the Proxy-Require field (Section 16.35), if there is a specified via the Proxy-Require field (Section 18.35), if there is a
proxy on the path between the client and the server, the proxy MUST proxy on the path between the client and the server, the proxy MUST
send a response message with a status code of 551 (Option Not send a response message with a status code of 551 (Option Not
Supported). The request MUST NOT be forwarded. Supported). The request MUST NOT be forwarded.