rfc7826v1.txt   rfc7826.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
Internet Engineering Task Force (IETF) H. Schulzrinne Internet Engineering Task Force (IETF) H. Schulzrinne
Request for Comments: 7826 Columbia University Request for Comments: 7826 Columbia University
Obsoletes: 2326 A. Rao Obsoletes: 2326 A. Rao
Category: Standards Track Cisco Category: Standards Track Cisco
ISSN: 2070-1721 R. Lanphier ISSN: 2070-1721 R. Lanphier
M. Westerlund M. Westerlund
Ericsson AB Ericsson AB
M. Stiemerling, Ed. M. Stiemerling, Ed.
NEC NEC
March 2016 September 2016
Real-Time Streaming Protocol (RTSP) Version 2.0 Real-Time Streaming Protocol Version 2.0
Abstract Abstract
This memorandum defines the Real-Time Streaming Protocol (RTSP) This memorandum defines the Real-Time Streaming Protocol (RTSP)
version 2.0, which obsoletes RTSP version 1.0 defined in RFC 2326. version 2.0, which obsoletes RTSP version 1.0 defined in RFC 2326.
RTSP is an application-layer protocol for the setup and control of RTSP is an application-layer protocol for the setup and control of
the delivery of data with real-time properties. RTSP provides an the delivery of data with real-time properties. RTSP provides an
extensible framework to enable controlled, on-demand delivery of extensible framework to enable controlled, on-demand delivery of
real-time data, such as audio and video. Sources of data can include real-time data, such as audio and video. Sources of data can include
skipping to change at page 3, line 21 skipping to change at page 3, line 21
5.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 35 5.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 35
5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 36 5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 36
5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 36 5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 36
6. General-Header Fields . . . . . . . . . . . . . . . . . . . . 37 6. General-Header Fields . . . . . . . . . . . . . . . . . . . . 37
7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 39 7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 39
7.2. Request-Header Fields . . . . . . . . . . . . . . . . . . 41 7.2. Request-Header Fields . . . . . . . . . . . . . . . . . . 41
8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 43 8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 43 8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 43
8.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 43 8.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 43
8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 47 8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 46
9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 47 9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 47
9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 48 9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 48
9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 49 9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 49
9.3. Message Body Format Negotiation . . . . . . . . . . . . . 49 9.3. Message Body Format Negotiation . . . . . . . . . . . . . 49
10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 50 10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 50
10.1. Reliability and Acknowledgements . . . . . . . . . . . . 50 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 50
10.2. Using Connections . . . . . . . . . . . . . . . . . . . 51 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 51
10.3. Closing Connections . . . . . . . . . . . . . . . . . . 54 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 54
10.4. Timing Out Connections and RTSP Messages . . . . . . . . 55 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 55
10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 56 10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 56
skipping to change at page 4, line 7 skipping to change at page 4, line 7
13.4.3. Updating Current PLAY Requests . . . . . . . . . . . 77 13.4.3. Updating Current PLAY Requests . . . . . . . . . . . 77
13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 80 13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 80
13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 80 13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 80
13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 80 13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 80
13.4.7. Playing Live with Recording . . . . . . . . . . . . 81 13.4.7. Playing Live with Recording . . . . . . . . . . . . 81
13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 82 13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 82
13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 82 13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 82
13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 83 13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 83
13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 85 13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 85
13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 86 13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 86
13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 87 13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 88
13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 90 13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 90
13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 90 13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 90
13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 91 13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 91
13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 92 13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 92
13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 94 13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 94
13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 96 13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 96
14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 98 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 99
15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
15.1. Proxies and Protocol Extensions . . . . . . . . . . . . 102 15.1. Proxies and Protocol Extensions . . . . . . . . . . . . 102
15.2. Multiplexing and Demultiplexing of Messages . . . . . . 103 15.2. Multiplexing and Demultiplexing of Messages . . . . . . 103
16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
16.1. Validation Model . . . . . . . . . . . . . . . . . . . . 104 16.1. Validation Model . . . . . . . . . . . . . . . . . . . . 104
16.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 105 16.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 105
16.1.2. Message Body Tag Cache Validators . . . . . . . . . 105 16.1.2. Message Body Tag Cache Validators . . . . . . . . . 105
16.1.3. Weak and Strong Validators . . . . . . . . . . . . . 105 16.1.3. Weak and Strong Validators . . . . . . . . . . . . . 106
16.1.4. Rules for When to Use Message Body Tags and Last- 16.1.4. Rules for When to Use Message Body Tags and Last-
Modified Dates . . . . . . . . . . . . . . . . . . . 108 Modified Dates . . . . . . . . . . . . . . . . . . . 108
16.1.5. Non-validating Conditionals . . . . . . . . . . . . 109 16.1.5. Non-validating Conditionals . . . . . . . . . . . . 109
16.2. Invalidation after Updates or Deletions . . . . . . . . 109 16.2. Invalidation after Updates or Deletions . . . . . . . . 110
17. Status Code Definitions . . . . . . . . . . . . . . . . . . . 110 17. Status Code Definitions . . . . . . . . . . . . . . . . . . . 110
17.1. Informational 1xx . . . . . . . . . . . . . . . . . . . 110 17.1. Informational 1xx . . . . . . . . . . . . . . . . . . . 111
17.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 110 17.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 111
17.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 111 17.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 111
17.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 111 17.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 111
17.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 111 17.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 111
17.3.1. 300 . . . . . . . . . . . . . . . . . . . . . . . . 112 17.3.1. 300 . . . . . . . . . . . . . . . . . . . . . . . . 112
17.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 112 17.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 112
17.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 112 17.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 112
17.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 112 17.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 112
17.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 112 17.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 113
17.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 113 17.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 113
17.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 113 17.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 113
17.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 113 17.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 113
17.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 113 17.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 113
17.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 114 17.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 114
17.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 114 17.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 114
17.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 114 17.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 114
17.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 114 17.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 114
17.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 114 17.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 114
17.4.8. 407 Proxy Authentication Required . . . . . . . . . 115 17.4.8. 407 Proxy Authentication Required . . . . . . . . . 115
17.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 115 17.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 115
17.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 115 17.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 115
17.4.11. 412 Precondition Failed . . . . . . . . . . . . . . 115 17.4.11. 412 Precondition Failed . . . . . . . . . . . . . . 116
17.4.12. 413 Request Message Body Too Large . . . . . . . . . 116 17.4.12. 413 Request Message Body Too Large . . . . . . . . . 116
17.4.13. 414 Request-URI Too Long . . . . . . . . . . . . . . 116 17.4.13. 414 Request-URI Too Long . . . . . . . . . . . . . . 116
17.4.14. 415 Unsupported Media Type . . . . . . . . . . . . . 116 17.4.14. 415 Unsupported Media Type . . . . . . . . . . . . . 116
17.4.15. 451 Parameter Not Understood . . . . . . . . . . . . 116 17.4.15. 451 Parameter Not Understood . . . . . . . . . . . . 116
17.4.16. 452 Illegal Conference Identifier . . . . . . . . . 116 17.4.16. 452 Illegal Conference Identifier . . . . . . . . . 117
17.4.17. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 116 17.4.17. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 117
17.4.18. 454 Session Not Found . . . . . . . . . . . . . . . 117 17.4.18. 454 Session Not Found . . . . . . . . . . . . . . . 117
17.4.19. 455 Method Not Valid in This State . . . . . . . . . 117 17.4.19. 455 Method Not Valid in This State . . . . . . . . . 117
17.4.20. 456 Header Field Not Valid for Resource . . . . . . 117 17.4.20. 456 Header Field Not Valid for Resource . . . . . . 117
17.4.21. 457 Invalid Range . . . . . . . . . . . . . . . . . 117 17.4.21. 457 Invalid Range . . . . . . . . . . . . . . . . . 117
17.4.22. 458 Parameter Is Read-Only . . . . . . . . . . . . . 117 17.4.22. 458 Parameter Is Read-Only . . . . . . . . . . . . . 117
17.4.23. 459 Aggregate Operation Not Allowed . . . . . . . . 117 17.4.23. 459 Aggregate Operation Not Allowed . . . . . . . . 117
17.4.24. 460 Only Aggregate Operation Allowed . . . . . . . . 117 17.4.24. 460 Only Aggregate Operation Allowed . . . . . . . . 118
17.4.25. 461 Unsupported Transport . . . . . . . . . . . . . 117 17.4.25. 461 Unsupported Transport . . . . . . . . . . . . . 118
17.4.26. 462 Destination Unreachable . . . . . . . . . . . . 118 17.4.26. 462 Destination Unreachable . . . . . . . . . . . . 118
17.4.27. 463 Destination Prohibited . . . . . . . . . . . . . 118 17.4.27. 463 Destination Prohibited . . . . . . . . . . . . . 118
17.4.28. 464 Data Transport Not Ready Yet . . . . . . . . . . 118 17.4.28. 464 Data Transport Not Ready Yet . . . . . . . . . . 118
17.4.29. 465 Notification Reason Unknown . . . . . . . . . . 118 17.4.29. 465 Notification Reason Unknown . . . . . . . . . . 118
17.4.30. 466 Key Management Error . . . . . . . . . . . . . . 118 17.4.30. 466 Key Management Error . . . . . . . . . . . . . . 119
17.4.31. 470 Connection Authorization Required . . . . . . . 118 17.4.31. 470 Connection Authorization Required . . . . . . . 119
17.4.32. 471 Connection Credentials Not Accepted . . . . . . 119 17.4.32. 471 Connection Credentials Not Accepted . . . . . . 119
17.4.33. 472 Failure to Establish Secure Connection . . . . . 119 17.4.33. 472 Failure to Establish Secure Connection . . . . . 119
17.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 119 17.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 119
17.5.1. 500 Internal Server Error . . . . . . . . . . . . . 119 17.5.1. 500 Internal Server Error . . . . . . . . . . . . . 119
17.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 119 17.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 119
17.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 119 17.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 120
17.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 119 17.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 120
17.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 120 17.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 120
17.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 120 17.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 120
17.5.7. 551 Option Not Supported . . . . . . . . . . . . . . 120 17.5.7. 551 Option Not Supported . . . . . . . . . . . . . . 120
17.5.8. 553 Proxy Unavailable . . . . . . . . . . . . . . . 120 17.5.8. 553 Proxy Unavailable . . . . . . . . . . . . . . . 121
18. Header Field Definitions . . . . . . . . . . . . . . . . . . 121 18. Header Field Definitions . . . . . . . . . . . . . . . . . . 121
18.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 131 18.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 132
18.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 132 18.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 133
18.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 133 18.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 134
18.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 134 18.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 135
18.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 135 18.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 136
18.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 135 18.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 136
18.7. Authentication-Info . . . . . . . . . . . . . . . . . . 136 18.7. Authentication-Info . . . . . . . . . . . . . . . . . . 136
18.8. Authorization . . . . . . . . . . . . . . . . . . . . . 136 18.8. Authorization . . . . . . . . . . . . . . . . . . . . . 137
18.9. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 137 18.9. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 138
18.10. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 137 18.10. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 138
18.11. Cache-Control . . . . . . . . . . . . . . . . . . . . . 138 18.11. Cache-Control . . . . . . . . . . . . . . . . . . . . . 139
18.12. Connection . . . . . . . . . . . . . . . . . . . . . . . 140 18.12. Connection . . . . . . . . . . . . . . . . . . . . . . . 141
18.13. Connection-Credentials . . . . . . . . . . . . . . . . . 141 18.13. Connection-Credentials . . . . . . . . . . . . . . . . . 142
18.14. Content-Base . . . . . . . . . . . . . . . . . . . . . . 142 18.14. Content-Base . . . . . . . . . . . . . . . . . . . . . . 143
18.15. Content-Encoding . . . . . . . . . . . . . . . . . . . . 142 18.15. Content-Encoding . . . . . . . . . . . . . . . . . . . . 143
18.16. Content-Language . . . . . . . . . . . . . . . . . . . . 143 18.16. Content-Language . . . . . . . . . . . . . . . . . . . . 144
18.17. Content-Length . . . . . . . . . . . . . . . . . . . . . 144 18.17. Content-Length . . . . . . . . . . . . . . . . . . . . . 145
18.18. Content-Location . . . . . . . . . . . . . . . . . . . . 144 18.18. Content-Location . . . . . . . . . . . . . . . . . . . . 145
18.19. Content-Type . . . . . . . . . . . . . . . . . . . . . . 145 18.19. Content-Type . . . . . . . . . . . . . . . . . . . . . . 146
18.20. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 145 18.20. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 146
18.21. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 147 18.21. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 148
18.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 148 18.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 149
18.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 149 18.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 150
18.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 149 18.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 150
18.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 150 18.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 151
18.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 150 18.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 151
18.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 151 18.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 152
18.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 151 18.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 152
18.29. Media-Properties . . . . . . . . . . . . . . . . . . . . 152 18.29. Media-Properties . . . . . . . . . . . . . . . . . . . . 153
18.30. Media-Range . . . . . . . . . . . . . . . . . . . . . . 154 18.30. Media-Range . . . . . . . . . . . . . . . . . . . . . . 155
18.31. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 154 18.31. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 155
18.32. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 155 18.32. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 156
18.33. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 155 18.33. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 156
18.34. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 156 18.34. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 157
18.35. Proxy-Authentication-Info . . . . . . . . . . . . . . . 156 18.35. Proxy-Authentication-Info . . . . . . . . . . . . . . . 157
18.36. Proxy-Authorization . . . . . . . . . . . . . . . . . . 157 18.36. Proxy-Authorization . . . . . . . . . . . . . . . . . . 158
18.37. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 157 18.37. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 158
18.38. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 157 18.38. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 158
18.39. Public . . . . . . . . . . . . . . . . . . . . . . . . . 158 18.39. Public . . . . . . . . . . . . . . . . . . . . . . . . . 159
18.40. Range . . . . . . . . . . . . . . . . . . . . . . . . . 159 18.40. Range . . . . . . . . . . . . . . . . . . . . . . . . . 160
18.41. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 161 18.41. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 162
18.42. Request-Status . . . . . . . . . . . . . . . . . . . . . 161 18.42. Request-Status . . . . . . . . . . . . . . . . . . . . . 162
18.43. Require . . . . . . . . . . . . . . . . . . . . . . . . 162 18.43. Require . . . . . . . . . . . . . . . . . . . . . . . . 163
18.44. Retry-After . . . . . . . . . . . . . . . . . . . . . . 163 18.44. Retry-After . . . . . . . . . . . . . . . . . . . . . . 164
18.45. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 163 18.45. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 164
18.46. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 165 18.46. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 166
18.47. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 166 18.47. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 167
18.48. Server . . . . . . . . . . . . . . . . . . . . . . . . . 168 18.48. Server . . . . . . . . . . . . . . . . . . . . . . . . . 169
18.49. Session . . . . . . . . . . . . . . . . . . . . . . . . 168 18.49. Session . . . . . . . . . . . . . . . . . . . . . . . . 170
18.50. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 169 18.50. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 171
18.51. Supported . . . . . . . . . . . . . . . . . . . . . . . 170 18.51. Supported . . . . . . . . . . . . . . . . . . . . . . . 172
18.52. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 171 18.52. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 172
18.53. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 171 18.53. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 173
18.54. Transport . . . . . . . . . . . . . . . . . . . . . . . 172 18.54. Transport . . . . . . . . . . . . . . . . . . . . . . . 173
18.55. Unsupported . . . . . . . . . . . . . . . . . . . . . . 179 18.55. Unsupported . . . . . . . . . . . . . . . . . . . . . . 181
18.56. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 179 18.56. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 181
18.57. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 180 18.57. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 182
18.58. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 180 18.58. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 182
19. Security Framework . . . . . . . . . . . . . . . . . . . . . 181 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 183
19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 181 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 183
19.1.1. Digest Authentication . . . . . . . . . . . . . . . 182 19.1.1. Digest Authentication . . . . . . . . . . . . . . . 184
19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 183 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 184
19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 184 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 185
19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 185 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 187
19.3.2. User-Approved TLS Procedure . . . . . . . . . . . . 186 19.3.2. User-Approved TLS Procedure . . . . . . . . . . . . 188
20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 188 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 190
20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 190 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 192
20.2.1. Generic Protocol Elements . . . . . . . . . . . . . 191 20.2.1. Generic Protocol Elements . . . . . . . . . . . . . 192
20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 193 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 195
20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 197 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 199
20.3. SDP Extension Syntax . . . . . . . . . . . . . . . . . . 206 20.3. SDP Extension Syntax . . . . . . . . . . . . . . . . . . 207
21. Security Considerations . . . . . . . . . . . . . . . . . . . 206 21. Security Considerations . . . . . . . . . . . . . . . . . . . 207
21.1. Signaling Protocol Threats . . . . . . . . . . . . . . . 207 21.1. Signaling Protocol Threats . . . . . . . . . . . . . . . 208
21.2. Media Stream Delivery Threats . . . . . . . . . . . . . 210 21.2. Media Stream Delivery Threats . . . . . . . . . . . . . 211
21.2.1. Remote DoS Attack . . . . . . . . . . . . . . . . . 211 21.2.1. Remote DoS Attack . . . . . . . . . . . . . . . . . 212
21.2.2. RTP Security Analysis . . . . . . . . . . . . . . . 212 21.2.2. RTP Security Analysis . . . . . . . . . . . . . . . 213
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 214 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 215
22.1. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 215 22.1. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 216
22.1.1. Description . . . . . . . . . . . . . . . . . . . . 215 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 216
22.1.2. Registering New Feature-Tags with IANA . . . . . . . 215 22.1.2. Registering New Feature-Tags with IANA . . . . . . . 216
22.1.3. Registered Entries . . . . . . . . . . . . . . . . . 216 22.1.3. Registered Entries . . . . . . . . . . . . . . . . . 217
22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 216 22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 217
22.2.1. Description . . . . . . . . . . . . . . . . . . . . 216 22.2.1. Description . . . . . . . . . . . . . . . . . . . . 217
22.2.2. Registering New Methods with IANA . . . . . . . . . 216 22.2.2. Registering New Methods with IANA . . . . . . . . . 217
22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 217 22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 218
22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 217 22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 218
22.3.1. Description . . . . . . . . . . . . . . . . . . . . 217 22.3.1. Description . . . . . . . . . . . . . . . . . . . . 218
22.3.2. Registering New Status Codes with IANA . . . . . . . 217 22.3.2. Registering New Status Codes with IANA . . . . . . . 218
22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 218 22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 219
22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 218 22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 219
22.4.1. Description . . . . . . . . . . . . . . . . . . . . 218 22.4.1. Description . . . . . . . . . . . . . . . . . . . . 219
22.4.2. Registering New Headers with IANA . . . . . . . . . 218 22.4.2. Registering New Headers with IANA . . . . . . . . . 219
22.4.3. Registered Entries . . . . . . . . . . . . . . . . . 218 22.4.3. Registered Entries . . . . . . . . . . . . . . . . . 219
22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 220 22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 221
22.5.1. Accept-Credentials Policies . . . . . . . . . . . . 220 22.5.1. Accept-Credentials Policies . . . . . . . . . . . . 221
22.5.2. Accept-Credentials Hash Algorithms . . . . . . . . . 220 22.5.2. Accept-Credentials Hash Algorithms . . . . . . . . . 221
22.6. Cache-Control Cache Directive Extensions . . . . . . . . 221 22.6. Cache-Control Cache Directive Extensions . . . . . . . . 222
22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 222 22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 223
22.7.1. Description . . . . . . . . . . . . . . . . . . . . 222 22.7.1. Description . . . . . . . . . . . . . . . . . . . . 223
22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 222 22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 223
22.7.3. Registered Values . . . . . . . . . . . . . . . . . 222 22.7.3. Registered Values . . . . . . . . . . . . . . . . . 223
22.8. Notify-Reason Values . . . . . . . . . . . . . . . . . . 223 22.8. Notify-Reason Values . . . . . . . . . . . . . . . . . . 224
22.8.1. Description . . . . . . . . . . . . . . . . . . . . 223 22.8.1. Description . . . . . . . . . . . . . . . . . . . . 224
22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 223 22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 224
22.8.3. Registered Values . . . . . . . . . . . . . . . . . 223 22.8.3. Registered Values . . . . . . . . . . . . . . . . . 224
22.9. Range Header Formats . . . . . . . . . . . . . . . . . . 223 22.9. Range Header Formats . . . . . . . . . . . . . . . . . . 224
22.9.1. Description . . . . . . . . . . . . . . . . . . . . 224 22.9.1. Description . . . . . . . . . . . . . . . . . . . . 225
22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 224 22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 225
22.9.3. Registered Values . . . . . . . . . . . . . . . . . 224 22.9.3. Registered Values . . . . . . . . . . . . . . . . . 225
22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 224 22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 225
22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . 225 22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . 226
22.10.2. Terminate-Reason Header Parameters . . . . . . . . 225 22.10.2. Terminate-Reason Header Parameters . . . . . . . . 226
22.11. RTP-Info Header Parameters . . . . . . . . . . . . . . . 226 22.11. RTP-Info Header Parameters . . . . . . . . . . . . . . . 227
22.11.1. Description . . . . . . . . . . . . . . . . . . . . 226 22.11.1. Description . . . . . . . . . . . . . . . . . . . . 227
22.11.2. Registration Rules . . . . . . . . . . . . . . . . 226 22.11.2. Registration Rules . . . . . . . . . . . . . . . . 227
22.11.3. Registered Values . . . . . . . . . . . . . . . . . 226 22.11.3. Registered Values . . . . . . . . . . . . . . . . . 227
22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 226 22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 227
22.12.1. Description . . . . . . . . . . . . . . . . . . . . 227 22.12.1. Description . . . . . . . . . . . . . . . . . . . . 228
22.12.2. Registration Rules . . . . . . . . . . . . . . . . 227 22.12.2. Registration Rules . . . . . . . . . . . . . . . . 228
22.12.3. Registered Values . . . . . . . . . . . . . . . . . 227 22.12.3. Registered Values . . . . . . . . . . . . . . . . . 228
22.13. Transport Header Registries . . . . . . . . . . . . . . 228 22.13. Transport Header Registries . . . . . . . . . . . . . . 229
22.13.1. Transport Protocol Identifier . . . . . . . . . . . 228 22.13.1. Transport Protocol Identifier . . . . . . . . . . . 229
22.13.2. Transport Modes . . . . . . . . . . . . . . . . . . 229 22.13.2. Transport Modes . . . . . . . . . . . . . . . . . . 230
22.13.3. Transport Parameters . . . . . . . . . . . . . . . 230 22.13.3. Transport Parameters . . . . . . . . . . . . . . . 231
22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 231 22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 232
22.14.1. The "rtsp" URI Scheme . . . . . . . . . . . . . . . 231 22.14.1. The "rtsp" URI Scheme . . . . . . . . . . . . . . . 232
22.14.2. The "rtsps" URI Scheme . . . . . . . . . . . . . . 232 22.14.2. The "rtsps" URI Scheme . . . . . . . . . . . . . . 233
22.14.3. The "rtspu" URI Scheme . . . . . . . . . . . . . . 233 22.14.3. The "rtspu" URI Scheme . . . . . . . . . . . . . . 234
22.15. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 234 22.15. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 235
22.16. Media Type Registration for text/parameters . . . . . . 235 22.16. Media Type Registration for text/parameters . . . . . . 236
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 236 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 237
23.1. Normative References . . . . . . . . . . . . . . . . . . 236 23.1. Normative References . . . . . . . . . . . . . . . . . . 237
23.2. Informative References . . . . . . . . . . . . . . . . . 240 23.2. Informative References . . . . . . . . . . . . . . . . . 242
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 243 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 244
A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . . 243 A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . . 245
A.2. Media on Demand Using Pipelining . . . . . . . . . . . . 248 A.2. Media on Demand Using Pipelining . . . . . . . . . . . . 249
A.3. Secured Media Session for On-Demand Content . . . . . . . 250 A.3. Secured Media Session for On-Demand Content . . . . . . . 251
A.4. Media on Demand (Unicast) . . . . . . . . . . . . . . . . 253 A.4. Media on Demand (Unicast) . . . . . . . . . . . . . . . . 254
A.5. Single-Stream Container Files . . . . . . . . . . . . . . 257 A.5. Single-Stream Container Files . . . . . . . . . . . . . . 258
A.6. Live Media Presentation Using Multicast . . . . . . . . . 259 A.6. Live Media Presentation Using Multicast . . . . . . . . . 260
A.7. Capability Negotiation . . . . . . . . . . . . . . . . . 260 A.7. Capability Negotiation . . . . . . . . . . . . . . . . . 261
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 261 Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 262
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 262 B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 263
B.2. State Variables . . . . . . . . . . . . . . . . . . . . . 262 B.2. State Variables . . . . . . . . . . . . . . . . . . . . . 263
B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 262 B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 263
B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 263 B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 264
Appendix C. Media-Transport Alternatives . . . . . . . . . . . . 267 Appendix C. Media-Transport Alternatives . . . . . . . . . . . . 268
C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . . 268 C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . . 269
C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . . 268 C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . . 269
C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 269 C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 270
C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 270 C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 271
C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 272 C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 273
C.1.6. RTCP Usage with RTSP . . . . . . . . . . . . . . . . 273 C.1.6. RTCP Usage with RTSP . . . . . . . . . . . . . . . . 274
C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 274 C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 275
C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 275 C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 276
C.2.2. RTP over Independent TCP . . . . . . . . . . . . . . 275 C.2.2. RTP over Independent TCP . . . . . . . . . . . . . . 276
C.3. Handling Media-Clock Time Jumps in the RTP Media Layer . 279 C.3. Handling Media-Clock Time Jumps in the RTP Media Layer . 280
C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . . 283 C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . . 284
C.5. RTSP/RTP Integration . . . . . . . . . . . . . . . . . . 285 C.5. RTSP/RTP Integration . . . . . . . . . . . . . . . . . . 286
C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 285 C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 286
C.7. Maintaining NPT Synchronization with RTP Timestamps . . . 285 C.7. Maintaining NPT Synchronization with RTP Timestamps . . . 286
C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 285 C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 286
C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 285 C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 286
C.10. Usage of SSRCs and the RTCP BYE Message during an RTSP C.10. Usage of SSRCs and the RTCP BYE Message during an RTSP
Session . . . . . . . . . . . . . . . . . . . . . . . . . 285 Session . . . . . . . . . . . . . . . . . . . . . . . . . 286
C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 286 C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 287
Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 287 Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 288
D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 287 D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 288
D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . . 287 D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . . 288
D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . . 289 D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . . 290
D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . . 289 D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . . 290
D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 289 D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 290
D.1.5. Directionality of Media Stream . . . . . . . . . . . 290 D.1.5. Directionality of Media Stream . . . . . . . . . . . 291
D.1.6. Range of Presentation . . . . . . . . . . . . . . . . 290 D.1.6. Range of Presentation . . . . . . . . . . . . . . . . 291
D.1.7. Time of Availability . . . . . . . . . . . . . . . . 291 D.1.7. Time of Availability . . . . . . . . . . . . . . . . 292
D.1.8. Connection Information . . . . . . . . . . . . . . . 292 D.1.8. Connection Information . . . . . . . . . . . . . . . 293
D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 292 D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 293
D.2. Aggregate Control Not Available . . . . . . . . . . . . . 292 D.2. Aggregate Control Not Available . . . . . . . . . . . . . 293
D.3. Aggregate Control Available . . . . . . . . . . . . . . . 293 D.3. Aggregate Control Available . . . . . . . . . . . . . . . 294
D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 294 D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 295
D.5. RTSP External SDP Delivery . . . . . . . . . . . . . . . 295 D.5. RTSP External SDP Delivery . . . . . . . . . . . . . . . 296
Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 295 Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 296
E.1. On-Demand Playback of Stored Content . . . . . . . . . . 295 E.1. On-Demand Playback of Stored Content . . . . . . . . . . 296
E.2. Unicast Distribution of Live Content . . . . . . . . . . 297 E.2. Unicast Distribution of Live Content . . . . . . . . . . 298
E.3. On-Demand Playback Using Multicast . . . . . . . . . . . 297 E.3. On-Demand Playback Using Multicast . . . . . . . . . . . 298
E.4. Inviting an RTSP Server into a Conference . . . . . . . . 298 E.4. Inviting an RTSP Server into a Conference . . . . . . . . 299
E.5. Live Content Using Multicast . . . . . . . . . . . . . . 299 E.5. Live Content Using Multicast . . . . . . . . . . . . . . 300
Appendix F. Text Format for Parameters . . . . . . . . . . . . . 299 Appendix F. Text Format for Parameters . . . . . . . . . . . . . 300
Appendix G. Requirements for Unreliable Transport of RTSP . . . 300 Appendix G. Requirements for Unreliable Transport of RTSP . . . 301
Appendix H. Backwards-Compatibility Considerations . . . . . . . 301 Appendix H. Backwards-Compatibility Considerations . . . . . . . 302
H.1. Play Request in Play State . . . . . . . . . . . . . . . 302 H.1. Play Request in Play State . . . . . . . . . . . . . . . 303
H.2. Using Persistent Connections . . . . . . . . . . . . . . 302 H.2. Using Persistent Connections . . . . . . . . . . . . . . 303
Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 302 Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 303
I.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 302 I.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 303
I.2. Detailed List of Changes . . . . . . . . . . . . . . . . 303 I.2. Detailed List of Changes . . . . . . . . . . . . . . . . 304
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 310 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 311
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 311 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 311 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 312
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-layer protocol for the setup (RTSP 2.0). RTSP 2.0 is an application-layer protocol for the setup
and control over the delivery of data with real-time properties, and 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. "network remote control" for multimedia servers.
skipping to change at page 12, line 13 skipping to change at page 12, line 13
method (Section 13.2). method (Section 13.2).
Parameters that commonly have to be included in the presentation Parameters that commonly have to be included in the presentation
description are the following: description are the following:
o The number of media streams; o The number of media streams;
o the resource identifier for each media stream/resource that is to o the resource identifier for each media stream/resource that is to
be controlled by RTSP; be controlled by RTSP;
o the protocol that each media stream is to be delivered over; o the protocol that will be used to deliver each media stream;
o the transport protocol parameters that are not negotiated or vary o the transport protocol parameters that are not negotiated or vary
with each client; with each client;
o the media-encoding information enabling a client to correctly o the media-encoding information enabling a client to correctly
decode the media upon reception; and decode the media upon reception; and
o an aggregate control resource identifier. o an aggregate control resource identifier.
RTSP uses its own URI schemes ("rtsp" and "rtsps") to reference media RTSP uses its own URI schemes ("rtsp" and "rtsps") to reference media
resources and aggregates under common control (see Section 4.2). resources and aggregates under common control (see Section 4.2).
This specification describes in Appendix D how one uses SDP [RFC4566] This specification describes in Appendix D how one uses SDP [RFC4566]
for presentation description. for describing the presentation.
2.2. Session Establishment 2.2. Session Establishment
The RTSP client can request the establishment of an RTSP session The RTSP client can request the establishment of an RTSP session
after having used the presentation description to determine which after having used the presentation description to determine which
media streams are available, which media delivery protocol is used, media streams are available, which media delivery protocol is used,
and the resource identifiers of the media streams. The RTSP session and the resource identifiers of the media streams. 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.
skipping to change at page 12, line 51 skipping to change at page 12, line 51
(Section 18.54) of the SETUP request, the client also includes all (Section 18.54) of the SETUP request, the client also includes all
the transport parameters necessary to enable the media delivery the transport parameters necessary to enable the media delivery
protocol to function. This includes parameters that are protocol to function. This includes parameters that are
preestablished by the presentation description but necessary for any preestablished by the presentation description but necessary for any
middlebox to correctly handle the media delivery protocols. The middlebox to correctly handle the media delivery protocols. The
Transport header in a request may contain multiple alternatives for Transport header in a request may contain multiple alternatives for
media delivery in a prioritized list, which the server can select media delivery in a prioritized list, which the server can select
from. These alternatives are typically based on information in the from. These alternatives are typically based on information in the
presentation description. presentation description.
The server determines if the media resource is available upon When receiving a SETUP request, the server determines if the media
receiving a SETUP request and if any of the transport parameter resource is available and if one or more of the of the transport
specifications are acceptable. If that is successful, an RTSP parameter specifications are acceptable. If that is successful, an
session context is created and the relevant parameters and state is RTSP session context is created and the relevant parameters and state
stored. An identifier is created for the RTSP session and included is stored. An identifier is created for the RTSP session and
in the response in the Session header (Section 18.49). The SETUP included in the response in the Session header (Section 18.49). The
response includes a Transport header that specifies which of the SETUP response includes a Transport header that specifies which of
alternatives has been selected and relevant parameters. the 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 multimedia for all media resources under RTSP control within a multimedia
content. However, aggregating resources from different content are content container. However, a server will likely refuse to aggregate
likely to be refused by the server. Even if an RTSP session contains resources from different content containers. Even if an RTSP session
only a single media, the RTSP session can be referenced by the contains only a single media stream, the RTSP session can be
aggregate control URI. referenced by the aggregate control URI.
To avoid an extra round trip in the session establishment of To avoid an extra round trip in the session establishment of
aggregated RTSP sessions, RTSP 2.0 supports pipelined requests; i.e., aggregated RTSP sessions, RTSP 2.0 supports pipelined requests; i.e.,
the client can send multiple requests back-to-back without waiting the client can send multiple requests back-to-back without waiting
first for the completion of any of them. The client uses a client- first for the completion of any of them. The client uses a client-
selected identifier in the Pipelined-Requests header (Section 18.33) selected identifier in the Pipelined-Requests header (Section 18.33)
to instruct the server to bind multiple requests together as if they to instruct the server to bind multiple requests together as if they
included the session identifier. included the session identifier.
The SETUP response also provides additional information about the The SETUP response also provides additional information about the
established sessions in a couple of different headers. The Media- established sessions in a couple of different headers. The Media-
Properties header (Section 18.29) includes a number of properties Properties header (Section 18.29) includes a number of properties
that apply for the aggregate that is valuable when doing media that apply for the aggregate that is valuable when doing media
delivery control and configuring user interface. The Accept-Ranges delivery control and configuring user interface. The Accept-Ranges
header (Section 18.5) informs the client about which range formats header (Section 18.5) informs the client about range formats that the
that the server supports with these media resources. The Media-Range server supports for these media resources. The Media-Range header
header (Section 18.30) informs the client about the time range of the (Section 18.30) informs the client about the time range of the media
media currently available. 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 "begin
using the PLAY method (Section 13.4) and Halt by using the PAUSE playback", using the PLAY method (Section 13.4) and "suspend (pause)
method (Section 13.6). PLAY also allows for choosing the starting playback" by using the PAUSE method (Section 13.6). PLAY also allows
media position from which the server should deliver the media. The for choosing the starting media position from which the server should
positioning is done by using the Range header (Section 18.40) that deliver the media. The positioning is done by using the Range header
supports several different time formats: Normal Play Time (NPT) (Section 18.40) that supports several different time formats: Normal
(Section 4.4.2), Society of Motion Picture and Television Engineers Play Time (NPT) (Section 4.4.2), Society of Motion Picture and
(SMPTE) Timestamps (Section 4.4.1), and absolute time Television Engineers (SMPTE) Timestamps (Section 4.4.1), and absolute
(Section 4.4.3). The Range header does further allow the client to time (Section 4.4.3). The Range header also allows 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 media content depends on The support for positioning/searching within media content depends on
the content's media properties. Content exists in a number of the content's media properties. Content exists in a number of
different types, such as: on-demand, live, and live with simultaneous different types, such as on-demand, live, and live with simultaneous
recording. Even within these categories, there are differences in recording. Even within these categories, there are differences in
how the content is generated and distributed, which affect how it can how the content is generated and distributed, which affect how it can
be accessed for playback. The properties applicable for the RTSP be 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 18.29). These are expressed using Media-Properties header (Section 18.29). 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 indicates whether positioning is possible, and with
granularity. Another aspect is whether the content will change what granularity. Another aspect is whether the content will change
during the lifetime of the session. While on-demand content will be during the lifetime of the session. While on-demand content will be
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 exists content that is dynamically built session goes on. There also exists content that is dynamically built
by a protocol other than RTSP and, thus, also changes in steps during by a protocol other 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 the complete content is not is recorded, there are cases where the complete content is not
maintained, but, for example, only the last hour. All of these maintained, but, for example, only the last hour. All of these
properties result in the need for mechanisms that will be discussed properties result in the need for mechanisms that will be discussed
below. below.
skipping to change at page 15, line 33 skipping to change at page 15, line 33
window that covers, for example, "now" to "now" minus 1 hour. A window that covers, for example, "now" to "now" minus 1 hour. A
client that pauses on a specific point within the content may not be client that pauses on a specific point within the content may not be
able to retrieve the content anymore. If the client waits too long able to retrieve the content anymore. If the client waits too long
before resuming the pause point, the content may no longer be before resuming the pause point, the content may no longer be
available. In this case, the pause point will be adjusted to the available. In this case, the pause point will be adjusted to the
closest point in the available media. closest point in the available media.
2.4. Session Parameter Manipulations 2.4. Session Parameter Manipulations
A session may have additional state or functionality that affects how A session may have additional state or functionality that affects how
the server or client treats the session and/or content, how it the server or client treats the session or content, how it functions,
functions, or feedback on how well the session works. Such or feedback on how well the session works. Such extensions are not
extensions are not defined in this specification, but they may be defined in this specification, but they may be covered in various
covered in various extensions. RTSP has two methods for retrieving extensions. RTSP has two methods for retrieving and setting
and setting parameter values on either the client or the server: parameter values on either the client or the server: GET_PARAMETER
GET_PARAMETER (Section 13.8) and SET_PARAMETER (Section 13.9). These (Section 13.8) and SET_PARAMETER (Section 13.9). These methods carry
methods carry the parameters in a message body of the appropriate the parameters in a message body of the appropriate format. One can
format. One can also use headers to query state with the also use headers to query state with the GET_PARAMETER method. As an
GET_PARAMETER method. As an example, clients needing to know the example, clients needing to know the current media range for a time-
current media-range for a time-progressing session can use the progressing session can use the GET_PARAMETER method and include the
GET_PARAMETER method and include the media-range. Furthermore, media range. Furthermore, synchronization information can be
synchronization information can be requested by using a combination requested by using a combination of RTP-Info (Section 18.45) and
of RTP-Info (Section 18.45) and Range (Section 18.40). Range (Section 18.40).
RTSP 2.0 does not have a strong mechanism for providing negotiation RTSP 2.0 does not have a strong mechanism for negotiating the headers
of the headers, or parameters and their formats, that can be used. or parameters and their formats. However, responses will indicate
However, responses will indicate request-headers or parameters that request-headers or parameters that are not supported. A priori
are not supported. A priori determination of what features are determination of what features are available needs to be done through
available needs to be done through out-of-band mechanisms, like the out-of-band mechanisms, like the session description, or through the
session description, or through the usage of feature tags usage of feature tags (Section 4.5).
(Section 4.5).
2.5. Media Delivery 2.5. Media Delivery
This document specifies how media is delivered with RTP [RFC3550] This document specifies how media is delivered with RTP [RFC3550]
over UDP [RFC0768], TCP [RFC0793], or the RTSP connection. over UDP [RFC0768], TCP [RFC0793], or the RTSP connection.
Additional protocols may be specified in the future based on demand. Additional protocols may be specified in the future as needed.
The usage of RTP as a media delivery protocol requires some The usage of RTP as a media delivery protocol requires some
additional information to function well. The PLAY response contains additional information to function well. The PLAY response contains
information to enable reliable and timely delivery of how a client information to enable reliable and timely delivery of how a client
should synchronize different sources in the different RTP sessions. should synchronize different sources in the different RTP sessions.
It also provides a mapping between RTP timestamps and the content- It also provides a mapping between RTP timestamps and the content-
time scale. When the server wants to notify the client about the time scale. When the server wants to notify the client about the
completion of the media delivery, it sends a PLAY_NOTIFY request to completion of the media delivery, it sends a PLAY_NOTIFY request to
the client. The PLAY_NOTIFY request includes information about the the client. The PLAY_NOTIFY request includes information about the
stream end, including the last RTP sequence number for each stream, stream end, including the last RTP sequence number for each stream,
skipping to change at page 16, line 43 skipping to change at page 16, line 43
Speed: The ratio of playback time delivered per unit of wallclock Speed: The ratio of playback time delivered per unit of wallclock
time. time.
Both affect the media delivery per time unit. However, they Both affect the media delivery per time unit. However, they
manipulate two independent timescales and the effects are possible to manipulate two independent timescales and the effects are possible to
combine. combine.
Scale (Section 18.46) is used for fast-forward or slow-motion control Scale (Section 18.46) is used for fast-forward or slow-motion control
as it changes the amount of content timescale that should be played as it changes the amount of content timescale that should be played
back per time unit. Scale > 1.0, means fast forward, e.g., Scale = back per time unit. Scale > 1.0, means fast forward, e.g., scale =
2.0 results in that 2 seconds of content being played back every 2.0 results in that 2 seconds of content being played back every
second of playback. Scale = 1.0 is the default value that is used if second of playback. Scale = 1.0 is the default value that is used if
no Scale is specified, i.e., playback at the content's original rate. no scale is specified, i.e., playback at the content's original rate.
Scale values between 0 and 1.0 provide for slow motion. Scale can be Scale values between 0 and 1.0 provide for slow motion. Scale can be
negative to allow for reverse playback in either regular pace (Scale negative to allow for reverse playback in either regular pace (scale
= -1.0), fast backwards (Scale < -1.0), or slow-motion backwards = -1.0), fast backwards (scale < -1.0), or slow-motion backwards
(-1.0 < Scale < 0). Scale = 0 would be equal to pause and is not (-1.0 < scale < 0). Scale = 0 would be equal to pause and is not
allowed. allowed.
In most cases, the realization of scale means server-side In most cases, the realization of scale means server-side
manipulation of the media to ensure that the client can actually play manipulation of the media to ensure that the client can actually play
it back. The nature of these media manipulations and when they are it back. The nature of these media manipulations and when they are
needed is highly media-type dependent. Let's consider an example needed is highly media-type dependent. Let's consider two common
with two common media types: audio and video. media types, audio and video.
It is very difficult to modify the playback rate of audio. A maximum It is very difficult to modify the playback rate of audio.
of 10-30% is possible by changing the pitch-rate of speech. Music Typically, no more than a factor of two is possible while maintaining
goes out of tune if one tries to manipulate the playback rate by intelligibility by changing the pitch and rate of speech. Music goes
out of tune if one tries to manipulate the playback rate by
resampling it. This is a well-known problem, and audio is commonly resampling it. This is a well-known problem, and audio is commonly
muted or played back in short segments with skips to keep up with the muted or played back in short segments with skips to keep up with the
current playback point. current playback point.
For video, it is possible to manipulate the frame rate, although the For video, it is possible to manipulate the frame rate, although the
rendering capabilities are often limited to certain frame rates. rendering capabilities are often limited to certain frame rates.
Also, the allowed bitrates in decoding, the structure used in the Also, the allowed bitrates in decoding, the structure used in the
encoding, and the dependency between frames and other capabilities of encoding, and the dependency between frames and other capabilities of
the rendering device limits the possible manipulations. Therefore, the rendering device limits the possible manipulations. Therefore,
the basic fast-forward capabilities often are implemented by the basic fast-forward capabilities often are implemented by
selecting certain subsets of frames. selecting certain subsets of frames.
Due to the media restrictions, the possible scale values are commonly Due to the media restrictions, the possible scale values are commonly
restricted to the set of realizable scale ratios. To enable the restricted to the set of realizable scale ratios. To enable the
clients to select from the possible scale values, RTSP can signal the clients to select from the possible scale values, RTSP can signal the
supported Scale ratios for the content. To support aggregated or supported scale ratios for the content. To support aggregated or
dynamic content, where this may change during the ongoing session and dynamic content, where this may change during the ongoing session and
dependent on the location within the content, a mechanism for dependent on the location within the content, a mechanism for
updating the media properties and the scale factor currently in use, updating the media properties and the scale factor currently in use,
exists. exists.
Speed (Section 18.50) affects how much of the playback timeline is Speed (Section 18.50) affects how much of the playback timeline is
delivered in a given wallclock period. The default is Speed = 1 delivered in a given wallclock period. The default is Speed = 1
which means to deliver at the same rate the media is consumed. Speed which means to deliver at the same rate the media is consumed. Speed
> 1 means that the receiver will get content faster than it regularly > 1 means that the receiver will get content faster than it regularly
would consume it. Speed < 1 means that delivery is slower than the would consume it. Speed < 1 means that delivery is slower than the
skipping to change at page 19, line 30 skipping to change at page 19, line 30
header. header.
The session context is normally terminated by the client sending a The session context is normally terminated by the client sending a
TEARDOWN request (Section 13.7) to the server referencing the TEARDOWN request (Section 13.7) to the server referencing the
aggregated control URI. An individual media resource can be removed aggregated control URI. An individual media resource can be removed
from a session context by a TEARDOWN request referencing that from a session context by a TEARDOWN request referencing that
particular media resource. If all media resources are removed from a particular media resource. If all media resources are removed from a
session context, the session context is terminated. session context, the session context is terminated.
A client may keep the session alive indefinitely if allowed by the A client may keep the session alive indefinitely if allowed by the
server; however, a client is recommended to release the session server; however, a client is advised to release the session context
context when an extended period of time without media delivery when an extended period of time without media delivery activity has
activity has passed. The client can re-establish the session context passed. The client can re-establish the session context if required
if required later. What constitutes an extended period of time is later. What constitutes an extended period of time is dependent on
dependent on the client, server, and their usage. It is recommended the client, server, and their usage. It is recommended that the
that the client terminate the session before ten times the session client terminate the session before ten times the session timeout
timeout value has passed. A server may terminate the session after value has passed. A server may terminate the session after one
one session timeout period without any client activity beyond keep- session timeout period without any client activity beyond keep-alive.
alive. When a server terminates the session context, it does so by When a server terminates the session context, it does so by sending a
sending a TEARDOWN request indicating the reason. TEARDOWN request indicating the reason.
A server can also request that the client tear down the session and A server can also request that the client tear down the session and
re-establish it at an alternative server, as may be needed for re-establish it at an alternative server, as may be needed for
maintenance. This is done by using the REDIRECT method maintenance. This is done by using the REDIRECT method
(Section 13.10). The Terminate-Reason header (Section 18.52) is used (Section 13.10). The Terminate-Reason header (Section 18.52) is used
to indicate when and why. The Location header indicates where it to indicate when and why. The Location header indicates where it
should connect if there is an alternative server available. When the should connect if there is an alternative server available. When the
deadline expires, the server simply stops providing the service. To deadline expires, the server simply stops providing the service. To
achieve a clean closure, the client needs to initiate session achieve a clean closure, the client needs to initiate session
termination prior to the deadline. In case the server has no other termination prior to the deadline. In case the server has no other
skipping to change at page 20, line 12 skipping to change at page 20, line 12
maintenance, it shall use the TEARDOWN method with a Terminate-Reason maintenance, it shall use the TEARDOWN method with a Terminate-Reason
header. header.
2.7. Extending RTSP 2.7. Extending RTSP
RTSP is quite a versatile protocol that supports extensions in many RTSP is quite a versatile protocol that 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 address additional use cases. However, extensions will affect the
the interoperability of the protocol; therefore, it is important that interoperability of the protocol; therefore, it is important that
they can be added in a structured way. 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 18.51). It method (Section 13.1) and the Supported header (Section 18.51). 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 be supported using the Require (Section 18.43) or particular features be supported using the Require (Section 18.43) or
Proxy-Require (Section 18.37) header. Proxy-Require (Section 18.37) header.
The RTSP, in itself, can be extended in three ways, listed here in The RTSP, in itself, can be extended in three ways, listed here in
increasing order of the magnitude of changes supported: increasing order of the magnitude of changes supported:
skipping to change at page 22, line 21 skipping to change at page 22, line 21
streaming where the relationship is less strict. streaming where the relationship is less strict.
Feature-tag: A tag representing a certain set of functionality, Feature-tag: A tag representing a certain set of functionality,
i.e., a feature. i.e., a feature.
IRI: An Internationalized Resource Identifier is similar to a URI IRI: An Internationalized Resource Identifier is similar to a URI
but allows characters from the whole Universal Character Set but allows characters from the whole Universal Character Set
(Unicode/ISO 10646), rather than the US-ASCII only. See [RFC3987] (Unicode/ISO 10646), rather than the US-ASCII only. See [RFC3987]
for more information. for more information.
Live: A term normally used to describe a presentation or session Live: A live presentation or session originates media from an event
with media coming from an ongoing event. This generally results taking place at the same time as the media delivery. Live
in the session having an unbound or only loosely defined duration sessions often have an unbound or only loosely defined duration
and sometimes no seek operations are possible. and seek operations may not be possible.
Media initialization: The datatype/codec specific initialization. Media initialization: The datatype- or codec-specific
This includes such things as clock rates, color tables, etc. Any initialization. This includes such things as clock rates, color
transport-independent information that is required by a client for tables, etc. Any transport-independent information that is
playback of a media stream occurs in the media initialization required by a client for playback of a media stream occurs in the
phase of stream setup. media initialization phase of stream setup.
Media parameter: A parameter specific to a media type that may be Media parameter: A parameter specific to a media type that may be
changed before or during stream delivery. changed before or during stream delivery.
Media server: The server providing media-delivery services for one Media server: The server providing media-delivery services for one
or more media streams. Different media streams within a or more media streams. Different media streams within a
presentation may originate from different media servers. A media presentation may originate from different media servers. A media
server may reside on the same host or on a different host from server may reside on the same host or on a different host from
which the presentation is invoked. which the presentation is invoked.
(Media) Stream: A single media instance, e.g., an audio stream or a (Media) Stream: A single media instance, e.g., an audio stream or a
video stream as well as a single whiteboard or shared application video stream as well as a single whiteboard or shared application
group. When using RTP, a stream consists of all RTP and RTCP group. When using RTP, a stream consists of all RTP and RTCP
packets created by a source within an RTP session. packets created by a media source within an RTP session.
Message: The basic unit of RTSP communication, consisting of a Message: The basic unit of RTSP communication, consisting of a
structured sequence of octets matching the syntax defined in structured sequence of octets matching the syntax defined in
Section 20 and transmitted over a connection-based transport. A Section 20 and transmitted over a transport between RTSP agents.
message is either a Request or a Response. A message is either a request or a response.
Message body: The information transferred as the payload of a Message body: The information transferred as the payload of a
message (Request or response). A message body consists of meta- message (request or response). A message body consists of meta-
information in the form of message-body headers and content in the information in the form of message body headers and content in the
form of an arbitrary number of data octets, as described in form of an arbitrary number of data octets, as described in
Section 9. Section 9.
Non-aggregated control: Control of a single media stream. Non-aggregated control: Control of a single media stream.
Presentation: A set of one or more streams presented to the client Presentation: A set of one or more streams presented to the client
as a complete media feed and described by a presentation as a complete media feed and described by a presentation
description as defined below. Presentations with more than one description as defined below. Presentations with more than one
media stream are often handled in RTSP under aggregate control. media stream are often handled in RTSP under aggregate control.
Presentation description: A presentation description contains Presentation description: A presentation description contains
information about one or more media streams within a presentation, information about one or more media streams within a presentation,
such as the set of encodings, network addresses, and information such as the set of encodings, network addresses, and information
about the content. Other IETF protocols, such as SDP ([RFC4566]), about the content. Other IETF protocols, such as SDP ([RFC4566]),
use the term "session" for a presentation. The presentation use the term "session" for a presentation. The presentation
description may take several different formats, including but not description may take several different formats, including but not
limited to SDP format. limited to SDP format.
Response: An RTSP response to a Request. One type of RTSP message. Response: An RTSP response to a request. One type of RTSP message.
If an HTTP response is meant, it is indicated explicitly. If an HTTP response is meant, it is indicated explicitly.
Request: An RTSP request. One type of RTSP message. If an HTTP Request: An RTSP request. One type of RTSP message. If an HTTP
request is meant, it is indicated explicitly. request is meant, it is indicated explicitly.
Request-URI: The URI used in a request to indicate the resource on Request-URI: The URI used in a request to indicate the resource on
which the request is to be performed. which the request is to be performed.
RTSP agent: Either an RTSP client, an RTSP server, or an RTSP proxy. RTSP agent: Either an RTSP client, an RTSP server, or an RTSP proxy.
In this specification, there are many capabilities that are common In this specification, there are many capabilities that are common
skipping to change at page 25, line 22 skipping to change at page 25, line 22
defined in RTSP 1.0. The "rtspu" scheme indicates unspecified defined in RTSP 1.0. The "rtspu" scheme indicates unspecified
transport of the RTSP messages over unreliable transport means (UDP transport of the RTSP messages over unreliable transport means (UDP
in RTSP 1.0). An RTSP server MUST respond with an error code in RTSP 1.0). An RTSP server MUST respond with an error code
indicating the "rtspu" scheme is not implemented (501) to a request indicating the "rtspu" scheme is not implemented (501) to a request
that carries a "rtspu" URI scheme. that carries a "rtspu" URI scheme.
The details of the syntax of "rtsp" and "rtsps" URIs have been The details of the syntax of "rtsp" and "rtsps" URIs have been
changed from RTSP 1.0. These changes include the addition of: changed from RTSP 1.0. These changes include the addition of:
o Support for an IPv6 literal in the host part and future IP o Support for an IPv6 literal in the host part and future IP
literals through a mechanism defined in RFC 3986. literals through a mechanism defined in [RFC3986].
o A new relative format to use in the RTSP elements that is not o A new relative format to use in the RTSP elements that is not
required to start with "/". required to start with "/".
Neither should have any significant impact on interoperability. If Neither should have any significant impact on interoperability. If
one is required to use IPv6 literals to reach an RTSP server, then IPv6 literals are needed in the RTSP URI, then that RTSP server must
that RTSP server must be IPv6 capable, and RTSP 1.0 is not a fully be IPv6 capable, and RTSP 1.0 is not a fully IPv6 capable protocol.
IPv6 capable protocol. If an RTSP 1.0 client attempts to process the If an RTSP 1.0 client attempts to process the URI, the URI will not
URI, the URI will not match the allowed syntax, it will be considered match the allowed syntax, it will be considered invalid, and
invalid, and processing will be stopped. This is clearly a failure processing will be stopped. This is clearly a failure to reach the
to reach the resource; however, it is not a signification issue as resource; however, it is not a signification issue as RTSP 2.0
RTSP 2.0 support was needed anyway in both server and client. Thus, support was needed anyway in both server and client. Thus, failure
failure will only occur in a later step when there is an RTSP version will only occur in a later step when there is an RTSP version
mismatch between client and server. The second change will only mismatch between client and server. The second change will only
occur inside RTSP message headers, as the Request-URI must be an occur inside RTSP message headers, as the Request-URI must be an
absolute URI. Thus, such usages will only occur after an agent has absolute URI. Thus, such usages will only occur after an agent has
accepted and started processing RTSP 2.0 messages, and an agent using accepted and started processing RTSP 2.0 messages, and an agent using
RTSP 1.0 only will not be required to parse such types of relative RTSP 1.0 only will not be required to parse such types of relative
URIs. URIs.
This specification also defines the format of the RTSP IRIs [RFC3987] This specification also defines the format of RTSP IRIs [RFC3987]
that can be used as RTSP resource identifiers and locators in that can be used as RTSP resource identifiers and locators on web
addition to in web pages, user interfaces, on paper, etc. However, pages, user interfaces, on paper, etc. However, the RTSP request
the RTSP request message format only allows usage of the absolute URI message format only allows usage of the absolute URI format. The
format. The RTSP IRI format MUST use the rules and transformation RTSP IRI format MUST use the rules and transformation for IRIs to
for IRIs to URIs, as defined in [RFC3987]. This allows a URI that URIs, as defined in [RFC3987]. This allows a URI that matches the
matches the RTSP 2.0 specification, and so is suitable for use in a RTSP 2.0 specification, and so is suitable for use in a request, to
request, to be created from an RTSP IRI. be created from an RTSP IRI.
The RTSP IRI and URI are both syntax restricted compared to the The RTSP IRI and URI are both syntax restricted compared to the
generic syntax defined in [RFC3986] and [RFC3987]: generic syntax defined in [RFC3986] and [RFC3987]:
o An absolute URI requires the authority part; i.e., a host identity o An absolute URI requires the authority part; i.e., a host identity
MUST be provided. MUST be provided.
o Parameters in the path element are prefixed with the reserved o Parameters in the path element are prefixed with the reserved
separator ";". separator ";".
skipping to change at page 27, line 16 skipping to change at page 27, line 16
may identify the audio stream within the presentation "twister", may identify the audio stream within the presentation "twister",
which can be controlled via RTSP requests issued over a TCP which can be controlled via RTSP requests issued over a TCP
connection to port 554 of host media.example.com. connection to port 554 of host media.example.com.
Also, the RTSP URI: Also, the RTSP URI:
rtsp://media.example.com:554/twister rtsp://media.example.com:554/twister
identifies the presentation "twister", which may be composed of audio identifies the presentation "twister", which may be composed of audio
and video streams, but could also be something else like a random and video streams, but could also be something else, such as a random
media redirector. media redirector.
This does not imply a standard way to reference streams in URIs. This does not imply a standard way to reference streams in URIs.
The presentation description defines the hierarchical The presentation description defines the hierarchical
relationships in the presentation and the URIs for the individual relationships in the presentation and the URIs for the individual
streams. A presentation description may name a stream "a.mov" and streams. A presentation description may name a stream "a.mov" and
the whole presentation "b.mov". the whole presentation "b.mov".
The path components of the RTSP URI are opaque to the client and do The path components of the RTSP URI are opaque to the client and do
not imply any particular file system structure for the server. not imply any particular file system structure for the server.
This decoupling also allows presentation descriptions to be used This decoupling also allows presentation descriptions to be used
with non-RTSP media control protocols simply by replacing the with non-RTSP media control protocols simply by replacing the
scheme in the URI. scheme in the URI.
4.3. Session Identifiers 4.3. Session Identifiers
Session identifiers are strings of a length between 8-128 characters. Session identifiers are strings of a length between 8-128 characters.
A session identifier MUST be generated using methods resulting A session identifier MUST be generated using methods that make it
cryptographically random properties (see [RFC4086]). It is cryptographically random (see [RFC4086]). It is RECOMMENDED that a
RECOMMENDED that a session identifier contain 128 bits of entropy, session identifier contain 128 bits of entropy, i.e., approximately
i.e., approximately 22 characters from a high-quality generator (see 22 characters from a high-quality generator (see Section 21).
Section 21). However, note that the session identifier does not However, note that the session identifier does not provide any
provide any security against session hijacking unless it is kept security against session hijacking unless it is kept confidential by
confidential by the client, server, and trusted proxies. the client, server, and trusted proxies.
4.4. Media-Time Formats 4.4. Media-Time Formats
RTSP currently supports three different media-time formats defined RTSP currently supports three different media-time formats defined
below. Additional time formats may be specified in the future. below. Additional time formats may be specified in the future.
These time formats can be used with the Range header (Section 18.40) These time formats can be used with the Range header (Section 18.40)
to request playback and specify at which media position protocol to request playback and specify at which media position protocol
requests actually will or have taken place. They are also used in requests actually will or have taken place. They are also used in
description of the media's properties using the Media-Range header description of the media's properties using the Media-Range header
(Section 18.30). The unqualified format identifier is used on its (Section 18.30). The unqualified format identifier is used on its
own in Accept-Ranges header (Section 18.5) to declare supported time own in Accept-Ranges header (Section 18.5) to declare supported time
formats and also in the Range header (Section 18.40) to request the formats and also in the Range header (Section 18.40) to request the
time format used in the response. time format used in the response.
4.4.1. SMPTE-Relative Timestamps 4.4.1. SMPTE-Relative Timestamps
A timestamp that is relative to the Society of Motion Picture and A timestamp may use a format derived from a Society of Motion Picture
Television Engineers (SMPTE) expresses time as relates to the start and Television Engineers (SMPTE) specification and expresses time
of the clip. Relative timestamps are expressed as SMPTE time codes offsets anchored at the start of the media clip. Relative timestamps
[SMPTE-TC] for frame-level access accuracy. The time code has the are expressed as SMPTE time codes [SMPTE-TC] for frame-level access
format: accuracy. The time code has the format:
hours:minutes:seconds:frames.subframes hours:minutes:seconds:frames.subframes
with the origin at the start of the clip. The default SMPTE format with the origin at the start of the clip. The default SMPTE format
is "SMPTE 30 drop" format, with a frame rate of 29.97 frames per is "SMPTE 30 drop" format, with a frame rate of 29.97 frames per
second. Other SMPTE codes MAY be supported (such as "SMPTE 25") second. Other SMPTE codes MAY be supported (such as "SMPTE 25")
through the use of "smpte-type". For SMPTE 30, the "frames" field in through the use of "smpte-type". For SMPTE 30, the "frames" field in
the time value can assume the values 0 through 29. The difference the time value can assume the values 0 through 29. The difference
between 30 and 29.97 frames per second is handled by dropping the between 30 and 29.97 frames per second is handled by dropping the
first two frame indices (values 00 and 01) of every minute, except first two frame indices (values 00 and 01) of every minute, except
skipping to change at page 29, line 9 skipping to change at page 29, line 9
values are not defined. values are not defined.
The special constant "now" is defined as the current instant of a The special constant "now" is defined as the current instant of a
live event. It MAY only be used for live events and MUST NOT be used live event. It MAY only be used for live events and MUST NOT be used
for on-demand (i.e., non-live) content. for on-demand (i.e., non-live) content.
NPT is defined as in Digital Storage Media Command and Control NPT is defined as in Digital Storage Media Command and Control
(DSMb;CC) [ISO.13818-6.1995]: (DSMb;CC) [ISO.13818-6.1995]:
Intuitively, NPT is the clock the viewer associates with a Intuitively, NPT is the clock the viewer associates with a
program. It is often digitally displayed on a VCR. NPT advances program. It is often digitally displayed on a DVD player. NPT
normally when in normal play mode (scale = 1), advances at a advances normally when in normal play mode (scale = 1), advances
faster rate when in fast-scan forward (high positive scale ratio), at a faster rate when in fast-scan forward (high positive scale
decrements when in scan reverse (negative scale ratio) and is ratio), decrements when in scan reverse (negative scale ratio) and
fixed in pause mode. NPT is (logically) equivalent to SMPTE time is fixed in pause mode. NPT is (logically) equivalent to SMPTE
codes. time codes.
Examples: Examples:
npt=123.45-125 npt=123.45-125
npt=12:05:35.3- npt=12:05:35.3-
npt=now- npt=now-
The syntax is based on ISO 8601 [ISO.8601.2000] and expresses the The syntax is based on ISO 8601 [ISO.8601.2000] and expresses the
time elapsed since presentation start, with two different notations time elapsed since presentation start, with two different notations
allowed: allowed:
skipping to change at page 29, line 40 skipping to change at page 29, line 40
to 0-24 hours; up to nineteen (19) hour digits are allowed. to 0-24 hours; up to nineteen (19) hour digits are allowed.
* In accordance with the requirements of the ISO 8601 time * In accordance with the requirements of the ISO 8601 time
format, the hours, minutes, and seconds MUST all be present, format, the hours, minutes, and seconds MUST all be present,
with two digits used for minutes and for seconds and with at with two digits used for minutes and for seconds and with at
least two digits for hours. An NPT of 7 minutes and 0 seconds least two digits for hours. An NPT of 7 minutes and 0 seconds
is represented as "00:07:00", and an NPT of 392 hours, 0 is represented as "00:07:00", and an NPT of 392 hours, 0
minutes, and 6 seconds is represented as "392:00:06". minutes, and 6 seconds is represented as "392:00:06".
* RTSP 1.0 allowed NPT in the npt-hhmmss notation without any * RTSP 1.0 allowed NPT in the npt-hhmmss notation without any
leading zeros to ensure that implementations don't fail; if any leading zeros to ensure that implementations don't fail; for
implementation follows the RTSP 1.0 format, all implementations backward compatibility, all RTSP 2.0 implementations are are
are REQUIRED to support receiving NPT values, hours, minutes, REQUIRED to support receiving NPT values, hours, minutes, or
or seconds, without leading zeros. seconds, without leading zeros.
o The npt-sec notation expresses the time in seconds, using between o The npt-sec notation expresses the time in seconds, using between
one and nineteen (19) digits. one and nineteen (19) digits.
Both notations allow decimal fractions of seconds as specified in Both notations allow decimal fractions of seconds as specified in
Section 5.3.1.3 of [ISO.8601.2000], using at most nine digits, and Section 5.3.1.3 of [ISO.8601.2000], using at most nine digits, and
allowing only "." (full stop) as the decimal separator. allowing only "." (full stop) as the decimal separator.
The npt-sec notation is optimized for automatic generation; the npt- The npt-sec notation is optimized for automatic generation; the npt-
hhmmss notation is optimized for consumption by human readers. The hhmmss notation is optimized for consumption by human readers. The
"now" constant allows clients to request to receive the live feed "now" constant allows clients to request to receive the live feed
rather than the stored or time-delayed version. This is needed since rather than the stored or time-delayed version. This is needed since
neither absolute time nor zero time are appropriate for this case. neither absolute time nor zero time are appropriate for this case.
4.4.3. Absolute Time 4.4.3. Absolute Time
Absolute time is expressed following a specific type of timestamp Absolute time is expressed using a timestamp based on ISO 8601
based on ISO 8601 [ISO.8601.2000]. The date is a complete [ISO.8601.2000]. The date is a complete representation of the
representation calendar date in basic format (YYYYMMDD) without calendar date in basic format (YYYYMMDD) without separators (per
separators (per Section 5.2.1.1 of [ISO.8601.2000]). The time of day Section 5.2.1.1 of [ISO.8601.2000]). The time of day is provided in
is provided in the complete representation basic format (hhmmss) as the complete representation basic format (hhmmss) as specified in
specified in Section 5.3.1.1 of [ISO.8601.2000], allowing decimal Section 5.3.1.1 of [ISO.8601.2000], allowing decimal fractions of
fractions of seconds following Section 5.3.1.3 requiring "." (full seconds following Section 5.3.1.3 requiring "." (full stop) as
stop) as decimal separator and limiting the number of digits to no decimal separator and limiting the number of digits to no more than
more than nine. The time expressed MUST use UTC (GMT), i.e., no time nine. The time expressed MUST use UTC (GMT), i.e., no time zone
zone offsets are allowed. The full date and time specification is offsets are allowed. The full date and time specification is the
the eight-digit date followed by a "T" followed by the six-digit time eight-digit date followed by a "T" followed by the six-digit time
value, optionally followed by a full stop followed by one to nine value, optionally followed by a full stop followed by one to nine
fractions of a second and ended by "Z", e.g., YYYYMMDDThhmmss.ssZ. fractions of a second and ended by "Z", e.g., YYYYMMDDThhmmss.ssZ.
The reasons for this time format rather than using "Date and Time The reasons for this time format rather than using "Date and Time
on the Internet: Timestamps" [RFC3339] are historic. We continue on the Internet: Timestamps" [RFC3339] are historic. We continue
to use the format specified in RTSP 1.0. The motivations raised to use the format specified in RTSP 1.0. The motivations raised
in RFC 3339 apply to why a selection from ISO 8601 was made; in RFC 3339 apply to why a selection from ISO 8601 was made;
however, a different and even more restrictive selection was however, a different and even more restrictive selection was
applied in this case. applied in this case.
Example for clock format range request for a starting time of Below are three examples of media time formats, first, a request for
November 8, 1996 at 14 h 37 min and 20 1/4 seconds UTC playing for 10 a clock format range request for a starting time of November 8, 1996
min and 5 seconds, a Media-Properties header's "Time-Limited UTC at 14 h 37 min and 20 1/4 seconds UTC playing for 10 min and 5
seconds, followed by a Media-Properties header's "Time-Limited" UTC
property for the 24th of December 2014 at 15 hours and 00 minutes, property for the 24th of December 2014 at 15 hours and 00 minutes,
and a Terminate-Reason header "time" property for the 18th of June and finally a Terminate-Reason header "time" property for the 18th of
2013 at 16 hours, 12 minutes, and 56 seconds: June 2013 at 16 hours, 12 minutes, and 56 seconds:
clock=19961108T143720.25Z-19961108T144725.25Z clock=19961108T143720.25Z-19961108T144725.25Z
Time-Limited=20141224T1500Z Time-Limited=20141224T1500Z
time=20130618T161256Z time=20130618T161256Z
4.5. Feature-Tags 4.5. 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 18.43), Proxy-Require RTSP. These tags are used in Require (Section 18.43), Proxy-Require
(Section 18.37), Proxy-Supported (Section 18.38), Supported (Section 18.37), Proxy-Supported (Section 18.38), Supported
skipping to change at page 32, line 6 skipping to change at page 32, line 6
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
have. This specification considers the media properties listed below have. This specification considers the media properties listed below
in its protocol operations. They are derived from the differences in its protocol operations. They are derived from the differences
between a number of supported usages. between a number of supported usages.
On-demand: Media that has a fixed (given) duration that doesn't On-demand: Media that has a fixed (given) duration that doesn't
change during the lifetime of the RTSP session and is known at the change during the lifetime of the RTSP session and is known at the
time of the creation of the session. It is expected that the time of the creation of the session. It is expected that the
content of the media will not change, even if the representation, content of the media will not change, even if the representation,
i.e., encoding, quality, etc., may change. Generally, one can such as encoding, or quality, may change. Generally, one can
seek, i.e., request any range, within the media. seek, i.e., request any range, within the media.
Dynamic On-demand: This is a variation of the on-demand case where Dynamic On-demand: This is a variation of the on-demand case where
external methods are used to manipulate the actual content of the external methods are used to manipulate the actual content of the
media setup for the RTSP session. The main example is content media setup for the RTSP session. The main example is content
defined by a playlist. defined by a playlist.
Live: Live media represents a progressing content stream (such as Live: Live media represents a progressing content stream (such as
broadcast TV) where the duration may or may not be known. It is broadcast TV) where the duration may or may not be known. It is
not seekable, only the content presently being delivered can be not seekable, only the content presently being delivered can be
skipping to change at page 33, line 13 skipping to change at page 33, line 13
content. content.
No-Seeking: Seeking is not possible at all. No-Seeking: Seeking is not possible at all.
If random access is possible, as indicated by the Media-Properties If random access is possible, as indicated by the Media-Properties
header, the actual behavior policy when seeking can be controlled header, the actual behavior policy when seeking can be controlled
using the Seek-Style header (Section 18.47). using the Seek-Style header (Section 18.47).
4.7.2. Retention 4.7.2. Retention
Media may have different retention policies in place that affect the The following retention policies are used by media to limit possible
possible protocol operations on the media. The following different protocol operations:
media retention policies are defined:
Unlimited: The media will not be removed as long as the RTSP session Unlimited: The media will not be removed as long as the RTSP session
is in existence. is in existence.
Time-Limited: The media will not be removed before the given Time-Limited: The media will not be removed before the given
wallclock time. After that time, it may or may not be available wallclock time. After that time, it may or may not be available
anymore. anymore.
Time-Duration: The media (on fragment or unit basis) will be Time-Duration: The media (on fragment or unit basis) will be
retained for the specified duration. retained for the specified duration.
4.7.3. Content Modifications 4.7.3. Content Modifications
The media content and its timeline can be of different types, e.g. The media content and its timeline can be of different types, e.g.
pre-produced content on demand, a live source that is being generated pre-produced content on demand, a live source that is being generated
as time progresses, or something that is dynamically altered or as time progresses, or something that is dynamically altered or
recomposed during playback. Therefore, a media property for content recomposed during playback. Therefore, a media property for content
modifications is needed and the following initial values are defined: modifications is needed and the following initial values are defined:
Immutable: The content of the media will not change, even if the Immutable: The content of the media will not change, even if the
representation, i.e., encoding, quality, etc., changes. representation, such as encoding or quality changes.
Dynamic: The content can change due to external methods or triggers, Dynamic: The content can change due to external methods or triggers,
such as playlists, but this will be announced by explicit updates. such as playlists, but this will be announced by explicit updates.
Time-Progressing: As time progresses, new content will become Time-Progressing: As time progresses, new content will become
available. If the content is also retained, it will become longer available. If the content is also retained, it will become longer
as everything between the start point and the point currently as everything between the start point and the point currently
being made available can be accessed. If the media server uses a being made available can be accessed. If the media server uses a
sliding-window policy for retention, the start point will also sliding-window policy for retention, the start point will also
change as time progresses. change as time progresses.
4.7.4. Supported Scale Factors 4.7.4. Supported Scale Factors
Content often supports only a limited set or range of scales when A particular media content item often supports only a limited set or
delivering the media. To enable the client to know what values or range of scales when delivering the media. To enable the client to
ranges of scale operations that the whole content or the current know what values or ranges of scale operations that the whole content
position supports, a media properties attribute for this is defined or the current position supports, a media properties attribute for
that contains a list with the values and/or ranges that are this is defined that contains a list with the values or ranges that
supported. The attribute is named "Scales". The "Scales" attribute are supported. The attribute is named "Scales". The "Scales"
may be updated at any point in the content due to content consisting attribute may be updated at any point in the content due to content
of spliced pieces or content being dynamically updated by out-of-band consisting of spliced pieces or content being dynamically updated by
mechanisms. out-of-band mechanisms.
4.7.5. Mapping to the Attributes 4.7.5. Mapping to the Attributes
This section shows examples of how one would map the above usages to This section shows examples of how one would map the above usages to
the properties and their values. the properties and their values.
Example of On-Demand: Example of On-Demand:
Random Access: Random-Access=5.0, Content Modifications: Random Access: Random-Access=5.0, Content Modifications:
Immutable, Retention: Unlimited or Time-Limited. Immutable, Retention: Unlimited or Time-Limited.
skipping to change at page 34, line 43 skipping to change at page 34, line 42
RTSP is a text-based protocol that uses the ISO 10646 character set RTSP is a text-based protocol that uses the ISO 10646 character set
in UTF-8 encoding per RFC 3629 [RFC3629]. Lines MUST be terminated in UTF-8 encoding per RFC 3629 [RFC3629]. Lines MUST be terminated
by a CRLF. by a CRLF.
Text-based protocols make it easier to add optional parameters in Text-based protocols make it easier to add optional parameters in
a self-describing manner. Since the number of parameters and the a self-describing manner. Since the number of parameters and the
frequency of commands is low, processing efficiency is not a frequency of commands is low, processing efficiency is not a
concern. Text-based protocols, if used carefully, also allow easy concern. Text-based protocols, if used carefully, also allow easy
implementation of research prototypes in scripting languages such implementation of research prototypes in scripting languages such
as TCL, Visual Basic, and Perl. as Python, PHP, Perl and TCL.
The ISO 10646 character set avoids character-set switching, but is The ISO 10646 character set avoids character-set switching, but is
invisible to the application as long as US-ASCII is being used. This invisible to the application as long as US-ASCII is being used. This
is also the encoding used for RTCP [RFC3550]. is also the encoding used for text fields in RTCP [RFC3550].
A request contains a method, the object the method is operating upon, A request contains a method, the object the method is operating upon,
and parameters to further describe the method. Methods are and parameters to further describe the method. Methods are
idempotent unless otherwise noted. Methods are also designed to idempotent unless otherwise noted. Methods are also designed to
require little or no state maintenance at the media server. require little or no state maintenance at the media server.
5.1. Message Types 5.1. Message Types
RTSP messages are either requests from client to server or from RTSP messages are either requests from client to server or from
server to client, and responses in the reverse direction. Request server to client, and responses in the reverse direction. Request
(Section 7) and Response (Section 8) messages use a format based on (Section 7) and response (Section 8) messages use a format based on
the generic message format of RFC 5322 [RFC5322] for transferring the generic message format of RFC 5322 [RFC5322] for transferring
bodies (the payload of the message). Both types of messages consist bodies (the payload of the message). Both types of messages consist
of a start-line, zero or more header fields (also known as of a start-line, zero or more header fields (also known as
"headers"), an empty line (i.e., a line with nothing preceding the "headers"), an empty line (i.e., a line with nothing preceding the
CRLF) indicating the end of the headers, and possibly the data of the CRLF) indicating the end of the headers, and possibly the data of the
message body. The ABNF [RFC5234] below is for information and the message body. The ABNF [RFC5234] below is for illustration only; the
formal message specification is present in Section 20.2.2. formal message specification is presented in Section 20.2.2.
generic-message = start-line generic-message = start-line
*(rtsp-header CRLF) *(rtsp-header CRLF)
CRLF CRLF
[ 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 Status-Line is expected. In other received where a Request-Line or Status-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 any number of CRLFs first, it MUST ignore of a message and receives any number of CRLFs first, it MUST ignore
all of the CRLFs. all of the CRLFs.
5.2. Message Headers 5.2. Message Headers
RTSP header fields (see Section 18) 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 a request-header or general-header fields first, followed by a request-header or
response-header field, and ending with the message-body header response-header field, and ending with the message body header
fields. fields.
Multiple header fields with the same field-name MAY be present in a Multiple header fields with the same field-name MAY be present in a
message if and only if the entire field-value for that header field message if and only if the entire field-value for that header field
is defined as a comma-separated list. It MUST be possible to combine is defined as a comma-separated list. It MUST be possible to combine
the multiple header fields into one "field-name: field-value" pair, the multiple header fields into one "field-name: field-value" pair,
without changing the semantics of the message, by appending each without changing the semantics of the message, by appending each
subsequent field-value to the first, each separated by a comma. The subsequent field-value to the first, each separated by a comma. The
order in which header fields with the same field-name are received is order in which header fields with the same field-name are received is
therefore significant to the interpretation of the combined field therefore significant to the interpretation of the combined field
value; thus, a proxy MUST NOT change the order of these field values value; thus, a proxy MUST NOT change the order of these field values
when a message is forwarded. 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 an RTSP the next protocol element, and not causing an error) by an RTSP
server or client. An RTSP Proxy MUST forward unknown message server or client. An RTSP proxy MUST forward unknown message
headers. Message headers defined outside of this specification that headers. Message headers defined outside of this specification that
are required to be interpreted by the RTSP agent will need to use are required to be interpreted by the RTSP agent will need to use
feature tags (Section 4.5) and include them in the appropriate feature tags (Section 4.5) and include them in the appropriate
Require (Section 18.43) or Proxy-Require (Section 18.37) header. Require (Section 18.43) or Proxy-Require (Section 18.37) 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 an SDP message. response. An example of a message body is an SDP message.
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 18.17) and Content-Type header (see Section 18.19). A Section 18.17) and Content-Type header (see Section 18.19). A
message body MUST NOT be included in a request or response if the message body MUST NOT be included in a request or response if the
specification of the particular method (see Method Definitions specification of the particular method (see Method Definitions
(Section 13)) does not allow sending a message body. In case a (Section 13)) does not allow sending a message body. In case a
message body is received in a message when not expected, the message- message body is received in a message when not expected, the message
body data SHOULD be discarded. This is to allow future extensions to body data SHOULD be discarded. This is to allow future extensions to
define optional use of a message body. define optional use of a message body.
5.4. Message Length 5.4. Message Length
An RTSP Message that does not contain any message body is terminated An RTSP message that does not contain any message body is terminated
by the first empty line after the header fields (note: an empty line by the first empty line after the header fields (note: an empty line
is a line with nothing preceding the CRLF.). In RTSP messages that is a line with nothing preceding the CRLF.). In RTSP messages that
contain message bodies, the empty line is followed by the message contain message bodies, the empty line is followed by the message
body. The length of that body is determined by the value of the body. The length of that body is determined by the value of the
Content-Length header (Section 18.17). The value in the header Content-Length header (Section 18.17). The value in the header
represents the length of the message-body in octets. If this header represents the length of the message body in octets. If this header
field is not present, a value of zero is assumed, i.e., no message field is not present, a value of zero is assumed, i.e., no message
body present in the message. Unlike an HTTP message, an RTSP message body present in the message. Unlike an HTTP message, an RTSP message
MUST contain a Content-Length header whenever it contains a message MUST contain a Content-Length header whenever it contains a message
body. Note that RTSP does not support the HTTP/1.1 "chunked" body. Note that RTSP does not support the HTTP/1.1 "chunked"
transfer coding (see Section 4.1 of [RFC7230]). transfer coding (see Section 4.1 of [RFC7230]).
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 | | Header Name | Defined in |
+--------------------+---------------+ +--------------------+----------------+
| Accept-Ranges | Section 18.5 | | Accept-Ranges | Section 18.5 |
| | | | | |
| Cache-Control | Section 18.11 | | Cache-Control | Section 18.11 |
| | | | | |
| Connection | Section 18.12 | | Connection | Section 18.12 |
| | | | | |
| CSeq | Section 18.20 | | CSeq | Section 18.20 |
| | | | | |
| Date | Section 18.21 | | Date | Section 18.21 |
| | | | | |
| Media-Properties | Section 18.29 | | Media-Properties | Section 18.29 |
| | | | | |
| Media-Range | Section 18.30 | | Media-Range | Section 18.30 |
| | | | | |
| Pipelined-Requests | Section 18.33 | | Pipelined-Requests | Section 18.33 |
| | | | | |
| Proxy-Supported | Section 18.38 | | Proxy-Supported | Section 18.38 |
| | | | | |
| Range | Section 18.40 | | Range | Section 18.40 |
| | | | | |
| RTP-Info | Section 18.45 | | RTP-Info | Section 18.45 |
| | | | | |
| Scale | Section 18.46 | | Scale | Section 18.46 |
| | | | | |
| Seek-Style | Section 18.47 | | Seek-Style | Section 18.47 |
| | | | | |
| Server | Section 18.48 | | Server | Section 18.48 |
| | | | | |
| Session | Section 18.49 | | Session | Section 18.49 |
| | | | | |
| Speed | Section 18.50 | | Speed | Section 18.50 |
| | | | | |
| Supported | Section 18.51 | | Supported | Section 18.51 |
| | | | | |
| Timestamp | Section 18.53 | | Timestamp | Section 18.53 |
| | | | | |
| Transport | Section 18.54 | | Transport | Section 18.54 |
| | | | | |
| User-Agent | Section 18.56 | | User-Agent | Section 18.56 |
| | | | | |
| Via | Section 18.57 | | Via | Section 18.57 |
+--------------------+---------------+ +--------------------+----------------+
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, whether 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,
the identifier of the resource, and the protocol version in use; the identifier of the resource, and the protocol version in use;
o Zero or more Header lines, which can be of the following types: o Zero or more Header lines, which can be of the following types:
general-headers (Section 6), request-headers (Section 7.2), or general-headers (Section 6), request-headers (Section 7.2), or
message body headers (Section 9.1); message body headers (Section 9.1);
o One empty line (CRLF) to indicate the end of the header section; o One empty line (CRLF) to indicate the end of the header section;
o Optionally, a message-body, consisting of one or more lines. The o Optionally, a message body, consisting of one or more lines. The
length of the message body in octets is indicated by the Content- length of the message body in octets is indicated by the Content-
Length message header. Length message header.
7.1. Request Line 7.1. Request Line
The request line provides the key information about the request: what The request line provides the key information about the request: what
method, on what resources, and using which RTSP version. The methods method, on what resources, and using which RTSP version. The methods
that are defined by this specification are listed in Table 2. that are defined by this specification are listed in Table 2.
+---------------+---------------+ +---------------+----------------+
| Method | Defined in | | Method | Defined in |
+---------------+---------------+ +---------------+----------------+
| DESCRIBE | Section 13.2 | | DESCRIBE | Section 13.2 |
| | | | | |
| GET_PARAMETER | Section 13.8 | | GET_PARAMETER | Section 13.8 |
| | | | | |
| OPTIONS | Section 13.1 | | OPTIONS | Section 13.1 |
| | | | | |
| PAUSE | Section 13.6 | | PAUSE | Section 13.6 |
| | | | | |
| PLAY | Section 13.4 | | PLAY | Section 13.4 |
| | | | | |
| PLAY_NOTIFY | Section 13.5 | | PLAY_NOTIFY | Section 13.5 |
| | | | | |
| REDIRECT | Section 13.10 | | REDIRECT | Section 13.10 |
| | | | | |
| SETUP | Section 13.3 | | SETUP | Section 13.3 |
| | | | | |
| SET_PARAMETER | Section 13.9 | | SET_PARAMETER | Section 13.9 |
| | | | | |
| TEARDOWN | Section 13.7 | | TEARDOWN | Section 13.7 |
+---------------+---------------+ +---------------+----------------+
Table 2: The RTSP Methods Table 2: The RTSP Methods
The syntax of the RTSP request line is the following: The syntax of the RTSP request line has the following:
<Method> SP <Request-URI> SP <RTSP-Version> CRLF <Method> SP <Request-URI> SP <RTSP-Version> CRLF
Note: This syntax cannot be freely changed in future versions of Note: This syntax cannot be freely changed in future versions of
RTSP. This line needs to remain parsable by older RTSP RTSP. This line needs to remain parsable by older RTSP
implementations since it indicates the RTSP version of the message. implementations since it indicates the RTSP version of the message.
In contrast to HTTP/1.1 [RFC2616], RTSP requests identify the In contrast to HTTP/1.1 [RFC7230], RTSP requests identify the
resource through an absolute RTSP URI (including scheme, host, and resource through an absolute RTSP URI (including scheme, host, and
port) (see Section 4.2) rather than just the absolute path. port) (see Section 4.2) rather than just the absolute path.
HTTP/1.1 requires servers to understand the absolute URI, but HTTP/1.1 requires servers to understand the absolute URI, but
clients are supposed to use the Host request-header. This is clients are supposed to use the Host request-header. This is
purely needed for backward compatibility with HTTP/1.0 servers, a purely needed for backward compatibility with HTTP/1.0 servers, a
consideration that does not apply to RTSP. consideration that does not apply to RTSP.
An asterisk "*" can be used instead of an absolute URI in the An asterisk "*" can be used instead of an absolute URI in the
Request-URI part to indicate that the request does not apply to a Request-URI part to indicate that the request does not apply to a
skipping to change at page 42, line 5 skipping to change at page 42, line 5
For example: For example:
OPTIONS rtsp://example.com RTSP/2.0 OPTIONS rtsp://example.com RTSP/2.0
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. headers, to modify the specifics of the request.
+---------------------+---------------+ +---------------------+----------------+
| Header | Defined in | | Header | Defined in |
+---------------------+---------------+ +---------------------+----------------+
| Accept | Section 18.1 | | Accept | Section 18.1 |
| | | | | |
| Accept-Credentials | Section 18.2 | | Accept-Credentials | Section 18.2 |
| | | | | |
| Accept-Encoding | Section 18.3 | | Accept-Encoding | Section 18.3 |
| | | | | |
| Accept-Language | Section 18.4 | | Accept-Language | Section 18.4 |
| | | | | |
| Authorization | Section 18.8 | | Authorization | Section 18.8 |
| | | | | |
| Bandwidth | Section 18.9 | | Bandwidth | Section 18.9 |
| | | | | |
| Blocksize | Section 18.10 | | Blocksize | Section 18.10 |
| | | | | |
| From | Section 18.23 | | From | Section 18.23 |
| | | | | |
| If-Match | Section 18.24 | | If-Match | Section 18.24 |
| | | | | |
| If-Modified-Since | Section 18.25 | | If-Modified-Since | Section 18.25 |
| | | | | |
| If-None-Match | Section 18.26 | | If-None-Match | Section 18.26 |
| | | | | |
| Notify-Reason | Section 18.32 | | Notify-Reason | Section 18.32 |
| | | | | |
| Proxy-Authorization | Section 18.36 | | Proxy-Authorization | Section 18.36 |
| | | | | |
| Proxy-Require | Section 18.37 | | Proxy-Require | Section 18.37 |
| | | | | |
| Referrer | Section 18.41 | | Referrer | Section 18.41 |
| | | | | |
| Request-Status | Section 18.42 | | Request-Status | Section 18.42 |
| | | | | |
| Require | Section 18.43 | | Require | Section 18.43 |
| | | | | |
| Terminate-Reason | Section 18.52 | | Terminate-Reason | Section 18.52 |
+---------------------+---------------+ +---------------------+----------------+
Table 3: The RTSP Request-Headers Table 3: The RTSP Request-Headers
Detailed header definitions are provided in Section 18. Detailed header definitions 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,
final, response. Only responses using the response code class 1xx, final, response. Responses using the response code class 1xx is the
are allowed to send one or more 1xx response messages prior to the only class for which there MAY be sent one or more responses prior to
final response message. the final response message.
The valid response codes and the methods they can be used with are The valid response codes and the methods they can be used with are
listed in Table 4. listed in Table 4.
8.1. Status-Line 8.1. Status-Line
The first line of a Response message is the Status-Line, consisting The first line of a response message is the Status-Line, consisting
of the protocol version followed by a numeric status code and the of the protocol version followed by a numeric status code and the
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
skipping to change at page 44, line 8 skipping to change at page 44, line 8
3rr: Redirection - Further action needs to be taken in order to 3rr: Redirection - Further action needs to be taken in order to
complete the request (3rr rather than 3xx is used as 304 is complete the request (3rr rather than 3xx is used as 304 is
excluded; see Section 17.3) excluded; see Section 17.3)
4xx: Client Error - The request contains bad syntax or cannot be 4xx: Client Error - The request contains bad syntax or cannot be
fulfilled fulfilled
5xx: Server Error - The server failed to fulfill an apparently valid 5xx: Server Error - The server failed to fulfill an apparently valid
request request
The individual values of the numeric status codes defined for The individual values of the numeric status codes defined for RTSP
RTSP/2.0, and an example set of corresponding Reason-Phrases, are 2.0, and an example set of corresponding Reason-Phrases, are
presented in Table 4. The reason phrases listed here are only presented in Table 4. The reason phrases listed here are only
recommended; they may be replaced by local equivalents without recommended; they may be replaced by local equivalents without
affecting the protocol. Note that RTSP adopts most HTTP/1.1 affecting the protocol. Note that RTSP adopted most HTTP/1.1
[RFC2616] status codes and adds RTSP-specific status codes starting [RFC2068] status codes and then added RTSP-specific status codes
at x50 to avoid conflicts with future HTTP status codes that are starting at x50 to avoid conflicts with future HTTP status codes that
desirable to import into RTSP. All these codes are RTSP specific and are desirable to import into RTSP. All these codes are RTSP specific
RTSP has its own registry separate from HTTP for status codes. and RTSP has its own registry separate from HTTP for status codes.
RTSP status codes are extensible. RTSP applications are not required RTSP status codes are extensible. RTSP applications are not required
to understand the meaning of all registered status codes, though such to understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST understanding is obviously desirable. However, applications MUST
understand the class of any status code, as indicated by the first understand the class of any status code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the digit, and treat any unrecognized response as being equivalent to the
x00 status code of that class, with an exception for unknown 3xx x00 status code of that class, with an exception for unknown 3xx
codes, which MUST be treated as a 302 (Found). The reason being that codes, which MUST be treated as a 302 (Found). The reason for that
no 300 (Multiple Choices in HTTP) is defined for RTSP. A response exception is that the status code 300 (Multiple Choices in HTTP) is
with an unrecognized status code MUST NOT be cached. For example, if not defined for RTSP. A response with an unrecognized status code
an unrecognized status code of 431 is received by the client, it can MUST NOT be cached. For example, if an unrecognized status code of
safely assume that there was something wrong with its request and 431 is received by the client, it can safely assume that there was
treat the response as if it had received a 400 status code. In such something wrong with its request and treat the response as if it had
cases, user agents SHOULD present to the user the message body received a 400 status code. In such cases, user agents SHOULD
returned with the response, since that message body is likely to present to the user the message body returned with the response,
include human-readable information that will explain the unusual since that message body is likely to include human-readable
status. information that will explain the unusual status.
+------+---------------------------------+--------------------------+ +------+---------------------------------+--------------------------+
| Code | Reason | Method | | Code | Reason | Method |
+------+---------------------------------+--------------------------+ +------+---------------------------------+--------------------------+
| 100 | Continue | all | | 100 | Continue | all |
| | | | | | | |
| | | |
| | | |
| 200 | OK | all | | 200 | OK | all |
| | | | | | | |
| | | |
| | | |
| 301 | Moved Permanently | all | | 301 | Moved Permanently | all |
| | | | | | | |
| 302 | Found | all | | 302 | Found | all |
| | | | | | | |
| 303 | See Other | n/a | | 303 | See Other | n/a |
| | | | | | | |
| 304 | Not Modified | all | | 304 | Not Modified | all |
| | | | | | | |
| 305 | Use Proxy | all | | 305 | Use Proxy | all |
| | | | | | | |
| | | |
| | | |
| 400 | Bad Request | all | | 400 | Bad Request | all |
| | | | | | | |
| 401 | Unauthorized | all | | 401 | Unauthorized | all |
| | | | | | | |
| 402 | Payment Required | all | | 402 | Payment Required | all |
| | | | | | | |
| 403 | Forbidden | all | | 403 | Forbidden | all |
| | | | | | | |
| 404 | Not Found | all | | 404 | Not Found | all |
| | | | | | | |
skipping to change at page 46, line 33 skipping to change at page 46, line 27
| | | | | | | |
| 470 | Connection Authorization | all | | 470 | Connection Authorization | all |
| | Required | | | | Required | |
| | | | | | | |
| 471 | Connection Credentials Not | all | | 471 | Connection Credentials Not | all |
| | Accepted | | | | Accepted | |
| | | | | | | |
| 472 | Failure to Establish Secure | all | | 472 | Failure to Establish Secure | all |
| | Connection | | | | Connection | |
| | | | | | | |
| | | |
| | | |
| 500 | Internal Server Error | all | | 500 | Internal Server Error | all |
| | | | | | | |
| 501 | Not Implemented | all | | 501 | Not Implemented | all |
| | | | | | | |
| 502 | Bad Gateway | all | | 502 | Bad Gateway | all |
| | | | | | | |
| 503 | Service Unavailable | all | | 503 | Service Unavailable | all |
| | | | | | | |
| 504 | Gateway Timeout | all | | 504 | Gateway Timeout | all |
| | | | | | | |
skipping to change at page 47, line 15 skipping to change at page 47, line 7
8.2. Response Headers 8.2. Response Headers
The response-headers allow the request recipient to pass additional The response-headers allow the request recipient to pass additional
information about the response that cannot be placed in the Status- information about the response that 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 | | Header | Defined in |
+------------------------+---------------+ +------------------------+----------------+
| Authentication-Info | Section 18.7 | | Authentication-Info | Section 18.7 |
| | | | | |
| Connection-Credentials | Section 18.13 | | Connection-Credentials | Section 18.13 |
| | | | | |
| Location | Section 18.28 | | Location | Section 18.28 |
| | | | | |
| MTag | Section 18.31 | | MTag | Section 18.31 |
| | | | | |
| Proxy-Authenticate | Section 18.34 | | Proxy-Authenticate | Section 18.34 |
| | | | | |
| Public | Section 18.39 | | Public | Section 18.39 |
| | | | | |
| Retry-After | Section 18.44 | | Retry-After | Section 18.44 |
| | | | | |
| Unsupported | Section 18.55 | | Unsupported | Section 18.55 |
| | | | | |
| WWW-Authenticate | Section 18.58 | | WWW-Authenticate | Section 18.58 |
+------------------------+---------------+ +------------------------+----------------+
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 can be given the semantics of response-header if all parties header can be given the semantics of response-header if all parties
in the communication recognize them to be a response-header. in the communication recognize them to be a response-header.
Unrecognized headers in responses MUST be ignored. Unrecognized headers in responses MUST be ignored.
9. Message Body 9. Message Body
Some Request and Response messages include a message body, if not Some request and response messages include a message body, if not
otherwise restricted by the request method or response status code. otherwise restricted by the request method or response status code.
The message body consists of the content data itself (see also The message body consists of the content data itself (see also
Section 5.3). Section 5.3).
The SET_PARAMETER and GET_PARAMETER requests and responses, and the The SET_PARAMETER and GET_PARAMETER requests and responses, and the
DESCRIBE response as defined by this specification, can have a DESCRIBE response as defined by this specification, can have a
message body; the purpose of the message body is defined in each message body; the purpose of the message body is defined in each
case. All 4xx and 5xx responses MAY also have a message body to case. All 4xx and 5xx responses MAY also have a message body to
carry additional response information. Generally, a message body MAY carry additional response information. Generally, a message body MAY
be attached to any RTSP 2.0 request or response, but the content of be attached to any RTSP 2.0 request or response, but the content of
the message body MAY be ignored by the receiver. Extensions to this the message body MAY be ignored by the receiver. Extensions to this
skipping to change at page 48, line 25 skipping to change at page 48, line 15
specification can specify the purpose and content of message bodies, specification can specify the purpose and content of message bodies,
including requiring their inclusion. including requiring their inclusion.
In this section, both sender and recipient refer to either the client In this section, both sender and recipient refer to either the client
or the server, depending on who sends and who receives the message or the server, depending on who sends and who receives the message
body. body.
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 | | Header | Defined in |
+------------------+---------------+ +------------------+----------------+
| Allow | Section 18.6 | | Allow | Section 18.6 |
| | | | | |
| Content-Base | Section 18.14 | | Content-Base | Section 18.14 |
| | | | | |
| Content-Encoding | Section 18.15 | | Content-Encoding | Section 18.15 |
| | | | | |
| Content-Language | Section 18.16 | | Content-Language | Section 18.16 |
| | | | | |
| Content-Length | Section 18.17 | | Content-Length | Section 18.17 |
| | | | | |
| Content-Location | Section 18.18 | | Content-Location | Section 18.18 |
| | | | | |
| Content-Type | Section 18.19 | | Content-Type | Section 18.19 |
| | | | | |
| Expires | Section 18.22 | | Expires | Section 18.22 |
| | | | | |
| Last-Modified | Section 18.27 | | Last-Modified | Section 18.27 |
+------------------+---------------+ +------------------+----------------+
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.
9.2. Message Body 9.2. Message Body
An RTSP message with a message body MUST include the Content-Type and An RTSP message with a message body MUST include the Content-Type and
Content-Length headers. When a message body is included with a Content-Length headers. When a message body is included with a
message, the data type of that content data is determined via the message, the data type of that content data is determined via the
Content-Type and Content-Encoding header fields. Content-Type and Content-Encoding header fields.
Content-Type specifies the media type of the underlying data. There Content-Type specifies the media type of the underlying data. There
is no default media format and the actual format used in the body is is no default media format and the actual format used in the body is
required to be explicitly stated in the Content-Type header. By required to be explicitly stated in the Content-Type header. By
being explicit and always requiring the inclusion of the Content-Type being explicit and always requiring the inclusion of the Content-Type
header with accurate information, one avoids the many pitfalls in a header with accurate information, one avoids the many pitfalls in a
heuristic-based interpretation of the body content. These are issues heuristic-based interpretation of the body content. The user
that HTTP and email have suffered from. experience of HTTP and email have suffered from relying on such
heuristics.
Content-Encoding may be used to indicate any additional content- Content-Encoding may be used to indicate any additional content-
codings applied to the data, usually for the purpose of data codings applied to the data, usually for the purpose of data
compression, that are a property of the requested resource. The compression, that are a property of the requested resource. The
default encoding is 'identity', i.e. no transformation of the message default encoding is 'identity', i.e. no transformation of the message
body. body.
The Content-Length of a message is the length of the content, The Content-Length of a message is the length of the content,
measured in octets. measured in octets.
skipping to change at page 50, line 4 skipping to change at page 49, line 48
the request response will be a 406 (Not Acceptable) error code. the request response will be a 406 (Not Acceptable) error code.
The media types that may be used on requests with message bodies need The media types that may be used on requests with message bodies need
to be determined through the use of feature-tags, specification to be determined through the use of feature-tags, specification
requirement, or trial and error. Trial and error works because when requirement, or trial and error. Trial and error works because when
the responder does not support the media type of the message body, it the responder does not support the media type of the message body, it
will respond with a 415 (Unsupported Media Type). will respond with a 415 (Unsupported Media Type).
The formats supported and their negotiation is done individually on a The formats supported and their negotiation is done individually on a
per method and direction (request or response body) direction. per method and direction (request or response body) direction.
Requirements on supporting particular media types for use as message Requirements on supporting particular media types for use as message
bodies in requests and response SHALL also be specified on a per- bodies in requests and response SHALL also be specified on a per-
method and per-direction basis. method and per-direction basis.
10. Connections 10. Connections
RTSP Messages are transferred between RTSP agents and proxies using a RTSP messages are transferred between RTSP agents and proxies using a
transport connection. This transport connection uses TCP or TCP/TLS. transport connection. This transport connection uses TCP or TCP/TLS.
This transport connection is referred to as the "connection" or "RTSP This transport connection is referred to as the "connection" or "RTSP
connection" within this document. connection" within this document.
RTSP requests can be transmitted using the two different connection RTSP requests can be transmitted using the two different connection
scenarios listed below: scenarios listed below:
o persistent - a transport connection is used for several request/ o persistent - a transport connection is used for several request/
response transactions; response transactions;
skipping to change at page 53, line 15 skipping to change at page 53, line 12
The sending of client and server requests can be asynchronous events. The sending of client and server requests can be asynchronous events.
To avoid deadlock situations, both client and server MUST be able to To avoid deadlock situations, both client and server MUST be able to
send and receive requests simultaneously. As an RTSP response may be send and receive requests simultaneously. As an RTSP response may be
queued up for transmission, reception or processing behind the peer queued up for transmission, reception or processing behind the peer
RTSP agent's own requests, all RTSP agents are required to have a RTSP agent's own requests, all RTSP agents are required to have a
certain capability of handling outstanding messages. A potential certain capability of handling outstanding messages. A potential
issue is that outstanding requests may time out despite being issue is that outstanding requests may time out despite being
processed by the peer; this can be due to the response being caught processed by the peer; this can be due to the response being caught
in the queue behind a number of requests that the RTSP agent is in the queue behind a number of requests that the RTSP agent is
processing but that take some time to complete. To avoid this processing but that take some time to complete. To avoid this
problem, an RTSP agent is recommended to buffer incoming messages problem, an RTSP agent should buffer incoming messages locally so
locally so that any response messages can be processed immediately that any response messages can be processed immediately upon
upon reception. If responses are separated from requests and reception. If responses are separated from requests and directly
directly forwarded for processing, not only can the result be used forwarded for processing, not only can the result be used
immediately, the state associated with that outstanding request can immediately, the state associated with that outstanding request can
also be released. However, buffering a number of requests on the also be released. However, buffering a number of requests on the
receiving RTSP agent consumes resources and enables a resource receiving RTSP agent consumes resources and enables a resource
exhaustion attack on the agent. Therefore, this buffer should be exhaustion attack on the agent. Therefore, this buffer should be
limited so that an unreasonable number of requests or total message limited so that an unreasonable number of requests or total message
size is not allowed to consume the receiving agent's resources. In size is not allowed to consume the receiving agent's resources. In
most APIs, having the receiving agent stop reading from the TCP most APIs, having the receiving agent stop reading from the TCP
socket will result in TCP's window being clamped. Thus, forcing the socket will result in TCP's window being clamped, thus forcing the
buffering onto the sending agent when the load is larger than buffering onto the sending agent when the load is larger than
expected. However, as both RTSP message sizes and frequency may be expected. However, as both RTSP message sizes and frequency may be
changed in the future by protocol extensions, an agent should be changed in the future by protocol extensions, an agent should be
careful about taking harsher measurements against a potential attack. careful about taking harsher measurements against a potential attack.
When under attack, an RTSP agent can close TCP connections and When under attack, an RTSP agent can close TCP connections and
release state associated with that TCP connection. release state associated with that TCP connection.
To provide some guidance on what is reasonable, the following To provide some guidance on what is reasonable, the following
guidelines are given. It is RECOMMENDED that: guidelines are given. It is RECOMMENDED that:
skipping to change at page 53, line 48 skipping to change at page 53, line 45
per RTSP session; per RTSP session;
o an RTSP agent should not have more than 10 outstanding requests o an RTSP agent should not have more than 10 outstanding requests
that are not related to an RTSP session or that are requesting to that are not related to an RTSP session or that are requesting to
create an RTSP session. create an RTSP session.
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).
RTSP Agents can send requests to multiple different destinations, RTSP agents can send requests to multiple different destinations,
either server or client contexts over the same connection to a proxy. either server or client contexts over the same connection to a proxy.
Then, the proxy forks the message to the different destinations over Then, the proxy forks the message to the different destinations over
proxy-to-agent connections. In these cases when multiple requests proxy-to-agent connections. In these cases when multiple requests
are outstanding, the requesting agent MUST be ready to receive the are outstanding, the requesting agent MUST be ready to receive the
responses out of order compared to the order they where sent on the responses out of order compared to the order they where sent on the
connection. The order between multiple messages for each destination connection. The order between multiple messages for each destination
will be maintained; however, the order between response from will be maintained; however, the order between response from
different destinations can be different. different destinations can be different.
The reason for this is to avoid a head-of-line blocking situation. The reason for this is to avoid a head-of-line blocking situation.
skipping to change at page 55, line 6 skipping to change at page 55, line 4
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 17.4.24) are used for negotiating capabilities Allowed) (Section 17.4.24) 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 or special types of requests or result
extra overhead for the client when testing for new features. On in extra overhead for the client when testing for new features.
the other hand, keeping connections open after sending an error On the other hand, keeping connections open after sending an error
response poses a Denial-of-Service (DoS) security risk response poses a Denial-of-Service (DoS) security risk
(Section 21). (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
amount of time. It is RECOMMENDED that the server wait at least 10 amount of time. It is RECOMMENDED that the server wait at least 10
seconds for the completion of a message or for the next part of the seconds for the completion of a message or for the next part of the
message to arrive (which is an indication that the transport and the message to arrive (which is an indication that the transport and the
client are still alive). Servers believing they are under attack or client are still alive). Servers believing they are under attack or
that are otherwise starved for resources during that event MAY that are otherwise starved for resources during that event MAY
skipping to change at page 57, line 28 skipping to change at page 57, line 26
client to server on average every 5 seconds. That client has, client to server on average every 5 seconds. That client has,
for a network with 5% packet loss, a probability of failing to for a network with 5% packet loss, a probability of failing to
confirm liveness within the timeout interval for that session confirm liveness within the timeout interval for that session
of 2.4*E-16. Sessions with shorter timeouts, much higher of 2.4*E-16. Sessions with shorter timeouts, much higher
packet loss, or small RTCP bandwidths SHOULD also implement one packet loss, or small RTCP bandwidths SHOULD also implement one
or more of the mechanisms below. or more of the mechanisms below.
SET_PARAMETER: When using SET_PARAMETER for keep-alives, a body SET_PARAMETER: When using SET_PARAMETER for keep-alives, a body
SHOULD NOT be included. This method is the RECOMMENDED RTSP SHOULD NOT be included. This method is the RECOMMENDED RTSP
method to use for a request intended only to perform keep- method to use for a request intended only to perform keep-
alives. Support of SET_PARAMETER is mandatory for RTSP Servers alives. RTSP servers MUST support the SET_PARAMETER method, so
to ensure clients can use this method. that clients can always use this mechanism.
GET_PARAMETER: When using GET_PARAMETER for keep-alives, a body GET_PARAMETER: When using GET_PARAMETER for keep-alives, a body
SHOULD NOT be included, dependent on implementation support in SHOULD NOT be included, dependent on implementation support in
the server. Use the OPTIONS method to determine if there is the server. Use the OPTIONS method to determine if there is
method support or simply try. method support or simply try.
OPTIONS: This method is also usable, but it causes the server to OPTIONS: This method is also usable, but it causes the server to
perform more unnecessary processing and results in bigger perform more unnecessary processing and results in bigger
responses than necessary for the task. The reason is that the responses than necessary for the task. The reason is that the
server needs to determine the capabilities associated with the server needs to determine the capabilities associated with the
skipping to change at page 58, line 28 skipping to change at page 58, line 28
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 17.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 18.44), the server or proxy can the Retry-After header (Section 18.44), the server or proxy can
indicate the time after which the requesting entity can send another indicate the time after which the requesting entity can send another
request to the proxy or server. request to the proxy or server.
There are two scopes of such 503 answers, one for established RTSP There are two scopes of such 503 answers. The first scope is for an
sessions, where the request resulting in the 503 response as well as established RTSP session, where the request resulting in the 503
the response itself carries a Session header identifying the session response as well as the response itself carries a Session header
that is suffering overload. This response only applies to this identifying the session that is suffering overload. This response
particular session. The other scope is the general RTSP server as only applies to this particular session. The other scope is the
identified by the host in the Request-URI. Such a 503 answer with general RTSP server as identified by the host in the Request-URI.
any Retry-After header applies to all requests that are not session Such a 503 answer with any Retry-After header applies to all requests
specific to that server, including a SETUP request intended to create that are not session specific to that server, including a SETUP
a new RTSP session. request intended to create a new RTSP session.
Another scope for overload situations exists: the RTSP proxy. To Another scope for overload situations exists: the RTSP proxy. To
enable an RTSP proxy to signal that it is overloaded, or otherwise enable an RTSP proxy to signal that it is overloaded, or otherwise
unavailable and unable to handle the request, a 553 response code has unavailable and unable to handle the request, a 553 response code has
been defined with the meaning "Proxy Unavailable". As with servers, been defined with the meaning "Proxy Unavailable". As with servers,
there is a separation in response scopes between requests associated there is a separation in response scopes between requests associated
with existing RTSP sessions and requests to create new sessions or with existing RTSP sessions and requests to create new sessions or
general proxy requests. general proxy requests.
Simply implementing and using the 503 (Service Unavailable) and 553 Simply implementing and using the 503 (Service Unavailable) and 553
skipping to change at page 60, line 41 skipping to change at page 60, line 41
is not dependent on a specific resource. The intended usage is is not dependent on a specific resource. The intended usage is
to determine before one needs to use a functionality that it is to determine before one needs to use a functionality that it is
supported. It can be used in any method, but OPTIONS is the supported. It can be used in any method, but OPTIONS is the
most suitable as it simultaneously determines all methods that most suitable as it simultaneously determines all methods that
are implemented. When sending a request, the requester are implemented. When sending a request, the requester
declares all its capabilities by including all supported declares all its capabilities by including all supported
feature-tags. This results in the receiver learning the feature-tags. This results in the receiver learning the
requester's feature support. The receiver then includes its requester's feature support. The receiver then includes its
set of features in the response. set of features in the response.
Proxy-Supported: This header is used similarly to the Supported Proxy-Supported: This header is used in a similar fashion as the
header, but instead of giving the supported functionality of Supported header, but instead of giving the supported
the client or server, it provides both the requester and the functionality of the client or server, it provides both the
responder a view of the common functionality supported in requester and the responder a view of the common functionality
general by all members of the proxy chain between the two supported in general by all members of the proxy chain between
supports and not dependent on the resource. Proxies are the client and server; it does not depend on the resource.
required to add this header whenever the Supported header is Proxies are required to add this header whenever the Supported
present, but proxies may also add it independently of the header is present, but proxies may also add it independently of
requester. the requester.
Require: This header can be included in any request where the Require: This header can be included in any request where the
endpoint, i.e., the client or server, is required to understand endpoint, i.e., the client or server, is required to understand
the feature to correctly perform the request. This can, for the feature to correctly perform the request. This can, for
example, be a SETUP request, where the server is required to example, be a SETUP request, where the server is required to
understand a certain parameter to be able to set up the media understand a certain parameter to be able to set up the media
delivery correctly. Ignoring this parameter would not have the delivery correctly. Ignoring this parameter would not have the
desired effect and is not acceptable. Therefore, the endpoint desired effect and is not acceptable. Therefore, the endpoint
receiving a request containing a Require MUST negatively receiving a request containing a Require MUST negatively
acknowledge any feature that it does not understand and not acknowledge any feature that it does not understand and not
perform the request. The response in cases where features are perform the request. The response in cases where features are
not supported is 551 (Option Not Supported). Also, the not supported is 551 (Option Not Supported). Also, the
features that are not supported are given in the Unsupported features that are not supported are given in the Unsupported
header in the response. header in the response.
Proxy-Require: This header has the same purpose and workings as Proxy-Require: This header has the same purpose and behavior as
Require except that it only applies to proxies and not the Require except that it only applies to proxies and not the
endpoint. Features that need to be supported by both proxies endpoint. Features that need to be supported by both proxies
and endpoints need to be included in both the Require and and endpoints need to be included in both the Require and
Proxy-Require header. Proxy-Require header.
Unsupported: This header is used in a 551 (Option Not Supported) Unsupported: This header is used in a 551 (Option Not Supported)
error response, to indicate which features were not supported. error response, to indicate which features were not supported.
Such a response is only the result of the usage of the Require Such a response is only the result of the usage of the Require
and/or Proxy-Require headers where one or more features were or Proxy-Require headers where one or more features were not
not supported. This information allows the requester to make supported. This information allows the requester to make the
the best of situations as it knows which features are not best of situations as it knows which features are not
supported. supported.
11.1. Feature Tag: play.basic 11.1. Feature Tag: play.basic
An implementation supporting all normative parts of this An implementation supporting all normative parts of this
specification for the setup and control of playback of media uses the specification for the setup and control of playback of media uses the
feature tag "play.basic" to indicate this support. The appendices feature tag "play.basic" to indicate this support. The appendices
(starting with letters), are not part of the functionality included (starting with letters) are not part of the functionality included in
in the feature tag unless the appendix is explicitly specified in a the feature tag unless the appendix is explicitly specified in a main
main section as being a required appendix. section as being a required appendix.
Note: This feature tag does not mandate any media delivery Note: This feature tag does not mandate any media delivery
protocol, such as RTP. protocol, such as RTP.
In RTSP 1.0, there was a minimal implementation section. However, In RTSP 1.0, there was a minimal implementation section. However,
that was not consistent with the rest of the specification. So, that was not consistent with the rest of the specification. So,
rather than making an attempt to explicitly enumerate the features rather than making an attempt to explicitly enumerate the features
for play.basic, this specification has to be taken as a whole and for play.basic, this specification has to be taken as a whole and
the necessary features normatively defined as being required are the necessary features normatively defined as being required are
included. included.
skipping to change at page 62, line 20 skipping to change at page 62, line 20
connection. For RTSP, where the relative order of requests will connection. For RTSP, where the relative order of requests will
matter, it is important to maintain the order of the requests. matter, it is important to maintain the order of the requests.
Because of this, the responding agent MUST process the incoming Because of this, the responding agent MUST process the incoming
requests in their sending order. The sending order can be determined requests in their sending order. The sending order can be determined
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, between two agents, as the sending order. order will be the same, between two agents, as the sending order.
The processing of the request MUST also have been finished before The processing of the request MUST also have been finished before
processing the next request from the same agent. The responses MUST processing the next request from the same agent. The responses MUST
be sent in the order the requests were processed. be sent in the order the requests were processed.
RTSP 2.0 has extended support for pipelining from that in RTSP 1.0. RTSP 2.0 has extended support for pipelining beyond the capabilities
The major improvement is to allow all requests involved in setting up in RTSP 1.0. As a major improvement, all requests involved in
and initiating media delivery to be pipelined after each other. This setting up and initiating media delivery can now be pipelined,
is accomplished by the utilization of the Pipelined-Requests header indicated by the Pipelined-Request header (see Section 18.33). This
(see Section 18.33). This header allows a client to request that two header allows a client to request that two or more requests be
or more requests be processed in the same RTSP session context that processed in the same RTSP session context that the first request
the first request creates. In other words, a client can request that creates. In other words, a client can request that two or more media
two or more media streams be set up and then played without needing streams be set up and then played without needing to wait for a
to wait for a single response. This speeds up the initial start-up single response. This speeds up the initial start-up time for an
time for an RTSP session by at least one RTT. RTSP session by 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 requests fails and a PLAY request. In case one of the SETUP requests fails
unexpectedly, the PLAY request can still be successfully executed. unexpectedly, the PLAY request can still be successfully executed.
However, the resulting presentation will not be as expected by the However, the resulting presentation will not be as expected by the
requesting client, as only a single media instead of two will be requesting client, as only a single media instead of two will be
played. In this case, the client can send a PAUSE request, correct played. In this case, the client can send a PAUSE request, correct
the failing SETUP request, and then request it be played. the failing SETUP request, and then request it be played.
13. Method Definitions 13. Method Definitions
The method indicates what is to be performed on the resource The method indicates what is to be performed on the resource
identified by the Request-URI. The method name is case sensitive. identified by the Request-URI. The method name is case sensitive.
New methods may be defined in the future. Method names MUST NOT New methods may be defined in the future. Method names MUST NOT
start with a $ character (decimal 36) and MUST be a token as defined start with a $ character (decimal 36) and MUST be a token as defined
by the ABNF [RFC5234] in the syntax chapter Section 20. The methods by the ABNF [RFC5234] in Section 20. The methods are summarized in
are summarized in Table 7. Table 7.
+---------------+-----------+--------+-------------+-------------+ +---------------+-----------+--------+-------------+-------------+
| method | direction | object | Server req. | Client req. | | method | direction | object | Server req. | Client req. |
+---------------+-----------+--------+-------------+-------------+ +---------------+-----------+--------+-------------+-------------+
| DESCRIBE | C -> S | P,S | recommended | recommended | | DESCRIBE | C -> S | P,S | recommended | recommended |
| | | | | | | | | | | |
| GET_PARAMETER | C -> S | P,S | optional | optional | | GET_PARAMETER | C -> S | P,S | optional | optional |
| | | | | | | | | | | |
| | S -> C | P,S | optional | optional | | | S -> C | P,S | optional | optional |
| | | | | | | | | | | |
skipping to change at page 65, line 21 skipping to change at page 65, line 21
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Proxy-Require: gzipped-messages Proxy-Require: gzipped-messages
Supported: play.basic Supported: play.basic
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS
Supported: play.basic, setup.rtp.rtcp.mux, play.scale Supported: play.basic, setup.rtp.rtcp.mux, play.scale
Server: PhonyServer/1.1 Server: PhonyServer/1.1
Note that some of the feature-tags in Supported and Proxy-Require are Note that the "gzipped-messages" feature-tag in the Proxy-Require is
fictitious features. a fictitious feature.
13.2. DESCRIBE 13.2. DESCRIBE
The DESCRIBE method is used to retrieve the description of a The DESCRIBE method is used to retrieve the description of a
presentation or media object from a server. The Request-URI of the presentation or media object from a server. The Request-URI of the
DESCRIBE request identifies the media resource of interest. The DESCRIBE request identifies the media resource of interest. The
client MAY include the Accept header in the request to list the client MAY include the Accept header in the request to list the
description formats that it understands. The server MUST respond description formats that it understands. The server MUST respond
with a description of the requested resource and return the with a description of the requested resource and return the
description in the message body of the response, if the DESCRIBE description in the message body of the response, if the DESCRIBE
skipping to change at page 67, line 4 skipping to change at page 67, line 4
If a client obtains a valid description from an alternate source, the If a client obtains a valid description from an alternate source, the
client MAY use this description for initialization purposes without client MAY use this description for initialization purposes without
issuing a DESCRIBE request for the same media. The client should use issuing a DESCRIBE request for the same media. The client should use
any MTag to either validate the presentation description or make the any MTag to either validate the presentation description or make the
session establishment conditional on being valid. session establishment conditional on being valid.
It is RECOMMENDED that minimal servers support the DESCRIBE method, It is RECOMMENDED that minimal servers support the DESCRIBE method,
and highly recommended that minimal clients support the ability to and highly recommended that minimal clients support the ability to
act as "helper applications" that accept a media initialization file act as "helper applications" that accept a media initialization file
from a user interface, and/or other means that are appropriate to the from a user interface, or other means that are appropriate to the
operating environment of the clients. operating environment of the clients.
13.3. SETUP 13.3. SETUP
The description below uses the following states in a protocol state The description below uses the following states in a protocol state
machine that is related to a specific session when that session has machine that is related to a specific session when that session has
been created. The state transitions are driven by protocol been created. The state transitions are driven by protocol
interactions. For additional information about the state machine, interactions. For additional information about the state machine,
see Appendix B. see Appendix B.
Init: Initial state. No session exists. Init: Initial state. No session exists.
Ready: Session is ready to start playing. Ready: Session is ready to start playing.
Play: Session is playing, i.e., sending media-stream data in the Play: Session is playing, i.e., sending media-stream data in the
direction S->C. direction S->C.
The SETUP request for a URI specifies the transport mechanism to be The SETUP request for a 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; creating an RTSP session and changing the transport different cases, namely, creating an RTSP session and changing the
parameters of media streams that are already set up. SETUP can be transport parameters of media streams that are already set up. SETUP
used in all three states; Init, Ready, and Play to change the can be used in all three states, Init, Ready, and Play, to change the
transport parameters. Additionally, Init and Ready can also be used transport parameters. Additionally, Init and Ready can also be used
for the creation of the RTSP session. The usage of the SETUP method for the creation of the RTSP session. The usage of the SETUP method
in the Play state to add a media resource to the session is in the Play state to add a media resource to the session is
unspecified. unspecified.
The Transport header, see Section 18.54, specifies the media- The Transport header, see Section 18.54, 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,
skipping to change at page 68, line 22 skipping to change at page 68, line 22
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 18.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 200 OK response MUST include the Media-Properties header The SETUP 200 OK response MUST include the Media-Properties header
(see Section 18.29 ). The combination of the parameters of the (see Section 18.29). The combination of the parameters of the Media-
Media-Properties header indicates the nature of the content present Properties header indicates the nature of the content present in the
in the session (see also Section 4.7). For example, a live stream session (see also Section 4.7). For example, a live stream with time
with time shifting is indicated by 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, and o Content Modifications set to Time-Progressing, and
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 200 OK response MUST include the Media-Range header (see The SETUP 200 OK response MUST include the Media-Range header (see
Section 18.30) if the media is Time-Progressing. Section 18.30) if the media is Time-Progressing.
skipping to change at page 69, line 16 skipping to change at page 69, line 16
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, clock Accept-Ranges: npt, clock
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: 302 CSeq: 302
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.1 Server: PhonyServer/1.1
Session: 47112344;timeout=60 Session: QKyjN8nt2WqbWw4tIYof52;timeout=60
Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/ Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/
"192.0.2.53:4589"; src_addr="198.51.100.241:6256"/ "192.0.2.53:4589"; src_addr="198.51.100.241:6256"/
"198.51.100.241:6257"; ssrc=2A3F93ED "198.51.100.241:6257"; ssrc=2A3F93ED
Accept-Ranges: npt Accept-Ranges: npt
Media-Properties: Random-Access=3.2, Time-Progressing, Media-Properties: Random-Access=3.2, Time-Progressing,
Time-Duration=3600.0 Time-Duration=3600.0
Media-Range: npt=0-2893.23 Media-Range: npt=0-2893.23
In the above example, the client wants to create an RTSP session In the above example, the client wants to create an RTSP session
containing the media resource "rtsp://example.com/foo/bar/baz.rm". containing the media resource "rtsp://example.com/foo/bar/baz.rm".
The transport parameters acceptable to the client are either RTP/AVP/ The transport parameters acceptable to the client are either RTP/AVP/
UDP (UDP per default) to be received on client port 4588 and 4589 at UDP (UDP per default) to be received on client port 4588 and 4589 at
the address the RTSP setup connection comes from or RTP/AVP the address the RTSP setup connection comes from or RTP/AVP
interleaved on the RTSP control channel. The server selects the interleaved on the RTSP control channel. The server selects the
RTP/AVP/UDP transport and adds the address and ports it will send and RTP/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 that latter case, the server MUST
SETUP request into the existing session (aggregated session) or bundle this SETUP request into the existing session (aggregated
return a 459 (Aggregate Operation Not Allowed) error code (see session) or return a 459 (Aggregate Operation Not Allowed) error code
Section 17.4.23). An Aggregate control URI MUST be used to control (see Section 17.4.23). An Aggregate control URI MUST be used to
an aggregated session. This URI MUST be different from the stream control an aggregated session. This URI MUST be different from the
control URIs of the individual media streams included in the stream 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 choose However, even if aggregated control is offered, the client MAY choose
not to set up the session in aggregated control. If an Aggregate not to 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.
The SETUP of media streams in an aggregate that has not been given an The SETUP of media streams in an aggregate that has not been given an
skipping to change at page 70, line 24 skipping to change at page 70, line 24
where it is useful to note the actual resource on which a request where it is useful to note the actual resource on which a request
was operating. was operating.
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 18.49. Signs of liveness for an RTSP further discussion, see Section 18.49. Signs of liveness for an RTSP
session are: session include any RTSP requests from a client that contain a
Session header with the ID for that session, as well as RTCP sender
o any RTSP request from a client that includes a Session header with or receiver reports if RTP is used to transport the underlying media
that session's ID. stream. RTCP sender reports may, for example, be received in session
where the server is invited into a conference session and are thus
o if RTP is used as a transport for the underlying media streams, an valid as a liveness indicator.
RTCP sender or receiver report from the client(s) for any of the
media streams in that RTSP session. RTCP Sender Reports may, for
example, be received in sessions where the server is invited into
a conference session and is valid for keep-alive.
If a SETUP request on a session fails for any reason, the session If a SETUP request on a session fails for any reason, the session
state, as well as transport and other parameters for associated state, as well as transport and other parameters for associated
streams, MUST remain unchanged from their values as if the SETUP streams, MUST remain unchanged from their values as if the SETUP
request had never been received by the server. request had never been received by the server.
13.3.1. Changing Transport Parameters 13.3.1. Changing Transport Parameters
A client MAY issue a SETUP request for a stream that is already set A client MAY issue a SETUP request for a stream that is already set
up or playing in the session to change transport parameters, which a up or playing in the session to change transport parameters, which a
skipping to change at page 71, line 14 skipping to change at page 71, line 11
perform a TEARDOWN of the affected media and then set it up again. perform a TEARDOWN of the affected media and then set it up again.
For an aggregated session, not tearing down all the media at the same For an aggregated session, not tearing down all the media at the same
time will avoid the creation of a new session. time will avoid the creation of a new session.
All transport parameters MAY be changed. However, the primary usage All transport parameters MAY be changed. However, the primary usage
expected is to either change the transport protocol completely, like expected is to either change the transport protocol completely, like
switching from Interleaved TCP mode to UDP or vice versa, or to switching from Interleaved TCP mode to UDP or vice versa, or to
change the delivery address. change the delivery address.
In a SETUP response for a request to change the transport parameters In a SETUP response for a request to change the transport parameters
while in Play state, the server MUST include the Range to indicate at while in Play state, the server MUST include the Range header to
what point the new transport parameters will be used. Further, if indicate at what point the new transport parameters will be used.
RTP is used for delivery, the server MUST also include the RTP-Info Further, if RTP is used for delivery, the server MUST also include
header to indicate at what timestamp and RTP sequence number the the RTP-Info header to indicate at what timestamp and RTP sequence
change will take place. If both RTP-Info and Range are included in number the change will take place. If both RTP-Info and Range are
the response, the "rtp_time" parameter and start point in the Range included in the response, the "rtp_time" parameter and start point in
header MUST be for the corresponding time, i.e., be used in the same the Range header MUST be for the corresponding time, i.e., be used in
way as for PLAY to ensure the correct synchronization information is the same way as for PLAY to ensure the correct synchronization
available. information is available.
If the transport-parameters change that happened while in Play state If the transport-parameters change that happened while in Play state
results in a change of synchronization-related information, for results in a change of synchronization-related information, for
example, changing RTP SSRC, the server MUST provide in the SETUP example, changing RTP SSRC, the server MUST include the necessary
response the necessary synchronization information. However, the synchronization information in the SETUP response. However, the
server is RECOMMENDED to avoid changing the synchronization server SHOULD avoid changing the synchronization information if
information if possible. possible.
13.4. PLAY 13.4. PLAY
This section describes the usage of the PLAY method in general, for This section describes the usage of the PLAY method in general, for
aggregated sessions, and in different usage scenarios. aggregated sessions, and in different usage scenarios.
13.4.1. General Usage 13.4.1. General Usage
The PLAY method tells the server to start sending data via the The PLAY method tells the server to start sending data via the
mechanism specified in SETUP and which part of the media should be mechanism specified in SETUP and which part of the media should be
skipping to change at page 72, line 47 skipping to change at page 72, line 43
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 18.30). It is specified include the Media-Range header (Section 18.30). 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 18.46) is included with a negative value and a Scale header (Section 18.46) 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 indicate which
preference on which policy for start point selection the server shall policy for start point selection the server should use. This is done
use. This is done by including the Seek-Style header (Section 18.47) by including the Seek-Style header (Section 18.47) in the PLAY
in the PLAY request. The Seek-Style applied will affect the content request. The Seek-Style applied will affect the content of the Range
of the Range header as it will be adjusted to indicate from what header as it will be adjusted to indicate from what point the media
point the media actually is delivered. 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.
All range specifiers in this specification allow for ranges with an All range specifiers in this specification allow for ranges with an
implicit start point (e.g., "npt=-30"). When used in a PLAY request, implicit start point (e.g., "npt=-30"). When used in a PLAY request,
the server treats this as a request to start or resume delivery from the server treats this as a request to start or resume delivery from
the current pause point, ending at the end time specified in the the current pause point, ending at the end time specified in the
Range header. If the pause point is located later than the given end Range header. If the pause point is located later than the given end
value, a 457 (Invalid Range) response MUST be given. value, a 457 (Invalid Range) response MUST be returned.
The example below will play seconds 10 through 25. It also requests The example below will play seconds 10 through 25. It also requests
that the server deliver media from the first Random Access Point that the server deliver media from the first Random Access Point
prior to the indicated start point. prior to the indicated start point.
C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0 C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: ULExwZCXh2pd0xuFgkgZJW
Range: npt=10-25 Range: npt=10-25
Seek-Style: RAP Seek-Style: RAP
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Servers MUST include a Range header in any PLAY response, even if no Servers MUST include a Range header in any PLAY response, even if no
Range header was present in the request. The response MUST use the Range header was present in the request. The response MUST use the
same format as the request's Range header contained. If no Range same format as the request's Range header contained. If no Range
header was in the request, the format used in any previous PLAY header was in the request, the format used in any previous PLAY
request within the session SHOULD be used. If no format has been request within the session SHOULD be used. If no format has been
indicated in a previous request, the server MAY use any time format indicated in a previous request, the server MAY use any time format
skipping to change at page 74, line 19 skipping to change at page 74, line 15
Section 18.45, and used in the following example. Section 18.45, 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: ULExwZCXh2pd0xuFgkgZJW
Range: npt=3.52- Range: npt=3.52-
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: 836 CSeq: 836
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Range: npt=3.51-324.39 Range: npt=3.51-324.39
Seek-Style: First-Prior Seek-Style: First-Prior
Session: ULExwZCXh2pd0xuFgkgZJW
RTP-Info:url="rtsp://example.com/audio" RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545 ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTP Packet TS=2345962545 => NPT=3.51 S->C: RTP Packet TS=2345962545 => NPT=3.51
Media duration=0.16 seconds Media duration=0.16 seconds
The server replies with the actual start point that will be The server replies with the actual start point that will be
delivered. This may differ from the requested range if alignment of delivered. This may differ from the requested range if alignment of
the requested range to valid frame boundaries is required for the the requested range to valid frame boundaries is required for the
media source. Note that some media streams in an aggregate may need media source. Note that some media streams in an aggregate may need
skipping to change at page 75, line 7 skipping to change at page 75, line 7
header. header.
In the following example, the client receives the first media packet In the following example, the client receives the first media packet
that stretches all the way up and past the requested playtime. Thus, that stretches all the way up and past the requested playtime. Thus,
it is the client's decision whether to render to the user the time it is the client's decision whether to render to the user the time
between 3.52 and 7.05 or to skip it. In most cases, it is probably between 3.52 and 7.05 or to skip it. In most cases, it is probably
most suitable not to render that time period. most suitable not to render that time period.
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: ZGGyCJOs8xaLkdNK2dmxQO
Range: npt=7.05- Range: npt=7.05-
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: 836 CSeq: 836
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Session: ZGGyCJOs8xaLkdNK2dmxQO
Range: npt=3.52- Range: npt=3.52-
Seek-Style: First-Prior Seek-Style: First-Prior
RTP-Info:url="rtsp://example.com/audio" RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545 ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTP Packet TS=2345962545 => NPT=3.52 S->C: RTP Packet TS=2345962545 => NPT=3.52
Duration=4.15 seconds Duration=4.15 seconds
After playing the desired range, if the presentation does NOT change After playing the desired range, the presentation does NOT change to
to the Ready state, media delivery simply stops. If it is necessary the Ready state, media delivery simply stops. If it is necessary to
to put the stream into the Ready state, a PAUSE request MUST be put the stream into the Ready state, a PAUSE request MUST be issued.
issued. A PLAY request while the stream is still in the Play state A PLAY request while the stream is still in the Play state is legal
is legal and can be issued without an intervening PAUSE request. and can be issued without an intervening PAUSE request. Such a
Such a request MUST replace the current PLAY action with the new one request MUST replace the current PLAY action with the new one
requested, i.e., being handled in the same way as if as the request requested, i.e., being handled in the same way as if as the request
was received in Ready state. In the case that the range in the Range was received in Ready state. In the case that the range in the Range
header has an implicit start time ("-endtime"), the server MUST header has an implicit start time ("-endtime"), the server MUST
continue to play from where it currently was until the specified continue to play from where it currently was until the specified
endpoint. This is useful to change the end to at another point than endpoint. This is useful to change the end to at another point than
in the previous request. in the previous request.
The following example plays the whole presentation starting at SMPTE The following example plays the whole presentation starting at SMPTE
time code 0:10:20 until the end of the clip. Note: the RTP-Info time code 0:10:20 until the end of the clip. Note: the RTP-Info
headers have been broken into several lines, where following lines headers have been broken into several lines, where subsequent lines
start with whitespace as allowed by the syntax. start with whitespace as allowed by the syntax.
C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0
CSeq: 833 CSeq: 833
Session: 12345678 Session: N465Wvsv0cjUy6tLqINkcf
Range: smpte=0:10:20- Range: smpte=0:10:20-
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: 833 CSeq: 833
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: 12345678 Session: N465Wvsv0cjUy6tLqINkcf
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Range: smpte=0:10:22-0:15:45 Range: smpte=0:10:22-0:15:45
Seek-Style: Next Seek-Style: Next
RTP-Info:url="rtsp://example.com/twister.en" RTP-Info:url="rtsp://example.com/twister.en"
ssrc=0D12F123:seq=14783;rtptime=2345962545 ssrc=0D12F123:seq=14783;rtptime=2345962545
For playing back a recording of a live presentation, it may be For playing back a recording of a live presentation, it may be
desirable to use clock units: desirable to use clock units:
C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: N465Wvsv0cjUy6tLqINkcf
Range: clock=19961108T142300Z-19961108T143520Z Range: clock=19961108T142300Z-19961108T143520Z
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: 835 CSeq: 835
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: 12345678 Session: N465Wvsv0cjUy6tLqINkcf
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Range: clock=19961108T142300Z-19961108T143520Z Range: clock=19961108T142300Z-19961108T143520Z
Seek-Style: Next Seek-Style: Next
RTP-Info:url="rtsp://example.com/meeting.en" RTP-Info:url="rtsp://example.com/meeting.en"
ssrc=0D12F123:seq=53745;rtptime=484589019 ssrc=0D12F123:seq=53745;rtptime=484589019
13.4.2. Aggregated Sessions 13.4.2. Aggregated Sessions
PLAY requests can operate on sessions controlling a single media and PLAY requests can operate on sessions controlling a single media
on aggregated sessions controlling multiple media. stream and on aggregated sessions controlling multiple media streams.
In an aggregated session, the PLAY request MUST contain an aggregated In an aggregated session, the PLAY request MUST contain an aggregated
control URI. A server MUST respond with a 460 error (Only Aggregate control URI. A server MUST respond with a 460 error (Only Aggregate
Operation Allowed) if the client PLAY Request-URI is for a single Operation Allowed) if the client PLAY Request-URI is for a single
media. The media in an aggregate MUST be played in sync. If a media. The media in an aggregate MUST be played in sync. If a
client wants individual control of the media, it needs to use client wants individual control of the media, it needs to use
separate RTSP sessions for each media. separate RTSP sessions for each media.
For aggregated sessions where the initial SETUP request (creating a For aggregated sessions where the initial SETUP request (creating a
session) is followed by one or more additional SETUP requests, a PLAY session) is followed by one or more additional SETUP requests, a PLAY
request MAY be pipelined after those additional SETUP requests request MAY be pipelined (Section 12) after those additional SETUP
without awaiting their responses. This procedure can reduce the requests without awaiting their responses. This procedure can reduce
delay from the start of session establishment until media playout has the delay from the start of session establishment until media playout
started with one RTT. However, a client needs to be aware that using has started with one RTT. However, a client needs to be aware that
this procedure will result in the playout of the server state using this procedure will result in the playout of the server state
established at the time of processing the PLAY, i.e., after the established at the time of processing the PLAY, i.e., after the
processing of all the requests prior to the PLAY request in the processing of all the requests prior to the PLAY request in the
pipeline. This state may not be the intended one due to failure of pipeline. This state may not be the intended one due to failure of
any of the prior requests. A client can easily determine this based any of the prior requests. A client can easily determine this based
on the responses from those requests. In case of failure, the client on the responses from those requests. In case of failure, the client
can halt the media playout using PAUSE and try to establish the can halt the media playout using PAUSE and try to establish the
intended state again before issuing another PLAY request. intended state again before issuing another PLAY request.
13.4.3. Updating Current PLAY Requests 13.4.3. Updating Current PLAY Requests
skipping to change at page 78, line 9 skipping to change at page 78, line 9
The following is an example of this behavior: The server has received The following is an example of this behavior: The server has received
requests to play ranges 10 to 15. If the new PLAY request arrives at requests to play ranges 10 to 15. If the new PLAY request arrives at
the server 4 seconds after the previous one, it will take effect the server 4 seconds after the previous one, it will take effect
while the server still plays the first range (10-15). The server while the server still plays the first range (10-15). The server
changes the current play to continue to 25 seconds, i.e., the changes the current play to continue to 25 seconds, i.e., the
equivalent single request would be PLAY with "range: npt=10-25". equivalent single request would be PLAY with "range: npt=10-25".
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: apzA8LnjQ5KWTdw0kUkiRh
Range: npt=10-15 Range: npt=10-15
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: 834 CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: 12345678 Session: apzA8LnjQ5KWTdw0kUkiRh
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Range: npt=10-15 Range: npt=10-15
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=934207921, ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792482193 ssrc=789DAF12:seq=57654;rtptime=2792482193
Session: 12345678
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: apzA8LnjQ5KWTdw0kUkiRh
Range: npt=-25 Range: npt=-25
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: 835 CSeq: 835
Date: Thu, 23 Jan 1997 15:35:09 GMT Date: Thu, 23 Jan 1997 15:35:09 GMT
Session: 12345678 Session: apzA8LnjQ5KWTdw0kUkiRh
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Range: npt=14-25 Range: npt=14-25
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
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 fast forward or fast scale of the media, i.e., entering or leaving fast forward or fast
rewind. The client can issue an updating PLAY request that is either rewind. The client can issue an updating PLAY request that is either
a continuation or a complete replacement, as discussed above this a continuation or a complete replacement, as discussed above this
section. Below is an example of a client that is requesting a fast section. Below is an example of a client that is requesting a fast
forward (scale=2) without giving a stop point and then a change from forward (scale = 2) without giving a stop point and then a change
fast forward to regular playout (scale = 1). In the second PLAY from fast forward to regular playout (scale = 1). In the second PLAY
request, the time is set explicitly to be wherever the server request, the time is set explicitly to be wherever the server
currently plays out (npt=now-) and the server responds with the currently plays out (npt=now-) and the server responds with the
actual playback point where the new scale actually takes effect actual playback point where the new scale actually takes effect
(npt=02:17:27.144-). (npt=02: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: apzA8LnjQ5KWTdw0kUkiRh
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
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: 12345678 Session: apzA8LnjQ5KWTdw0kUkiRh
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Range: npt=02:17:21.394- Range: npt=02:17:21.394-
Seek-Style: Next Seek-Style: Next
Scale: 2.0 Scale: 2.0
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921, ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792482193 ssrc=789DAF12:seq=57654;rtptime=2792482193
[playing in fast forward and now returning to scale = 1] [playing in fast forward and now returning to scale = 1]
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2035 CSeq: 2035
Session: 12345678 Session: apzA8LnjQ5KWTdw0kUkiRh
Range: npt=now- Range: npt=now-
Scale: 1.0 Scale: 1.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: 2035 CSeq: 2035
Date: Thu, 23 Jan 1997 15:35:09 GMT Date: Thu, 23 Jan 1997 15:35:09 GMT
Session: 12345678 Session: apzA8LnjQ5KWTdw0kUkiRh
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Range: npt=02:17:27.144- Range: npt=02:17:27.144-
Seek-Style: Next Seek-Style: Next
Scale: 1.0 Scale: 1.0
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
skipping to change at page 80, line 38 skipping to change at page 80, line 38
o the Retention property is set to Unlimited or Time-Limited. o the Retention property is 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 first being that the client will media resources in Play state. The first being that the client will
receive a PLAY_NOTIFY request with the Notify-Reason header set to receive a PLAY_NOTIFY request with the Notify-Reason header set to
media-properties-update (see Section 13.5.2). The client can use the media-properties-update (see Section 13.5.2). The client can use the
value of the Media-Range to decide further actions, if the Media- value of the Media-Range header to decide further actions, if the
Range header is present in the PLAY_NOTIFY request. The second way Media-Range header is present in the PLAY_NOTIFY request. The second
is that the client issues a GET_PARAMETER request without a body but way is that the client issues a GET_PARAMETER request without a body
including a Media-Range header. The 200 OK response MUST include the but including a Media-Range header. The 200 OK response MUST include
current Media-Range header (see Section 18.30). the current Media-Range header (see Section 18.30).
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 when (see also Section 18.29): in the SETUP response when (see also Section 18.29):
o the Random-Access property is set to No-Seeking; o the Random-Access property is set to No-Seeking;
o the Content Modifications property is set to Time-Progressing; o the Content Modifications property is set to Time-Progressing;
o the Retention property's Time-Duration is set to 0.0. o the Retention property's Time-Duration is set to 0.0.
For live media, the SETUP 200 OK response MUST include the Media- For live media, the SETUP 200 OK response MUST include the Media-
Range header (see Section 18.30). Range header (see Section 18.30).
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-" cannot be used in the response. Instead, the time
the time since session start is recommended, expressed as an open since session start is recommended, expressed as an open interval,
interval, e.g., "npt=96.23-". An absolute time value (clock) for the e.g., "npt=96.23-". An absolute time value (clock) for the
corresponding time MAY be given, i.e., "clock=20030213T143205Z-". corresponding time MAY be given, i.e., "clock=20030213T143205Z-".
The Absolute Time format can only be used if the client has shown The Absolute Time format can only be used if the client has shown
support for it using the Accept-Ranges header. support for it 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
skipping to change at page 81, line 49 skipping to change at page 81, line 49
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 border of the window. If the client requests a delivery point that
is located outside the recording window, e.g., if the requested point is located outside the recording window, e.g., if the requested point
is too far in the past, the server selects the oldest point in the is too far in the past, the server selects the oldest point in the
recording. The considerations in Section 13.5.3 apply if a client recording. The considerations in Section 13.5.3 apply if a client
requests delivery with Scale (Section 18.46) values other than 1.0 requests delivery with scale (Section 18.46) values other than 1.0
(normal playback rate) while delivering live media with recording. (normal playback 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 when (see also Properties header in the SETUP response when (see also
skipping to change at page 82, line 25 skipping to change at page 82, line 25
o the Random Access property is set to Random-Access; o the Random Access property is set to Random-Access;
o the Content Modifications property is set to Time-Progressing; o the Content Modifications property is set to Time-Progressing;
o the Retention property is set to Time-Duration and a value o the Retention property is set to Time-Duration and a value
indicating the recording interval (>0). indicating the recording interval (>0).
The SETUP 200 OK response MUST include the Media-Range header (see The SETUP 200 OK response MUST include the Media-Range header (see
Section 18.30) for this type of media. For live media with Section 18.30) for this type of media. For live media with
recording, the Range header indicates the current time in the media recording, the Range header indicates the current time in the media
and the Media Range indicates a window around the current time. This and the Media-Range header indicates a window around the current
window can cover recorded content in the past (seen from current time time. This window can cover recorded content in the past (seen from
in the media) or recorded content in the future (seen from current current time in the media) or recorded content in the future (seen
time in the media). The server adjusts the play point to the from current time in the media). The server adjusts the play point
requested border of the window, if the client requests a play point to the requested border of the window, if the client requests a play
that is located outside the recording windows, e.g., if requested too point that is located outside the recording windows, e.g., if
far in the past, the server selects the oldest range in the requested too far in the past, the server selects the oldest range in
recording. The considerations in Section 13.5.3 apply if a client the recording. The considerations in Section 13.5.3 apply if a
requests delivery using a Scale (Section 18.46) value other than 1.0 client requests delivery using a scale (Section 18.46) value other
(normal playback rate) while delivering live media with time-shift. than 1.0 (normal playback 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 83, line 26 skipping to change at page 83, line 27
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 18.32) specifies the reason why The Notify-Reason header (see Section 18.32) 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 can be added in the future (see Section 22.8). In case the reasons can 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 a 465 (Notification Reason Unknown) (Section 17.4.29) respond with a 465 (Notification Reason Unknown) (Section 17.4.29)
error code. Servers can send PLAY_NOTIFY with these types: error code. This document defines how servers can send PLAY_NOTIFY
with Notify-Reason values of 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 the Notify-Reason header set to end-of- A PLAY_NOTIFY request with the Notify-Reason header set to end-of-
stream indicates the completion or near completion of the PLAY stream indicates the completion or near completion of the PLAY
request and the ending delivery of the media stream(s). The request request and the ending delivery of the media stream(s). The request
MUST NOT be issued unless the server is in the Play state. The end MUST NOT be issued unless the server is in the Play state. The end
of the media stream delivery notification may be used either to of the media stream delivery notification may be used either to
indicate a successful completion of the PLAY request currently being indicate a successful completion of the PLAY request currently being
served or to indicate some error resulting in failure to complete the served or to indicate some error resulting in failure to complete the
request. The Request-Status header (Section 18.42) MUST be included request. The Request-Status header (Section 18.42) MUST be included
to indicate which request the notification is for and its completion to 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 MAY 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.
PLAY_NOTIFY requests with the Notify-Reason header set to end-of- PLAY_NOTIFY requests with the Notify-Reason header set to end-of-
stream MUST include a Range header and the Scale header if the scale stream MUST include a Range header and the Scale header if the scale
value is not 1. The Range header indicates the point in the stream value is not 1. The Range header indicates the point in the stream
or streams where delivery is ending with the timescale that was used or streams where delivery is ending with the timescale that was used
by the server in the PLAY response for the request being fulfilled. by the server in the PLAY response for the request being fulfilled.
The server MUST NOT use the "now" constant in the Range header; it The server MUST NOT use the "now" constant in the Range header; it
MUST use the actual numeric end position in the proper timescale. MUST use the actual numeric end position in the proper timescale.
When end-of-stream notifications are issued prior to having sent the When end-of-stream notifications are issued prior to having sent the
last media packets, this is made evident because the end time in the last media packets, this is made evident because the end time in the
Range header is beyond the current time in the media being received Range header is beyond the current time in the media being received
by the client, e.g., "npt=-15", if npt is currently at 14.2 seconds. by the client, e.g., "npt=-15", if npt is currently at 14.2 seconds.
The Scale header is to be included so that it is evident if the media The Scale header is to be included so that it is evident if the media
timescale is moving backwards and/or has a non-default pace. The timescale is moving backwards or has a non-default pace. The end-of-
end-of-stream notification does not prevent the client from sending a stream notification does not prevent the client from sending a new
new PLAY request. PLAY request.
If RTP is used as media transport, an RTP-Info header MUST be If RTP is used as media transport, an RTP-Info header MUST be
included, and the RTP-Info header MUST indicate the last sequence included, and the RTP-Info header MUST indicate the last sequence
number in the sequence parameter. number in the sequence parameter.
For an RTSP Session where media resources are under aggregated For an RTSP Session where media resources are under aggregated
control, the media resources will normally end at approximately the control, the media resources will normally end at approximately the
same time, although some small differences may exist, on the scale of same time, although some small differences may exist, on the scale of
a few hundred milliseconds. In those cases, an RTSP session under a few hundred milliseconds. In those cases, an RTSP session under
aggregated control SHOULD send only a single PLAY_NOTIFY request. By aggregated control SHOULD send only a single PLAY_NOTIFY request. By
skipping to change at page 85, line 14 skipping to change at page 85, line 17
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 854 CSeq: 854
Notify-Reason: end-of-stream Notify-Reason: end-of-stream
Request-Status: cseq=853 status=200 reason="OK" Request-Status: cseq=853 status=200 reason="OK"
Range: npt=-145 Range: npt=-145
RTP-Info:url="rtsp://example.com/fizzle/foo/audio" RTP-Info:url="rtsp://example.com/fizzle/foo/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545, ssrc=0D12F123:seq=14783;rtptime=2345962545,
url="rtsp://example.com/fizzle/video" url="rtsp://example.com/fizzle/video"
ssrc=789DAF12:seq=57654;rtptime=2792482193 ssrc=789DAF12:seq=57654;rtptime=2792482193
Session: CDtUJfDQXJWtJ7Iqua2xOi
Session: uZ3ci0K+Ld-M
Date: Mon, 08 Mar 2010 13:37:16 GMT Date: Mon, 08 Mar 2010 13:37:16 GMT
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: CDtUJfDQXJWtJ7Iqua2xOi
13.5.2. Media-Properties-Update 13.5.2. Media-Properties-Update
A PLAY_NOTIFY request with a Notify-Reason header set to media- A PLAY_NOTIFY request with a 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 18.29) and/or the available media range given session (see Section 18.29) or the available media range that
that can be played as indicated by the Media-Range header can be played as indicated by the Media-Range header (Section 18.30).
(Section 18.30). PLAY_NOTIFY requests with Notify-Reason header set PLAY_NOTIFY requests with Notify-Reason header set to media-
to media-properties-update MUST include a Media-Properties and Date properties-update MUST include a Media-Properties and Date header and
header and SHOULD include a Media-Range header. The Media-Properties SHOULD include a Media-Range header. The Media-Properties header has
header has session scope; thus, for aggregated sessions, the session scope; thus, for aggregated sessions, the PLAY_NOTIFY request
PLAY_NOTIFY request MUST use the aggregated control URI. MUST use the aggregated control URI.
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 available for play-back media range will estimates on how the available for play-back media range will
progress with wall clock time. In addition, it is RECOMMENDED that progress with wall clock time. In addition, it is RECOMMENDED that
the server send these notifications approximately every 5 minutes for the server send these notifications approximately every 5 minutes for
time-progressing content to ensure the long-term stability of the time-progressing content to ensure the long-term stability of the
client estimation and allow for clock skew detection by the client. client estimation and allow for clock skew detection by the client.
The time between notifications should be greater than 1 minute and The time between notifications should be greater than 1 minute and
less than 2 hours. For the reasons just explained, requests MUST less than 2 hours. For the reasons just explained, requests MUST
include a Media-Range header to provide current Media duration and a include a Media-Range header to provide current Media duration and a
Range header to indicate the current playing point and any remaining Range header to indicate the current playing point and any remaining
skipping to change at page 86, line 12 skipping to change at page 86, line 14
synchronization, it is only for determining which content is synchronization, it is only for determining which content is
available to the user. available to the user.
A PLAY_NOTIFY request with Notify-Reason header set to media- A PLAY_NOTIFY request with Notify-Reason header set to media-
properties-update MUST NOT carry a message body. properties-update MUST NOT carry a message body.
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
Date: Tue, 14 Apr 2008 15:48:06 GMT Date: Tue, 14 Apr 2008 15:48:06 GMT
CSeq: 854 CSeq: 854
Notify-Reason: media-properties-update Notify-Reason: media-properties-update
Session: uZ3ci0K+Ld-M Session: CDtUJfDQXJWtJ7Iqua2xOi
Media-Properties: Time-Progressing, Media-Properties: Time-Progressing,
Time-Limited=20080415T153919.36Z, Random-Access=5.0 Time-Limited=20080415T153919.36Z, Random-Access=5.0
Media-Range: npt=00:00:00-01:37:21.394 Media-Range: npt=00:00:00-01:37:21.394
Range: npt=01:15:49.873- Range: npt=01: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: CDtUJfDQXJWtJ7Iqua2xOi
13.5.3. Scale-Change 13.5.3. Scale-Change
The server may be forced to change the rate of media time per The server may be forced to change the rate of media time per
playback time when a client requests delivery using a Scale playback time when a client requests delivery using a scale
(Section 18.46) value other than 1.0 (normal playback rate). For (Section 18.46) value other than 1.0 (normal playback rate). For
time-progressing media with some retention, i.e., the server stores time-progressing media with some retention, i.e., the server stores
already-sent content, a client requesting to play with Scale values already-sent content, a client requesting to play with scale values
larger than 1 may catch up with the front end of the media. The larger than 1 may catch up with the front end of the media. The
server will then be unable to continue to provide content at Scale server will then be unable to continue to provide content at scale
larger than 1 as content is only made available by the server at larger than 1 as content is only made available by the server at
Scale=1. Another case is when Scale < 1 and the media retention is scale = 1. Another case is when scale < 1 and the media retention is
Time-Duration limited. In this case, the delivery point can reach Time-Duration limited. In this case, the delivery point can reach
the oldest media unit available, and further playback at this scale the oldest media unit available, and further playback at this scale
becomes impossible as there will be no media available. To avoid becomes impossible as there will be no media available. To avoid
having the client lose any media, the scale will need to be adjusted having the client lose any media, the scale will need to be adjusted
to the same rate at which the media is removed from the storage to the same rate at which the media is removed from the storage
buffer, commonly Scale = 1.0. buffer, commonly scale = 1.0.
Another case is when the content itself consists of spliced pieces or Another case is when the content itself consists of spliced pieces or
is dynamically updated. In these cases, the server may be required is dynamically updated. In these cases, the server may be required
to change from one supported scale value (different than Scale=1.0) to change from one supported scale value (different than scale = 1.0)
to another. In this case, the server will pick the closest value and to another. In this case, the server will pick the closest value and
inform the client of what it has picked. In these cases, the media inform the client of what it has picked. In these cases, the media
properties will also be sent, updating the supported Scale values. properties will also be sent, updating the supported scale values.
This enables a client to adjust the Scale value used. This enables a client to adjust the scale value used.
To minimize impact on playback in any of the above cases, the server To minimize impact on playback in any of the above cases, the server
MUST modify the playback properties, set Scale to a supportable MUST modify the playback properties, set scale to a supportable
value, and continue delivery of the media. When doing this value, and continue delivery of the media. When doing this
modification, it MUST send a PLAY_NOTIFY message with the Notify- modification, it MUST send a PLAY_NOTIFY message with the Notify-
Reason header set to "scale-change". The request MUST contain a Reason header set to "scale-change". The request MUST contain a
Range header with the media time when the change took effect, a Scale Range header with the media time when the change took effect, a Scale
header with the new value in use, a Session header with the header with the new value in use, a Session header with the
identifier for the session to which it applies, and a Date header identifier for the session to which it applies, and a Date header
with the server wallclock time of the change. For time-progressing with the server wallclock time of the change. For time-progressing
content, the Media-Range and the Media-Properties headers at this content, the Media-Range and the Media-Properties headers at this
point in time also MUST be included. The Media-Properties header point in time also MUST be included. The Media-Properties header
MUST be included if the scale change was due to the content changing MUST be included if the scale change was due to the content changing
what scale values are supported. what scale values ("Scales") are supported.
For media streams delivered using RTP, an RTP-Info header MUST also For media streams delivered using RTP, an RTP-Info header MUST also
be included. It MUST contain the rtptime parameter with a value be included. It MUST contain the rtptime parameter with a value
corresponding to the point of change in that media and optionally the corresponding to the point of change in that media and optionally the
sequence number. sequence number.
PLAY_NOTIFY requests for aggregated sessions MUST use the aggregated PLAY_NOTIFY requests for aggregated sessions MUST use the aggregated
control URI in the request. The scale change for any aggregated control URI in the request. The scale change for any aggregated
session applies to all media streams that are part of the aggregate. session applies to all media streams that are part of the aggregate.
A PLAY_NOTIFY request with Notify-Reason header set to "Scale-Change" A PLAY_NOTIFY request with Notify-Reason header set to "Scale-Change"
MUST NOT carry a message body. MUST NOT carry a message body.
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
Date: Tue, 14 Apr 2008 15:48:06 GMT Date: Tue, 14 Apr 2008 15:48:06 GMT
CSeq: 854 CSeq: 854
Notify-Reason: scale-change Notify-Reason: scale-change
Session: uZ3ci0K+Ld-M Session: CDtUJfDQXJWtJ7Iqua2xOi
Media-Properties: Time-Progressing, Media-Properties: Time-Progressing,
Time-Limited=20080415T153919.36Z, Random-Access=5.0 Time-Limited=20080415T153919.36Z, Random-Access=5.0
Media-Range: npt=00:00:00-01:37:21.394 Media-Range: npt=00:00:00-01:37:21.394
Range: npt=01:37:21.394- Range: npt=01:37:21.394-
Scale: 1 Scale: 1
RTP-Info: url="rtsp://example.com/fizzle/foo/audio" RTP-Info: url="rtsp://example.com/fizzle/foo/audio"
ssrc=0D12F123:rtptime=2345962545, ssrc=0D12F123:rtptime=2345962545,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/foo/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792482193 ssrc=789DAF12:seq=57654;rtptime=2792482193
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: CDtUJfDQXJWtJ7Iqua2xOi
13.6. PAUSE 13.6. PAUSE
The PAUSE request causes the stream delivery to immediately be The PAUSE request causes the stream delivery to immediately be
interrupted (halted). A PAUSE request MUST be made either with the interrupted (halted). A PAUSE request MUST be made either with the
aggregated control URI for aggregated sessions, resulting in all aggregated control URI for aggregated sessions, resulting in all
media being halted, or with the media URI for non-aggregated media being halted, or with the media URI for non-aggregated
sessions. Any attempt to mute a single media with a PAUSE request in sessions. Any attempt to mute a single media with a PAUSE request in
an aggregated session MUST be responded to with a 460 (Only Aggregate an aggregated session MUST be responded to with a 460 (Only Aggregate
Operation Allowed) error. After resuming playback, synchronization Operation Allowed) error. After resuming playback, synchronization
of the tracks MUST be maintained. Any server resources are kept, of the tracks MUST be maintained. Any server resources are kept,
though servers MAY close the session and free resources after being though servers MAY close the session and free resources after being
paused for the duration specified with the timeout parameter of the paused for the duration specified with the timeout parameter of the
Session header in the SETUP message. Session header in the SETUP message.
Example: Example:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: OoOUPyUwt0VeY9fFRHuZ6L
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: 834 CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: OoOUPyUwt0VeY9fFRHuZ6L
Range: npt=45.76-75.00 Range: npt=45.76-75.00
The PAUSE request causes stream delivery to be interrupted The PAUSE request causes stream delivery to be interrupted
immediately on receipt of the message, and the pause point is set to immediately on receipt of the message, and the pause point is set to
the current point in the presentation. That pause point in the media the current point in the presentation. That pause point in the media
stream needs to be maintained. A subsequent PLAY request without a stream needs to be maintained. A subsequent PLAY request without a
Range header resumes from the pause point and plays until media end. Range header resumes from the pause point and plays until media end.
The pause point after any PAUSE request MUST be returned to the The pause point after any PAUSE request MUST be returned to the
client by adding a Range header with what remains unplayed of the client by adding a Range header with what remains unplayed of the
PLAY request's range. For media with random access properties, if PLAY request's range. For media with random access properties, if
one desires to resume playing a ranged request, one simply includes one desires to resume playing a ranged request, one simply includes
the Range header from the PAUSE response and includes the Seek-Style the Range header from the PAUSE response and includes the Seek-Style
header with the Next policy in the PLAY request. For media that is header with the Next policy in the PLAY request. For media that is
time-progressing and has retention duration=0, the follow-up PLAY time-progressing and has retention duration=0, the follow-up PLAY
request to start media delivery again MUST use "npt=now-" and not the request to start media delivery again MUST use "npt=now-" and not the
answer given in the response to PAUSE. answer given in the response to PAUSE.
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Range: npt=10-30 Range: npt=10-30
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: 834 CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Range: npt=10-30 Range: npt=10-30
Seek-Style: First-Prior Seek-Style: First-Prior
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921, ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=4FAD8726:seq=57654;rtptime=2792482193 ssrc=4FAD8726:seq=57654;rtptime=2792482193
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
After 11 seconds, i.e., at 21 seconds into the presentation: After 11 seconds, i.e., at 21 seconds into the presentation:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
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: 835 CSeq: 835
Date: 23 Jan 1997 15:35:17 GMT Date: 23 Jan 1997 15:35:17 GMT
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Range: npt=21-30 Range: npt=21-30
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
If a client issues a PAUSE request and the server acknowledges and If a client issues a PAUSE request and the server acknowledges and
enters the Ready state, the proper server response, if the player enters the Ready state, the proper server response, if the player
issues another PAUSE, is still 200 OK. The 200 OK response MUST issues another PAUSE, is still 200 OK. The 200 OK response MUST
include the Range header with the current pause point. See examples include the Range header with the current pause point. See examples
below: below:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
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: 834 CSeq: 834
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Range: npt=45.76-98.36 Range: npt=45.76-98.36
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
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: 835 CSeq: 835
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Date: 23 Jan 1997 15:35:07 GMT Date: 23 Jan 1997 15:35:07 GMT
Range: npt=45.76-98.36 Range: npt=45.76-98.36
13.7. TEARDOWN 13.7. TEARDOWN
13.7.1. Client to Server 13.7.1. Client to Server
The TEARDOWN client-to-server request stops the stream delivery for The TEARDOWN client-to-server request stops the stream delivery for
the given URI, freeing the resources associated with it. A TEARDOWN the given URI, freeing the resources associated with it. A TEARDOWN
request can be performed on either an aggregated or a media control request can be performed on either an aggregated or a media control
skipping to change at page 91, line 12 skipping to change at page 91, line 12
that will exist after the processing of the TEARDOWN request MUST, in that will exist after the processing of the TEARDOWN request MUST, in
the response to that TEARDOWN request, contain a Session header. the response to that TEARDOWN request, contain a Session header.
Thus, the presence of the Session header indicates to the receiver of Thus, the presence of the Session header indicates to the receiver of
the response if the session is still extant or has been removed. the response if the session is still extant or has been removed.
Example: Example:
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 892 CSeq: 892
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
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: 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 18.52). in the Terminate-Reason header (Section 18.52).
When an RTSP client has maintained an RTSP session that otherwise is When an RTSP client has maintained an 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 18.49). However, the server is Session Timeout period (Section 18.49). However, the server is NOT
RECOMMENDED not to perform this operation until an extended period of RECOMMENDED to perform this operation until an extended period of
inactivity of 10 times the Session-Timeout period has passed. It is inactivity of 10 times the Session-Timeout period has passed. It is
up to the operator of the RTSP server to actually configure how long up to the operator of the RTSP server to actually configure how long
this extended period of inactivity is. An operator should take into this extended period of inactivity is. An operator should take into
account, when doing this configuration, what the served content is account, when doing this configuration, what the served content is
and what this means for the extended period of inactivity. and what this means for the extended period of inactivity.
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 92, line 35 skipping to change at page 92, line 35
the original server or the target server in the redirect. the original server or the target server in the redirect.
13.8. GET_PARAMETER 13.8. GET_PARAMETER
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. are two ways of specifying the parameters to be retrieved.
The first is by including headers that have been defined such that The first approach includes headers that have been defined to be
you can use them for this purpose. Headers for this purpose should usable for this purpose. Headers for this purpose should allow
allow empty, or stripped value parts to avoid having to specify bogus empty, or stripped value parts to avoid having to specify bogus data
data when indicating the desire to retrieve a value. The successful when indicating the desire to retrieve a value. The successful
completion of the request should also be evident from any filled out completion of the request should also be evident from any filled out
values in the response. The headers in this specification that MAY values in the response. The headers in this specification that MAY
be used for retrieving their current value using GET_PARAMETER are be used for retrieving their current value using GET_PARAMETER are
listed below; additional headers MAY be specified in the future: listed below; additional headers MAY be specified in the future:
o Accept-Ranges o Accept-Ranges
o Media-Range o Media-Range
o Media-Properties o Media-Properties
skipping to change at page 93, line 16 skipping to change at page 93, line 16
The other way is to specify a message body that lists the 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 18.19) is used to specify which format the message header (Section 18.19) is used to specify which format the message
body has. If the receiver of the request does not support the media body has. If the receiver of the request does not support the media
type used for the message body, it SHALL respond using the error code type used for the message body, it SHALL respond using the error code
415 (Unsupported Media Type). The responder to a GET_PARAMETER 415 (Unsupported Media Type). The responder to a GET_PARAMETER
request MUST use the media type of the request for the response. For request MUST use the media type of the request for the response. For
additional considerations regarding message body negotiation, see additional considerations regarding message body negotiation, see
Section 9.3. Section 9.3.
RTSP Agents implementing support for responding to GET_PARAMETER RTSP agents implementing support for responding to GET_PARAMETER
requests SHALL implement the "text/parameters" format (Appendix F). requests SHALL implement the "text/parameters" format (Appendix F).
This to ensure that at least one known format for parameters is This to ensure that at least one known format for parameters is
implemented and, thus, prevent parameter format negotiation failure. implemented and, thus, prevent parameter format negotiation failure.
Parameters specified within the body of the message must all be Parameters specified within the body of the message must all be
understood by the request-receiving agent. If one or more parameters understood by the request-receiving agent. If one or more parameters
are not understood a 451 (Parameter Not Understood) MUST be sent are not understood a 451 (Parameter Not Understood) MUST be sent
including a body listing the parameters that weren't understood. If including a body listing the parameters that weren't understood. If
all parameters are understood, their values are filled in and all parameters are understood, their values are filled in and
returned in the response message body. returned in the response message body.
skipping to change at page 94, line 8 skipping to change at page 94, line 8
has been processed. However, for cases when this is difficult to has been processed. However, for cases when this is difficult to
determine, it is recommended to use a feature-tag and the Require determine, it is recommended to use a feature-tag and the Require
header. For this reason, it is usually easier if any parameters to header. For this reason, it is usually easier if any parameters to
be retrieved are sent in the body, rather than using any header. be retrieved are sent in the body, rather than using any header.
Example: Example:
S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 431 CSeq: 431
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Content-Length: 26 Content-Length: 26
Content-Type: text/parameters Content-Type: text/parameters
packets_received packets_received
jitter jitter
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 431 CSeq: 431
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Server: PhonyServer/1.1 Server: PhonyServer/1.1
Date: Mon, 08 Mar 2010 13:43:23 GMT Date: Mon, 08 Mar 2010 13:43:23 GMT
Content-Length: 38 Content-Length: 38
Content-Type: text/parameters Content-Type: text/parameters
packets_received: 10 packets_received: 10
jitter: 0.3838 jitter: 0.3838
13.9. SET_PARAMETER 13.9. SET_PARAMETER
This method requests the setting of the value of a parameter or a set This method requests the setting of the value of a parameter or a set
of parameters for a presentation or stream specified by the URI. The of parameters for a presentation or stream specified by the URI. If
method MAY also be used without a message body. It is the the Session header is present in a request, the value of a parameter
RECOMMENDED method to be used in a request sent for the sole purpose MUST be retrieved in the specified session context. The method MAY
of updating the keep-alive timer. If this request is successful, also be used without a message body. It is the RECOMMENDED method to
i.e., a 200 OK response is received, then the keep-alive timer has be used in a request sent for the sole purpose of updating the keep-
been updated. Any non-required header present in such a request may alive timer. If this request is successful, i.e., a 200 OK response
or may not have been processed. To allow a client to determine if is received, then the keep-alive timer has been updated. Any non-
any such header has been processed, it is necessary to use a feature required header present in such a request may or may not have been
tag and the Require header. Due to this reason it is RECOMMENDED processed. To allow a client to determine if any such header has
that any parameters are sent in the body rather than using any been processed, it is necessary to use a feature tag and the Require
header. header. Due to this reason it is RECOMMENDED that any parameters are
sent in the body rather than using any header.
When using a message body to list the parameter(s) desired to be set, When using a message body to list the parameter(s) desired to be set,
the Content-Type header (Section 18.19) is used to specify which the Content-Type header (Section 18.19) is used to specify which
format the message body has. If the receiver of the request is not format the message body has. If the receiver of the request is not
supporting the media type used for the message body, it SHALL respond supporting the media type used for the message body, it SHALL respond
using the error code 415 (Unsupported Media Type). For additional using the error code 415 (Unsupported Media Type). For additional
considerations regarding message body negotiation, see Section 9.3. considerations regarding message body negotiation, see Section 9.3.
The responder to a SET_PARAMETER request MUST use the media type of
the request for the response. For additional considerations
regarding message body negotiation, see Section 9.3.
RTSP Agents implementing support for responding to SET_PARAMETER RTSP agents implementing support for responding to SET_PARAMETER
requests SHALL implement the text/parameters format (Appendix F). requests SHALL implement the text/parameters format (Appendix F).
This is to ensure that at least one known format for parameters is This is to ensure that at least one known format for parameters is
implemented and, thus, prevent parameter format negotiation failure. implemented and, thus, prevent parameter format negotiation failure.
A request is RECOMMENDED to only contain a single parameter to allow A request is RECOMMENDED to only contain a single parameter to allow
the client to determine why a particular request failed. If the the client to determine why a particular request failed. If the
request contains several parameters, the server MUST only act on the request contains several parameters, the server MUST only act on the
request if all of the parameters can be set successfully. A server request if all of the parameters can be set successfully. A server
MUST allow a parameter to be set repeatedly to the same value, but it MUST allow a parameter to be set repeatedly to the same value, but it
MAY disallow changing parameter values. If the receiver of the MAY disallow changing parameter values. If the receiver of the
skipping to change at page 95, line 22 skipping to change at page 95, line 27
(Parameter Not Understood) MUST be used. When a parameter is not (Parameter Not Understood) MUST be used. When a parameter is not
allowed to change, the error code is 458 (Parameter Is Read-Only). allowed to change, the error code is 458 (Parameter Is Read-Only).
The response body MUST contain only the parameters that have errors. The response body MUST contain only the parameters that have errors.
Otherwise, a body MUST NOT be returned. The response body MUST use Otherwise, a body MUST NOT be returned. The response body MUST use
the media type of the request for the response. the media type of the request for the response.
Note: transport parameters for the media stream MUST only be set with Note: transport parameters for the media stream MUST only be set with
the SETUP command. the SETUP command.
Restricting setting transport parameters to SETUP is for the Restricting setting transport parameters to SETUP is for the
benefit of firewalls. benefit of firewalls connected to border RTSP proxies.
The parameters are split in a fine-grained fashion so that there The parameters are split in a fine-grained fashion so that there
can be more meaningful error indications. However, it may make can be more meaningful error indications. However, it may make
sense to allow the setting of several parameters if an atomic sense to allow the setting of several parameters if an atomic
setting is desirable. Imagine device control where the client setting is desirable. Imagine device control where the client
does not want the camera to pan unless it can also tilt to the does not want the camera to pan unless it can also tilt to the
right angle at the same time. right angle at the same time.
Example: Example:
skipping to change at page 97, line 35 skipping to change at page 98, line 6
responded to REDIRECT requests for all the sessions managed by the responded to REDIRECT requests for all the sessions managed by the
signaling connection. signaling connection.
The Terminate-Reason header "time" parameter MAY be used to indicate The Terminate-Reason header "time" parameter MAY be used to indicate
the wallclock time by which the redirection MUST have taken place. the wallclock time by which the redirection MUST have taken place.
To allow a client to determine that redirect time without being time To allow a client to determine that redirect time without being time
synchronized with the server, the server MUST include a Date header synchronized with the server, the server MUST include a Date header
in the request. The client should have terminated the session and in the request. The client should have terminated the session and
closed the connection before the redirection time-line terminated. closed the connection before the redirection time-line terminated.
The server MAY simply cease to provide service when the deadline time The server MAY simply cease to provide service when the deadline time
has been reached, or it may issue TEARDOWN requests to the remaining has been reached, or it can issue a TEARDOWN requests to the
sessions. remaining sessions.
If the REDIRECT request times out following the rules in If the REDIRECT request times out following the rules in
Section 10.4, the server MAY terminate the session or transport Section 10.4, the server MAY terminate the session or transport
connection that would be redirected by the request. This is a connection that would be redirected by the request. This is a
safeguard against misbehaving clients that refuse to respond to a safeguard against misbehaving clients that refuse to respond to a
REDIRECT request. This action removes any incentive of not REDIRECT request. This action removes any incentive of not
acknowledging the reception of a REDIRECT request. acknowledging the reception of a REDIRECT request.
After a REDIRECT request has been processed, a client that wants to After a REDIRECT request has been processed, a client that wants to
continue to receive media for the resource identified by the Request- continue to receive media for the resource identified by the Request-
skipping to change at page 98, line 21 skipping to change at page 98, line 38
the old server, i.e., all media configuration information from the the old server, i.e., all media configuration information from the
old session is still valid except for the host address. However, the old session is still valid except for the host address. However, the
usage of conditional SETUP using MTag identifiers is RECOMMENDED as a usage of conditional SETUP using MTag identifiers is RECOMMENDED as a
means to verify the assumption. means to verify the assumption.
This example request redirects traffic for this session to the new This example request redirects traffic for this session to the new
server at the given absolute time: server at the given absolute time:
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 732 CSeq: 732
Location: rtsp://s2.example.com:8001 Location: rtsp://s2.example.com:8001/fizzle/foo
Terminate-Reason: Server-Admin ;time=19960213T143205Z Terminate-Reason: Server-Admin ;time=19960213T143205Z
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
Date: Thu, 13 Feb 1996 14:30:43 GMT Date: Thu, 13 Feb 1996 14:30:43 GMT
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 732 CSeq: 732
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
14. Embedded (Interleaved) Binary Data 14. Embedded (Interleaved) Binary Data
skipping to change at page 100, line 15 skipping to change at page 100, line 23
C->S: SETUP rtsp://example.com/bar.file RTSP/2.0 C->S: SETUP rtsp://example.com/bar.file 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, clock Accept-Ranges: npt, smpte, clock
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: 2 CSeq: 2
Date: Thu, 05 Jun 1997 18:57:18 GMT Date: Thu, 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;unicast;interleaved=5-6 Transport: RTP/AVP/TCP;unicast;interleaved=5-6
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Accept-Ranges: npt Accept-Ranges: npt
Media-Properties: Random-Access=0.2, Immutable, Unlimited Media-Properties: Random-Access=0.2, Immutable, Unlimited
C->S: PLAY rtsp://example.com/bar.file RTSP/2.0 C->S: PLAY rtsp://example.com/bar.file RTSP/2.0
CSeq: 3 CSeq: 3
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
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: 3 CSeq: 3
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
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 octet length}{"length" octets data, w/RTP header} S->C: $005{2 octet length}{"length" octets data, w/RTP header}
S->C: $005{2 octet length}{"length" octets data, w/RTP header} S->C: $005{2 octet length}{"length" octets data, w/RTP header}
S->C: $006{2 octet length}{"length" octets RTCP packet} S->C: $006{2 octet length}{"length" octets RTCP packet}
skipping to change at page 103, line 15 skipping to change at page 103, line 26
by proxy. by proxy.
15.2. Multiplexing and Demultiplexing of Messages 15.2. Multiplexing and Demultiplexing of Messages
RTSP proxies may have to multiplex several RTSP sessions from their RTSP proxies may have to multiplex several RTSP sessions from their
clients towards RTSP servers. This requires that RTSP requests from clients towards RTSP servers. This requires that RTSP requests from
multiple clients be multiplexed onto a common connection for requests multiple clients be multiplexed onto a common connection for requests
outgoing to an RTSP server, and, on the way back, the responses be outgoing to an RTSP server, and, on the way back, the responses be
demultiplexed from the server to per-client responses. On the demultiplexed from the server to per-client responses. On the
protocol level, this requires that request and response messages be protocol level, this requires that request and response messages be
handled in both ways, requiring that there be a mechanism to handled in both directions, requiring that there be a mechanism to
correlate which request/response pair exchanged between proxy and correlate which request/response pair exchanged between proxy and
server is mapped to which client (or client request). server is mapped to which client (or client request).
This multiplexing of requests and demultiplexing of responses is done This multiplexing of requests and demultiplexing of responses is done
by using the CSeq header field. The proxy has to rewrite the CSeq in by using the CSeq header field. The proxy has to rewrite the CSeq in
requests to the server and responses from the server and remember requests to the server and responses from the server and remember
which CSeq is mapped to which client. The proxy also needs to ensure which CSeq is mapped to which client. The proxy also needs to ensure
that the order of the message related to each client is maintained. that the order of the message related to each client is maintained.
Section 18.20 defines the handling of how requests and responses are Section 18.20 defines the handling of how requests and responses are
rewritten. rewritten.
skipping to change at page 105, line 17 skipping to change at page 105, line 27
header (which includes the validator) that implicitly turns the header (which includes the validator) that implicitly turns the
method (usually DESCRIBE or SETUP) into a conditional. method (usually DESCRIBE or SETUP) into a conditional.
The protocol includes both positive and negative senses of cache- The protocol includes both positive and negative senses of cache-
validating conditions. That is, it is possible to request that a validating conditions. That is, it is possible to request that a
method be performed either if and only if a validator matches or if method be performed either if and only if a validator matches or if
and only if no validators match. and only if no validators match.
Note: a response that lacks a validator may still be cached, and Note: a response that lacks a validator may still be cached, and
served from cache until it expires, unless this is explicitly served from cache until it expires, unless this is explicitly
prohibited by a cache-control directive (see Section 18.11). prohibited by a cache directive (see Section 18.11). However, a
However, a cache cannot perform a conditional retrieval if it does cache cannot perform a conditional retrieval if it does not have a
not have a validator for the resource, which means it will not be validator for the resource, which means it will not be refreshable
refreshable after it expires. after it expires.
Media streams that are being adapted based on the transport capacity Media streams that are being adapted based on the transport capacity
between the server and the cache make caching more difficult. A between the server and the cache make caching more difficult. A
server needs to consider how it views the caching of media streams server needs to consider how it views the caching of media streams
that it adapts and potentially instruct any caches not to cache such that it adapts and potentially instruct any caches not to cache such
streams. streams.
16.1.1. Last-Modified Dates 16.1.1. Last-Modified Dates
The Last-Modified header (Section 18.27) value is often used as a The Last-Modified header (Section 18.27) value is often used as a
cache validator. In simple terms, a cache entry is considered to be cache validator. In simple terms, a cache entry is considered to be
valid if the cache entry was created after the Last-Modified time. valid if the cache entry was created after the Last-Modified time.
16.1.2. Message Body Tag Cache Validators 16.1.2. Message Body Tag Cache Validators
The MTag response-header field value, a message body tag, provides The MTag response-header field-value, a message body tag, provides
for an "opaque" cache validator. This might allow more reliable for an "opaque" cache validator. This might allow more reliable
validation in situations where it is inconvenient to store validation in situations where it is inconvenient to store
modification dates, where the one-second resolution of RTSP-date modification dates, where the one-second resolution of RTSP-date
values is not sufficient, or where the origin server wishes to avoid values is not sufficient, or where the origin server wishes to avoid
certain paradoxes that might arise from the use of modification certain paradoxes that might arise from the use of modification
dates. dates.
Message body tags are described in Section 4.6 Message body tags are described in Section 4.6
16.1.3. Weak and Strong Validators 16.1.3. Weak and Strong Validators
skipping to change at page 110, line 42 skipping to change at page 111, line 9
Where applicable, HTTP status codes (see Section 6 of [RFC7231]) are Where applicable, HTTP status codes (see Section 6 of [RFC7231]) are
reused. See Table 4 in Section 8.1 for a listing of which status reused. See Table 4 in Section 8.1 for a listing of which status
codes may be returned by which requests. All error messages, 4xx and codes may be returned by which requests. All error messages, 4xx and
5xx, MAY return a body containing further information about the 5xx, MAY return a body containing further information about the
error. error.
17.1. Informational 1xx 17.1. Informational 1xx
17.1.1. 100 Continue 17.1.1. 100 Continue
The client SHOULD continue with its request. This interim response The agent SHOULD continue with its request. This interim response is
is used to inform the client that the initial part of the request has used to inform the agent 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 agent. The agent
client SHOULD continue by sending the remainder of the request or, if SHOULD continue by sending the remainder of the request or, if the
the request has already been completed, ignore this response. The request has already been completed, continue to wait for a final
server MUST send a final response after the request has been response (See Section 10.4). The agent MUST send a final response
completed. after the request has been completed.
17.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 agent's request was
successfully received, understood, and accepted. successfully received, understood, and accepted.
17.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.
17.3. Redirection 3xx 17.3. Redirection 3xx
The notation "3xx" indicates response codes from 300 to 399 inclusive The notation "3xx" indicates response codes from 300 to 399 inclusive
that are meant for redirection. The response code 304 is excluded, that are meant for redirection. We use the notation "3rr" to
as it is not used for redirection and instead the "3rr" notation is indicate all 3xx codes used for redirection, i.e., excluding 304.
used. The 304 response code appears here, rather than a 2xx response The 304 response code appears here, rather than a 2xx response code,
code, which would have been appropriate; 304 has also been used in which would have been appropriate; 304 has also been used in RTSP 1.0
RTSP 1.0 [RFC2326]. [RFC2326].
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 agent. Mechanisms to determine topological proximity are beyond the
scope of this specification. scope of this specification.
A 3rr code MAY be used to respond to any request. The Location A 3rr code MAY be used to respond to any request. The Location
header MUST be included in any 3rr response. It is RECOMMENDED that header MUST be included in any 3rr response. It is RECOMMENDED that
they are used if necessary before a session is established, i.e., in they are used if necessary before a session is established, i.e., in
response to DESCRIBE or SETUP. However, in cases where a server is response to DESCRIBE or SETUP. However, in cases where a server is
not able to send a REDIRECT request to the client, the server MAY not able to send a REDIRECT request to the agent, the server MAY need
need to resort to using 3rr responses to inform a client with an to resort to using 3rr responses to inform a agent with an
established session about the need for redirecting the session. If a established session about the need for redirecting the session. If a
3rr response is received for a request in relation to an established 3rr response is received for a request in relation to an established
session, the client SHOULD send a TEARDOWN request for the session session, the agent SHOULD send a TEARDOWN request for the session and
and MAY reestablish the session using the resource indicated by the MAY reestablish the session using the resource indicated by the
Location. 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 agent is redirected
to; the URI MUST NOT only contain the hostname. to; the URI MUST NOT only contain the hostname.
In the event that an unknown 3rr status code is received, the agent In the event that an unknown 3rr status code is received, the agent
SHOULD behave as if a 302 response code had been received SHOULD behave as if a 302 response code had been received
(Section 17.3.3). (Section 17.3.3).
17.3.1. 300 17.3.1. 300
The 300 response code is not used in RTSP 2.0. The 300 response code is not used in RTSP 2.0.
17.3.2. 301 Moved Permanently 17.3.2. 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 agent 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.
17.3.3. 302 Found 17.3.3. 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. This response is intended to be used for many types Location header. This response is intended to be used for many types
of temporary redirects, e.g., load balancing. It is RECOMMENDED that of 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 Location header MUST be included in the
automatically to the given URI. This response MUST NOT contain a response. The user agent SHOULD redirect automatically to the given
message-body. URI. This response MUST NOT contain a message body.
This example shows a client being redirected to a different server: This example shows a client being redirected to a different server:
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, clock Accept-Ranges: npt, smpte, clock
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
17.3.4. 303 See Other 17.3.4. 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 in RTSP 1.0 [RFC2326]. allowed in RTSP 1.0 [RFC2326].
17.3.5. 304 Not Modified 17.3.5. 304 Not Modified
If the client has performed a conditional DESCRIBE or SETUP (see If the agent has performed a conditional DESCRIBE or SETUP (see
Section 18.25) and the requested resource has not been modified, the Sections 18.25 and 18.26) and the requested resource has not been
server SHOULD send a 304 response. This response MUST NOT contain a modified, the server SHOULD send a 304 response. This response MUST
message-body. NOT contain a 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 headers would have been sent
in a 200 response to the same request. o MTag or Content-Location, if the headers would have been sent in a
200 response to the same request.
o Expires and Cache-Control if the field-value might differ from o Expires and Cache-Control if the field-value might differ from
that sent in any previous response for the same variant. that sent in any previous response for the same 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 header (Section 18.24) may be used
DESCRIBE and SETUP in this manner. to link the DESCRIBE and SETUP in this manner.
17.3.6. 305 Use Proxy 17.3.6. 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 header that MUST be included. The Location header
The recipient is expected to repeat this single request via the field-value gives the URI of the proxy. The recipient is expected to
proxy. 305 responses MUST only be generated by origin servers. repeat this single request via the proxy. 305 responses MUST only be
generated by origin servers.
17.4. Client Error 4xx 17.4. Client Error 4xx
17.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 agent due to malformed
syntax. The client SHOULD NOT repeat the request without syntax. The agent 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 agent
server MUST NOT include a CSeq in the response. MUST NOT include a CSeq in the response.
17.4.2. 401 Unauthorized 17.4.2. 401 Unauthorized
The request requires user authentication. The response MUST include The request requires user authentication using the HTTP
a WWW-Authenticate header (Section 18.58) field containing a authentication mechanism [RFC7235]. The usage of the error code is
challenge applicable to the requested resource. The client MAY defined in [RFC7235] and any applicable HTTP authetnication scheme,
repeat the request with a suitable Authorization header field. If such as Digest [RFC7616]. The response is to include a WWW-
the request already included authorization credentials, then the 401 Authenticate header (Section 18.58) field containing a challenge
response indicates that authorization has been refused for those applicable to the requested resource. The agent can repeat the
credentials. If the 401 response contains the same challenge as the request with a suitable Authorization header field. If the request
prior response, and the user agent has already attempted already included authorization credentials, then the 401 response
authentication at least once, then the user SHOULD be presented the indicates that authorization has been refused for those credentials.
message body that was given in the response, since that message body If the 401 response contains the same challenge as the prior
might include relevant diagnostic information. HTTP access response, and the user agent has already attempted authentication at
authentication is explained in [RFC2617]. least once, then the user SHOULD be presented the message body that
was given in the response, since that message body might include
relevant diagnostic information.
17.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.
17.4.4. 403 Forbidden 17.4.4. 403 Forbidden
The server understood the request, but is refusing to fulfill it. The agent 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 agent 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 agent does not wish to make this information
available to the client, the status code 404 (Not Found) can be used available to the agent, the status code 404 (Not Found) can be used
instead. instead.
17.4.5. 404 Not Found 17.4.5. 404 Not Found
The server has not found anything matching the Request-URI. No The agent 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 agent
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 agent 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.
17.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.
17.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 that have content characteristics not response message bodies that 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.
17.4.8. 407 Proxy Authentication Required 17.4.8. 407 Proxy Authentication Required
This code is similar to 401 (Unauthorized) (Section 17.4.2), but it This code is similar to 401 (Unauthorized) (Section 17.4.2), but it
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 usage of this error code is defined in [RFC7235] and any
(Section 18.34) containing a challenge applicable to the proxy for applicable HTTP authentication scheme, suc as Digest [RFC7616]. The
the requested resource. proxy MUST return a Proxy-Authenticate header field (Section 18.34)
containing a challenge applicable to the proxy for the requested
resource.
17.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 agent did not produce a request within the time that the agent
was prepared to wait. The client MAY repeat the request without was prepared to wait. The agent MAY repeat the request without
modifications at any later time. modifications at any later time.
17.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.
skipping to change at page 115, line 45 skipping to change at page 116, line 8
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.
17.4.11. 412 Precondition Failed 17.4.11. 412 Precondition Failed
The precondition given in one or more of the 'if-' request-header The precondition given in one or more of the 'if-' request-header
fields evaluated to false when it was tested on the server. See fields evaluated to false when it was tested on the agent. See these
these sections for the 'if-' headers: If-Match Section 18.24, If- sections for the 'if-' headers: If-Match Section 18.24, If-Modified-
Modified-Since Section 18.25, and If-None-Match Section 18.26. This Since Section 18.25, and If-None-Match Section 18.26. This response
response code allows the client to place preconditions on the current code allows the agent to place preconditions on the current resource
resource meta-information (header-field data) and, thus, prevent the meta-information (header field data) and, thus, prevent the requested
requested method from being applied to a resource other than the one method from being applied to a resource other than the one intended.
intended.
17.4.12. 413 Request Message Body Too Large 17.4.12. 413 Request Message Body Too Large
The server is refusing to process a request because the request The agent 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 agent is willing or able to process.
The server MAY close the connection to prevent the client from The agent MAY close the connection to prevent the requesting agent
continuing the request. from continuing the request.
If the condition is temporary, the server SHOULD include a Retry- If the condition is temporary, the agent SHOULD include a Retry-After
After header field to indicate that it is temporary and after what header field to indicate that it is temporary and after what time the
time the client MAY try again. requesting agent MAY try again.
17.4.13. 414 Request-URI Too Long 17.4.13. 414 Request-URI Too Long
The server is refusing to service the request because the Request-URI The responding agent is refusing to service the request because the
is longer than the server is willing to interpret. This rare Request-URI is longer than the agent is willing to interpret. This
condition is only likely to occur when a client has used a request rare condition is only likely to occur when an agent has used a
with long query information, when the client has descended into a URI request with long query information, when the agent has descended
"black hole" of redirection (e.g., a redirected URI prefix that into a URI "black hole" of redirection (e.g., a redirected URI prefix
points to a suffix of itself), or when the server is under attack by that points to a suffix of itself), or when the agent is under attack
a client attempting to exploit security holes present in some servers by a agent attempting to exploit security holes present in some
using fixed-length buffers for reading or manipulating the Request- agents using fixed-length buffers for reading or manipulating the
URI. Request-URI.
17.4.14. 415 Unsupported Media Type 17.4.14. 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.
17.4.15. 451 Parameter Not Understood 17.4.15. 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 agent SHOULD return a message body containing the offending
parameter(s). parameter(s).
17.4.16. 452 Illegal Conference Identifier 17.4.16. 452 Illegal Conference Identifier
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 in RTSP 1.0 [RFC2326]. allowed in RTSP 1.0 [RFC2326].
17.4.17. 453 Not Enough Bandwidth 17.4.17. 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.
17.4.18. 454 Session Not Found 17.4.18. 454 Session Not Found
The RTSP session identifier in the Session header is missing, is The RTSP session identifier in the Session header is missing, is
invalid, or has timed out. invalid, or has timed out.
17.4.19. 455 Method Not Valid in This State 17.4.19. 455 Method Not Valid in This State
The client or server cannot process this request in its current The agent cannot process this request in its current state. The
state. The response MUST contain an Allow header to make error response MUST contain an Allow header to make error recovery
recovery possible. possible.
17.4.20. 456 Header Field Not Valid for Resource 17.4.20. 456 Header Field Not Valid for Resource
The server could not act on a required request-header. For example, The targeted agent could not act on a required request-header. For
if PLAY contains the Range header field but the stream does not allow example, if PLAY request contains the Range header field but the
seeking. This error message may also be used for specifying when the stream does not allow seeking. This error message may also be used
time format in Range is impossible for the resource. In that case, for specifying when the time format in Range is impossible for the
the Accept-Ranges header MUST be returned to inform the client of resource. In that case, the Accept-Ranges header MUST be returned to
which formats are allowed. inform the agent of which formats are allowed.
17.4.21. 457 Invalid Range 17.4.21. 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.
17.4.22. 458 Parameter Is Read-Only 17.4.22. 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 modified. When returning this error message, the sender SHOULD
skipping to change at page 118, line 8 skipping to change at page 118, line 19
applied on the aggregate-control URI. applied on the aggregate-control URI.
17.4.25. 461 Unsupported Transport 17.4.25. 461 Unsupported Transport
The Transport field did not contain a supported transport The Transport field did not contain a supported transport
specification. specification.
17.4.26. 462 Destination Unreachable 17.4.26. 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 agent 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 agent attempt to place an invalid dest_addr parameter
parameter in the Transport field. in the Transport field.
17.4.27. 463 Destination Prohibited 17.4.27. 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 agent address. This error is most likely
the result of a client attempt to redirect media traffic to another the result of a agent 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.
17.4.28. 464 Data Transport Not Ready Yet 17.4.28. 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).
skipping to change at page 119, line 15 skipping to change at page 119, line 28
17.4.32. 471 Connection Credentials Not Accepted 17.4.32. 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.
17.4.33. 472 Failure to Establish Secure Connection 17.4.33. 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 the server not accepting any cipher handshake, for example, due to the agent not accepting any cipher
suites. suites.
17.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.
17.5.1. 500 Internal Server Error 17.5.1. 500 Internal Server Error
The server encountered an unexpected condition that prevented it from The agent encountered an unexpected condition that prevented it from
fulfilling the request. fulfilling the request.
17.5.2. 501 Not Implemented 17.5.2. 501 Not Implemented
The server does not support the functionality required to fulfill the The agent 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 agent 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.
17.5.3. 502 Bad Gateway 17.5.3. 502 Bad Gateway
The server, while acting as a gateway or proxy, received an invalid The agent, while acting as a gateway or proxy, received an invalid
response from the upstream server it accessed in attempting to response from the upstream agent it accessed in attempting to fulfill
fulfill the request. the request.
17.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 that will be alleviated after is that this is a temporary condition that 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 agent 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 agent 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 transport connection.
The response scope is dependent on the Request. If the request was The response scope is dependent on the request. If the request was
in relation to an existing RTSP session, the scope of the overload in relation to an existing RTSP session, the scope of the overload
response is to this individual RTSP session. If the request was not response is to this individual RTSP session. If the request was not
session specific or intended to form an RTSP session, it applies to session specific or intended to form an RTSP session, it applies to
the RTSP server identified by the hostname in the Request-URI. the RTSP server identified by the hostname in the Request-URI.
17.5.5. 504 Gateway Timeout 17.5.5. 504 Gateway Timeout
The server, while acting as a proxy, did not receive a timely The agent, while acting as a proxy, did not receive a timely response
response from the upstream server specified by the URI or some other from the upstream agent specified by the URI or some other auxiliary
auxiliary server (e.g., DNS) that it needed to access in attempting server (e.g., DNS) that it needed to access in attempting to complete
to complete the request. the request.
17.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 version The agent does not support, or refuses to support, the RTSP version
that was used in the request message. The server is indicating that that was used in the request message. The agent is indicating that
it is unable or unwilling to complete the request using the same it is unable or unwilling to complete the request using the same
major version as the client other than with this error message. The major version as the agent other than with this error message. The
response SHOULD contain a message body describing why that version is response SHOULD contain a message body describing why that version is
not supported and what other protocols are supported by that server. not supported and what other protocols are supported by that agent.
17.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.
17.5.8. 553 Proxy Unavailable 17.5.8. 553 Proxy Unavailable
The proxy is currently unable to handle the request due to a The proxy is currently unable to handle the request due to a
temporary overloading or maintenance of the proxy. The implication temporary overloading or maintenance of the proxy. The implication
is that this is a temporary condition that will be alleviated after is that this is a temporary condition that 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 agent 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 agent 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 553 status code does not imply that Note: The existence of the 553 status code does not imply that
a proxy must use it when becoming overloaded. Some proxies may a proxy must use it when becoming overloaded. Some proxies may
wish to simply refuse the connection. wish to simply refuse the connection.
The response scope is dependent on the Request. If the request was The response scope is dependent on the Request. If the request was
in relation to an existing RTSP session, the scope of the overload in relation to an existing RTSP session, the scope of the overload
response is to this individual RTSP session. If the request was non- response is to this individual RTSP session. If the request was non-
session specific or intended to form an RTSP session, it applies to session specific or intended to form an RTSP session, it applies to
skipping to change at page 121, line 42 skipping to change at page 122, line 33
| SET_PARAMETER | C -> S, S -> C | P,S | SPR | R,r | | SET_PARAMETER | C -> S, S -> C | P,S | SPR | R,r |
| | | | | | | | | | | |
| TEARDOWN | C -> S | P,S | TRD | | | TEARDOWN | C -> S | P,S | TRD | |
| | | | | | | | | | | |
| | S -> C | P | TRD | | | | S -> C | P | TRD | |
+---------------+----------------+--------+---------+------+ +---------------+----------------+--------+---------+------+
This table is an overview of RTSP methods, their direction, and what This table is an overview of RTSP methods, their direction, and what
objects (P: presentation, S: stream) they operate on. "Body" denotes objects (P: presentation, S: stream) they operate on. "Body" denotes
if a method is allowed to carry body and in which direction; R = if a method is allowed to carry body and in which direction; R =
Request, r=response. Note: All error messages for statuses 4xx and request, r=response. Note: All error messages for statuses 4xx and
5xx are allowed to carry a body. 5xx are allowed to carry a body.
Table 8: Overview of RTSP Methods Table 8: Overview of RTSP Methods
The general syntax for header fields is covered in Section 5.2. This The general syntax for header fields is covered in Section 5.2. This
section lists the full set of header fields along with notes on section lists the full set of header fields along with notes on
meaning and usage. The syntax definitions for header fields are meaning and usage. The syntax definitions for header fields are
present in Section 20.2.3. Examples of each header field are given. present in Section 20.2.3. Examples of each header field are given.
Information about header fields in relation to methods and proxy Information about header fields in relation to methods and proxy
skipping to change at page 122, line 39 skipping to change at page 123, line 28
The "proxy" column describes the operations a proxy may perform on a The "proxy" column describes the operations a proxy may perform on a
header field. An empty proxy column indicates that the proxy MUST header field. An empty proxy column indicates that the proxy MUST
NOT make any changes to that header, all allowed operations are NOT make any changes to that header, all allowed operations are
explicitly stated: explicitly stated:
a: A proxy can add or concatenate the header field if not present. a: A proxy can add or concatenate the header field if not present.
m: A proxy can modify an existing header field value. m: A proxy can modify an existing header field value.
d: A proxy can delete a header field value. d: A proxy can delete a header field-value.
r: A proxy needs to be able to read the header field; thus, this r: A proxy needs to be able to read the header field; thus, this
header field cannot be encrypted. header field cannot be encrypted.
The rest of the columns relate to the presence of a header field in a The rest of the columns relate to the presence of a header field in a
method. The method names when abbreviated, are according to Table 8: method. The method names when abbreviated, are according to Table 8:
c: Conditional; requirements on the header field depend on the c: Conditional; requirements on the header field depend on the
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 agents need to be prepared
prepared to receive messages without that header field. 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 Sections 18.17, 18.19 and 5.3 for details. empty. See Sections 18.17, 18.19 and 5.3 for 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 an agent MAY include the header field in a
a request or response. The Client/Server behavior when receiving request or response. The agent behavior when receiving such headers
such headers varies; for some, it may ignore the header field. In varies; for some, it may ignore the header field. In other cases, it
other cases, it is a request to process the header. This is is a request to process the header. This is regulated by the method
regulated by the method and header descriptions. Examples of headers and header descriptions. Examples of headers that require processing
that require processing are the Require and Proxy-Require header are the Require and Proxy-Require header fields discussed in Sections
fields discussed in Sections 18.43 and 18.37. A "mandatory" header 18.43 and 18.37. A "mandatory" header field MUST be present in a
field MUST be present in a request, and it MUST be understood by the request, and it MUST be understood by the agent receiving the
Client/Server receiving the request. A mandatory response-header request. A mandatory response-header field MUST be present in the
field MUST be present in the response, and the header field MUST be response, and the header field MUST be understood by the processing
understood by the Client/Server processing the response. "Not the response. "Not applicable" means that the header field MUST NOT
applicable" means that the header field MUST NOT be present in a be present in a request. If one is placed in a request by mistake,
request. If one is placed in a request by mistake, it MUST be it MUST be ignored by the agent 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 agent MUST NOT place the header field in the response, and the agent
the Client/Server MUST ignore the header field in the response. MUST ignore the header field in the response.
An RTSP agent MUST ignore extension headers that are not understood. An RTSP agent MUST ignore extension headers that are not understood.
The From and Location header fields contain a URI. If the URI The From and Location header fields contain a URI. If the URI
contains a comma (') or semicolon (;), the URI MUST be enclosed in contains a comma (') or semicolon (;), the URI MUST be enclosed in
double quotes ("). Any URI parameters are contained within these double quotes ("). Any URI parameters are contained within these
quotes. If the URI is not enclosed in double quotes, any semicolon- quotes. If the URI is not enclosed in double quotes, any semicolon-
delimited parameters are header-parameters, not URI parameters. delimited parameters are header-parameters, not URI parameters.
+-------------------+------+------+----+----+-----+-----+-----+-----+ +-------------------+------+------+----+----+-----+-----+-----+-----+
skipping to change at page 124, line 16 skipping to change at page 125, line 5
| | | | | | | | | | | | | | | | | | | |
| Accept-Ranges | 456 | r | - | - | - | m | - | - | | Accept-Ranges | 456 | r | - | - | - | m | - | - |
| | | | | | | | | | | | | | | | | | | |
| Allow | r | am | c | c | c | - | - | - | | Allow | r | am | c | c | c | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Allow | 405 | am | m | m | m | m | m | m | | Allow | 405 | am | m | m | m | m | m | m |
| | | | | | | | | | | | | | | | | | | |
| Authentication- | r | | o | o | o | o | o | o/- | | Authentication- | r | | o | o | o | o | o | o/- |
| Info | | | | | | | | | | Info | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Authorization | R | | o | o | o | o | o | o | | Authorization | R | | o | o | o | o | o | o/- |
| | | | | | | | | | | | | | | | | | | |
| Bandwidth | R | | o | o | o | o | - | - | | Bandwidth | R | | o | o | o | o | - | - |
| | | | | | | | | | | | | | | | | | | |
| Blocksize | R | | o | - | o | o | - | - | | Blocksize | R | | o | - | o | o | - | - |
| | | | | | | | | | | | | | | | | | | |
| Cache-Control | G | r | o | - | o | - | - | - | | Cache-Control | G | r | o | - | o | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Connection | G | ad | o | o | o | o | o | o | | Connection | G | ad | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Connection- | 470, | ar | o | o | o | o | o | o | | Connection- | 470, | ar | o | o | o | o | o | o |
skipping to change at page 125, line 32 skipping to change at page 126, line 21
| 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-Since | R | r | o | - | o | - | - | - | | If-Modified-Since | R | r | o | - | o | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| If-None-Match | R | r | o | - | o | - | - | - | | If-None-Match | R | r | o | - | o | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Last-Modified | r | r | o | - | o | - | - | - | | Last-Modified | r | r | o | - | o | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Location | 3rr | | o | o | o | o | o | o | | Location | 3rr | | m | m | m | m | m | m |
+-------------------+------+------+----+----+-----+-----+-----+-----+ +-------------------+------+------+----+----+-----+-----+-----+-----+
Table 9: Overview of RTSP Header Fields (A-L) Related to Methods Table 9: Overview of RTSP Header Fields (A-L) Related to Methods
DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN
+------------------+---------+-----+----+----+----+-----+-----+-----+ +------------------+---------+-----+----+----+----+-----+-----+-----+
| Header | Where | Pro | DE | OP | ST | PLY | PSE | TRD | | Header | Where | Pro | DE | OP | ST | PLY | PSE | TRD |
| | | xy | S | T | P | | | | | | | xy | S | T | P | | | |
+------------------+---------+-----+----+----+----+-----+-----+-----+ +------------------+---------+-----+----+----+----+-----+-----+-----+
| Media- | G | | - | - | m | m | m | - | | Media- | r | | - | - | m | o | o | - |
| Properties | | | | | | | | | | Properties | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Media-Range | G | | - | - | m | m | m | - | | Media-Range | r | | - | - | c | c | c | - |
| | | | | | | | | | | | | | | | | | | |
| MTag | r | r | o | - | o | - | - | - | | MTag | r | r | o | - | o | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Pipelined- | G | amd | - | o | o | o | o | o | | Pipelined- | G | amd | - | o | o | o | o | o |
| Requests | | r | | | | | | | | Requests | | r | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Proxy- | 407 | amr | m | m | m | m | m | m | | Proxy- | 407 | amr | m | m | m | m | m | m |
| Authenticate | | | | | | | | | | Authenticate | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Proxy- | r | amd | o | o | o | o | o | o/- | | Proxy- | r | amd | o | o | o | o | o | o/- |
skipping to change at page 126, line 45 skipping to change at page 127, line 34
| | | | | | | | | | | | | | | | | | | |
| Retry-After | 3rr,503 | | o | o | o | o | o | - | | Retry-After | 3rr,503 | | o | o | o | o | o | - |
| | ,553 | | | | | | | | | | ,553 | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Retry-After | 413 | | o | - | - | - | - | - | | Retry-After | 413 | | o | - | - | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| RTP-Info | r | | - | - | c | c | - | - | | RTP-Info | r | | - | - | c | c | - | - |
| | | | | | | | | | | | | | | | | | | |
| Scale | R | r | - | - | - | o | - | - | | Scale | R | r | - | - | - | o | - | - |
| | | | | | | | | | | | | | | | | | | |
| Scale | r | amr | - | - | - | c | - | - | | Scale | r | amr | - | - | c | c | c | - |
| | | | | | | | | | | | | | | | | | | |
| Seek-Style | R | | - | - | - | o | - | - | | Seek-Style | R | | - | - | - | o | - | - |
| | | | | | | | | | | | | | | | | | | |
| Seek-Style | r | | - | - | - | m | - | - | | Seek-Style | r | | - | - | - | m | - | - |
| | | | | | | | | | | | | | | | | | | |
| Server | R | r | - | o | - | - | - | o | | Server | R | r | - | o | - | - | - | o |
| | | | | | | | | | | | | | | | | | | |
| Server | r | r | o | o | o | o | o | o | | Server | r | r | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Session | R | r | - | o | o | m | m | m | | Session | R | r | - | o | o | m | m | m |
| | | | | | | | | | | | | | | | | | | |
| Session | r | r | - | c | m | m | m | o | | Session | r | r | - | c | m | m | m | o |
| | | | | | | | | | | | | | | | | | | |
| Speed | R | adm | - | - | - | o | - | - | | Speed | R | adm | - | - | - | o | - | - |
| | | r | | | | | | | | | | r | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Speed | r | adm | - | - | - | c | - | - | | Speed | r | adm | - | - | - | c | - | - |
| | | r | | | | | | | | | | r | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Supported | R | amr | o | o | o | o | o | o | | Supported | R | r | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Supported | r | amr | c | c | c | c | c | c | | Supported | r | r | c | c | c | c | c | c |
| | | | | | | | | | | | | | | | | | | |
| Terminate-Reason | R | r | - | - | - | - | - | - | | Terminate-Reason | R | r | - | - | - | - | - | -/o |
| | | | | | | | | | | | | | | | | | | |
| Timestamp | R | adm | o | o | o | o | o | o | | Timestamp | R | adm | o | o | o | o | o | o |
| | | r | | | | | | | | | | r | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Timestamp | c | adm | m | m | m | m | m | m | | Timestamp | c | adm | m | m | m | m | m | m |
| | | r | | | | | | | | | | r | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Transport | G | mr | - | - | m | - | - | - | | Transport | G | 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* |
| | | | | | | | | | | | | | | | | | | |
| Via | R | amr | o | o | o | o | o | o | | Via | R | amr | c | c | c | c | c | c |
| | | | | | | | | | | | | | | | | | | |
| Via | c | dr | m | m | m | m | m | m | | Via | r | amr | c | c | c | c | c | c |
| | | | | | | | | | | | | | | | | | | |
| 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-Credentials | R | rm | o | o | o | - | | Accept-Credentials | R | rm | o | o | o | - |
| | | | | | | | | | | | | | | |
| Accept-Encoding | R | r | o | o | o | - | | Accept-Encoding | R | r | o | o | o | - |
| | | | | | | | | | | | | | | |
| Accept-Language | R | r | o | o | o | - | | Accept-Language | R | r | o | o | o | - |
| | | | | | | | | | | | | | | |
| Accept-Ranges | G | rm | o | - | - | - | | Accept-Ranges | G | rm | o | - | - | - |
| | | | | | | | | | | | | | | |
| Allow | 405 | amr | m | m | m | - | | Allow | 405 | amr | m | m | m | m |
| | | | | | | | | | | | | | | |
| Authentication-Info | r | | o/- | o/- | - | - | | Authentication-Info | r | | o/- | o/- | - | - |
| | | | | | | | | | | | | | | |
| Authorization | R | | o | o | o | - | | Authorization | R | | o | o | o | - |
| | | | | | | | | | | | | | | |
| Bandwidth | R | | - | o | - | - | | Bandwidth | R | | - | o | - | - |
| | | | | | | | | | | | | | | |
| Blocksize | R | | - | o | - | - | | Blocksize | R | | - | o | - | - |
| | | | | | | | | | | | | | | |
| Cache-Control | G | r | o | o | - | - | | Cache-Control | G | r | o | o | - | - |
| | | | | | | | | | | | | | | |
| Connection | G | | o | o | o | o | | Connection | G | | o | o | o | o |
| | | | | | | | | | | | | | | |
| Connection-Credentials | 470, | ar | o | o | o | - | | Connection-Credentials | 470, | ar | o | o | o | - |
| | 407 | | | | | | | | 407 | | | | | |
| | | | | | | | | | | | | | | |
| Content-Base | R | | o | o | - | - | | Content-Base | R | | o | o | - | o |
| | | | | | | | | | | | | | | |
| Content-Base | r | | o | o | - | - | | Content-Base | r | | o | o | - | - |
| | | | | | | | | | | | | | | |
| Content-Base | 4xx, | | o | o | o | o | | Content-Base | 4xx, | | o | o | o | o |
| | 5xx | | | | | | | | 5xx | | | | | |
| | | | | | | | | | | | | | | |
| Content-Encoding | R | r | o | o | - | - | | Content-Encoding | R | r | o | o | - | o |
| | | | | | | | | | | | | | | |
| Content-Encoding | r | r | o | o | - | - | | Content-Encoding | r | r | o | o | - | - |
| | | | | | | | | | | | | | | |
| Content-Encoding | 4xx, | r | o | o | o | o | | Content-Encoding | 4xx, | r | o | o | o | o |
| | 5xx | | | | | | | | 5xx | | | | | |
| | | | | | | | | | | | | | | |
| Content-Language | R | r | o | o | - | - | | Content-Language | R | r | o | o | - | o |
| | | | | | | | | | | | | | | |
| Content-Language | r | r | o | o | - | - | | Content-Language | r | r | o | o | - | - |
| | | | | | | | | | | | | | | |
| Content-Language | 4xx, | r | o | o | o | o | | Content-Language | 4xx, | r | o | o | o | o |
| | 5xx | | | | | | | | 5xx | | | | | |
| | | | | | | | | | | | | | | |
| Content-Length | R | r | * | * | - | - | | Content-Length | R | r | * | * | - | * |
| | | | | | | | | | | | | | | |
| Content-Length | r | r | * | * | - | - | | Content-Length | r | r | * | * | - | - |
| | | | | | | | | | | | | | | |
| Content-Length | 4xx, | r | * | * | * | * | | Content-Length | 4xx, | r | * | * | * | * |
| | 5xx | | | | | | | | 5xx | | | | | |
| | | | | | | | | | | | | | | |
| Content-Location | R | | o | o | - | - | | Content-Location | R | | o | o | - | o |
| | | | | | | | | | | | | | | |
| Content-Location | r | | o | o | - | - | | Content-Location | r | | o | o | - | - |
| | | | | | | | | | | | | | | |
| Content-Location | 4xx, | | o | o | o | o | | Content-Location | 4xx, | | o | o | o | o |
| | 5xx | | | | | | | | 5xx | | | | | |
| | | | | | | | | | | | | | | |
| Content-Type | R | | * | * | - | - | | Content-Type | R | | * | * | - | * |
| | | | | | | | | | | | | | | |
| Content-Type | r | | * | * | - | - | | Content-Type | r | | * | * | - | - |
| | | | | | | | | | | | | | | |
| Content-Type | 4xx, | | * | * | * | * | | Content-Type | 4xx, | | * | * | * | * |
| | 5xx | | | | | | | | 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 | r | r | - | - | - | - | | Expires | r | r | - | - | - | - |
| | | | | | | | | | | | | | | |
| From | R | r | o | o | o | - | | From | R | r | o | o | o | - |
| | | | | | | | | | | | | | | |
| If-Match | R | r | - | - | - | - | | 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 | | m | m | m | - |
| | | | | | | | | | | | | | | |
| 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 | - | - | - |
skipping to change at page 130, line 30 skipping to change at page 131, line 17
| Proxy-Supported | R | amr | c | c | c | - | | Proxy-Supported | R | amr | c | c | c | - |
| | | | | | | | | | | | | | | |
| Proxy-Supported | r | | c | c | c | - | | Proxy-Supported | r | | c | c | c | - |
| | | | | | | | | | | | | | | |
| Public | 501 | admr | m | m | m | - | | Public | 501 | admr | m | m | m | - |
+---------------------------+-------+-------+-----+-----+-----+-----+ +---------------------------+-------+-------+-----+-----+-----+-----+
Table 11: Overview of RTSP Header Fields (A-P) Related to Methods Table 11: Overview of RTSP Header Fields (A-P) Related to Methods
GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY
+------------------+---------+-------+-----+-----+-----+-----+ +------------------+-------------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY | | Header | Where | Proxy | GPR | SPR | RDR | PNY |
+------------------+---------+-------+-----+-----+-----+-----+ +------------------+-------------+-------+-----+-----+-----+-----+
| Range | R | | o | - | o | m | | Range | R | | o | - | - | m |
| | | | | | | | | | | | | | | |
| Referrer | R | | o | o | o | - | | Range | r | | c | - | - | - |
| | | | | | | | | | | | | | | |
| Request-Status | R | | - | - | - | c | | Referrer | R | | o | o | o | - |
| | | | | | | | | | | | | | | |
| Require | R | r | o | o | o | - | | Request-Status | R | mr | - | - | - | c |
| | | | | | | | | | | | | | | |
| Retry-After | 3rr,503 | | o | o | - | - | | Require | R | r | o | o | o | o |
| | | | | | | | | | | | | | | |
| Retry-After | 413 | | o | o | - | - | | Retry-After | 3rr,503,553 | | o | o | - | - |
| | | | | | | | | | | | | | | |
| RTP-Info | R | r | o | - | - | C | | Retry-After | 413 | | o | o | - | - |
| | | | | | | | | | | | | | | |
| RTP-Info | r | r | c | - | - | - | | RTP-Info | R | r | o | - | - | C |
| | | | | | | | | | | | | | | |
| Scale | G | | - | - | - | c | | RTP-Info | r | r | c | - | - | - |
| | | | | | | | | | | | | | | |
| Seek-Style | G | | - | - | - | - | | Scale | G | | c | - | c | c |
| | | | | | | | | | | | | | | |
| Server | R | r | o | o | o | o | | Seek-Style | G | | - | - | - | - |
| | | | | | | | | | | | | | | |
| Server | r | r | o | o | - | - | | Server | R | r | o | o | o | o |
| | | | | | | | | | | | | | | |
| Session | R | r | o | o | o | m | | Server | r | r | o | o | - | - |
| | | | | | | | | | | | | | | |
| Session | r | r | c | c | o | m | | Session | R | r | o | o | o | m |
| | | | | | | | | | | | | | | |
| Speed | G | | - | - | - | - | | Session | r | r | c | c | o | m |
| | | | | | | | | | | | | | | |
| Supported | R | adrm | o | o | o | - | | Speed | G | | - | - | - | - |
| | | | | | | | | | | | | | | |
| Supported | r | adrm | c | c | c | - | | Supported | R | r | o | o | o | - |
| | | | | | | | | | | | | | | |
| Terminate-Reason | R | r | - | - | m | - | | Supported | r | r | c | c | c | - |
| | | | | | | | | | | | | | | |
| Timestamp | R | adrm | o | o | o | - | | Terminate-Reason | R | r | - | - | m | - |
| | | | | | | | | | | | | | | |
| Timestamp | c | adrm | m | m | m | - | | Timestamp | R | adrm | o | o | o | o |
| | | | | | | | | | | | | | | |
| Transport | G | mr | - | - | - | - | | Timestamp | c | adrm | m | m | m | m |
| | | | | | | | | | | | | | | |
| Unsupported | r | arm | c | c | c | - | | Transport | G | mr | - | - | - | - |
| | | | | | | | | | | | | | | |
| User-Agent | R | r | m* | m* | - | - | | Unsupported | r | arm | c | c | c | c |
| | | | | | | | | | | | | | | |
| User-Agent | r | r | m* | m* | m* | m* | | User-Agent | R | r | m* | m* | - | - |
| | | | | | | | | | | | | | | |
| Via | R | amr | o | o | o | - | | User-Agent | r | r | m* | m* | m* | m* |
| | | | | | | | | | | | | | | |
| Via | c | dr | m | m | m | - | | Via | R | amr | c | c | c | c |
| | | | | | | | | | | | | | | |
| WWW-Authenticate | 401 | | m | m | m | - | | Via | r | amr | c | c | c | c |
+------------------+---------+-------+-----+-----+-----+-----+ | | | | | | | |
| 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
18.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 [RFC6838] that are presentation description and parameter media types [RFC6838] that are
acceptable for the response to DESCRIBE and GET_PARAMETER requests. acceptable for the response to the DESCRIBE request.
See Section 20.2.3 for the syntax. See Section 20.2.3 for the syntax.
The asterisk "*" character is used to group media types into ranges, The asterisk "*" character is used to group media types into ranges,
with "*/*" indicating all media types and "type/*" indicating all with "*/*" indicating all media types and "type/*" indicating all
subtypes of that type. The media-range MAY include media type subtypes of that type. The range MAY include media type parameters
parameters that are applicable to that range. that are generally applicable to that range.
Each media-range MAY be followed by one or more accept-params, Each media type or range MAY be followed by one or more accept-
beginning with the "q" parameter to indicate a relative quality params, beginning with the "q" parameter to indicate a relative
factor. The first "q" parameter (if any) separates the media-range quality factor. The first "q" parameter (if any) separates the media
parameter(s) from the accept-params. Quality factors allow the user type or range's parameters from the accept-params. Quality factors
or user agent to indicate the relative degree of preference for that allow the user or user agent to indicate the relative degree of
media-range, using the qvalue scale from 0 to 1 (Section 5.3.1 of preference for that media type, using the qvalue scale from 0 to 1
[RFC7231]). The default value is q=1. (Section 5.3.1 of [RFC7231]). The default value is q=1.
Example of use: Example of use:
Accept: application/example ;q=0.7, application/sdp Accept: application/example ;q=0.7, application/sdp
Indicates that the requesting agent prefers the media type Indicates that the requesting agent prefers the media type
application/sdp through the default 1.0 rating but also accepts the application/sdp through the default 1.0 rating but also accepts the
application/example media type with a 0.7 quality rating. application/example media type with a 0.7 quality rating.
If no Accept header field is present, then it is assumed that the If no Accept header field is present, then it is assumed that the
client accepts all media types. If an Accept header field is client accepts all media types. If an Accept header field is
present, and if the server cannot send a response that is acceptable present, and if the server cannot send a response that is acceptable
according to the combined Accept field value, then the server SHOULD according to the combined Accept field-value, then the server SHOULD
send a 406 (Not Acceptable) response. send a 406 (Not Acceptable) response.
18.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. It MUST NOT be included in server-to-client proxies or servers. It MUST NOT be included in server-to-client
requests. See Section 19 for the usage of this header requests. See Section 19 for the usage of this header
In a request, the header MUST contain the method (User, Proxy, or In a request, the header MUST contain the method (User, Proxy, or
Any) for approving credentials selected by the requester. The method Any) for approving credentials selected by the requester. The method
MUST NOT be changed by any proxy, unless it is "Proxy" when a proxy MUST 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 MAY change it to "user" to take the role of user approving each
further hop. If the method is "User", the header contains zero or further hop. If the method is "User", the header contains zero or
more of the credentials that the client accepts. The header may more of the credentials that the client accepts. The header may
contain zero credentials in the first RTSP request to an RTSP server contain zero credentials in the first RTSP request to an RTSP server
when using the "User" method. This is because the client has not yet via a proxy when using the "User" method. This is because the client
received any credentials to accept. Each credential MUST consist of has not yet received any credentials to accept. Each credential MUST
one URI identifying the proxy or server, the hash algorithm consist of one URI identifying the proxy or server, the hash
identifier, and the hash over that agent's ASN.1 DER-encoded algorithm identifier, and the hash over that agent's ASN.1 DER-
certificate [RFC5280] in Base64, according to Section 4 of [RFC4648] encoded certificate [RFC5280] in Base64, according to Section 4 of
and where the padding bits are set to zero. All RTSP clients and [RFC4648] and where the padding bits are set to zero. All RTSP
proxies MUST implement the SHA-256 [FIPS180-4] algorithm for clients and proxies MUST implement the SHA-256 [FIPS180-4] algorithm
computation of the hash of the DER-encoded certificate. The SHA-256 for computation of the hash of the DER-encoded certificate. The
algorithm is identified by the token "sha-256". SHA-256 algorithm is identified by the token "sha-256".
The intention of allowing for other hash algorithms is to enable the The intention of allowing for other hash algorithms is to enable the
future retirement of algorithms that are not implemented somewhere future retirement of algorithms that are not implemented somewhere
other than here. Thus, the definition of future algorithms for this other than here. Thus, the definition of future algorithms for this
purpose is intended to be extremely limited. A feature tag can be purpose is intended to be extremely limited. A feature tag can be
used to ensure that support for the replacement algorithm exists. used to ensure that support for the replacement algorithm exists.
Example: Example:
Accept-Credentials:User Accept-Credentials:User
skipping to change at page 134, line 17 skipping to change at page 135, line 10
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.
18.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 (response message body) and any reason
media content. phrases, but not the 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.
The syntax and registry of RTSP 2.0 language tags are the same as The syntax and registry of RTSP 2.0 language tags are the same as
those defined by [RFC5646]. those defined by [RFC5646].
Each language-range MAY be given an associated quality value that Each language-range MAY be given an associated quality value that
represents an estimate of the user's preference for the languages represents an estimate of the user's preference for the languages
specified by that range. The quality value defaults to "q=1". For specified by that range. The quality value defaults to "q=1". For
skipping to change at page 135, line 18 skipping to change at page 136, line 11
are equally acceptable. If an Accept-Language header is present, are equally acceptable. If an Accept-Language header is present,
then all languages that are assigned a qualification factor greater then all languages that are assigned a qualification factor greater
than 0 are acceptable. than 0 are acceptable.
18.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 are acceptable header in SETUP requests to indicate which formats are acceptable
when received in PLAY and PAUSE responses and REDIRECT requests. The when received in PLAY and PAUSE responses and REDIRECT requests. The
server MUST include the header in SETUP and 456 (Header Field Not server MUST include the header in SETUP responses and 456 (Header
Valid for Resource) error responses to indicate the formats supported Field Not Valid for Resource) error responses to indicate the formats
for the resource indicated by the Request-URI. The header MAY be supported for the resource indicated by the Request-URI. The header
included in GET_PARAMETER request and response pairs. The MAY be included in GET_PARAMETER request and response pairs. The
GET_PARAMETER request MUST contain a Session header to identify the GET_PARAMETER request MUST contain a Session header to identify the
session context the request is related to. The requester and session context the request is related to. The requester and
responder will indicate their capabilities regarding Range formats responder will indicate their capabilities regarding Range formats
respectively. respectively.
Accept-Ranges: npt, smpte, clock Accept-Ranges: npt, smpte, clock
The syntax is defined in Section 20.2.3. The syntax is defined in Section 20.2.3.
18.6. Allow 18.6. Allow
The Allow message-body header field lists the methods supported by The Allow message body header field lists the methods supported by
the resource identified by the Request-URI. The purpose of this the resource identified by the Request-URI. The purpose of this
field is to inform the recipient of the complete set of valid methods field is to inform the recipient of the complete set of valid methods
associated with the resource. An Allow header field MUST be present associated with the resource. An Allow header field MUST be present
in a 405 (Method Not Allowed) response. The Allow header MUST also in a 405 (Method Not Allowed) response. The Allow header MUST also
be present in all OPTIONS responses where the content of the header be present in all OPTIONS responses where the content of the header
will not include exactly the same methods as listed in the Public will not include exactly the same methods as listed in the Public
header. header.
The Allow message-body header MUST also be included in SETUP and The Allow message body header MUST also be included in SETUP and
DESCRIBE responses, if the methods allowed for the resource are DESCRIBE responses, if the methods allowed for the resource are
different from the complete set of methods defined in this memo. different from the complete 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
18.7. Authentication-Info 18.7. Authentication-Info
The Authentication-Info response-header is used by the server to The Authentication-Info response-header is used by the server to
communicate some information regarding the successful authentication communicate some information regarding the successful HTTP
in the response message. This usage of this header is specified in authentication [RFC7235] in the response message. The definition of
[RFC2617] with some RTSP clarification in Section 19.1. This header the header is in [RFC7615], and any applicable HTTP authentication
MUST only be used in response messages related to client to server schemes, such as digest [RFC7616]. This header MUST only be used in
requests. response messages related to client to server requests.
18.8. Authorization 18.8. 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
the authentication mechanism from HTTP [RFC2617], usually (but not the authentication mechanism from HTTP [RFC7235], 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. This header MUST only be used in client- resource being requested. The definition of the header is in
to-server requests. [RFC7235], and any applicable HTTP authentication schemes, such as
digest [RFC7616] and Basic [RFC7617]. This header MUST only be used
in client-to-server requests.
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). Each client-to-server request value or using synchronized clocks). Each client-to-server request
MUST be individually authorized by including the Authorization header MUST be individually authorized by including the Authorization header
with the information. with the information.
When a shared cache (see Section 16) 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 directive, the cache
the cache MAY use that response in replying to a subsequent MAY use that response in replying to a subsequent request. But
request. But (if the specified maximum age has passed) a proxy (if the specified maximum age has passed) a proxy cache MUST
cache MUST first revalidate it with the origin server, using the first revalidate it with the origin server, using the request-
request-headers from the new request to allow the origin server headers from the new request to allow the origin server to
to authenticate the new request. (This is the defined behavior authenticate the new request. (This is the defined behavior for
for max-age.) If the response includes "max-age=0", the proxy max-age.) If the response includes "max-age=0", the proxy MUST
MUST always revalidate it before reusing it. always revalidate it before reusing it.
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 directive, it MAY be
MAY be returned in reply to any subsequent request. returned in reply to any subsequent request.
18.9. Bandwidth 18.9. 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
skipping to change at page 138, line 19 skipping to change at page 139, line 19
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 for HTTP, Control does not govern only the caching of responses for the RTSP
instead it also applies to the media stream identified by the SETUP messages, instead it also applies to the media stream identified by
request. The RTSP requests are generally not cacheable; for further the SETUP request. The RTSP requests are generally not cacheable;
information, see Section 16. Below are the descriptions of the cache for further information, see Section 16. Below are the descriptions
directives that can be included in the Cache-Control header. of the cache directives that can be included in the Cache-Control
header.
no-cache: Indicates that the media stream or RTSP response MUST NOT no-cache: Indicates that the media stream or RTSP response MUST NOT
be cached anywhere. This allows an origin server to prevent be cached anywhere. This allows an origin server to prevent
caching even by caches that have been configured to return caching even by caches that have been configured to return
stale responses to client requests. Note: there is no security stale responses to client requests. Note: there is no security
function preventing the caching of content. function preventing the caching of content.
public: Indicates that the media stream or RTSP response is public: Indicates that the media stream or RTSP response is
cacheable by any cache. cacheable by any cache.
skipping to change at page 139, line 12 skipping to change at page 140, line 12
directive, an intermediate cache or proxy MUST NOT change the directive, an intermediate cache or proxy MUST NOT change the
encoding of the stream or response. Unlike HTTP, RTSP does not encoding of the stream or response. Unlike HTTP, RTSP does not
provide for partial transformation at this point, e.g., provide for partial transformation at this point, e.g.,
allowing translation into a different language. allowing translation into a different language.
only-if-cached: In some cases, such as times of extremely poor only-if-cached: In some cases, such as times of extremely poor
network connectivity, a client may want a cache to return only network connectivity, a client may want a cache to return only
those media streams or RTSP responses that it currently has those media streams or RTSP responses that it currently has
stored and not to receive these from the origin server. To do stored and not to receive these from the origin server. To do
this, the client may include the only-if-cached directive in a this, the client may include the only-if-cached directive in a
request. If it receives this directive, a cache SHOULD either request. If the cache receives this directive, it SHOULD
respond using a cached media stream or response that is either respond using a cached media stream or response that is
consistent with the other constraints of the request or respond consistent with the other constraints of the request or respond
with a 504 (Gateway Timeout) status. However, if a group of with a 504 (Gateway Timeout) status. However, if a group of
caches is being operated as a unified system with good internal caches is being operated as a unified system with good internal
connectivity, such a request MAY be forwarded within that group connectivity, such a request MAY be forwarded within that group
of caches. of caches.
max-stale: Indicates that the client is willing to accept a media max-stale: Indicates that the client is willing to accept a media
stream or RTSP response that has exceeded its expiration time. stream or RTSP response that has exceeded its expiration time.
If max-stale is assigned a value, then the client is willing to If max-stale is assigned a value, then the client is willing to
accept a response that has exceeded its expiration time by no accept a response that has exceeded its expiration time by no
skipping to change at page 140, line 4 skipping to change at page 141, line 4
proxy-revalidate: The proxy-revalidate directive has the same proxy-revalidate: The proxy-revalidate directive has the same
meaning as the must-revalidate directive, except that it does meaning as the must-revalidate directive, except that it does
not apply to non-shared user agent caches. It can be used on a not apply to non-shared user agent caches. It can be used on a
response to an authenticated request to permit the user's cache response to an authenticated request to permit the user's cache
to store and later return the response without needing to to store and later return the response without needing to
revalidate it (since it has already been authenticated once by revalidate it (since it has already been authenticated once by
that user), while still requiring proxies that service many that user), while still requiring proxies that service many
users to revalidate each time (in order to make sure that each users to revalidate each time (in order to make sure that each
user has been authenticated). Note that such authenticated user has been authenticated). Note that such authenticated
responses also need the public cache-control directive in order responses also need the "public" cache directive in order to
to allow them to be cached at all. allow them to be cached at all.
max-age: When an intermediate cache is forced, by means of a max- max-age: When an intermediate cache is forced, by means of a max-
age=0 directive, to revalidate its own cache entry, and the age=0 directive, to revalidate its own cache entry, and the
client has supplied its own validator in the request, the client has supplied its own validator in the request, the
supplied validator might differ from the validator currently supplied validator might differ from the validator currently
stored with the cache entry. In this case, the cache MAY use stored with the cache entry. In this case, the cache MAY use
either validator in making its own request without affecting either validator in making its own request without affecting
semantic transparency. semantic transparency.
However, the choice of validator might affect performance. The However, the choice of validator might affect performance. The
skipping to change at page 142, line 23 skipping to change at page 143, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DER Encoding of Certificate #2 : : DER Encoding of Certificate #2 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DER Encoding of Certificate #3 : : DER Encoding of Certificate #3 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format Example of Connection-Credentials Header Certificate Figure 2: Format Example of Connection-Credentials Header Certificate
18.14. Content-Base 18.14. Content-Base
The Content-Base message-body header field may be used to specify the The Content-Base message body header field may be used to specify the
base URI for resolving relative URIs within the message body. base 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 a message body If no Content-Base field is present, the base URI of a message body
is defined by either its Content-Location (if that Content-Location is defined by either 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
message-body. body.
18.15. Content-Encoding 18.15. Content-Encoding
The Content-Encoding message-body header field is used as a modifier The Content-Encoding message body header field is used as a modifier
of the media-type. When present, its value indicates what additional of the media-type. When present, its value indicates what additional
content-codings have been applied to the message body, and thus what content-codings have been applied to the message body, and thus what
decoding mechanisms must be applied in order to obtain the media-type decoding 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
by the Request-URI. Typically, the message body is stored with this by the Request-URI. Typically, the message body is stored with this
encoding and is only decoded before rendering or analogous usage. encoding and is only decoded before rendering or analogous usage.
However, an RTSP proxy MAY modify the content-coding if the new However, an RTSP proxy MAY modify the content-coding if the new
coding is known to be acceptable to the recipient, unless the "no- coding is known to be acceptable to the recipient, unless the "no-
transform" cache-control directive is present in the message. transform" cache directive is present in the message.
If the content-coding of a message body is not "identity", then the If the content-coding of a message body is not "identity", then the
message MUST include a Content-Encoding message-body header that message MUST include a Content-Encoding message body header that
lists the non-identity content-coding(s) used. lists the non-identity content-coding(s) used.
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.
18.16. Content-Language 18.16. Content-Language
The Content-Language message-body header field describes the natural The Content-Language message body header field describes the natural
language(s) of the intended audience for the enclosed message body. language(s) of the intended audience for the enclosed message body.
Note that this might not be equivalent to all the languages used Note that this might not be equivalent to all the languages used
within the message body. within the message body.
Language tags are mentioned in Section 18.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
skipping to change at page 144, line 10 skipping to change at page 145, line 10
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.
18.17. Content-Length 18.17. Content-Length
The Content-Length message-body header field contains the length of The Content-Length message body header field contains the length of
the message body of the RTSP message (i.e., after the double CRLF the 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) in octets of bits. Unlike HTTP, it MUST
messages that carry a message body beyond the header portion of the be included in all messages that carry a message body beyond the
RTSP message. If it is missing, a default value of zero is assumed. header portion of the RTSP message. If it is missing, a default
Any Content-Length greater than or equal to zero is a valid value. value of zero is assumed. Any Content-Length greater than or equal
to zero is a valid value.
18.18. Content-Location 18.18. Content-Location
The Content-Location message-body header field MAY be used to supply The Content-Location message body header field MAY be used to supply
the resource location for the message body enclosed in the message the resource location for the message body enclosed in the message
when that body is accessible from a location separate from the when that body is accessible from a location separate from the
requested resource's URI. A server SHOULD provide a Content-Location requested resource's URI. A server SHOULD provide a Content-Location
for the variant corresponding to the response message body; for the variant corresponding to the response message body;
especially in the case where a resource has multiple variants especially in the case where a resource has multiple variants
associated with it, and those entities actually have separate associated with it, and those entities actually have separate
locations by which they might be individually accessed, the server locations by which they might be individually accessed, the server
SHOULD provide a Content-Location for the particular variant that is SHOULD provide a Content-Location for the particular variant that is
returned. returned.
skipping to change at page 145, line 19 skipping to change at page 146, line 20
Note that Content-Location can be used in some cases to derive the Note that Content-Location can be used in some cases to derive the
base-URI for relative URI(s) present in session description formats. base-URI for relative URI(s) present in session description formats.
This needs to be taken into account when Content-Location is used. This needs to be taken into account when Content-Location is used.
The easiest way to avoid needing to consider that issue is to include The easiest way to avoid needing to consider that issue is to include
the Content-Base whenever the Content-Location is included. the Content-Base whenever the Content-Location is included.
Note also, when using Media Tags in conjunction with Content- Note also, when using Media Tags in conjunction with Content-
Location, it is important that the different versions have different Location, it is important that the different versions have different
MTags, even if provided under different Content-Location URIs. This MTags, even if provided under different Content-Location URIs. This
as the different content variants still have been provided in is because the different content variants still have been provided in
response to the same request URI. response to the same request URI.
Note also, as in most cases, the URIs used in the DESCRIBE and the Note also, as in most cases, the URIs 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. Location response can't directly be used in a SETUP request.
Instead, the steps of deriving the media resource URIs are necessary. Instead, the steps of deriving the media resource URIs are necessary.
This commonly involves combing the media description's relative URIs, This commonly involves combing the media description's relative URIs,
e.g., from the SDP's a=control attribute, with the base-URI to create e.g., from the SDP's a=control attribute, with the base-URI to create
the absolute URIs needed in the SETUP request. the absolute URIs needed in the SETUP request.
18.19. Content-Type 18.19. Content-Type
The Content-Type message-body header indicates the media type of the The Content-Type message body header indicates the media type of the
message body sent to the recipient. Note that the content types message body sent to the recipient. Note that the content types
suitable for RTSP are likely to be restricted in practice to suitable for RTSP are likely to be restricted in practice to
presentation descriptions and parameter-value types. presentation descriptions and parameter-value types.
18.20. CSeq 18.20. CSeq
The CSeq general-header field specifies the sequence number (integer) The CSeq general-header field specifies the sequence number (integer)
for an RTSP request/response pair. This field MUST be present in all for an RTSP request/response pair. This field MUST be present in all
requests and responses. RTSP agents maintain a sequence number requests and responses. RTSP agents maintain a sequence number
series for each responder to which they have an open message series for each responder to which they have an open message
skipping to change at page 146, line 10 skipping to change at page 147, line 11
client has one series for its requests to a server and the server has client has one series for its requests to a server and the server has
another when sending requests to the client. Each requester and another when sending requests to the client. Each requester and
responder is identified by its socket address (IP address and port responder is identified by its socket address (IP address and port
number), i.e., per direction of a TCP connection. Any retransmitted number), i.e., per direction of a TCP connection. Any retransmitted
request MUST contain the same sequence number as the original, i.e., request MUST contain the same sequence number as the original, i.e.,
the sequence number is not incremented for retransmissions of the the sequence number is not incremented for retransmissions of the
same request. The RTSP agent receiving requests MUST process the same request. The RTSP agent receiving requests MUST process the
requests arriving on a particular transport in the order of the requests arriving on a particular transport in the order of the
sequence numbers. Responses are sent in the order that they are sequence numbers. Responses are sent in the order that they are
generated. The RTSP response MUST have the same sequence number as generated. The RTSP response MUST have the same sequence number as
was present in the corresponding request. An RTSP Agent receiving a was present in the corresponding request. An RTSP agent receiving a
response MAY receive the responses out of order compared to the order response MAY receive the responses out of order compared to the order
of the requests it sent. Thus, the agent MUST use the sequence of the requests it sent. Thus, the agent MUST use the sequence
number in the response to pair it with the corresponding request. number in the response to pair it with the corresponding request.
The main purpose of the sequence number is to map responses to The main purpose of the sequence number is to map responses to
requests. requests.
The requirement to use a sequence-number increment of one for each The requirement to use a sequence-number increment of one for each
new request is to support any future specification of RTSP message new request is to support any future specification of RTSP message
transport over a protocol that does not provide in-order delivery transport over a protocol that does not provide in-order delivery
skipping to change at page 148, line 26 skipping to change at page 149, line 26
format in RFC 5322. This format is more flexible than the date format in RFC 5322. This format is more flexible than the date
format in RFC 1123 used by RTSP 1.0. Thus, implementations should format in RFC 1123 used by RTSP 1.0. Thus, implementations should
use single spaces as separators, as recommended by RFC 5322, and use single spaces as separators, as recommended by RFC 5322, and
support receiving the obsolete format. support receiving the obsolete format.
Further, note that the syntax allows for a comment to be added at Further, note that the syntax allows for a comment to be added at
the end of the date. the end of the date.
18.22. Expires 18.22. Expires
The Expires message-body header field gives a date and time after The Expires message body header field gives a date and time after
which the description or media-stream should be considered stale. which the description or media-stream should be considered stale.
The interpretation depends on the method: The 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 indicates a date and time after SETUP response: The Expires header indicates a date and time after
which the media stream SHOULD be considered stale. which the media stream SHOULD be considered stale.
skipping to change at page 149, line 5 skipping to change at page 150, line 5
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: Wed, 23 Jan 2013 15:36:52 +0000 Expires: Wed, 23 Jan 2013 15:36:52 +0000
RTSP/2.0 clients and caches MUST treat other invalid date formats, RTSP 2.0 clients and caches MUST treat other invalid date formats,
especially those including the value "0", as having occurred in the especially those including the value "0", as having occurred in the
past (i.e., already expired). past (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
RTSP/2.0 servers SHOULD NOT send Expires dates that are more than one 2.0 servers SHOULD NOT send Expires dates that are more than one year
year in the future. in the future.
18.23. From 18.23. From
The From request-header field, if given, SHOULD contain an Internet The From request-header field, if given, SHOULD contain an Internet
email address for the human user who controls the requesting user email 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
skipping to change at page 150, line 20 skipping to change at page 151, line 20
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.
18.25. If-Modified-Since 18.25. 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
18.26. If-None-Match 18.26. 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
skipping to change at page 151, line 26 skipping to change at page 152, line 26
header MUST be ignored. (See Section 16.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.
18.27. Last-Modified 18.27. Last-Modified
The Last-Modified message-body header field indicates the date and The Last-Modified message body header field indicates the date and
time at which the origin server believes the presentation description time at which the origin server believes the presentation description
or media stream was last modified. For the DESCRIBE method, the or media stream was last modified. For the DESCRIBE method, the
header field indicates the last modification date and time of the header field indicates the last modification date and time of the
description, for the SETUP of the media stream. description, for the SETUP of the media stream.
An origin server MUST NOT send a Last-Modified date that is later An origin server MUST NOT send a Last-Modified date that 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
future, the server MUST replace that date with the message future, the server MUST replace that date with the message
origination date. origination date.
skipping to change at page 152, line 4 skipping to change at page 153, line 4
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.
18.28. Location 18.28. 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 3rr responses, the request or identification of a new resource. For 3rr 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 18.18) differs from Note: The Content-Location header field (Section 18.18) 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. Therefore, it location of the message body enclosed in the request. Therefore, it
is possible for a response to contain header fields for both Location is possible for a response to contain header fields for both Location
and Content-Location. Also, see Section 16.2 for cache requirements and Content-Location. Also, see Section 16.2 for cache requirements
of some methods. of some methods.
18.29. Media-Properties 18.29. Media-Properties
skipping to change at page 154, line 22 skipping to change at page 155, line 22
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
18.30. Media-Range 18.30. 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 the SETUP response, PLAY and PAUSE responses for media included in the SETUP response, PLAY and PAUSE responses for media
that are Time-Progressing, PLAY and PAUSE responses after any change that are time-progressing, PLAY and PAUSE responses after any change
for media that are Dynamic, and in PLAY_NOTIFY requests that are sent for media that are Dynamic, and in PLAY_NOTIFY requests that are sent
due to Media-Property-Update. A Media-Range header without any range due to Media-Property-Update. A Media-Range header without any range
specifications MAY be included in GET_PARAMETER requests to the specifications MAY be included in GET_PARAMETER requests to the
server to request the current range. In this case, the server MUST server to request the current range. In this case, the server MUST
include the current range at the time of sending the response. 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 18.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. The range indicate media that has non-continuous range. The range
specifications SHALL be ordered with the range with the lowest value specifications SHALL be ordered with the range with the lowest value
or earliest start time first, followed by ranges with increasingly or earliest start time first, followed by ranges with increasingly
higher values or later start time. higher values or later start time.
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 header values will only be valid for the particular point in time
was issued. As the wallclock progresses, so will the media range. when it was issued. As the wallclock progresses, so will the media
However, it shall be assumed that media time progresses in direct range. However, it shall be assumed that media time progresses in
relationship to wallclock time (with the exception of clock skew) so direct relationship to wallclock time (with the exception of clock
that a reasonably accurate estimation of the media range can be skew) so that a reasonably accurate estimation of the media range can
calculated. be calculated.
18.31. MTag 18.31. 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.6) returned in or SETUP responses. The message body tags (Section 4.6) returned in
a DESCRIBE response and the one in SETUP refer to the presentation, a DESCRIBE response and the one in SETUP refer 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.
skipping to change at page 155, line 20 skipping to change at page 156, line 20
If the MTag is provided both inside the message body, e.g., within 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 the "a=mtag" attribute in SDP, and in the response message, then both
tags MUST be identical. It is RECOMMENDED that the MTag be primarily tags MUST be identical. It is RECOMMENDED that the MTag be 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 18.24) and If-None-Match ( using the headers If-Match (Section 18.24) and If-None-Match
Section 18.26). (Section 18.26).
18.32. Notify-Reason 18.32. Notify-Reason
The Notify-Reason response-header is solely used in the PLAY_NOTIFY The Notify-Reason response-header is solely used in the PLAY_NOTIFY
method. It indicates the reason why the server has sent the method. It indicates the reason why the server has sent the
asynchronous PLAY_NOTIFY request (see Section 13.5). asynchronous PLAY_NOTIFY request (see Section 13.5).
18.33. Pipelined-Requests 18.33. Pipelined-Requests
The Pipelined-Requests general-header is used to indicate that a The Pipelined-Requests general-header is used to indicate that a
skipping to change at page 155, line 49 skipping to change at page 156, line 49
Upon receiving a request with the Pipelined-Requests, the responding Upon receiving a request with the Pipelined-Requests, the responding
agent MUST look up if there exists a binding between this Pipelined- agent MUST look up if there exists a binding between this Pipelined-
Requests identifier for the current persistent connection and an RTSP Requests identifier for the current persistent connection and an RTSP
session ID. If the binding exists, then the received request is session ID. If the binding exists, then the received request is
processed the same way as if it contained the Session header with the processed the same way as if it contained the Session header with the
found session ID. If there does not exist a mapping and no Session found session ID. If there does not exist a mapping and no Session
header is included in the request, the responding agent MUST create a header is included in the request, the responding agent MUST create a
binding upon the successful completion of a session creating request, binding upon the successful completion of a session creating request,
i.e., SETUP. A binding MUST NOT be created, if the request failed to i.e., SETUP. A binding MUST NOT be created, if the request failed to
create an RTSP session. In case the request contains both a Session create an RTSP session. In case the request contains both a Session
header and the Pipelined-Requests header, the Pipelined-Requests MUST header and the Pipelined-Requests header, the Pipelined-Requests
be ignored. header MUST be ignored.
Note: Based on the above definition, at least the first request Note: Based on the above definition, at least the first request
containing a new unique Pipelined-Requests header will be required to containing a new unique Pipelined-Requests header will be required to
be a SETUP request (unless the protocol is extended with new methods be a SETUP request (unless the protocol is extended with new methods
of creating a session). After that first one, additional SETUP of creating a session). After that first one, additional SETUP
requests or requests of any type using the RTSP session context may requests or requests of any type using the RTSP session context may
include the Pipelined-Requests header. include the Pipelined-Requests header.
When responding to any request that contained the Pipelined-Requests When responding to any request that contained the Pipelined-Requests
header, the server MUST also include the Session header when a header, the server MUST also include the Session header when a
skipping to change at page 156, line 36 skipping to change at page 157, line 36
RTSP agents are RECOMMENDED not to reuse identifiers to allow for RTSP agents are RECOMMENDED not to 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 requests to outgoing to allow for aggregation of values from incoming requests to outgoing to allow for aggregation of
requests onto a persistent connection. requests onto a persistent connection.
18.34. Proxy-Authenticate 18.34. 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
definition of the header is in [RFC7235], and any applicable HTTP
authentication schemes, such as Digest [RFC7616] and Basic [RFC7617].
The HTTP access authentication process is described in [RFC2617]. The HTTP access authentication process is described in [RFC7235].
Unlike WWW-Authenticate, the Proxy-Authenticate header field applies This header MUST only be used in response messages related to client-
only to the current connection and SHOULD NOT be passed on to to-server requests.
downstream agents. This header MUST only be used in response
messages related to client-to-server requests.
18.35. Proxy-Authentication-Info 18.35. Proxy-Authentication-Info
The Proxy-Authentication-Info response-header is used by the proxy to The Proxy-Authentication-Info response-header is used by the proxy to
communicate some information regarding the successful authentication communicate some information regarding the successful authentication
to the proxy in the message response. The content and usage of this to the proxy in the message response when using the digest scheme.
header is described in the HTTP access authentication [RFC2617] that The definition of the header is in [RFC7615], and any applicable HTTP
is also used by RTSP and clarified in Section 19.1. This header MUST authentication schemes, such as Digest [RFC7616]. This header MUST
only be used in response messages related to client-to-server only be used in response messages related to client-to-server
requests. This header has hop-by-hop scope. requests. This header has hop-by-hop scope.
18.36. Proxy-Authorization 18.36. 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 that requires identify itself (or its user) to a proxy that 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 or realm of the resource being requested. The
definition of the header is in [RFC7235], and any applicable HTTP
authentication schemes, such as Digest [RFC7616] and Basic [RFC7617].
The HTTP access authentication process is described in [RFC2617]. The HTTP access authentication process is described in [RFC7235].
Unlike Authorization, the Proxy-Authorization header field applies Unlike Authorization, the Proxy-Authorization header field applies
only to the next-hop proxy. This header MUST only be used in client- only to the next-hop proxy. This header MUST only be used in client-
to-server requests. to-server requests.
18.37. Proxy-Require 18.37. 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
skipping to change at page 159, line 23 skipping to change at page 160, line 23
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.
18.40. Range 18.40. Range
The Range general-header specifies a time range in PLAY The Range general-header specifies a time range in PLAY
(Section 13.4), PAUSE (Section 13.6), SETUP (Section 13.3), REDIRECT (Section 13.4), PAUSE (Section 13.6), SETUP (Section 13.3), and
(Section 13.10), and PLAY_NOTIFY (Section 13.5) requests and PLAY_NOTIFY (Section 13.5) requests and responses. It MAY be
responses. It MAY be included in GET_PARAMETER requests from the included in GET_PARAMETER requests from the client to the server with
client to the server with only a Range format and no value to request only a Range format and no value to request the current media
the current media position, whether the session is in Play or Ready position, whether the session is in Play or Ready state in the
state in the included format. The server SHALL, if supporting the included format. The server SHALL, if supporting the range format,
range format, respond with the current playing point or pause point respond with the current playing point or pause point as the start of
as the start of the range. If an explicit stop point was used in the the range. If an explicit stop point was used in the previous PLAY
previous PLAY request, then that value shall be included as stop request, then that value shall be included as stop point. Note that
point. Note that if the server is currently under any type of media if the server is currently under any type of media playback
playback manipulation affecting the interpretation of Range, like manipulation affecting the interpretation of the Range header, like
Scale, that fact is also required to be included in any GET_PARAMETER scale value other than 1, that fact is also required to be included
response to provide complete information. in any GET_PARAMETER response by including the Scale header to
provide complete information.
The range can be specified in a number of units. This specification The range can be specified in a number of units. This specification
defines smpte (Section 4.4.1), npt (Section 4.4.2), and clock defines smpte (Section 4.4.1), npt (Section 4.4.2), and clock
(Section 4.4.3) range units. While octet ranges (Byte Ranges) (see (Section 4.4.3) range units. While octet ranges (Byte Ranges) (see
Section 2.1 of [RFC7233]) and other extended units MAY be used, their Section 2.1 of [RFC7233]) and other extended units MAY be used, their
behavior is unspecified since they are not normally meaningful in behavior is unspecified since they are not normally meaningful in
RTSP. Servers supporting the Range header MUST understand the NPT RTSP. Servers supporting the Range header MUST understand the NPT
range format and SHOULD understand the SMPTE range format. If the range format and SHOULD understand the SMPTE range format. If the
Range header is sent in a time format that is not understood, the Range header is sent in a time format that is not understood, the
recipient SHOULD return 456 (Header Field Not Valid for Resource) and recipient SHOULD return 456 (Header Field Not Valid for Resource) and
skipping to change at page 160, line 14 skipping to change at page 161, line 14
The Range header contains a range of one single range format. A The Range header contains a range of one single range format. A
range is a half-open interval with a start and an end point, range is a half-open interval with a start and an end point,
including the start point but excluding the end point. A range may including the start point but excluding the end point. A range may
either be fully specified with explicit values for start point and either be fully specified with explicit values for start point and
end point or have either the start or end point be implicit. An end point or have either the start or end point be implicit. An
implicit start point indicates the session's pause point, and if no implicit start point indicates the session's pause point, and if no
pause point is set, the start of the content. An implicit end point pause point is set, the start of the content. An implicit end point
indicates the end of the content. The usage of both implicit start indicates the end of the content. The usage of both implicit start
and end points is not allowed in the same Range header; however, the and end points is not allowed in the same Range header; however, the
exclusion of the Range header has that meaning, i.e., from pause omission of the Range header has that meaning, i.e., from pause point
point (or start) until end of content. (or start) until end of content.
Regarding the half-open intervals; a range of A-B starts exactly As noted, Range headers define half-open intervals. A range of
at time A, but ends just before B. Only the start time of a media A-B starts exactly at time A, but ends just before B. Only the
unit such as a video or audio frame is relevant. For example, start time of a media unit such as a video or audio frame is
assume that video frames are generated every 40 ms. A range of relevant. For example, assume that video frames are generated
10.0-10.1 would include a video frame starting at 10.0 or later every 40 ms. A range of 10.0-10.1 would include a video frame
time and would include a video frame starting at 10.08, even starting at 10.0 or later time and would include a video frame
though it lasted beyond the interval. A range of 10.0-10.08, on starting at 10.08, even though it lasted beyond the interval. A
the other hand, would exclude the frame at 10.08. range of 10.0-10.08, on the other hand, would exclude the frame at
10.08.
Please note the difference between NPT timescales' "now" and an Please note the difference between NPT timescales' "now" and an
implicit start value. Implicit values reference the current implicit start value. Implicit values reference the current
pause-point. While "now" is the currently ongoing time. In a pause-point, while "now" is the current time. In a time-
time-progressing session with recording (retention for some or progressing session with recording (retention for some or full
full time), the pause point may be 2 min into the session while time), the pause point may be 2 min into the session while now
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 18.46) indicates a negative scale value. For example, this Section 18.46) indicates a negative scale value. For example, this
skipping to change at page 161, line 15 skipping to change at page 162, line 16
on a reverse playback for formats that have such a notion, like NPT on a reverse playback for formats that have such a notion, like NPT
and SMPTE. and SMPTE.
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 value in
header is not valid. the Scale header is not valid.
18.41. Referrer 18.41. 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
keyboard. keyboard.
If the field value is a relative URI, it SHOULD be interpreted If the field-value is a relative URI, it SHOULD be interpreted
relative to the Request-URI. The URI MUST NOT include a fragment relative to the Request-URI. The URI MUST NOT include a fragment
identifier. identifier.
Because the source of a link might be private information or might Because the source of a link might be private information or might
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.
skipping to change at page 162, line 5 skipping to change at page 163, line 6
RTSP request if the referring page was transferred with a secure RTSP request if the referring page was transferred with a secure
protocol. protocol.
18.42. Request-Status 18.42. 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 take time to complete, such as PLAY (Section 13.4). It is sent that take time to complete, such as 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 and the Session ID used in the request reported on. This
request. It provides both a numerical status code (according to is not ensured to be unambigous due to the fact that the CSeq number
Section 8.1.1) and a human-readable reason phrase. is scoped by the transport connection. Agents originating requests
can reduce the issue by using a monotonically increasing counter
across all sequential transports used. The header provides both a
numerical status code (according to 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"
Proxies that renumber the CSeq header need to perform corresponding
remapping of the cseq parameter in this header when forwarding the
request to the next-hop agent.
18.43. Require 18.43. Require
The Require request-header field is used by agents to ensure that the The Require request-header field is used by agents to ensure that the
other endpoint supports features that are required in respect to this other endpoint supports features that are required in respect to this
request. It can also be used to query if the other endpoint supports request. It can also be used to query if the other endpoint supports
certain features; however, the use of the Supported general-header certain features; however, the use of the Supported general-header
(Section 18.51) is much more effective in this purpose. In case any (Section 18.51) is much more effective in this purpose. In case any
of the feature-tags listed by the Require header are not supported by of the feature-tags listed by the Require header are not supported by
the server or client receiving the request, it MUST respond to the the server or client receiving the request, it MUST respond to the
request using the error code 551 (Option Not Supported) and include request using the error code 551 (Option Not Supported) and include
skipping to change at page 163, line 23 skipping to change at page 164, line 35
(Section 15.1) about when to consider that a feature requires proxy (Section 15.1) about when to consider that a feature requires proxy
support. support.
18.44. Retry-After 18.44. 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) or 553 (Proxy Unavailable) response to indicate how long Unavailable) or 553 (Proxy Unavailable) response to indicate how long
the service is expected to be unavailable to the requesting client. the service is expected to be unavailable to the requesting client.
This field MAY also be used with any 3rr (Redirection) response to This field MAY also be used with any 3rr (Redirection) response to
indicate the minimum time the user agent is asked to wait before indicate the minimum time the user agent is asked to wait before
issuing the redirected request. The value of this field can be issuing the redirected request. A response using 413 (Request
Message Body Too Large) when the restriction is temporary MAY also
include the Retry-After header. The value of this field can be
either an RTSP-date or an integer number of seconds (in decimal) either an RTSP-date or an integer number of seconds (in decimal)
after the time of the response. 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.
skipping to change at page 165, line 50 skipping to change at page 167, line 16
rate ("fast forward") and a value of 0.5 indicates half the normal rate ("fast forward") and a value of 0.5 indicates half the normal
viewing rate. In other words, a value of 2 has content time increase viewing rate. In other words, a value of 2 has content time increase
at twice the playback time. For every second of elapsed (wallclock) at twice the playback time. For every second of elapsed (wallclock)
time, 2 seconds of content time will be delivered. A negative value time, 2 seconds of content time will be delivered. A negative value
indicates reverse direction. For certain media transports, this may indicates reverse direction. For certain media transports, this may
require certain considerations to work consistently; see Appendix C.1 require certain considerations to work consistently; see Appendix C.1
for description on how RTP handles this. for description on how RTP handles this.
The transmitted-data rate SHOULD NOT be changed by selection of a The transmitted-data rate SHOULD NOT be changed by selection of a
different scale value. The resulting bitrate should be reasonably different scale value. The resulting bitrate should be reasonably
close to the nominal bitrate of the content for Scale = 1. The close to the nominal bitrate 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 18.29). The client SHOULD only indicate request header (Section 18.29). The client SHOULD only indicate request
values to be supported. However, as the values may change as the values 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, it only forces the server to choose the closest generate an error, it 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 18.40. Section 18.40.
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
skipping to change at page 168, line 49 skipping to change at page 170, line 17
The Session general-header field identifies an RTSP session. An RTSP The Session general-header field identifies an RTSP session. An RTSP
session is created by the server as a result of a successful SETUP session is created by the server as a result of a successful SETUP
request, and in the response, the session identifier is given to the request, and in the response, the session identifier is given to the
client. The RTSP session exists until destroyed by a TEARDOWN or a client. The RTSP session exists until destroyed by a TEARDOWN or a
REDIRECT or is timed out by the server. REDIRECT or is 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
that session. This means that the Session header MUST be included in that session. This means that the Session header MUST be included in
a request, using the following methods: PLAY, PAUSE, and TEARDOWN. a request, using the following methods: PLAY, PAUSE, PLAY_NOTIFY and
It MAY be included in SETUP, OPTIONS, SET_PARAMETER, GET_PARAMETER, TEARDOWN. It MAY be included in SETUP, OPTIONS, SET_PARAMETER,
and REDIRECT. It MUST NOT be included in DESCRIBE. The Session GET_PARAMETER, and REDIRECT. It MUST NOT be included in DESCRIBE.
header MUST NOT be included in the following methods, if these The Session header MUST NOT be included in the following methods, if
requests are pipelined and if the session identifier is not yet these requests are pipelined and if the session identifier is not yet
known: PLAY, PAUSE, TEARDOWN, SETUP, OPTIONS SET_PARAMETER, and known: PLAY, PAUSE, TEARDOWN, SETUP, OPTIONS SET_PARAMETER, and
GET_PARAMETER. GET_PARAMETER.
In an RTSP response, the session header MUST be included in methods, In an RTSP response, the session header MUST be included in methods,
SETUP, PLAY, and PAUSE, and it MAY be included in methods TEARDOWN SETUP, PLAY, PAUSE, and PLAY_NOTIFY, and it MAY be included in
and REDIRECT. If included in the request of the following methods it methods TEARDOWN and REDIRECT. If included in the request of the
MUST also be included in the response: OPTIONS, GET_PARAMETER, and following methods it MUST also be included in the response: OPTIONS,
SET_PARAMETER. It MUST NOT be included in DESCRIBE responses. GET_PARAMETER, and SET_PARAMETER. It MUST NOT be included in
DESCRIBE responses.
Note that a session identifier identifies an RTSP session across Note that a session identifier identifies an RTSP session across
transport sessions or connections. RTSP requests for a given session transport sessions or connections. RTSP requests for a given session
can use different URIs (Presentation and media URIs). Note, that can use different URIs (Presentation and media URIs). Note, that
there are restrictions depending on the session as to which URIs are there are restrictions depending on the session as to which URIs are
acceptable for a given method. However, multiple "user" sessions for acceptable for a given method. However, multiple "user" sessions for
the same URI from the same client will require use of different the same URI from the same client will require use of different
session identifiers. session identifiers.
The session identifier is needed to distinguish several delivery The session identifier is needed to distinguish several delivery
skipping to change at page 172, line 51 skipping to change at page 174, line 19
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.
The transport protocol identifier defines, for each transport The transport protocol identifier defines, for each transport
specification, which transport protocol to use and any related rules. specification, which transport protocol to use and any related rules.
Each transport protocol identifier defines the parameters that are Each transport protocol identifier defines the parameters that are
required to occur; additional optional parameters MAY occur. This required to occur; additional optional parameters MAY occur. This
flexibility is provided as parameters may be different and provide flexibility is provided as parameters may be different and provide
different options to the RTSP Agent. A transport specification may different options to the RTSP agent. A transport specification may
only contain one of any given parameter within it. A parameter only contain one of any given parameter within it. A parameter
consists of a name and optionally a value string. Parameters MAY be consists of a name and optionally a value string. Parameters MAY be
given in any order. Additionally, a transport specification may only given in any order. Additionally, a transport specification may only
contain either the unicast or the multicast transport type parameter. contain either the unicast or the multicast transport type parameter.
The transport protocol identifier, and all parameters, need to be The transport protocol identifier, and all parameters, need to be
understood in a transport specification; if not, the transport understood in a transport specification; if not, the transport
specification MUST be ignored. An RTSP proxy of any type that uses specification MUST be ignored. An RTSP proxy of any type that uses
or modifies the transport specification, e.g., access proxy or or modifies the transport specification, e.g., access proxy or
security proxy, MUST remove specifications with unknown parameters security proxy, MUST remove specifications with unknown parameters
before forwarding the RTSP message. If that results in no remaining before forwarding the RTSP message. If that results in no remaining
skipping to change at page 177, line 21 skipping to change at page 178, line 38
IPv6 as the scoping is part of the IPv6 multicast address IPv6 as the scoping is part of the IPv6 multicast address
[RFC4291]. [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. The values are
an eight-digit hexadecimal value. expressed as a slash-seperated sequence of eight-digit
hexadecimal value.
The ssrc parameter MUST NOT be specified in requests. The The ssrc parameter MUST NOT be specified in requests. The
functionality of specifying the ssrc parameter in a SETUP functionality of specifying the ssrc parameter in a SETUP
request is deprecated as it is incompatible with the request is deprecated as it is incompatible with the
specification of RTP in RFC 3550[RFC3550]. If the parameter is specification of RTP [RFC3550]. If the parameter is included
included in the Transport header of a SETUP request, the server in the Transport header of a SETUP request, the server SHOULD
SHOULD ignore it, and choose appropriate SSRCs for the stream. ignore it, and choose appropriate SSRCs for the stream. The
The server SHOULD set the ssrc parameter in the Transport server SHOULD set the ssrc parameter in the Transport header of
header of the response. the response.
RTCP-mux: Use to negotiate the usage of RTP and RTCP multiplexing RTCP-mux: Used to negotiate the usage of RTP and RTCP multiplexing
[RFC5761] on a single underlying transport stream/flow. The [RFC5761] on a single underlying transport stream/flow. The
presence of this parameter in a SETUP request indicates the presence of this parameter in a SETUP request indicates the
client's support and requires the server to use RTP and RTCP client's support and requires the server to use RTP and RTCP
multiplexing. The client SHALL only include one transport multiplexing. The client SHALL only include one transport
stream in the Transport header specification. To provide the stream in the Transport header specification. To provide the
server with a choice between using RTP/RTCP multiplexing or server with a choice between using RTP/RTCP multiplexing or
not, two different transport header specifications must be not, two different transport header specifications must be
included. included.
The parameter setup and connection defined below MAY only be used if The parameter setup and connection defined below MAY only be used if
skipping to change at page 179, line 28 skipping to change at page 181, line 16
CSeq: 302 CSeq: 302
Transport: RTP/AVP;multicast;mode="PLAY", Transport: RTP/AVP;multicast;mode="PLAY",
RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
"192.0.2.5:3457";mode="PLAY" "192.0.2.5:3457";mode="PLAY"
Accept-Ranges: npt, smpte, clock Accept-Ranges: npt, smpte, clock
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: 302 CSeq: 302
Date: Fri, 20 Dec 2013 10:20:32 +0000 Date: Fri, 20 Dec 2013 10:20:32 +0000
Session: 47112344 Session: rQi1hBrGlFdiYld241FxUO
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
18.55. Unsupported 18.55. Unsupported
The Unsupported response-header lists the features not supported by The Unsupported response-header lists the features not supported by
skipping to change at page 180, line 27 skipping to change at page 182, line 17
The Via general-header field MUST be used by proxies to indicate the The Via general-header field MUST be used by proxies to indicate the
intermediate protocols and recipients between the user agent and the intermediate protocols and recipients between the user agent and the
server on requests and between the origin server and the client on server on requests and between the origin server and the client on
responses. The field is intended to be used for tracking message responses. The field is intended to be used for tracking message
forwards, avoiding request loops, and identifying the protocol forwards, avoiding request loops, and identifying the protocol
capabilities of all senders along the request/response chain. capabilities of all senders along the request/response chain.
Each of multiple values in the Via field represents each proxy that Each of multiple values in the Via field represents each proxy that
has forwarded the message. Each recipient MUST append its has forwarded the message. Each recipient MUST append its
information such that the end result is ordered according to the information such that the end result is ordered according to the
sequence of forwarding applications. sequence of forwarding applications. So message originating client
or server do not include the Via header. The first proxy or other
intermediate adds the header and its information into the field. Any
additional intermediate adds additional field values. Resulting in
the server seeing the chains of intermediates in a client-to-server
request and the client seeing the full chain in the response message.
Proxies (e.g., Access Proxy or Translator Proxy) SHOULD NOT, by Proxies (e.g., Access Proxy or Translator Proxy) SHOULD NOT, by
default, forward the names and ports of hosts within the private/ default, forward the names and ports of hosts within the private/
protected region. This information SHOULD only be propagated if protected region. This information SHOULD only be propagated if
explicitly enabled. If not enabled, the via-received of any host explicitly enabled. If not enabled, the via-received of any host
behind the firewall/NAT SHOULD be replaced by an appropriate behind the firewall/NAT SHOULD be replaced by an appropriate
pseudonym for that host. pseudonym for that host.
For organizations that have strong privacy requirements for hiding For organizations that have strong privacy requirements for hiding
internal structures, a proxy MAY combine an ordered subsequence of internal structures, a proxy MAY combine an ordered subsequence of
Via header field entries with identical sent-protocol values into a Via header field entries with identical sent-protocol values into a
single such entry. Applications MUST NOT combine entries that have single such entry. Applications MUST NOT combine entries that have
different received-protocol values. different received-protocol values.
18.58. WWW-Authenticate 18.58. WWW-Authenticate
The WWW-Authenticate response-header field MUST be included in 401 The WWW-Authenticate header is specified in [RFC7235]; its usage
(Unauthorized) response messages. The field value consists of at depends on the used authentication schemes, such as Digest [RFC7616]
least one challenge that indicates the authentication scheme(s) and and Basic [RFC7617]. The WWW-Authenticate response-header field MUST
parameters applicable to the Request-URI. This header MUST only be be included in 401 (Unauthorized) response messages. The field-value
used in response messages related to client to server requests. consists of at least one challenge that indicates the authentication
scheme(s) and parameters applicable to the Request-URI. This header
MUST only be used in response messages related to client to server
requests.
The HTTP access authentication process is described in [RFC2617] with The HTTP access authentication process is described in [RFC7235] with
some clarification in Section 19.1. User agents are advised to take some clarification in Section 19.1. User agents are advised to take
special care in parsing the WWW-Authenticate field value as it might special care in parsing the WWW-Authenticate field-value as it might
contain more than one challenge, or if more than one WWW-Authenticate contain more than one challenge, or if more than one WWW-Authenticate
header field is provided, the contents of a challenge itself can header field is provided, the contents of a challenge itself can
contain a comma-separated list of authentication parameters. contain a comma-separated list of authentication parameters.
19. Security Framework 19. Security Framework
The RTSP security framework consists of two high-level components: The RTSP security framework consists of two high-level components:
the pure authentication mechanisms based on HTTP authentication and the pure authentication mechanisms based on HTTP authentication and
the message transport protection based on TLS, which is independent the message transport protection based on TLS, which is independent
of RTSP. Because of the similarity in syntax and usage between RTSP of RTSP. Because of the similarity in syntax and usage between RTSP
servers and HTTP servers, the security for HTTP is reused to a large servers and HTTP servers, the security for HTTP is reused to a large
extent. extent.
19.1. RTSP and HTTP Authentication 19.1. RTSP and HTTP Authentication
RTSP and HTTP share common authentication schemes; thus, they follow RTSP and HTTP share common authentication schemes; thus, they follow
the same usage guidelines as specified in [RFC2617] with the the same framework as specified in [RFC7235]. RTSP uses the
additions for digest authentication specified below in corresponding RTSP error codes (401 and 407) and headers (WWW-
Section 19.1.1. Servers SHOULD implement both basic and digest Authenticate, Authorization, Proxy-Authenticate, Proxy-Authorization)
[RFC2617] authentication. Clients MUST implement both basic and by importing the definitions from [RFC7235]. Servers SHOULD
digest authentication [RFC2617] so that a server that requires the implement both the Basic [RFC7617] and the Digest [RFC7616]
client to authenticate can trust that the capability is present. authentication schemes. Clients MUST implement both the Basic and
the Digest authentication schemes so that a server that requires the
client to authenticate can trust that the capability is present. If
implementing the Digest authentication scheme, then the additional
considerations specified below in Section 19.1.1 MUST be followed.
It should be stressed that using the HTTP authentication alone does It should be stressed that using the HTTP authentication alone does
not provide full control message security. Therefore, in not provide full RTSP message security. Therefore, TLS SHOULD be
environments requiring tighter security for the control messages, TLS used; see Section 19.2. Any RTSP message containing an Authorization
SHOULD be used; see Section 19.2. Any RTSP message containing an header using the Basic authentication scheme MUST be using a TLS
Authorization header using basic authorization MUST be using a TLS
connection with confidentiality protection enabled, i.e., no NULL connection with confidentiality protection enabled, i.e., no NULL
encryption. encryption.
In cases where there is a chain of proxies between the client and the In cases where there is a chain of proxies between the client and the
server, each proxy may individually request the client or previous server, each proxy may individually request the client or previous
proxy to authenticate itself. This is done using the Proxy- proxy to authenticate itself. This is done using the Proxy-
Authenticate (Section 18.34), the Proxy-Authorization Authenticate (Section 18.34), the Proxy-Authorization
(Section 18.36), and the Proxy-Authentication-Info (Section 18.35) (Section 18.36), and the Proxy-Authentication-Info (Section 18.35)
headers. These headers are hop-by-hop headers and are only scoped to headers. These headers are hop-by-hop headers and are only scoped to
the current connection and hop. Thus, if a proxy chain exists, a the current connection and hop. Thus, if a proxy chain exists, a
proxy connecting to another proxy will have to act as a client to proxy connecting to another proxy will have to act as a client to
authorize itself towards the next proxy. The WWW-Authenticate authorize itself towards the next proxy. The WWW-Authenticate
(Section 18.58), Authorization (Section 18.8), and Authentication- (Section 18.58), Authorization (Section 18.8), and Authentication-
Info (Section 18.7) headers are end-to-end and must not be modified Info (Section 18.7) headers are end-to-end and MUST NOT be modified
by proxies. by proxies.
This authentication mechanism works only for client-to-server This authentication mechanism works only for client-to-server
requests as currently defined. This leaves server-to-client request requests as currently defined. This leaves server-to-client request
outside of the context of TLS-based communication more vulnerable to outside of the context of TLS-based communication more vulnerable to
message-injection attacks on the client. Based on the server-to- message-injection attacks on the client. Based on the server-to-
client methods that exist, the potential risks are various: hijacking client methods that exist, the potential risks are various: hijacking
(REDIRECT), denial of service (TEARDOWN and PLAY_NOTIFY), or attacks (REDIRECT), denial of service (TEARDOWN and PLAY_NOTIFY), or attacks
with uncertain results (SET_PARAMETER). with uncertain results (SET_PARAMETER).
19.1.1. Digest Authentication 19.1.1. Digest Authentication
This section describes the modifications and clarifications required This section describes the modifications and clarifications required
to apply the HTTP Digest authentication scheme to RTSP. The RTSP to apply the HTTP Digest authentication scheme to RTSP. The RTSP
scheme usage is almost completely identical to that for HTTP scheme usage is almost completely identical to that for HTTP
[RFC2617]. These are based on the procedures defined for SIP 2.0 [RFC7616]. These modifications are based on the procedures defined
[RFC3261]. for SIP 2.0 [RFC3261] (in Section 22.4) but updated to use RFC 7235,
RFC 7616 and RFC 7615 instead of RFC 2617.
Digest authentication uses two additional headers, Authentication-
Info and Proxy-Authentication-Info, that are defined as in [RFC7615].
The rules for Digest authentication follow those defined in The rules for Digest authentication follow those defined in
[RFC2617], with "HTTP/1.1" replaced by "RTSP/2.0" in addition to the [RFC7616], with "HTTP/1.1" replaced by "RTSP/2.0" in addition to the
following differences: following differences:
1. Use the ABNF specified in this document, rather than the one in 1. Use the ABNF specified in the referenced documents, with the
[RFC2617]. Consequently, the following is assured: difference that the URI parameter uses the request URI format for
RTSP, i.e. the ABNF element: Request-URI (see Section 20.2.1).
* Using the right RTSP URIs allowed in the challenge as well as The domain parameter uses the RTSP-URI-Ref element for absolute
in the digest. and relative URIs.
* Resolving the error in the "uri" parameter of the
Authorization header in [RFC2617].
2. If MTags are used, then the example procedure for choosing a 2. If MTags are used, then the example procedure for choosing a
nonce based on ETag can work, based on replacing the ETag with nonce based on ETag can work, based on replacing the ETag with
the MTag. the MTag.
3. As a clarification to the calculation of the A2 value for message 3. As a clarification to the calculation of the A2 value for message
integrity assurance in the Digest authentication scheme, integrity assurance in the Digest authentication scheme,
implementers should assume, when the entity-body is empty (that implementers should assume, when the entity-body is empty (that
is, when the RTSP messages have no message body) that the hash of is, when the RTSP messages have no message body) that the hash of
the message-body resolves to the MD5 hash of an empty string, or: the message body resolves to the hash of an empty string, or:
H(entity-body) = MD5("") = "d41d8cd98f00b204e9800998ecf8427e". H(entity-body), example MD5("") =
"d41d8cd98f00b204e9800998ecf8427e".
4. RFC 2617 notes that a cnonce value MUST NOT be sent in an
Authorization (and by extension Proxy-Authorization) header field
if no qop directive has been sent. Therefore, any algorithms
that have a dependency on the cnonce (including "MD5-Sess")
require that the qop directive be sent. Use of the "qop"
parameter is optional in RFC 2617 for the purposes of backwards
compatibility with RFC 2069; since this specification defines
RTSP 2.0, there is no backwards compatibility issue with
mandating. Thus, all RTSP agents MUST implement qop-options.
19.2. RTSP over TLS 19.2. RTSP over TLS
RTSP agents MUST implement RTSP over TLS as defined in this section RTSP agents MUST implement RTSP over TLS as defined in this section
and the next Section 19.3. RTSP MUST follow the same guidelines with and the next Section 19.3. RTSP MUST follow the same guidelines with
regard to TLS [RFC5246] usage as specified for HTTP; see [RFC2818]. regard to TLS [RFC5246] usage as specified for HTTP; see [RFC2818].
RTSP over TLS is separated from unsecured RTSP both on the URI level RTSP over TLS is separated from unsecured RTSP both on the URI level
and the port level. Instead of using the "rtsp" scheme identifier in and the port level. Instead of using the "rtsp" scheme identifier in
the URI, the "rtsps" scheme identifier MUST be used to signal RTSP the URI, the "rtsps" scheme identifier MUST be used to signal RTSP
over TLS. If no port is given in a URI with the "rtsps" scheme, port over TLS. If no port is given in a URI with the "rtsps" scheme, port
skipping to change at page 185, line 33 skipping to change at page 187, line 26
Establish Secure Connection). Establish Secure Connection).
19.3.1. Accept-Credentials 19.3.1. Accept-Credentials
The Accept-Credentials header can be used by the client to distribute The Accept-Credentials header can be used by the client to distribute
simple authorization policies to intermediate proxies. The client simple authorization policies to intermediate proxies. The client
includes the Accept-Credentials header to dictate how the proxy includes the Accept-Credentials header to dictate how the proxy
treats the server / next proxy certificate. There are currently treats the server / next proxy certificate. There are currently
three methods defined: three methods defined:
Any: which means that the proxy (or proxies) MUST accept whatever Any: With "any", the proxy (or proxies) MUST accept whatever
certificate is presented. Of course, this is not a recommended certificate is presented. Of course, this is not a recommended
option to use, but it may be useful in certain circumstances option to use, but it may be useful in certain circumstances
(such as testing). (such as testing).
Proxy: which means that the proxy (or proxies) MUST use its own Proxy: For the "proxy" method, the proxy (or proxies) MUST use its
policies to validate the certificate and decide whether or not own policies to validate the certificate and decide whether or
to accept it. This is convenient in cases where the user has a not to accept it. This is convenient in cases where the user
strong trust relation with the proxy. Reasons why a strong has a strong trust relation with the proxy. Reasons why a
trust relation may exist are personal/company proxy or the strong trust relation may exist are personal/company proxy or
proxy has an out-of-band policy configuration mechanism. the proxy has an out-of-band policy configuration mechanism.
User: which means that the proxy (or proxies) MUST send credential User: For the "user" method, the proxy (or proxies) MUST send
information about the next hop to the client for authorization. credential information about the next hop to the client for
The client can then decide whether or not the proxy should authorization. The client can then decide whether or not the
accept the certificate. See Section 19.3.2 for further proxy should accept the certificate. See Section 19.3.2 for
details. further details.
If the Accept-Credentials header is not included in the RTSP request If the Accept-Credentials header is not included in the RTSP request
from the client, then the "Proxy" method MUST be used as default. If from the client, then the "Proxy" method MUST be used as default. If
a method other than the "Proxy" is to be used, then the Accept- a method other than the "Proxy" is to be used, then the Accept-
Credentials header MUST be included in all of the RTSP requests from Credentials header MUST be included in all of the RTSP requests from
the client. This is because it cannot be assumed that the proxy the client. This is because it cannot be assumed that the proxy
always keeps the TLS state or the user's previous preference between always keeps the TLS state or the user's previous preference between
different RTSP messages (in particular, if the time interval between different RTSP messages (in particular, if the time interval between
the messages is long). the messages is long).
skipping to change at page 188, line 31 skipping to change at page 190, line 21
Please note that ABNF strings, e.g., "Accept", are case insensitive Please note that ABNF strings, e.g., "Accept", are case insensitive
as specified in Section 2.3 of RFC 5234. as specified in Section 2.3 of RFC 5234.
The RTSP syntax makes use of the ISO 10646 character set in UTF-8 The RTSP syntax makes use of the ISO 10646 character set in UTF-8
encoding [RFC3629]. encoding [RFC3629].
20.1. Base Syntax 20.1. Base Syntax
RTSP header values can be folded onto multiple lines if the RTSP header values can be folded onto multiple lines if the
continuation line begins with a space or horizontal tab. All linear continuation line begins with a space or horizontal tab. All linear
white space, including folding, has the same semantics as SP. A whitespace, including folding, has the same semantics as SP. A
recipient MAY replace any linear white space with a single SP before recipient MAY replace any linear whitespace with a single SP before
interpreting the field value or forwarding the message downstream. interpreting the field-value or forwarding the message downstream.
This is intended to behave exactly as HTTP/1.1 as described in RFC This is intended to behave exactly as HTTP/1.1 as described in RFC
2616 [RFC2616]. The SWS construct is used when linear white space is 2616 [RFC2616]. The SWS construct is used when linear whitespace is
optional, generally between tokens and separators. optional, generally between tokens and separators.
To separate the header name from the rest of value, a colon is used, To separate the header name from the rest of value, a colon is used,
which, by the above rule, allows whitespace before, but no line which, by the above rule, allows whitespace before, but no line
break, and whitespace after, including a line break. The HCOLON break, and whitespace after, including a line break. The HCOLON
defines this construct. defines this construct.
OCTET = %x00-FF ; any 8-bit sequence of data OCTET = %x00-FF ; any 8-bit sequence of data
CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127) CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127)
UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z" UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z"
skipping to change at page 189, line 19 skipping to change at page 191, line 4
ALPHA = UPALPHA / LOALPHA ALPHA = UPALPHA / LOALPHA
DIGIT = %x30-39 ; any US-ASCII digit "0".."9" DIGIT = %x30-39 ; any US-ASCII digit "0".."9"
CTL = %x00-1F / %x7F ; any US-ASCII control character CTL = %x00-1F / %x7F ; any US-ASCII control character
; (octets 0 - 31) and DEL (127) ; (octets 0 - 31) and DEL (127)
CR = %x0D ; US-ASCII CR, carriage return (13) CR = %x0D ; US-ASCII CR, carriage return (13)
LF = %x0A ; US-ASCII LF, linefeed (10) LF = %x0A ; US-ASCII LF, linefeed (10)
SP = %x20 ; US-ASCII SP, space (32) SP = %x20 ; US-ASCII SP, space (32)
HT = %x09 ; US-ASCII HT, horizontal-tab (9) HT = %x09 ; US-ASCII HT, horizontal-tab (9)
BACKSLASH = %x5C ; US-ASCII backslash (92) BACKSLASH = %x5C ; US-ASCII backslash (92)
CRLF = CR LF CRLF = CR LF
LWS = [CRLF] 1*( SP / HT ) ; Line-breaking whitespace
LWS = [CRLF] 1*( SP / HT ) ; Line-breaking White Space SWS = [LWS] ; Separating whitespace
SWS = [LWS] ; Separating White Space
HCOLON = *( SP / HT ) ":" SWS HCOLON = *( SP / HT ) ":" SWS
TEXT = %x20-7E / %x80-FF ; any OCTET except CTLs TEXT = %x20-7E / %x80-FF ; any OCTET except CTLs
tspecials = "(" / ")" / "<" / ">" / "@" tspecials = "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / BACKSLASH / DQUOTE / "," / ";" / ":" / BACKSLASH / DQUOTE
/ "/" / "[" / "]" / "?" / "=" / "/" / "[" / "]" / "?" / "="
/ "{" / "}" / SP / HT / "{" / "}" / SP / HT
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7A / %x7C / %x7E) / %x41-5A / %x5E-7A / %x7C / %x7E)
; 1*<any CHAR except CTLs or tspecials> ; 1*<any CHAR except CTLs or tspecials>
quoted-string = ( DQUOTE *qdtext DQUOTE ) quoted-string = ( DQUOTE *qdtext DQUOTE )
skipping to change at page 191, line 4 skipping to change at page 192, line 29
UTF8-1 = <As defined in RFC 3629> UTF8-1 = <As defined in RFC 3629>
UTF8-2 = <As defined in RFC 3629> UTF8-2 = <As defined in RFC 3629>
UTF8-3 = <As defined in RFC 3629> UTF8-3 = <As defined in RFC 3629>
UTF8-4 = <As defined in RFC 3629> UTF8-4 = <As defined in RFC 3629>
UTF8-tail = <As defined in RFC 3629> UTF8-tail = <As defined in RFC 3629>
POS-FLOAT = 1*12DIGIT ["." 1*9DIGIT] POS-FLOAT = 1*12DIGIT ["." 1*9DIGIT]
FLOAT = ["-"] POS-FLOAT FLOAT = ["-"] POS-FLOAT
20.2. RTSP Protocol Definition 20.2. RTSP Protocol Definition
20.2.1. Generic Protocol Elements
20.2.1. Generic Protocol Elements
RTSP-IRI = schemes ":" IRI-rest RTSP-IRI = schemes ":" IRI-rest
IRI-rest = ihier-part [ "?" iquery ] IRI-rest = ihier-part [ "?" iquery ]
ihier-part = "//" iauthority ipath-abempty ihier-part = "//" iauthority ipath-abempty
RTSP-IRI-ref = RTSP-IRI / irelative-ref RTSP-IRI-ref = RTSP-IRI / irelative-ref
irelative-ref = irelative-part [ "?" iquery ] irelative-ref = irelative-part [ "?" iquery ]
irelative-part = "//" iauthority ipath-abempty irelative-part = "//" iauthority ipath-abempty
/ ipath-absolute / ipath-absolute
/ ipath-noscheme / ipath-noscheme
/ ipath-empty / ipath-empty
skipping to change at page 193, line 25 skipping to change at page 195, line 25
npt-range = "npt" [EQUAL npt-range-spec] npt-range = "npt" [EQUAL npt-range-spec]
npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time ) npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time )
npt-time = "now" / npt-sec / npt-hhmmss / npt-hhmmss-comp npt-time = "now" / npt-sec / npt-hhmmss / npt-hhmmss-comp
npt-sec = 1*19DIGIT [ "." 1*9DIGIT ] npt-sec = 1*19DIGIT [ "." 1*9DIGIT ]
npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." 1*9DIGIT ] npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." 1*9DIGIT ]
npt-hh = 2*19DIGIT ; any positive number npt-hh = 2*19DIGIT ; any positive number
npt-mm = 2*2DIGIT ; 0-59 npt-mm = 2*2DIGIT ; 0-59
npt-ss = 2*2DIGIT ; 0-59 npt-ss = 2*2DIGIT ; 0-59
npt-hhmmss-comp = npt-hh-comp ":" npt-mm-comp ":" npt-ss-comp npt-hhmmss-comp = npt-hh-comp ":" npt-mm-comp ":" npt-ss-comp
[ "." 1*9DIGIT ] # Compatibility format [ "." 1*9DIGIT ] ; Compatibility format
npt-hh-comp = 1*19DIGIT ; any positive number npt-hh-comp = 1*19DIGIT ; any positive number
npt-mm-comp = 1*2DIGIT ; 0-59 npt-mm-comp = 1*2DIGIT ; 0-59
npt-ss-comp = 1*2DIGIT ; 0-59 npt-ss-comp = 1*2DIGIT ; 0-59
utc-range = "clock" [EQUAL utc-range-spec] utc-range = "clock" [EQUAL utc-range-spec]
utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time ) utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time )
utc-time = utc-date "T" utc-clock "Z" utc-time = utc-date "T" utc-clock "Z"
utc-date = 8DIGIT utc-date = 8DIGIT
utc-clock = 6DIGIT [ "." 1*9DIGIT ] utc-clock = 6DIGIT [ "." 1*9DIGIT ]
skipping to change at page 198, line 22 skipping to change at page 200, line 44
language-range = language-tag / "*" language-range = language-tag / "*"
language-tag = primary-tag *( "-" subtag ) language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA primary-tag = 1*8ALPHA
subtag = 1*8ALPHA subtag = 1*8ALPHA
Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges
acceptable-ranges = (range-unit *(COMMA range-unit)) acceptable-ranges = (range-unit *(COMMA range-unit))
range-unit = "npt" / "smpte" / "smpte-30-drop" / "smpte-25" range-unit = "npt" / "smpte" / "smpte-30-drop" / "smpte-25"
/ "clock" / extension-format / "clock" / extension-format
extension-format = token extension-format = token
Allow = "Allow" HCOLON Method *(COMMA Method) Allow = "Allow" HCOLON Method *(COMMA Method)
Authentication-Info = "Authentication-Info" HCOLON auth-info Authentication-Info = "Authentication-Info" HCOLON auth-param-list
auth-info = auth-info-entry *(COMMA auth-info-entry) auth-param-list = <As the Authentication-Info element in RFC 7615>
auth-info-entry = nextnonce
/ message-qop
/ response-auth
/ cnonce
/ nonce-count
nextnonce = "nextnonce" EQUAL nonce-value
response-auth = "rspauth" EQUAL response-digest
response-digest = DQUOTE *LHEX DQUOTE
Authorization = "Authorization" HCOLON credentials Authorization = "Authorization" HCOLON credentials
credentials = basic-credential credentials = <As defined by RFC 7235>
/ digest-credential
/ other-response
basic-credential = "Basic" LWS basic-credentials
basic-credentials = base64 ; Base64 encoding of user-password
user-password = basic-username ":" password
basic-username = *CF-TEXT
CF-TEXT = %x20-39 / %x3B-7E / %x80-FF ; TEXT without :
password = *TEXT
digest-credential = ("Digest" LWS digest-response)
digest-response = dig-resp *(COMMA dig-resp)
dig-resp = username / realm / nonce / digest-uri
/ dresponse / algorithm / cnonce
/ opaque / message-qop
/ nonce-count / auth-param
username = "username" EQUAL username-value
username-value = quoted-string
digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT
digest-uri-value = RTSP-REQ-URI
message-qop = "qop" EQUAL qop-value
cnonce = "cnonce" EQUAL cnonce-value
cnonce-value = nonce-value
nonce-count = "nc" EQUAL nc-value
nc-value = 8LHEX
dresponse = "response" EQUAL request-digest
request-digest = LDQUOT 32LHEX RDQUOT
auth-param = auth-param-name EQUAL
( token / quoted-string )
auth-param-name = token
other-response = auth-scheme LWS auth-param
*(COMMA auth-param)
auth-scheme = token
Bandwidth = "Bandwidth" HCOLON 1*19DIGIT Bandwidth = "Bandwidth" HCOLON 1*19DIGIT
Blocksize = "Blocksize" HCOLON 1*9DIGIT Blocksize = "Blocksize" HCOLON 1*9DIGIT
Cache-Control = "Cache-Control" HCOLON cache-directive Cache-Control = "Cache-Control" HCOLON cache-directive
*(COMMA cache-directive) *(COMMA cache-directive)
cache-directive = cache-rqst-directive cache-directive = cache-rqst-directive
/ cache-rspns-directive / cache-rspns-directive
cache-rqst-directive = "no-cache" cache-rqst-directive = "no-cache"
/ "max-stale" [EQUAL delta-seconds] / "max-stale" [EQUAL delta-seconds]
/ "min-fresh" EQUAL delta-seconds / "min-fresh" EQUAL delta-seconds
/ "only-if-cached" / "only-if-cached"
/ cache-extension / cache-extension
skipping to change at page 202, line 4 skipping to change at page 203, line 11
ranges-list = ranges-spec *(COMMA ranges-spec) ranges-list = ranges-spec *(COMMA ranges-spec)
MTag = "MTag" HCOLON message-tag MTag = "MTag" HCOLON message-tag
Notify-Reason = "Notify-Reason" HCOLON Notify-Reas-val Notify-Reason = "Notify-Reason" HCOLON Notify-Reas-val
Notify-Reas-val = "end-of-stream" Notify-Reas-val = "end-of-stream"
/ "media-properties-update" / "media-properties-update"
/ "scale-change" / "scale-change"
/ Notify-Reason-extension / Notify-Reason-extension
Notify-Reason-extension = token Notify-Reason-extension = token
Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id
startup-id = 1*8DIGIT startup-id = 1*8DIGIT
Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge-list Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge-list
challenge-list = challenge *(COMMA challenge) challenge-list = <As defined by the WWW-Authenticate in RFC 7235>
challenge = ("Digest" LWS digest-cln *(COMMA digest-cln))
/ ("Basic" LWS realm)
/ other-challenge
other-challenge = auth-scheme LWS auth-param
*(COMMA auth-param)
digest-cln = realm / domain / nonce
/ opaque / stale / algorithm
/ qop-options / auth-param
realm = "realm" EQUAL realm-value
realm-value = quoted-string
domain = "domain" EQUAL LDQUOT RTSP-REQ-Ref
*(1*SP RTSP-REQ-Ref ) RDQUOT
nonce = "nonce" EQUAL nonce-value
nonce-value = quoted-string
opaque = "opaque" EQUAL quoted-string
stale = "stale" EQUAL ( "true" / "false" )
algorithm = "algorithm" EQUAL ("MD5" / "MD5-sess" / token)
qop-options = "qop" EQUAL LDQUOT qop-value
*("," qop-value) RDQUOT
qop-value = "auth" / "auth-int" / token
Proxy-Authentication-Info = "Proxy-Authentication-Info" HCOLON Proxy-Authentication-Info = "Proxy-Authentication-Info" HCOLON
auth-info auth-param-list
Proxy-Authorization = "Proxy-Authorization" HCOLON credentials Proxy-Authorization = "Proxy-Authorization" HCOLON credentials
Proxy-Require = "Proxy-Require" HCOLON feature-tag-list Proxy-Require = "Proxy-Require" HCOLON feature-tag-list
feature-tag-list = feature-tag *(COMMA feature-tag) feature-tag-list = feature-tag *(COMMA feature-tag)
Proxy-Supported = "Proxy-Supported" HCOLON [feature-tag-list] Proxy-Supported = "Proxy-Supported" HCOLON [feature-tag-list]
Public = "Public" HCOLON Method *(COMMA Method) Public = "Public" HCOLON Method *(COMMA Method)
Range = "Range" HCOLON ranges-spec Range = "Range" HCOLON ranges-spec
ranges-spec = npt-range / utc-range / smpte-range ranges-spec = npt-range / utc-range / smpte-range
skipping to change at page 209, line 5 skipping to change at page 210, line 5
Section 15.4 of [RFC2616]). Section 15.4 of [RFC2616]).
In addition to the recommendations in the current HTTP specifications In addition to the recommendations in the current HTTP specifications
([RFC7230], [RFC7231], [RFC7232], [RFC7233], [RFC7234], and [RFC7235] ([RFC7230], [RFC7231], [RFC7232], [RFC7233], [RFC7234], and [RFC7235]
as of this writing) and also those of the previous relevant RFCs as of this writing) and also those of the previous relevant RFCs
[RFC2068] [RFC2616], future HTTP specifications may provide [RFC2068] [RFC2616], future HTTP specifications may provide
additional guidance on security issues. additional guidance on security issues.
The following are added considerations for RTSP implementations. The following are added considerations for RTSP implementations.
Session hijacking: Since there is no or little relation between a Session Hijacking: Since there is no or little relation between a
transport-layer connection and an RTSP session, it is possible transport-layer connection and an RTSP session, it is possible
for a malicious client to issue requests with random session for a malicious client to issue requests with random session
identifiers that could affect other clients of an unsuspecting identifiers that could affect other clients of an unsuspecting
server. To mitigate this, the server SHALL use a large, random server. To mitigate this, the server SHALL use a large, random
and non-sequential session identifier to minimize the and non-sequential session identifier to minimize the
possibility of this kind of attack. However, unless the RTSP possibility of this kind of attack. However, unless the RTSP
signaling is always confidentiality protected, e.g., using TLS, signaling is always confidentiality protected, e.g., using TLS,
an on-path attacker will be able to hijack a session. Another an on-path attacker will be able to hijack a session. Another
choice for preventing session hijacking is to use client choice for preventing session hijacking is to use client
authentication and only allow the authenticated client creating authentication and only allow the authenticated client creating
the session to access that session. the session to access that session.
Authentication: Servers SHOULD implement both basic and digest Authentication: Servers SHOULD implement both basic and digest
[RFC2617] authentication. In environments requiring tighter [RFC2617] authentication. In environments requiring tighter
security for the control messages, the transport-layer security for the control messages, the transport-layer
mechanism TLS [RFC5246] SHOULD be used. mechanism TLS [RFC5246] SHOULD be used.
Suspicious behavior: Upon detecting instances of behavior that is Suspicious Behavior: Upon detecting instances of behavior that is
deemed a security risk, RTSP servers SHOULD return error code deemed a security risk, RTSP servers SHOULD return error code
403 (Forbidden). RTSP servers SHOULD also be aware of attempts 403 (Forbidden). RTSP servers SHOULD also be aware of attempts
to probe the server for weaknesses and entry points and MAY to probe the server for weaknesses and entry points and MAY
arbitrarily disconnect and ignore further requests from clients arbitrarily disconnect and ignore further requests from clients
that are deemed to be in violation of local security policy. that are deemed to be in violation of local security policy.
TLS through proxies: If one uses the possibility to connect TLS in TLS through Proxies: If one uses the possibility to connect TLS in
multiple legs (Section 19.3), one really needs to be aware of multiple legs (Section 19.3), one really needs to be aware of
the trust model. This procedure requires trust in all proxies the trust model. This procedure requires trust in all proxies
part of the path to the server. The proxies one connects part of the path to the server. The proxies one connects
through are identified, assuming the proxies so far connected through are identified, assuming the proxies so far connected
through are well behaved and fulfilling the trust. The through are well behaved and fulfilling the trust. The
accepted proxies are men in the middle and have access to all accepted proxies are men in the middle and have access to all
that goes on over the TLS connection. Thus, it is important to that goes on over the TLS connection. Thus, it is important to
consider if that trust model is acceptable in the actual consider if that trust model is acceptable in the actual
application. Further discussion of the actual trust model is application. Further discussion of the actual trust model is
in Section 19.3. It is important to note what difference in in Section 19.3. It is important to note what difference in
skipping to change at page 212, line 20 skipping to change at page 213, line 20
The server SHOULD NOT allow the destination field to be set unless a The server SHOULD NOT allow the destination field to be set unless a
mechanism exists in the system to authorize the request originator to mechanism exists in the system to authorize the request originator to
direct streams to the recipient. It is preferred that this direct streams to the recipient. It is preferred that this
authorization be performed by the media recipient (destination) authorization be performed by the media recipient (destination)
itself and the credentials be passed along to the server. However, itself and the credentials be passed along to the server. However,
in certain cases, such as when the recipient address is a multicast in certain cases, such as when the recipient address is a multicast
group or when the recipient is unable to communicate with the server group or when the recipient is unable to communicate with the server
in an out-of-band manner, this may not be possible. In these cases, in an out-of-band manner, this may not be possible. In these cases,
the server may choose another method such as a server-resident the server may choose another method such as a server-resident
authorization list to ensure that the request originator has the authorization list to ensure that the request originator has the
proper credentials to request stream delivery to the recipient.x proper credentials to request stream delivery to the recipient.
One solution that performs the necessary verification of acceptance One solution that performs the necessary verification of acceptance
of media suitable for unicast-based delivery is the NAT traversal of media suitable for unicast-based delivery is the NAT traversal
method based on Interactive Connectivity Establishment (ICE) method based on Interactive Connectivity Establishment (ICE)
[RFC5245] described in [RFC7825]. This mechanism uses random [RFC5245] described in [RFC7825]. This mechanism uses random
passwords and a username so that the probability of unintended passwords and a username so that the probability of unintended
indication as a valid media destination is very low. In addition, indication as a valid media destination is very low. In addition,
the server includes in its Session Traversal Utilities for NAT (STUN) the server includes in its Session Traversal Utilities for NAT (STUN)
[RFC5389] requests a cookie (consisting of random material) that the [RFC5389] requests a cookie (consisting of random material) that the
destination echoes back; thus, the solution also safeguards against destination echoes back; thus, the solution also safeguards against
skipping to change at page 218, line 51 skipping to change at page 219, line 51
o How the header is to be handled by proxies. o How the header is to be handled by proxies.
o A description of the purpose of the header. o A description of the purpose of the header.
22.4.3. Registered Entries 22.4.3. Registered Entries
All headers specified in Section 18 in RFC 7826 have been registered. All headers specified in Section 18 in RFC 7826 have been registered.
The registry includes the header name and reference. The registry includes the header name and reference.
Furthermore, the following legacy RTSP headers defined in other Furthermore, the following legacy RTSP headers defined in other
specifications are registered with header name, reference, and specifications are registered with header name, and reference
description according to below list. Note: these references may not according to below list. Note: these references may not fulfill all
fulfill all of the above rules for registrations due to their legacy of the above rules for registrations due to their legacy status.
status.
o x-wap-profile defined in [TS-26234]. The x-wap-profile request- o x-wap-profile defined in [TS-26234]. The x-wap-profile request-
header contains one or more absolute URLs to the requesting header contains one or more absolute URLs to the requesting
agent's device-capability profile. agent's device-capability profile.
o x-wap-profile-diff defined in [TS-26234]. The x-wap-profile-diff o x-wap-profile-diff defined in [TS-26234]. The x-wap-profile-diff
request-header contains a subset of a device-capability profile. request-header contains a subset of a device-capability profile.
o x-wap-profile-warning defined in [TS-26234]. The x-wap-profile- o x-wap-profile-warning defined in [TS-26234]. The x-wap-profile-
warning is a response-header that contains error codes explaining warning is a response-header that contains error codes explaining
skipping to change at page 221, line 27 skipping to change at page 222, line 27
sha-256 RFC 7826 sha-256 RFC 7826
22.6. Cache-Control Cache Directive Extensions 22.6. Cache-Control Cache Directive Extensions
There exist a number of cache directives that can be sent in the There exist a number of cache directives that can be sent in the
Cache-Control header. A registry for these cache directives has been Cache-Control header. A registry for these cache directives has been
established by IANA. New registrations in this registry require established by IANA. New registrations in this registry require
Standards Action or IESG Approval [RFC5226]. A registration request Standards Action or IESG Approval [RFC5226]. A registration request
needs to contain the following information. needs to contain the following information.
o The name of the directive. o The name of the cache directive.
o A definition of the parameter value, if any is allowed. o A definition of the parameter value, if any is allowed.
o The specification if it is a request or response directive. o The specification if it is a request or response directive.
o Text that explains how the cache directive is used for RTSP- o Text that explains how the cache directive is used for RTSP-
controlled media streams. controlled media streams.
o A contact person. o A contact person.
skipping to change at page 223, line 43 skipping to change at page 224, line 43
val ABNF, Section 20.2.3: val ABNF, Section 20.2.3:
end-of-stream: This Notify-Reason value indicates the end of a media end-of-stream: This Notify-Reason value indicates the end of a media
stream. stream.
media-properties-update: This Notify-Reason value allows the server media-properties-update: This Notify-Reason value allows the server
to indicate that the properties of the media have changed during to indicate that the properties of the media have changed during
the playout. the playout.
scale-change: This Notify-Reason value allows the server to notify scale-change: This Notify-Reason value allows the server to notify
the client about a change in the Scale of the media. the client about a change in the scale of the media.
The registry contains the name, description, and reference. The registry contains the name, description, and reference.
22.9. Range Header Formats 22.9. Range Header Formats
22.9.1. Description 22.9.1. Description
The Range header (Section 18.40) allows for different range formats. The Range header (Section 18.40) allows for different range formats.
These range formats also need an identifier to be used in the Accept- These range formats also need an identifier to be used in the Accept-
Ranges header (Section 18.5). New range formats may be registered, Ranges header (Section 18.5). New range formats may be registered,
but moderation should be applied as it makes interoperability more but moderation should be applied as it makes interoperability more
skipping to change at page 240, line 25 skipping to change at page 241, line 25
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014, RFC 7234, DOI 10.17487/RFC7234, June 2014,
<http://www.rfc-editor.org/info/rfc7234>. <http://www.rfc-editor.org/info/rfc7234>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235, Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014, DOI 10.17487/RFC7235, June 2014,
<http://www.rfc-editor.org/info/rfc7235>. <http://www.rfc-editor.org/info/rfc7235>.
[RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy-
Authentication-Info Response Header Fields", RFC 7615,
DOI 10.17487/RFC7615, September 2015,
<http://www.rfc-editor.org/info/rfc7615>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", RFC 7616,
DOI 10.17487/RFC7616, September 2015,
<http://www.rfc-editor.org/info/rfc7616>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015,
<http://www.rfc-editor.org/info/rfc7617>.
[RFC7825] Goldberg, J., Westerlund, M., and T. Zeng, "A Network [RFC7825] Goldberg, J., Westerlund, M., and T. Zeng, "A Network
Address Translator (NAT) Traversal Mechanism for Media Address Translator (NAT) Traversal Mechanism for Media
Controlled by Real-Time Streaming Protocol (RTSP)", Controlled by Real-Time Streaming Protocol (RTSP)",
RFC 7825, DOI 10.17487/RFC7825, March 2016, RFC 7825, DOI 10.17487/RFC7825, September 2016,
<http://www.rfc-editor.org/info/rfc7825>. <http://www.rfc-editor.org/info/rfc7825>.
[RTP-CIRCUIT-BREAKERS]
Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", Work in
Progress, draft-ietf-avtcore-rtp-circuit-breakers-13,
February 2016.
[SMPTE-TC] [SMPTE-TC]
Society of Motion Picture and Television Engineers, "ST Society of Motion Picture and Television Engineers, "ST
12-1:2008 For Television -- Time and Control Code", 12-1:2008 For Television -- Time and Control Code",
DOI 10.5594/SMPTE.ST12-1.2008, February 2008, DOI 10.5594/SMPTE.ST12-1.2008, February 2008,
<http://ieeexplore.ieee.org/servlet/ <http://ieeexplore.ieee.org/servlet/
opac?punumber=7289818>. opac?punumber=7289818>.
[TS-26234] [TS-26234]
3rd Generation Partnership Project (3GPP), "Transparent 3rd Generation Partnership Project (3GPP), "Transparent
end-to-end Packet-switched Streaming Service (PSS); end-to-end Packet-switched Streaming Service (PSS);
skipping to change at page 243, line 25 skipping to change at page 244, line 41
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>. <http://www.rfc-editor.org/info/rfc5905>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, "Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011, DOI 10.17487/RFC6298, June 2011,
<http://www.rfc-editor.org/info/rfc6298>. <http://www.rfc-editor.org/info/rfc6298>.
[RTP-CIRCUIT-BREAKERS]
Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", Work in
Progress, draft-ietf-avtcore-rtp-circuit-breakers-13,
February 2016.
[Stevens98] [Stevens98]
Stevens, W., Fenner, B., and A. Rudoff, "Unix Networking Stevens, W., Fenner, B., and A. Rudoff, "Unix Networking
Programming, Volume 1: The Sockets Networking API (3rd Programming, Volume 1: The Sockets Networking API (3rd
Edition)", 1998. Edition)", 1998.
Appendix A. Examples Appendix A. Examples
This section contains several different examples trying to illustrate This section contains several different examples trying to illustrate
possible ways of using RTSP. The examples can also help with the possible ways of using RTSP. The examples can also help with the
understanding of how functions of RTSP work. However, remember that understanding of how functions of RTSP work. However, remember that
these are examples and the normative and syntax descriptions in the these are examples and the normative and syntax descriptions in the
other sections take precedence. Please also note that many of the other sections take precedence. Please also note that many of the
examples contain syntax illegal line breaks to accommodate the examples have been broken into several lines, where following lines
formatting restriction that the RFC series impose. start with whitespace as allowed by the syntax.
A.1. Media on Demand (Unicast) A.1. Media on Demand (Unicast)
This is an example of media-on-demand streaming of media stored in a This is an example of media-on-demand streaming of media stored in a
container file. For the purposes of this example, a container file container file. For the purposes of this example, a container file
is a storage entity in which multiple continuous media types is a storage entity in which multiple continuous media types
pertaining to the same end-user presentation are present. In effect, pertaining to the same end-user presentation are present. In effect,
the container file represents an RTSP presentation, with each of its the container file represents an RTSP presentation, with each of its
components being RTSP-controlled media streams. Container files are components being RTSP-controlled media streams. Container files are
a widely used means to store such presentations. While the a widely used means to store such presentations. While the
skipping to change at page 246, line 18 skipping to change at page 247, line 18
Require: play.basic Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001"
Accept-Ranges: npt, smpte, clock Accept-Ranges: npt, smpte, clock
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/AVP;unicast; ssrc=93CB001E; Transport: RTP/AVP;unicast; ssrc=93CB001E;
dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; dest_addr="192.0.2.53:8000"/"192.0.2.53:8001";
src_addr="198.51.100.5:9000"/"198.51.100.5:9001" src_addr="198.51.100.5:9000"/"198.51.100.5:9001"
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:20:33 +0000 Expires: Fri, 20 Dec 2013 12:20:33 +0000
Date: Fri, 20 Dec 2013 10:20:33 +0000 Date: Fri, 20 Dec 2013 10:20:33 +0000
Accept-Ranges: npt Accept-Ranges: npt
Media-Properties: Random-Access=0.02, Immutable, Unlimited Media-Properties: Random-Access=0.02, Immutable, Unlimited
C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Require: play.basic Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Accept-Ranges: npt, smpte, clock Accept-Ranges: npt, smpte, clock
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/AVP;unicast; ssrc=A813FC13; Transport: RTP/AVP;unicast; ssrc=A813FC13;
dest_addr="192.0.2.53:8002"/"192.0.2.53:8003"; dest_addr="192.0.2.53:8002"/"192.0.2.53:8003";
src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; src_addr="198.51.100.5:9002"/"198.51.100.5:9003";
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:20:33 +0000 Expires: Fri, 20 Dec 2013 12:20:33 +0000
Date: Fri, 20 Dec 2013 10:20:33 +0000 Date: Fri, 20 Dec 2013 10:20:33 +0000
Accept-Range: NPT Accept-Range: NPT
Media-Properties: Random-Access=0.8, Immutable, Unlimited Media-Properties: Random-Access=0.8, Immutable, Unlimited
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4 CSeq: 4
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Range: npt=30- Range: npt=30-
Seek-Style: RAP Seek-Style: RAP
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 4 CSeq: 4
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:20:34 +0000 Date: Fri, 20 Dec 2013 10:20:34 +0000
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Range: npt=30-634.10 Range: npt=30-634.10
Seek-Style: RAP Seek-Style: RAP
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012, ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsp://example.com/twister.3gp/trackID=1" url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889 ssrc=4F312DD8:seq=54321;rtptime=2876889
C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0 C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 5 CSeq: 5
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
# Pause happens 0.87 seconds after starting to play # Pause happens 0.87 seconds after starting to play
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 5 CSeq: 5
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:20:35 +0000 Date: Fri, 20 Dec 2013 10:20:35 +0000
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Range: npt=30.87-634.10 Range: npt=30.87-634.10
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 6 CSeq: 6
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Range: npt=30.87-634.10 Range: npt=30.87-634.10
Seek-Style: Next Seek-Style: Next
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 6 CSeq: 6
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:22:13 +0000 Date: Fri, 20 Dec 2013 10:22:13 +0000
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Range: npt=30.87-634.10 Range: npt=30.87-634.10
Seek-Style: Next Seek-Style: Next
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12555;rtptime=6330012, ssrc=0D12F123:seq=12555;rtptime=6330012,
url="rtsp://example.com/twister.3gp/trackID=1" url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=55021;rtptime=3132889 ssrc=4F312DD8:seq=55021;rtptime=3132889
C->M: TEARDOWN rtsp://example.com/twister.3gp/ RTSP/2.0 C->M: TEARDOWN rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 7 CSeq: 7
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 7 CSeq: 7
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:31:53 +0000 Date: Fri, 20 Dec 2013 10:31:53 +0000
A.2. Media on Demand Using Pipelining A.2. Media on Demand Using Pipelining
This example is basically the example above (Appendix A.1), but now This example is basically the example above (Appendix A.1), but now
utilizing pipelining to speed up the setup. It requires only two utilizing pipelining to speed up the setup. It requires only two
skipping to change at page 249, line 35 skipping to change at page 250, line 35
Seek-Style: RAP Seek-Style: RAP
Pipelined-Requests: 7654 Pipelined-Requests: 7654
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/AVP;unicast; Transport: RTP/AVP;unicast;
dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; dest_addr="192.0.2.53:8000"/"192.0.2.53:8001";
src_addr="198.51.100.5:9000"/"198.51.100.5:9001"; src_addr="198.51.100.5:9000"/"198.51.100.5:9001";
ssrc=93CB001E ssrc=93CB001E
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:20:32 +0000 Expires: Fri, 20 Dec 2013 12:20:32 +0000
Date: Fri, 20 Dec 2013 10:20:32 +0000 Date: Fri, 20 Dec 2013 10:20:32 +0000
Accept-Ranges: npt Accept-Ranges: npt
Pipelined-Requests: 7654 Pipelined-Requests: 7654
Media-Properties: Random-Access=0.2, Immutable, Unlimited Media-Properties: Random-Access=0.2, Immutable, Unlimited
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/AVP;unicast; Transport: RTP/AVP;unicast;
dest_addr="192.0.2.53:8002"/"192.0.2.53:8003; dest_addr="192.0.2.53:8002"/"192.0.2.53:8003;
src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; src_addr="198.51.100.5:9002"/"198.51.100.5:9003";
ssrc=A813FC13 ssrc=A813FC13
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Expires: Sat, 21 Dec 2013 10:20:32 +0000 Expires: Sat, 21 Dec 2013 10:20:32 +0000
Date: Fri, 20 Dec 2013 10:20:32 +0000 Date: Fri, 20 Dec 2013 10:20:32 +0000
Accept-Range: NPT Accept-Range: NPT
Pipelined-Requests: 7654 Pipelined-Requests: 7654
Media-Properties: Random-Access=0.8, Immutable, Unlimited Media-Properties: Random-Access=0.8, Immutable, Unlimited
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 4 CSeq: 4
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:20:32 +0000 Date: Fri, 20 Dec 2013 10:20:32 +0000
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Range: npt=0-623.10 Range: npt=0-623.10
Seek-Style: RAP Seek-Style: RAP
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012, ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsp://example.com/twister.3gp/trackID=1" url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889 ssrc=4F312DD8:seq=54321;rtptime=2876889
Pipelined-Requests: 7654 Pipelined-Requests: 7654
A.3. Secured Media Session for On-Demand Content A.3. Secured Media Session for On-Demand Content
This example is basically the above example (Appendix A.2), but now This example is basically the above example (Appendix A.2), but now
including establishment of SRTP crypto contexts to get a secured including establishment of SRTP crypto contexts to get a secured
media delivery. First of all, the client attempts to fetch this media delivery. First of all, the client attempts to fetch this
insecurely, but the server redirects to a URI indicating a insecurely, but the server redirects to a URI indicating a
requirement on using a secure connection for the RTSP messages. The requirement on using a secure connection for the RTSP messages. The
client establishes a TCP/TLS connection, and the session description client establishes a TCP/TLS connection, and the session description
is retrieved to determine what media resources need to be set up. In is retrieved to determine what media resources need to be set up. In
the this session description, secure media (SRTP) is indicated. In the this session description, secure media (SRTP) is indicated. In
the next step, the client sends the necessary SETUP requests the next step, the client sends the necessary SETUP requests
including MIKEY messages. This is pipeline with a PLAY request to including MIKEY messages. This is pipelined with a PLAY request to
initiate media delivery. initiate media delivery.
Client C requests a presentation from media server M. The movie is Client C requests a presentation from media server M. The movie is
stored in a container file. The client has obtained an RTSP URI to stored in a container file. The client has obtained an RTSP URI to
the container file. the container file.
Note: The MIKEY messages below are not valid MIKEY messages and are Note: The MIKEY messages below are not valid MIKEY messages and are
Base64-encoded random data to represent where the MIKEY messages Base64-encoded random data to represent where the MIKEY messages
would go. would go.
skipping to change at page 252, line 20 skipping to change at page 253, line 20
Pipelined-Requests: 7654 Pipelined-Requests: 7654
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/SAVP;unicast; Transport: RTP/SAVP;unicast;
dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; dest_addr="192.0.2.53:8000"/"192.0.2.53:8001";
src_addr="198.51.100.5:9000"/"198.51.100.5:9001"; src_addr="198.51.100.5:9000"/"198.51.100.5:9001";
ssrc=93CB001E; ssrc=93CB001E;
MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD0x MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD0x
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:25:34 +0000 Expires: Fri, 20 Dec 2013 12:25:34 +0000
Date: Fri, 20 Dec 2013 10:25:34 +0000 Date: Fri, 20 Dec 2013 10:25:34 +0000
Accept-Ranges: npt Accept-Ranges: npt
Pipelined-Requests: 7654 Pipelined-Requests: 7654
Media-Properties: Random-Access=0.2, Immutable, Unlimited Media-Properties: Random-Access=0.2, Immutable, Unlimited
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 4 CSeq: 4
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/SAVP;unicast; Transport: RTP/SAVP;unicast;
dest_addr="192.0.2.53:8002"/"192.0.2.53:8003; dest_addr="192.0.2.53:8002"/"192.0.2.53:8003;
src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; src_addr="198.51.100.5:9002"/"198.51.100.5:9003";
ssrc=A813FC13; ssrc=A813FC13;
MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD00 MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD00
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:25:34 +0000 Expires: Fri, 20 Dec 2013 12:25:34 +0000
Date: Fri, 20 Dec 2013 10:25:34 +0000 Date: Fri, 20 Dec 2013 10:25:34 +0000
Accept-Range: NPT Accept-Range: NPT
Pipelined-Requests: 7654 Pipelined-Requests: 7654
Media-Properties: Random-Access=0.8, Immutable, Unlimited Media-Properties: Random-Access=0.8, Immutable, Unlimited
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 5 CSeq: 5
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:25:34 +0000 Date: Fri, 20 Dec 2013 10:25:34 +0000
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Range: npt=0-623.10 Range: npt=0-623.10
Seek-Style: RAP Seek-Style: RAP
RTP-Info: url="rtsps://example.com/twister.3gp/trackID=4" RTP-Info: url="rtsps://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012, ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsps://example.com/twister.3gp/trackID=1" url="rtsps://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889; ssrc=4F312DD8:seq=54321;rtptime=2876889;
Pipelined-Requests: 7654 Pipelined-Requests: 7654
A.4. Media on Demand (Unicast) A.4. Media on Demand (Unicast)
An alternative example of media on demand with a few more tweaks is An alternative example of media on demand with a few more tweaks is
the following. Client C requests a movie distributed from two the following. Client C requests a movie distributed from two
different media servers A (audio.example.com) and V different media servers A (audio.example.com) and V
(video.example.com). The media description is stored on a web server (video.example.com). The media description is stored on a web server
W. The media description contains descriptions of the presentation W. The media description contains descriptions of the presentation
and all its streams, including the codecs that are available, dynamic and all its streams, including the codecs that are available and the
RTP payload types, the protocol stack, and content information such protocol stack.
as language or copyright restrictions. It may also give an
indication about the timeline of the movie.
In this example, the client is only interested in the last part of In this example, the client is only interested in the last part of
the movie. the movie.
C->W: GET /twister.sdp HTTP/1.1 C->W: GET /twister.sdp HTTP/1.1
Host: www.example.com Host: www.example.com
Accept: application/sdp Accept: application/sdp
W->C: HTTP/1.1 200 OK W->C: HTTP/1.1 200 OK
Date: Wed, 23 Jan 2013 15:35:06 GMT Date: Wed, 23 Jan 2013 15:35:06 GMT
skipping to change at page 254, line 36 skipping to change at page 255, line 36
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057", Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057",
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: npt, smpte, clock Accept-Ranges: npt, smpte, clock
A->C: RTSP/2.0 200 OK A->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Transport: RTP/AVP/UDP;unicast; Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; dest_addr="192.0.2.53:3056"/"192.0.2.53:3057";
src_addr="198.51.100.5:5000"/"198.51.100.5:5001" src_addr="198.51.100.5:5000"/"198.51.100.5:5001"
Date: Wed, 23 Jan 2013 15:35:12 +0000 Date: Wed, 23 Jan 2013 15:35:12 +0000
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Expires: Thu, 24 Jan 2013 15:35:12 +0000 Expires: Thu, 24 Jan 2013 15:35:12 +0000
Cache-Control: public Cache-Control: public
Accept-Ranges: npt, smpte Accept-Ranges: npt, smpte
Media-Properties: Random-Access=0.02, Immutable, Unlimited Media-Properties: Random-Access=0.02, Immutable, Unlimited
C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0 C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast; Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3058"/"192.0.2.53:3059", dest_addr="192.0.2.53:3058"/"192.0.2.53:3059",
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: npt, smpte, clock Accept-Ranges: npt, smpte, clock
V->C: RTSP/2.0 200 OK V->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Session: 23456789 Session: P5it3pMo6xHkjUcDrNkBjf
Transport: RTP/AVP/UDP;unicast; Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3058"/"192.0.2.53:3059"; dest_addr="192.0.2.53:3058"/"192.0.2.53:3059";
src_addr="198.51.100.5:5002"/"198.51.100.5:5003" src_addr="198.51.100.5:5002"/"198.51.100.5:5003"
Date: Wed, 23 Jan 2013 15:35:12 +0000 Date: Wed, 23 Jan 2013 15:35:12 +0000
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Cache-Control: public Cache-Control: public
Expires: Thu, 24 Jan 2013 15:35:12 +0000 Expires: Thu, 24 Jan 2013 15:35:12 +0000
Accept-Ranges: npt, smpte Accept-Ranges: npt, smpte
Media-Properties: Random-Access=1.2, Immutable, Unlimited Media-Properties: Random-Access=1.2, Immutable, Unlimited
C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0 C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 2 CSeq: 2
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 23456789 Session: P5it3pMo6xHkjUcDrNkBjf
Range: smpte=0:10:00- Range: smpte=0:10:00-
V->C: RTSP/2.0 200 OK V->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Session: 23456789 Session: P5it3pMo6xHkjUcDrNkBjf
Range: smpte=0:10:00-1:49:23 Range: smpte=0:10:00-1:49:23
Seek-Style: First-Prior Seek-Style: First-Prior
RTP-Info: url="rtsp://video.example.com/twister/video" RTP-Info: url="rtsp://video.example.com/twister/video"
ssrc=A17E189D:seq=12312232;rtptime=78712811 ssrc=A17E189D:seq=12312232;rtptime=78712811
Server: PhonyServer/2.0 Server: PhonyServer/2.0
Date: Wed, 23 Jan 2013 15:35:13 +0000 Date: Wed, 23 Jan 2013 15:35:13 +0000
C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 2 CSeq: 2
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Range: smpte=0:10:00- Range: smpte=0:10:00-
A->C: RTSP/2.0 200 OK A->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Range: smpte=0:10:00-1:49:23 Range: smpte=0:10:00-1:49:23
Seek-Style: First-Prior Seek-Style: First-Prior
RTP-Info: url="rtsp://audio.example.com/twister/audio.en" RTP-Info: url="rtsp://audio.example.com/twister/audio.en"
ssrc=3D124F01:seq=876655;rtptime=1032181 ssrc=3D124F01:seq=876655;rtptime=1032181
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:35:13 +0000 Date: Wed, 23 Jan 2013 15:35:13 +0000
C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
A->C: RTSP/2.0 200 OK A->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000 Date: Wed, 23 Jan 2013 15:36:52 +0000
C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 23456789 Session: P5it3pMo6xHkjUcDrNkBjf
V->C: RTSP/2.0 200 OK V->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/2.0 Server: PhonyServer/2.0
Date: Wed, 23 Jan 2013 15:36:52 +0000 Date: Wed, 23 Jan 2013 15:36:52 +0000
Even though the audio and video track are on two different servers Even though the audio and video track are on two different servers
that may start at slightly different times and may drift with respect that may start at slightly different times and may drift with respect
to each other over time, the client can perform initial to each other over time, the client can perform initial
synchronization of the two media using RTP-Info and Range received in synchronization of the two media using RTP-Info and Range received in
skipping to change at page 258, line 18 skipping to change at page 259, line 18
CSeq: 2 CSeq: 2
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Accept-Ranges: npt, smpte, clock Accept-Ranges: npt, smpte, clock
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
Transport: RTP/AVP/UDP;unicast; Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:6970"/"192.0.2.53:6971"; dest_addr="192.0.2.53:6970"/"192.0.2.53:6971";
src_addr="198.51.100.5:6970"/"198.51.100.5:6971"; src_addr="198.51.100.5:6970"/"198.51.100.5:6971";
mode="PLAY";ssrc=EAB98712 mode="PLAY";ssrc=EAB98712
CSeq: 2 CSeq: 2
Session: 2034820394 Session: NYkqQYKk0bb12BY3goyoyO
Expires: Thu, 24 Jan 2013 15:36:52 +0000 Expires: Thu, 24 Jan 2013 15:36:52 +0000
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000 Date: Wed, 23 Jan 2013 15:36:52 +0000
Accept-Ranges: npt Accept-Ranges: npt
Media-Properties: Random-Access=0.5, Immutable, Unlimited Media-Properties: Random-Access=0.5, Immutable, Unlimited
C->S: PLAY rtsp://foo.example.com/test.wav/ RTSP/2.0 C->S: PLAY rtsp://foo.example.com/test.wav/ RTSP/2.0
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 2034820394 Session: NYkqQYKk0bb12BY3goyoyO
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000 Date: Wed, 23 Jan 2013 15:36:52 +0000
Session: 2034820394 Session: NYkqQYKk0bb12BY3goyoyO
Range: npt=0-600 Range: npt=0-600
Seek-Style: RAP Seek-Style: RAP
RTP-Info: url="rtsp://foo.example.com/test.wav/streamid=0" RTP-Info: url="rtsp://foo.example.com/test.wav/streamid=0"
ssrc=0D12F123:seq=981888;rtptime=3781123 ssrc=0D12F123:seq=981888;rtptime=3781123
Note the different URI in the SETUP command and then the switch back Note the different URI in the SETUP command and then the switch back
to the aggregate URI in the PLAY command. This makes complete sense to the aggregate URI in the PLAY command. This makes complete sense
when there are multiple streams with aggregate control, but it is when there are multiple streams with aggregate control, but it is
less than intuitive in the special case where the number of streams less than intuitive in the special case where the number of streams
is one. However, the server has declared the aggregated control URI is one. However, the server has declared the aggregated control URI
in the SDP; therefore, this is legal. in the SDP; therefore, this is legal.
In this case, it is also required that servers accept implementations In this case, it is also required that servers accept implementations
that use the non-aggregated interpretation and use the individual that use the non-aggregated interpretation and use the individual
media URI, like this: media URI, like this:
C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0 C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 2034820394 Session: NYkqQYKk0bb12BY3goyoyO
A.6. Live Media Presentation Using Multicast A.6. Live Media Presentation Using Multicast
The media server M chooses the multicast address and port. Here, it The media server M chooses the multicast address and port. Here, it
is assumed that the web server only contains a pointer to the full is assumed that the web server only contains a pointer to the full
description, while the media server M maintains the full description. description, while the media server M maintains the full description.
C->W: GET /sessions.html HTTP/1.1 C->W: GET /sessions.html HTTP/1.1
Host: www.example.com Host: www.example.com
skipping to change at page 260, line 19 skipping to change at page 261, line 19
Accept-Ranges: npt, smpte, clock Accept-Ranges: npt, smpte, clock
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000 Date: Wed, 23 Jan 2013 15:36:52 +0000
Transport: RTP/AVP;multicast; Transport: RTP/AVP;multicast;
dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16 dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16
;ssrc=4D12AB92/0DF876A3 ;ssrc=4D12AB92/0DF876A3
Session: 0456804596 Session: qHj4jidpmF6zy9v9tNbtxr
Accept-Ranges: npt, clock Accept-Ranges: npt, clock
Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0 Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0
C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 3 CSeq: 3
Session: 0456804596 Session: qHj4jidpmF6zy9v9tNbtxr
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000 Date: Wed, 23 Jan 2013 15:36:52 +0000
Session: 0456804596 Session: qHj4jidpmF6zy9v9tNbtxr
Seek-Style: Next Seek-Style: Next
Range:npt=1256- Range:npt=1256-
RTP-Info: url="rtsp://live.example.com/concert/audio" RTP-Info: url="rtsp://live.example.com/concert/audio"
ssrc=0D12F123:seq=1473; rtptime=80000 ssrc=0D12F123:seq=1473; rtptime=80000
A.7. Capability Negotiation A.7. Capability Negotiation
This example illustrates how the client and server determine their This example illustrates how the client and server determine their
capability to support a special feature, in this case, "play.scale". capability to support a special feature, in this case, "play.scale".
The server, through the client request and the included Supported The server, through the client request and the included Supported
skipping to change at page 261, line 33 skipping to change at page 262, line 33
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast; Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3056"/"192.0.2.53:3057", dest_addr="192.0.2.53:3056"/"192.0.2.53:3057",
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
Require: play.scale Require: play.scale
Accept-Ranges: npt, smpte, clock Accept-Ranges: npt, smpte, clock
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: 3 CSeq: 3
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Transport: RTP/AVP/UDP;unicast; Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; dest_addr="192.0.2.53:3056"/"192.0.2.53:3057";
src_addr="198.51.100.5:5000"/"198.51.100.5:5001" src_addr="198.51.100.5:5000"/"198.51.100.5:5001"
Server: PhonyServer/2.0 Server: PhonyServer/2.0
Accept-Ranges: npt, smpte Accept-Ranges: npt, smpte
Media-Properties: Random-Access=0.8, Immutable, Unlimited Media-Properties: Random-Access=0.8, Immutable, Unlimited
Appendix B. RTSP Protocol State Machine Appendix B. RTSP Protocol State Machine
The RTSP session state machine describes the behavior of the protocol The RTSP session state machine describes the behavior of the protocol
skipping to change at page 264, line 52 skipping to change at page 265, line 52
| | | | | | | | | |
| S -> C: REDIRECT | No Session hdr | Init | Terminate all SES | | S -> C: REDIRECT | No Session hdr | Init | Terminate all SES |
+------------------+----------------+-----------+-------------------+ +------------------+----------------+-----------+-------------------+
Table 14: State: Init Table 14: State: Init
The initial state of the state machine (Table 14) can only be left by The initial state of the state machine (Table 14) can only be left by
processing a correct SETUP request. As seen in the table, the two processing a correct SETUP request. As seen in the table, the two
state variables are also set by a correct request. This table also state variables are also set by a correct request. This table also
shows that a correct SETUP can in some cases be redirected to another shows that a correct SETUP can in some cases be redirected to another
URI and/or server by a 3rr response. URI or server by a 3rr response.
+-------------+------------------------+---------+------------------+ +-------------+------------------------+---------+------------------+
| Action | Requisite | New | Response | | Action | Requisite | New | Response |
| | | State | | | | | State | |
+-------------+------------------------+---------+------------------+ +-------------+------------------------+---------+------------------+
| SETUP | New URI | Ready | NRM +=1 | | SETUP | New URI | Ready | NRM +=1 |
| | | | | | | | | |
| SETUP | URI Setup prior | Ready | Change transport | | SETUP | URI Setup prior | Ready | Change transport |
| | | | param | | | | | param |
| | | | | | | | | |
skipping to change at page 266, line 37 skipping to change at page 267, line 37
| PLAY | Prs URI, No range | Play | Play from | | PLAY | Prs URI, No range | Play | Play from |
| | | | present point | | | | | present point |
| | | | | | | | | |
| PLAY | Prs URI, Range | Play | According to | | PLAY | Prs URI, Range | Play | According to |
| | | | range | | | | | range |
| | | | | | | | | |
| SC:PLAY_NOTIFY | | Play | 200 | | SC:PLAY_NOTIFY | | Play | 200 |
| | | | | | | | | |
| SETUP | New URI | Play | 455 | | SETUP | New URI | Play | 455 |
| | | | | | | | | |
| SETUP | Session Bound URI | Play | 455 | | SETUP | md URI | Play | 455 |
| | | | | | | | | |
| SETUP | Session Bound URI, | Play | Change | | SETUP | md URI, IFI | Play | Change |
| | IFI | | transport | | | | | transport |
| | | | param. | | | | | param. |
| | | | | | | | | |
| TEARDOWN | Prs URI | Init | No session hdr | | TEARDOWN | Prs URI | Init | No session hdr |
| | | | | | | | | |
| TEARDOWN | md URI,NRM=1 | Init | No Session hdr, | | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, |
| | | | NRM=0 | | | | | NRM=0 |
| | | | | | | | | |
| TEARDOWN | md URI | Play | 455 | | TEARDOWN | md URI | Play | 455 |
| | | | | | | | | |
| SC:REDIRECT | Terminate Reason with | Play | Set RedP | | SC:REDIRECT | Terminate Reason with | Play | Set RedP |
skipping to change at page 267, line 31 skipping to change at page 268, line 31
than one media stream. than one media stream.
To avoid inconsistencies between the client and server, automatic To avoid inconsistencies between the client and server, automatic
state transitions are avoided. This can be seen at, for example, an state transitions are avoided. This can be seen at, for example, an
"End of media" event when all media has finished playing but the "End of media" event when all media has finished playing but the
session still remains in Play state. An explicit PAUSE request needs session still remains in Play state. An explicit PAUSE request needs
to be sent to change the state to Ready. It may appear that there to be sent to change the state to Ready. It may appear that there
exist automatic transitions in "RedP reached" and "PP reached". exist automatic transitions in "RedP reached" and "PP reached".
However, they are requested and acknowledged before they take place. However, they are requested and acknowledged before they take place.
The time at which the transition will happen is known by looking at The time at which the transition will happen is known by looking at
the Range header. If the client sends a request close in time to the Terminate-Reason header's time parameter and Range header,
these transitions, it needs to be prepared for receiving error respectively. If the client sends a request close in time to these
messages, as the state may or may not have changed. transitions, it needs to be prepared for receiving error messages, as
the state may or may not have changed.
Appendix C. Media-Transport Alternatives Appendix C. Media-Transport Alternatives
This section defines how certain combinations of protocols, profiles, This section defines how certain combinations of protocols, profiles,
and lower transports are used. This includes the usage of the and lower transports are used. This includes the usage of the
Transport header's source and destination address parameters: Transport header's source and destination address parameters:
"src_addr" and "dest_addr". "src_addr" and "dest_addr".
C.1. RTP C.1. RTP
skipping to change at page 279, line 12 skipping to change at page 280, line 12
setup=active;connection=new setup=active;connection=new
Accept-Ranges: npt, smpte, clock Accept-Ranges: npt, smpte, clock
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/AVP/TCP;unicast; Transport: RTP/AVP/TCP;unicast;
dest_addr=":9"/":9"; dest_addr=":9"/":9";
src_addr="198.51.100.5:53478"/"198.51.100:54091"; src_addr="198.51.100.5:53478"/"198.51.100:54091";
setup=passive;connection=new;ssrc=93CB001E setup=passive;connection=new;ssrc=93CB001E
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Expires: Thu, 24 Jan 2013 15:36:52 +0000 Expires: Thu, 24 Jan 2013 15:36:52 +0000
Date: Wed, 23 Jan 2013 15:36:52 +0000 Date: Wed, 23 Jan 2013 15:36:52 +0000
Accept-Ranges: npt Accept-Ranges: npt
Media-Properties: Random-Access=0.8, Immutable, Unlimited Media-Properties: Random-Access=0.8, Immutable, Unlimited
C->M: TCP Connection Establishment x2 C->M: TCP Connection Establishment x2
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4 CSeq: 4
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Range: npt=30- Range: npt=30-
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 4 CSeq: 4
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:54 +0000 Date: Wed, 23 Jan 2013 15:36:54 +0000
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Range: npt=30-623.10 Range: npt=30-623.10
Seek-Style: First-Prior Seek-Style: First-Prior
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1" RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889 ssrc=4F312DD8:seq=54321;rtptime=2876889
C.3. Handling Media-Clock Time Jumps in the RTP Media Layer C.3. Handling Media-Clock Time Jumps in the RTP Media Layer
RTSP allows media clients to control selected, non-contiguous RTSP allows media clients to control selected, non-contiguous
sections of media presentations, rendering those streams with an RTP sections of media presentations, rendering those streams with an RTP
media layer [RFC3550]. Two cases occur, the first is when a new PLAY media layer [RFC3550]. Two cases occur, the first is when a new PLAY
request replaces an old ongoing request and the new request results request replaces an old ongoing request and the new request results
in a jump in the media. This should produce in the RTP layer a in a jump in the media. This should produce continuous media stream
continuous media stream. A client may also directly follow a at the RTP layer. A client may also immediately follow a completed
completed PLAY request perform a new PLAY request. This will result PLAY request with a new PLAY request. This will result in some gap
in some gap in the media layer. The below text will look into both in the media layer. The below text will look into both cases.
cases.
A PLAY request that replaces an ongoing PLAY request allows the media A PLAY request that replaces an ongoing PLAY request allows the media
layer rendering the RTP stream to do so continuously without being layer rendering the RTP stream to do so continuously without being
affected by jumps in media-clock time. The RTP timestamps for the affected by jumps in media-clock time. The RTP timestamps for the
new media range are set so that they become continuous with the new media range are set so that they become continuous with the
previous media range in the previous request. The RTP sequence previous media range in the previous request. The RTP sequence
number for the first packet in the new range will be the next number for the first packet in the new range will be the next
following the last packet in the previous range, i.e., monotonically following the last packet in the previous range, i.e., monotonically
increasing. The goal is to allow the media-rendering layer to work increasing. The goal is to allow the media-rendering layer to work
without interruption or reconfiguration across the jumps in media without interruption or reconfiguration across the jumps in media
skipping to change at page 280, line 40 skipping to change at page 281, line 39
delivery. Note also that in this case the RTP sequence number should delivery. Note also that in this case the RTP sequence number should
be the next packet number. If not, the RTCP packet loss reporting be the next packet number. If not, the RTCP packet loss reporting
will indicate as loss all packets not received between the point of will indicate as loss all packets not received between the point of
pausing and later resuming. This may trigger congestion avoidance pausing and later resuming. This may trigger congestion avoidance
mechanisms. An allowed exception from the above recommendation on mechanisms. An allowed exception from the above recommendation on
monotonically increasing RTP sequence number is live media streams, monotonically increasing RTP sequence number is live media streams,
likely being relayed. In this case, when the client resumes likely being relayed. In this case, when the client resumes
delivery, it will get the media that is currently being delivered to delivery, it will get the media that is currently being delivered to
the server itself. For this type of basic delivery of live streams the server itself. For this type of basic delivery of live streams
to multiple users over unicast, individual rewriting of RTP sequence to multiple users over unicast, individual rewriting of RTP sequence
numbers becomes quite a burden. For solutions that anyway caches numbers becomes quite a burden. For solutions that already cache
media, timeshifts, etc, the rewriting should be a minor issue. media or perform time shifting, the rewriting should impose only a
minor burden.
The goal when handling jumps in media-clock time is that the provided The goal when handling jumps in media-clock time is that the provided
stream is continuous without gaps in RTP timestamp or sequence stream is continuous without gaps in RTP timestamp or sequence
number. However, when delivery has been halted for some reason, the number. However, when delivery has been halted for some reason, the
RTP timestamp, when resuming, MUST represent the duration that the RTP timestamp, when resuming, MUST represent the duration that the
delivery was halted. An RTP sequence number MUST generally be the delivery was halted. An RTP sequence number MUST generally be the
next number, i.e., monotonically increasing modulo 65536. For media next number, i.e., monotonically increasing modulo 65536. For media
resources with the properties Time-Progressing and Time-Duration=0.0, resources with the properties Time-Progressing and Time-Duration=0.0,
the server MAY create RTP media streams with RTP sequence number the server MAY create RTP media streams with RTP sequence number
jumps in them due to the client first halting delivery and later jumps in them due to the client first halting delivery and later
skipping to change at page 281, line 27 skipping to change at page 282, line 27
agent may believe later packets to be duplicates of packets just agent may believe later packets to be duplicates of packets just
played out. Having the RTP timestamp jump will also affect the played out. Having the RTP timestamp jump will also affect the
RTCP measurements based on this. RTCP measurements based on this.
As an example, assume an RTP timestamp frequency of 8000 Hz, a As an example, assume an RTP timestamp frequency of 8000 Hz, a
packetization interval of 100 ms, and an initial sequence number and packetization interval of 100 ms, and an initial sequence number and
timestamp of zero. timestamp of zero.
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 4 CSeq: 4
Session: abcdefgh Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10-15 Range: npt=10-15
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: 4 CSeq: 4
Session: abcdefgh Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10-15 Range: npt=10-15
RTP-Info: url="rtsp://example.com/fizzle/audiotrack" RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=0;rtptime=0 ssrc=0D12F123:seq=0;rtptime=0
The ensuing RTP data stream is depicted below: The ensuing RTP data stream is depicted below:
S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s
S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s
. . . . . .
S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s
skipping to change at page 282, line 12 skipping to change at page 283, line 12
Upon the completion of the requested delivery, the server sends a Upon the completion of the requested delivery, the server sends a
PLAY_NOTIFY. PLAY_NOTIFY.
S->C: PLAY_NOTIFY rtsp://example.com/fizzle RTSP/2.0 S->C: PLAY_NOTIFY rtsp://example.com/fizzle RTSP/2.0
CSeq: 5 CSeq: 5
Notify-Reason: end-of-stream Notify-Reason: end-of-stream
Request-Status: cseq=4 status=200 reason="OK" Request-Status: cseq=4 status=200 reason="OK"
Range: npt=-15 Range: npt=-15
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=49;rtptime=39200 ssrc=0D12F123:seq=49;rtptime=39200
Session: abcdefgh Session: ymIqLXufHkMHGdtENdblWK
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 5 CSeq: 5
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Upon the completion of the play range, the client follows up with a Upon the completion of the play range, the client follows up with a
request to PLAY from a new NPT. request to PLAY from a new NPT.
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 6 CSeq: 6
Session: abcdefg Session: ymIqLXufHkMHGdtENdblWK
Range: npt=18-20 Range: npt=18-20
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: 6 CSeq: 6
Session: abcdefg Session: ymIqLXufHkMHGdtENdblWK
Range: npt=18-20 Range: npt=18-20
RTP-Info: url="rtsp://example.com/fizzle/audiotrack" RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=50;rtptime=40100 ssrc=0D12F123:seq=50;rtptime=40100
The ensuing RTP data stream is depicted below: The ensuing RTP data stream is depicted below:
S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s
S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s
. . . . . .
S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s
skipping to change at page 283, line 34 skipping to change at page 284, line 34
timestamp space allows the same timestamp model for both stored timestamp space allows the same timestamp model for both stored
and live media and allows better opportunity to integrate both and live media and allows better opportunity to integrate both
types of media under a single control. types of media under a single control.
As an example, assume a clock frequency of 8000 Hz, a packetization As an example, assume a clock frequency of 8000 Hz, a packetization
interval of 100 ms, and an initial sequence number and timestamp of interval of 100 ms, and an initial sequence number and timestamp of
zero. zero.
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 4 CSeq: 4
Session: abcdefg Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10-15 Range: npt=10-15
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: 4 CSeq: 4
Session: abcdefg Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10-15 Range: npt=10-15
RTP-Info: url="rtsp://example.com/fizzle/audiotrack" RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=0;rtptime=0 ssrc=0D12F123:seq=0;rtptime=0
The ensuing RTP data stream is depicted below: The ensuing RTP data stream is depicted below:
S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s
S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s
S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s
S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s
The client then sends a PAUSE request: The client then sends a PAUSE request:
C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0
CSeq: 5 CSeq: 5
Session: abcdefg Session: ymIqLXufHkMHGdtENdblWK
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: 5 CSeq: 5
Session: abcdefg Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10.4-15 Range: npt=10.4-15
20 seconds elapse and then the client sends a PLAY request. In 20 seconds elapse and then the client sends a PLAY request. In
addition, the server requires 15 ms to process the request: addition, the server requires 15 ms to process the request:
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 6 CSeq: 6
Session: abcdefg Session: ymIqLXufHkMHGdtENdblWK
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: 6 CSeq: 6
Session: abcdefg Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10.4-15 Range: npt=10.4-15
RTP-Info: url="rtsp://example.com/fizzle/audiotrack" RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=4;rtptime=164400 ssrc=0D12F123:seq=4;rtptime=164400
The ensuing RTP data stream is depicted below: The ensuing RTP data stream is depicted below:
S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s
S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s
S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s
skipping to change at page 287, line 34 skipping to change at page 288, line 34
simultaneously and a set of alternatives (e.g., two audio streams simultaneously and a set of alternatives (e.g., two audio streams
spoken in different languages). The SDP extension found in "The spoken in different languages). The SDP extension found in "The
Session Description Protocol (SDP) Grouping Framework" [RFC5888] Session Description Protocol (SDP) Grouping Framework" [RFC5888]
provides such functionality to some degree. Appendix D.4 describes provides such functionality to some degree. Appendix D.4 describes
the usage of SDP media line grouping for RTSP. the usage of SDP media line grouping for RTSP.
D.1. Definitions D.1. Definitions
The terms "session-level", "media-level", and other key/attribute The terms "session-level", "media-level", and other key/attribute
names and values used in this appendix are to be used as defined in names and values used in this appendix are to be used as defined in
SDP[RFC4566]: SDP [RFC4566]:
D.1.1. Control URI D.1.1. Control URI
The "a=control" attribute is used to convey the control URI. This The "a=control" attribute is used to convey the control URI. This
attribute is used both for the session and media descriptions. If attribute is used both for the session and media descriptions. If
used for individual media, it indicates the URI to be used for used for individual media, it indicates the URI to be used for
controlling that particular media stream. If found at the session controlling that particular media stream. If found at the session
level, the attribute indicates the URI for aggregate control level, the attribute indicates the URI for aggregate control
(presentation URI). The session-level URI MUST be different from any (presentation URI). The session-level URI MUST be different from any
media-level URI. The presence of a session-level control attribute media-level URI. The presence of a session-level control attribute
skipping to change at page 296, line 12 skipping to change at page 297, line 12
the presentation (content); for example, which media codecs are the presentation (content); for example, which media codecs are
needed for the content. Other information that is important needed for the content. Other information that is important
includes the number of media streams the presentation contains, includes the number of media streams the presentation contains,
the transport protocols used for the media streams, and the transport protocols used for the media streams, and
identifiers for these media streams. This information is identifiers for these media streams. This information is
required before setup of the content is possible and to required before setup of the content is possible and to
determine if the client is even capable of using the content. determine if the client is even capable of using the content.
This information need not be sent using RTSP; other external This information need not be sent using RTSP; other external
protocols can be used to transmit the transport presentation protocols can be used to transmit the transport presentation
descriptions. Two good examples are the use of HTTP [RFC2616] descriptions. Two good examples are the use of HTTP [RFC7230]
or email to fetch or receive presentation descriptions like SDP or email to fetch or receive presentation descriptions like SDP
[RFC4566] [RFC4566]
Setup: Set up some or all of the media streams in a presentation. Setup: Set up some or all of the media streams in a presentation.
The setup itself consists of selecting the protocol for media The setup itself consists of selecting the protocol for media
transport and the necessary parameters for the protocol, like transport and the necessary parameters for the protocol, like
addresses and ports. addresses and ports.
Control of Transmission: After the necessary media streams have been Control of Transmission: After the necessary media streams have been
established, the client can request the server to start established, the client can request the server to start
skipping to change at page 301, line 37 skipping to change at page 302, line 37
o Timestamp: See Section 18.53 o Timestamp: See Section 18.53
Appendix H. Backwards-Compatibility Considerations Appendix H. Backwards-Compatibility Considerations
This section contains notes on issues about backwards compatibility This section contains notes on issues about backwards compatibility
with clients or servers being implemented according to RFC 2326 with clients or servers being implemented according to RFC 2326
[RFC2326]. Note that there exists no requirement to implement RTSP [RFC2326]. Note that there exists no requirement to implement RTSP
1.0; in fact, this document recommends against it as it is difficult 1.0; in fact, this document recommends against it as it is difficult
to do in an interoperable way. to do in an interoperable way.
A server implementing RTSP/2.0 MUST include an RTSP-Version of A server implementing RTSP 2.0 MUST include an RTSP-Version of
RTSP/2.0 in all responses to requests containing RTSP-Version "RTSP/2.0" in all responses to requests containing RTSP-Version value
RTSP/2.0. If a server receives an RTSP/1.0 request, it MAY respond of "RTSP/2.0". If a server receives an RTSP 1.0 request, it MAY
with an RTSP/1.0 response if it chooses to support RFC 2326. If the respond with an RTSP 1.0 response if it chooses to support RFC 2326.
server chooses not to support RFC 2326, it MUST respond with a 505 If the server chooses not to support RFC 2326, it MUST respond with a
(RTSP Version Not Supported) status code. A server MUST NOT respond 505 (RTSP Version Not Supported) status code. A server MUST NOT
to an RTSP-Version RTSP/1.0 request with an RTSP-Version RTSP/2.0 respond to an RTSP 1.0 request with an RTSP 2.0 response.
response.
Clients implementing RTSP/2.0 MAY use an OPTIONS request with an Clients implementing RTSP 2.0 MAY use an OPTIONS request with an
RTSP-Version of 2.0 to determine whether a server supports RTSP/2.0. RTSP-Version of "RTSP/2.0" to determine whether a server supports
If the server responds with either an RTSP-Version of 1.0 or a status RTSP 2.0. If the server responds with either an RTSP-Version of
code of 505 (RTSP Version Not Supported), the client will have to use "RTSP/1.0" or a status code of 505 (RTSP Version Not Supported), the
RTSP/1.0 requests if it chooses to support RFC 2326. client will have to use RTSP 1.0 requests if it chooses to support
RFC 2326.
H.1. Play Request in Play State H.1. Play Request in Play State
The behavior in the server when a Play is received in Play state has The behavior in the server when a Play is received in Play state has
changed (Section 13.4). In RFC 2326, the new PLAY request would be changed (Section 13.4). In RFC 2326, the new PLAY request would be
queued until the current Play completed. Any new PLAY request now queued until the current Play completed. Any new PLAY request now
takes effect immediately replacing the previous request. takes effect immediately replacing the previous request.
H.2. Using Persistent Connections H.2. Using Persistent Connections
skipping to change at page 305, line 21 skipping to change at page 306, line 21
* Rules for how to handle the timing out RTSP messages have been * Rules for how to handle the timing out RTSP messages have been
added. added.
* Extended Pipelining rules allowing for quick session startup. * Extended Pipelining rules allowing for quick session startup.
* Sequence numbering and proxy handling of sequence numbers have * Sequence numbering and proxy handling of sequence numbers have
been defined, including cases when responses arrive out of been defined, including cases when responses arrive out of
order. order.
o The HTTP references have been updated to RFCs 2616 and 2617. Most o The HTTP references have been updated to first RFCs 2616 and 2617
of the text has been copied and then altered to fit RTSP into this and then to RFC 7230-7235. Most of the text has been copied and
specification. The Public and the Content-Base headers have also then altered to fit RTSP into this specification. The Public and
been imported from RFC 2068 so that they are defined in the RTSP the Content-Base headers have also been imported from RFC 2068 so
specification. Known effects on RTSP due to HTTP clarifications: that they are defined in the RTSP specification. Known effects on
RTSP due to HTTP clarifications:
* Content-Encoding header can include encoding of type * Content-Encoding header can include encoding of type
"identity". "identity".
o The state machine section has been completely rewritten. It now o The state machine section has been completely rewritten. It now
includes more details and is also more clear about the model used. includes more details and is also more clear about the model used.
o An IANA section has been included that contains a number of o An IANA section has been included that contains a number of
registries and their rules. This will allow us to use IANA to registries and their rules. This will allow us to use IANA to
keep track of RTSP extensions. keep track of RTSP extensions.
skipping to change at page 312, line 5 skipping to change at page 313, line 5
United States United States
Email: schulzrinne@cs.columbia.edu Email: schulzrinne@cs.columbia.edu
Anup Rao Anup Rao
Cisco Cisco
United States United States
Email: anrao@cisco.com Email: anrao@cisco.com
Rob Lanphier Rob Lanphier
Seattle, WA San Francisco, CA
United States United States
Email: robla@robla.net Email: robla@robla.net
Magnus Westerlund Magnus Westerlund
Ericsson AB Ericsson AB
Faeroegatan 6 Faeroegatan 6
Stockholm SE-164 80 Stockholm SE-164 80
Sweden Sweden
 End of changes. 433 change blocks. 
1416 lines changed or deleted 1389 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/