draft-ietf-mmusic-rfc2326bis-27.txt   draft-ietf-mmusic-rfc2326bis-28.txt 
MMUSIC Working Group H. Schulzrinne MMUSIC Working Group H. Schulzrinne
Internet-Draft Columbia University Internet-Draft Columbia University
Obsoletes: 2326 (if approved) A. Rao Obsoletes: 2326 (if approved) A. Rao
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: September 10, 2011 R. Lanphier Expires: April 30, 2012 R. Lanphier
M. Westerlund M. Westerlund
Ericsson AB Ericsson AB
M. Stiemerling (Ed.) M. Stiemerling (Ed.)
NEC NEC
March 9, 2011 October 28, 2011
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-27 draft-ietf-mmusic-rfc2326bis-28
Abstract Abstract
This memorandum defines RTSP version 2.0 which obsoletes RTSP version This memorandum defines RTSP version 2.0 which obsoletes RTSP version
1.0 which is defined in RFC 2326. 1.0 which is defined in RFC 2326.
The Real Time Streaming Protocol, or RTSP, is an application-level The Real Time Streaming Protocol, or RTSP, is an application-level
protocol for setup and control of the delivery of data with real-time protocol for setup and control of the delivery of data with real-time
properties. RTSP provides an extensible framework to enable properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and controlled, on-demand delivery of real-time data, such as audio and
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2011. This Internet-Draft will expire on April 30, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 19 skipping to change at page 4, line 19
10.7. Overload Control . . . . . . . . . . . . . . . . . . . . 56 10.7. Overload Control . . . . . . . . . . . . . . . . . . . . 56
11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 58 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 58
12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 60 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 60
13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 61 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 61
13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 62 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 62
13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 63 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 63
13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 65 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 65
13.3.1. Changing Transport Parameters . . . . . . . . . . . 68 13.3.1. Changing Transport Parameters . . . . . . . . . . . 68
13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 69 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 69
13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 69 13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 69
13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 73 13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 74
13.4.3. Updating current PLAY Requests . . . . . . . . . . . 74 13.4.3. Updating current PLAY Requests . . . . . . . . . . . 75
13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 77 13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 77
13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 77 13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 78
13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 77 13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 78
13.4.7. Playing Live with Recording . . . . . . . . . . . . 78 13.4.7. Playing Live with Recording . . . . . . . . . . . . 79
13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 79 13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 79
13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 79 13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 80
13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 80 13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 81
13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 81 13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 82
13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 82 13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 83
13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 84 13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 84
13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 86 13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 87
13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 86 13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 87
13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 87 13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 88
13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 88 13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 89
13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 89 13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 91
13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 91 13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 92
14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 94 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 95
15. Status Code Definitions . . . . . . . . . . . . . . . . . . . 96 15. Status Code Definitions . . . . . . . . . . . . . . . . . . . 97
15.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 96 15.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 97
15.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 96 15.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 97
15.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 96 15.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 97
15.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 96 15.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 97
15.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 96 15.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 97
15.3.1. 301 Moved Permanently . . . . . . . . . . . . . . . 97 15.3.1. 301 Moved Permanently . . . . . . . . . . . . . . . 98
15.3.2. 302 Found . . . . . . . . . . . . . . . . . . . . . 97 15.3.2. 302 Found . . . . . . . . . . . . . . . . . . . . . 98
15.3.3. 303 See Other . . . . . . . . . . . . . . . . . . . 97 15.3.3. 303 See Other . . . . . . . . . . . . . . . . . . . 98
15.3.4. 304 Not Modified . . . . . . . . . . . . . . . . . . 97 15.3.4. 304 Not Modified . . . . . . . . . . . . . . . . . . 98
15.3.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 98 15.3.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 99
15.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 98 15.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 99
15.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 98 15.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 99
15.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 98 15.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 99
15.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 99 15.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 100
15.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 99 15.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 100
15.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 99 15.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 100
15.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 99 15.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 100
15.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 99 15.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 100
15.4.8. 407 Proxy Authentication Required . . . . . . . . . 100 15.4.8. 407 Proxy Authentication Required . . . . . . . . . 101
15.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 100 15.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 101
15.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 100 15.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 101
15.4.11. 411 Length Required . . . . . . . . . . . . . . . . 100 15.4.11. 411 Length Required . . . . . . . . . . . . . . . . 101
15.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 101 15.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 102
15.4.13. 413 Request Message Body Too Large . . . . . . . . . 101 15.4.13. 413 Request Message Body Too Large . . . . . . . . . 102
15.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 101 15.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 102
15.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 101 15.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 102
15.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 101 15.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 102
15.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 101 15.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 102
15.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 102 15.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 103
15.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 102 15.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 103
15.4.20. 455 Method Not Valid in This State . . . . . . . . . 102 15.4.20. 455 Method Not Valid in This State . . . . . . . . . 103
15.4.21. 456 Header Field Not Valid for Resource . . . . . . 102 15.4.21. 456 Header Field Not Valid for Resource . . . . . . 103
15.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 102 15.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 103
15.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 102 15.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 103
15.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 102 15.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 103
15.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 102 15.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 103
15.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 103 15.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 104
15.4.27. 462 Destination Unreachable . . . . . . . . . . . . 103 15.4.27. 462 Destination Unreachable . . . . . . . . . . . . 104
15.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 103 15.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 104
15.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 103 15.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 104
15.4.30. 465 Notification Reason Unknown . . . . . . . . . . 103 15.4.30. 465 Notification Reason Unknown . . . . . . . . . . 104
15.4.31. 466 Key Management Error . . . . . . . . . . . . . . 103 15.4.31. 466 Key Management Error . . . . . . . . . . . . . . 104
15.4.32. 470 Connection Authorization Required . . . . . . . 104 15.4.32. 470 Connection Authorization Required . . . . . . . 105
15.4.33. 471 Connection Credentials not accepted . . . . . . 104 15.4.33. 471 Connection Credentials not accepted . . . . . . 105
15.4.34. 472 Failure to establish secure connection . . . . . 104 15.4.34. 472 Failure to establish secure connection . . . . . 105
15.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 104 15.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 105
15.5.1. 500 Internal Server Error . . . . . . . . . . . . . 104 15.5.1. 500 Internal Server Error . . . . . . . . . . . . . 105
15.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 104 15.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 105
15.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 104 15.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 105
15.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 105 15.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 106
15.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 105 15.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 106
15.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 105 15.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 106
15.5.7. 551 Option not supported . . . . . . . . . . . . . . 105 15.5.7. 551 Option not supported . . . . . . . . . . . . . . 106
16. Header Field Definitions . . . . . . . . . . . . . . . . . . 106 16. Header Field Definitions . . . . . . . . . . . . . . . . . . 107
16.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 116 16.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 117
16.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 116 16.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 117
16.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 117 16.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 118
16.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 118 16.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 119
16.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 119 16.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 120
16.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 119 16.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 120
16.7. Authorization . . . . . . . . . . . . . . . . . . . . . 119 16.7. Authorization . . . . . . . . . . . . . . . . . . . . . 120
16.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 120 16.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 121
16.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 121 16.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 122
16.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 121 16.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 122
16.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 123 16.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 125
16.12. Connection-Credentials . . . . . . . . . . . . . . . . . 124 16.12. Connection-Credentials . . . . . . . . . . . . . . . . . 125
16.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 125 16.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 126
16.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 125 16.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 126
16.15. Content-Language . . . . . . . . . . . . . . . . . . . . 126 16.15. Content-Language . . . . . . . . . . . . . . . . . . . . 127
16.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 127 16.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 128
16.17. Content-Location . . . . . . . . . . . . . . . . . . . . 127 16.17. Content-Location . . . . . . . . . . . . . . . . . . . . 128
16.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 128 16.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 129
16.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 128 16.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 129
16.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 129 16.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 130
16.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 130 16.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 131
16.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 130 16.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 131
16.23. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 131 16.23. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 132
16.24. If-Modified-Since . . . . . . . . . . . . . . . . . . . 131 16.24. If-Modified-Since . . . . . . . . . . . . . . . . . . . 132
16.25. If-None-Match . . . . . . . . . . . . . . . . . . . . . 132 16.25. If-None-Match . . . . . . . . . . . . . . . . . . . . . 133
16.26. Last-Modified . . . . . . . . . . . . . . . . . . . . . 132 16.26. Last-Modified . . . . . . . . . . . . . . . . . . . . . 134
16.27. Location . . . . . . . . . . . . . . . . . . . . . . . . 133 16.27. Location . . . . . . . . . . . . . . . . . . . . . . . . 134
16.28. Media-Properties . . . . . . . . . . . . . . . . . . . . 133 16.28. Media-Properties . . . . . . . . . . . . . . . . . . . . 134
16.29. Media-Range . . . . . . . . . . . . . . . . . . . . . . 135 16.29. Media-Range . . . . . . . . . . . . . . . . . . . . . . 136
16.30. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 136 16.30. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 137
16.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 136 16.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 137
16.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 136 16.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 137
16.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 137 16.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 139
16.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 138 16.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 139
16.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 138 16.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 139
16.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 139 16.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 140
16.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 139 16.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 141
16.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 140 16.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 141
16.39. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 142 16.39. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 143
16.40. Request-Status . . . . . . . . . . . . . . . . . . . . . 142 16.40. Request-Status . . . . . . . . . . . . . . . . . . . . . 144
16.41. Require . . . . . . . . . . . . . . . . . . . . . . . . 143 16.41. Require . . . . . . . . . . . . . . . . . . . . . . . . 144
16.42. Retry-After . . . . . . . . . . . . . . . . . . . . . . 144 16.42. Retry-After . . . . . . . . . . . . . . . . . . . . . . 145
16.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 144 16.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 145
16.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 146 16.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 148
16.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 147 16.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 149
16.46. Server . . . . . . . . . . . . . . . . . . . . . . . . . 149 16.46. Server . . . . . . . . . . . . . . . . . . . . . . . . . 150
16.47. Session . . . . . . . . . . . . . . . . . . . . . . . . 149 16.47. Session . . . . . . . . . . . . . . . . . . . . . . . . 151
16.48. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 150 16.48. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 152
16.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 151 16.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 153
16.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 152 16.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 153
16.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 152 16.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 154
16.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 153 16.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 154
16.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 160 16.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 161
16.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 160 16.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 161
16.55. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 160 16.55. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 162
16.56. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 161 16.56. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 162
16.57. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 162 16.57. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 163
17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
17.1. Proxies and Protocol Extensions . . . . . . . . . . . . 164 17.1. Proxies and Protocol Extensions . . . . . . . . . . . . 165
17.2. Multiplexing and Demultiplexing of Messages . . . . . . 165 17.2. Multiplexing and Demultiplexing of Messages . . . . . . 166
18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
18.1. Validation Model . . . . . . . . . . . . . . . . . . . . 166 18.1. Validation Model . . . . . . . . . . . . . . . . . . . . 167
18.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 168 18.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 169
18.1.2. Message Body Tag Cache Validators . . . . . . . . . 168 18.1.2. Message Body Tag Cache Validators . . . . . . . . . 169
18.1.3. Weak and Strong Validators . . . . . . . . . . . . . 168 18.1.3. Weak and Strong Validators . . . . . . . . . . . . . 169
18.1.4. Rules for When to Use Message Body Tags and 18.1.4. Rules for When to Use Message Body Tags and
Last-Modified Dates . . . . . . . . . . . . . . . . 170 Last-Modified Dates . . . . . . . . . . . . . . . . 171
18.1.5. Non-validating Conditionals . . . . . . . . . . . . 172 18.1.5. Non-validating Conditionals . . . . . . . . . . . . 173
18.2. Invalidation After Updates or Deletions . . . . . . . . 172 18.2. Invalidation After Updates or Deletions . . . . . . . . 173
19. Security Framework . . . . . . . . . . . . . . . . . . . . . 174 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 175
19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 174 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 175
19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 174 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 175
19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 175 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 176
19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 176 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 177
19.3.2. User approved TLS procedure . . . . . . . . . . . . 177 19.3.2. User approved TLS procedure . . . . . . . . . . . . 178
20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 180 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 181
20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 182 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 183
20.2.1. Generic Protocol elements . . . . . . . . . . . . . 182 20.2.1. Generic Protocol elements . . . . . . . . . . . . . 183
20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 185 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 186
20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 189 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 190
20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 198 20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 199
21. Security Considerations . . . . . . . . . . . . . . . . . . . 199 21. Security Considerations . . . . . . . . . . . . . . . . . . . 200
21.1. Remote denial of Service Attack . . . . . . . . . . . . 201 21.1. Remote denial of Service Attack . . . . . . . . . . . . 202
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 203 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 204
22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 203 22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 204
22.1.1. Description . . . . . . . . . . . . . . . . . . . . 203 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 205
22.1.2. Registering New Feature-tags with IANA . . . . . . . 204 22.1.2. Registering New Feature-tags with IANA . . . . . . . 205
22.1.3. Registered entries . . . . . . . . . . . . . . . . . 204 22.1.3. Registered entries . . . . . . . . . . . . . . . . . 205
22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 204 22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 206
22.2.1. Description . . . . . . . . . . . . . . . . . . . . 204 22.2.1. Description . . . . . . . . . . . . . . . . . . . . 206
22.2.2. Registering New Methods with IANA . . . . . . . . . 205 22.2.2. Registering New Methods with IANA . . . . . . . . . 206
22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 205 22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 206
22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 205 22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 207
22.3.1. Description . . . . . . . . . . . . . . . . . . . . 205 22.3.1. Description . . . . . . . . . . . . . . . . . . . . 207
22.3.2. Registering New Status Codes with IANA . . . . . . . 206 22.3.2. Registering New Status Codes with IANA . . . . . . . 207
22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 206 22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 207
22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 206 22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 207
22.4.1. Description . . . . . . . . . . . . . . . . . . . . 206 22.4.1. Description . . . . . . . . . . . . . . . . . . . . 207
22.4.2. Registering New Headers with IANA . . . . . . . . . 206 22.4.2. Registering New Headers with IANA . . . . . . . . . 208
22.4.3. Registered entries . . . . . . . . . . . . . . . . . 207 22.4.3. Registered entries . . . . . . . . . . . . . . . . . 208
22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 207 22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 209
22.5.1. Accept-Credentials policies . . . . . . . . . . . . 207 22.5.1. Accept-Credentials policies . . . . . . . . . . . . 209
22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 208 22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 209
22.6. Cache-Control Cache Directive Extensions . . . . . . . . 208 22.6. Cache-Control Cache Directive Extensions . . . . . . . . 210
22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 209 22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 211
22.7.1. Description . . . . . . . . . . . . . . . . . . . . 209 22.7.1. Description . . . . . . . . . . . . . . . . . . . . 211
22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 209 22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 211
22.7.3. Registered Values . . . . . . . . . . . . . . . . . 210 22.7.3. Registered Values . . . . . . . . . . . . . . . . . 211
22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 210 22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 211
22.8.1. Description . . . . . . . . . . . . . . . . . . . . 210 22.8.1. Description . . . . . . . . . . . . . . . . . . . . 211
22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 210 22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 212
22.8.3. Registered Values . . . . . . . . . . . . . . . . . 211 22.8.3. Registered Values . . . . . . . . . . . . . . . . . 212
22.9. Range header formats . . . . . . . . . . . . . . . . . . 211 22.9. Range header formats . . . . . . . . . . . . . . . . . . 212
22.9.1. Description . . . . . . . . . . . . . . . . . . . . 211 22.9.1. Description . . . . . . . . . . . . . . . . . . . . 212
22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 211 22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 212
22.9.3. Registered Values . . . . . . . . . . . . . . . . . 211 22.9.3. Registered Values . . . . . . . . . . . . . . . . . 213
22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 212 22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 213
22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 212 22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 213
22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 212 22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 213
22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 212 22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 214
22.11.1. Description . . . . . . . . . . . . . . . . . . . . 212 22.11.1. Description . . . . . . . . . . . . . . . . . . . . 214
22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 213 22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 214
22.11.3. Registered Values . . . . . . . . . . . . . . . . . 213 22.11.3. Registered Values . . . . . . . . . . . . . . . . . 214
22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 213 22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 215
22.12.1. Description . . . . . . . . . . . . . . . . . . . . 213 22.12.1. Description . . . . . . . . . . . . . . . . . . . . 215
22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 213 22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 215
22.12.3. Registered Values . . . . . . . . . . . . . . . . . 214 22.12.3. Registered Values . . . . . . . . . . . . . . . . . 215
22.13. Transport Header Registries . . . . . . . . . . . . . . 214 22.13. Transport Header Registries . . . . . . . . . . . . . . 215
22.13.1. Transport Protocol Specification . . . . . . . . . . 214 22.13.1. Transport Protocol Specification . . . . . . . . . . 216
22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 216 22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 217
22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 216 22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 217
22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 216 22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 218
22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 216 22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 218
22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 217 22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 219
22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 218 22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 220
22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 219 22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 221
22.16. Media Type Registration for text/parameters . . . . . . 220 22.16. Media Type Registration for text/parameters . . . . . . 222
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 222 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 224
23.1. Normative References . . . . . . . . . . . . . . . . . . 222 23.1. Normative References . . . . . . . . . . . . . . . . . . 224
23.2. Informative References . . . . . . . . . . . . . . . . . 224 23.2. Informative References . . . . . . . . . . . . . . . . . 226
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 227 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 229
A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 227 A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 229
A.2. Media on Demand using Pipelining . . . . . . . . . . . . 231 A.2. Media on Demand using Pipelining . . . . . . . . . . . . 233
A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 233 A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 235
A.4. Single Stream Container Files . . . . . . . . . . . . . 237 A.4. Single Stream Container Files . . . . . . . . . . . . . 239
A.5. Live Media Presentation Using Multicast . . . . . . . . 239 A.5. Live Media Presentation Using Multicast . . . . . . . . 241
A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 240 A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 242
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 242 Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 244
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 242 B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 244
B.2. State variables . . . . . . . . . . . . . . . . . . . . 242 B.2. State variables . . . . . . . . . . . . . . . . . . . . 244
B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 242 B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 244
B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 243 B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 245
Appendix C. Media Transport Alternatives . . . . . . . . . . . . 249 Appendix C. Media Transport Alternatives . . . . . . . . . . . . 251
C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 249 C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 251
C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 249 C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 251
C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 249 C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 251
C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 250 C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 252
C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 251 C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 253
C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 253 C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 255
C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 253 C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 255
C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 255 C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 257
C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 255 C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 257
C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 255 C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 257
C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 259 C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 261
C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 263 C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 265
C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 265 C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 267
C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 265 C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 267
C.7. Maintaining NPT synchronization with RTP timestamps . . 265 C.7. Maintaining NPT synchronization with RTP timestamps . . 267
C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 265 C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 267
C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 265 C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 267
C.10. Usage of SSRCs and the RTCP BYE Message During an C.10. Usage of SSRCs and the RTCP BYE Message During an
RTSP Session . . . . . . . . . . . . . . . . . . . . . . 265 RTSP Session . . . . . . . . . . . . . . . . . . . . . . 267
C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 266 C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 268
Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 267 Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 269
D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 267 D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 269
D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 267 D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 269
D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 268 D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 270
D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 269 D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 271
D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 269 D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 271
D.1.5. Directionality of media stream . . . . . . . . . . . 269 D.1.5. Directionality of media stream . . . . . . . . . . . 271
D.1.6. Range of Presentation . . . . . . . . . . . . . . . 270 D.1.6. Range of Presentation . . . . . . . . . . . . . . . 272
D.1.7. Time of Availability . . . . . . . . . . . . . . . . 271 D.1.7. Time of Availability . . . . . . . . . . . . . . . . 273
D.1.8. Connection Information . . . . . . . . . . . . . . . 271 D.1.8. Connection Information . . . . . . . . . . . . . . . 273
D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 271 D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 273
D.2. Aggregate Control Not Available . . . . . . . . . . . . 272 D.2. Aggregate Control Not Available . . . . . . . . . . . . 274
D.3. Aggregate Control Available . . . . . . . . . . . . . . 272 D.3. Aggregate Control Available . . . . . . . . . . . . . . 275
D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 273 D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 276
D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 274 D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 276
Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 275 Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 277
E.1. On-demand Playback of Stored Content . . . . . . . . . . 275 E.1. On-demand Playback of Stored Content . . . . . . . . . . 277
E.2. Unicast Distribution of Live Content . . . . . . . . . . 276 E.2. Unicast Distribution of Live Content . . . . . . . . . . 278
E.3. On-demand Playback using Multicast . . . . . . . . . . . 277 E.3. On-demand Playback using Multicast . . . . . . . . . . . 279
E.4. Inviting an RTSP server into a conference . . . . . . . 277 E.4. Inviting an RTSP server into a conference . . . . . . . 279
E.5. Live Content using Multicast . . . . . . . . . . . . . . 278 E.5. Live Content using Multicast . . . . . . . . . . . . . . 280
Appendix F. Text format for Parameters . . . . . . . . . . . . . 280 Appendix F. Text format for Parameters . . . . . . . . . . . . . 282
Appendix G. Requirements for Unreliable Transport of RTSP . . . 281 Appendix G. Requirements for Unreliable Transport of RTSP . . . 283
Appendix H. Backwards Compatibility Considerations . . . . . . . 283 Appendix H. Backwards Compatibility Considerations . . . . . . . 285
H.1. Play Request in Play State . . . . . . . . . . . . . . . 283 H.1. Play Request in Play State . . . . . . . . . . . . . . . 285
H.2. Using Persistent Connections . . . . . . . . . . . . . . 283 H.2. Using Persistent Connections . . . . . . . . . . . . . . 285
Appendix I. Open Issues . . . . . . . . . . . . . . . . . . . . 284 Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 286
Appendix J. Changes . . . . . . . . . . . . . . . . . . . . . . 285 I.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 286
J.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 285 I.2. Detailed List of Changes . . . . . . . . . . . . . . . . 287
J.2. Detailed List of Changes . . . . . . . . . . . . . . . . 286 Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 294
Appendix K. Acknowledgements . . . . . . . . . . . . . . . . . . 293 J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 294
K.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 293 Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 296
Appendix L. RFC Editor Consideration . . . . . . . . . . . . . . 295 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 297
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 296
1. Introduction 1. Introduction
This memo defines version 2.0 of the Real Time Streaming Protocol This memo defines version 2.0 of the Real Time Streaming Protocol
(RTSP 2.0). RTSP 2.0 is an application-level protocol for setup and (RTSP 2.0). RTSP 2.0 is an application-level protocol for setup and
control over the delivery of data with real-time properties, control over the delivery of data with real-time properties,
typically streaming media. Streaming media is, for instance, video typically streaming media. Streaming media is, for instance, video
on demand or audio live streaming. Put simply, RTSP acts as a on demand or audio live streaming. Put simply, RTSP acts as a
"network remote control" for multimedia servers, similar to the "network remote control" for multimedia servers, similar to the
remote control for a DVD player. remote control for a DVD player.
skipping to change at page 11, line 27 skipping to change at page 11, line 27
Clients can request information about streaming media from servers by Clients can request information about streaming media from servers by
asking for a description of the media or use media description asking for a description of the media or use media description
provided externally. The media delivery protocol is used to provided externally. The media delivery protocol is used to
establish the media streams described by the media description. establish the media streams described by the media description.
Clients can then request to play out the media, pause it, or stop it Clients can then request to play out the media, pause it, or stop it
completely, as known from DVD players remote control or media completely, as known from DVD players remote control or media
players. The requested media can consist of multiple audio and video players. The requested media can consist of multiple audio and video
streams that are delivered as a time-synchronized streams from streams that are delivered as a time-synchronized streams from
servers to clients. servers to clients.
RTSP 2.0 is a replacement of RTSP 1.0 [RFC2326] that obsoletes that RTSP 2.0 is a replacement of RTSP 1.0 [RFC2326] and obsoletes that
specification. This protocol is based on RTSP 1.0 but is not specification. This protocol is based on RTSP 1.0 but is not
backwards compatible other than in the basic version negotiation backwards compatible other than in the basic version negotiation
mechanism. The changes are documented in Appendix J. There are many mechanism. The changes are documented in Appendix I. There are many
reasons why RTSP 2.0 can't be backwards compatible with RTSP 1.0 but reasons why RTSP 2.0 can't be backwards compatible with RTSP 1.0 but
some of the main ones are: some of the main ones are:
o Most headers that needed to be extensible did not define the o Most headers that needed to be extensible did not define the
allowed syntax, preventing safe deployment of extensions; allowed syntax, preventing safe deployment of extensions;
o The changed behavior of the PLAY method when received in Play o The changed behavior of the PLAY method when received in Play
state; state;
o Changed behavior of the extensibility model and its mechanism; o Changed behavior of the extensibility model and its mechanism;
o The change of syntax for some headers. o The change of syntax for some headers.
In summary, there are so many small details that changing version In summary, there are so many small details that changing version
become necessary to enable clarification and consistent behavior. became necessary to enable clarification and consistent behavior.
This document is structured as follows. It begins with an overview This document is structured as follows. It begins with an overview
of the protocol operations and its functions in an informal way. of the protocol operations and its functions in an informal way.
Then a set of definitions of used terms and document conventions is Then a set of definitions of used terms and document conventions is
introduced. It is followed by the actual protocol specification. In introduced. It is followed by the actual RTSP 2.0 core protocol
the appendix some functionality that isn't core RTSP, but still specification. The appendixes describe and define some
important to enable some usage, is defined. RTP usage is defined in functionalities that are not part of the core RTSP specification, but
Appendix C and SDP usage with RTSP Appendix D, making these two which are still important to enable some usages. Among them, the RTP
appendixes mandatory. This is followed by a number of informational usage is defined in Appendix C and the SDP usage with RTSP is defined
parts discussing the changes, use cases, different considerations or in Appendix D, which are two mandatory appendixes. While others
motivations. include a number of informational parts discussing the changes, use
cases, different considerations or motivations.
2. Protocol Overview 2. Protocol Overview
This section provides a informative overview of the different This section provides an informative overview of the different
mechanisms in the RTSP 2.0 protocol, to give the reader a high level mechanisms in the RTSP 2.0 protocol, to give the reader a high level
understanding before getting into all the different details. In case understanding before getting into all the different details. In case
of conflict with this description and the later sections, the later of conflict with this description and the later sections, the later
sections take precedence. For more information about considered use sections take precedence. For more information about considered use
cases for RTSP see Appendix E. cases for RTSP see Appendix E.
RTSP 2.0 is a bi-directional request and response protocol that first RTSP 2.0 is a bi-directional request and response protocol that first
establishes a context including content resources (the media) and establishes a context including content resources (the media) and
then controls the delivery of these content resources from the then controls the delivery of these content resources from the
provider to the consumer. RTSP has three fundamental parts: Session provider to the consumer. RTSP has three fundamental parts: Session
skipping to change at page 13, line 29 skipping to change at page 13, line 29
described below. The protocol is based on some assumptions about described below. The protocol is based on some assumptions about
existing functionality to provide a complete solution for client existing functionality to provide a complete solution for client
controlled real-time media delivery. controlled real-time media delivery.
RTSP uses text-based messages, requests and responses, that may RTSP uses text-based messages, requests and responses, that may
contain a binary message body. An RTSP request starts with a method contain a binary message body. An RTSP request starts with a method
line that identifies the method, the protocol and version and the line that identifies the method, the protocol and version and the
resource to act on. Following the method line are a number of RTSP resource to act on. Following the method line are a number of RTSP
headers. This part is ended by two consecutive carriage return line headers. This part is ended by two consecutive carriage return line
feed (CRLF) character pairs. The message body if present follows the feed (CRLF) character pairs. The message body if present follows the
two CRLF and the body's length are described by a message header. two CRLF and the body's length is described by a message header.
RTSP responses are similar, but start with a response line with the RTSP responses are similar, but start with a response line with the
protocol and version, followed by a status code and a reason phrase. protocol and version, followed by a status code and a reason phrase.
RTSP messages are sent over a reliable transport protocol between the RTSP messages are sent over a reliable transport protocol between the
client and server. RTSP 2.0 requires clients and servers to client and server. RTSP 2.0 requires clients and servers to
implement TCP, and TLS over TCP, as mandatory transports for RTSP implement TCP, and TLS over TCP, as mandatory transports for RTSP
messages. messages.
2.1. Presentation Description 2.1. Presentation Description
RTSP exists to provide access to multi-media presentations and RTSP exists to provide access to multi-media presentations and
content, but tries to be agnostic about the media type or the actual content, but tries to be agnostic about the media type or the actual
media delivery protocol that is used. To enable a client to media delivery protocol that is used. To enable a client to
implement a complete system, an RTSP-external mechanism for implement a complete system, an RTSP-external mechanism for
describing the presentation and the delivery protocol(s) is used. describing the presentation and the delivery protocol(s) is used.
RTSP assumes that this description is either delivered completely out RTSP assumes that this description is either delivered completely out
of bands or as a data object in the response to a client's request of bands or as a data object in the response to a client's request
using the DESCRIBE method (Section 13.2). using the DESCRIBE method (Section 13.2).
Parameters that commonly have to be included in the Content Parameters that commonly have to be included in the Presentation
Description are the following: Description are the following:
o Number of media streams o 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 each media stream is to be delivered over;
o Transport protocol parameters that are not negotiated or vary with o Transport protocol parameters that are not negotiated or vary with
each client each client;
o Media encoding information enabling a client to correctly decode o Media encoding information enabling a client to correctly decode
it upon reception the media upon reception;
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. resources and aggregates under common control.
This specification describes in Appendix D how one uses SDP [RFC4566] This specification describes in Appendix D how one uses SDP [RFC4566]
for Content Description for Presentation Description
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, and also which media delivery protocol media streams are available, and also which media delivery protocol
is used and their particular resource identifiers. The RTSP session is used and their particular resource identifiers. The RTSP session
is a common context between the client and the server that consist of is a common context between the client and the server that consists
one or more media resources that are to be under common media of one or more media resources that are to be under common media
delivery control. delivery control.
The client creates an RTSP session by sending a request using the The client creates an RTSP session by sending a request using the
SETUP method (Section 13.3) to the server. In the SETUP request the SETUP method (Section 13.3) to the server. In the SETUP request the
client also includes all the transport parameters necessary to enable client also includes all the transport parameters necessary to enable
the media delivery protocol to function in the "Transport" header the media delivery protocol to function in the "Transport" header
(Section 16.52). This includes parameters that are pre-established (Section 16.52). This includes parameters that are pre-established
by the presentation description but necessary for any middlebox to by the presentation description but necessary for any middlebox to
correctly handle the media delivery protocols. The Transport header correctly handle the media delivery protocols. The Transport header
in a request may contain multiple alternatives for media delivery in in a request may contain multiple alternatives for media delivery in
a prioritized list, which the server can select from. These a prioritized list, which the server can select from. These
alternatives are typically based on information in the content alternatives are typically based on information in the presentation
description. description.
The server determines if the media resource is available upon The server determines if the media resource is available upon
receiving a SETUP request and if any of the transport parameter receiving a SETUP request and if any of the transport parameter
specifications are acceptable. If that is successful, an RTSP specifications are acceptable. If that is successful, an RTSP
session context is created and the relevant parameters and state is session context is created and the relevant parameters and state is
stored. An identifier is created for the RTSP session and included stored. An identifier is created for the RTSP session and included
in the response in the Session header (Section 16.47). The SETUP in the response in the Session header (Section 16.47). The SETUP
response includes a Transport header that specifies which of the response includes a Transport header that specifies which of the
alternatives has been selected and relevant parameters. alternatives has been selected and relevant parameters.
skipping to change at page 15, line 40 skipping to change at page 15, line 40
media resources. The Media-Range header inform the client about the media resources. The Media-Range header inform the client about the
time range of the media currently available. time range of the media currently available.
2.3. Media Delivery Control 2.3. Media Delivery Control
After having established an RTSP session, the client can start After having established an RTSP session, the client can start
controlling the media delivery. The basic operations are Start by controlling the media delivery. The basic operations are Start by
using the PLAY method (Section 13.4) and Halt by using the PAUSE using the PLAY method (Section 13.4) and Halt by using the PAUSE
method (Section 13.6). PLAY also allows for choosing the starting method (Section 13.6). PLAY also allows for choosing the starting
media position from which the server should deliver the media. The media position from which the server should deliver the media. The
positioning is done using the Range header (Section 16.38) that positioning is done by using the Range header (Section 16.38) that
supports several different time formats: Normal Play Time supports several different time formats: Normal Play Time (NPT)
(Section 4.5), SMPTE Timestamps (Section 4.4) and absolute time (Section 4.5), SMPTE Timestamps (Section 4.4) and absolute time
(Section 4.6). The Range header does further allow the client to (Section 4.6). The Range header does further allow the client to
specify a position where delivery should end, thus allowing a specify a position where delivery should end, thus allowing a
specific interval to be delivered. specific interval to be delivered.
The support for positioning/searching within a content depends on the The support for positioning/searching within a content depends on the
content's media properties. Content exists in a number of different content's media properties. Content exists in a number of different
types, such as: on-demand, live, and live with simultaneous types, such as: on-demand, live, and live with simultaneous
recording. Even within these categories there are differences in how recording. Even within these categories there are differences in how
the content is generated and distributed, which affect how it can be the content is generated and distributed, which affect how it can be
skipping to change at page 16, line 21 skipping to change at page 16, line 21
provided in full from the beginning, a live stream being recorded provided in full from the beginning, a live stream being recorded
results in the length of the accessible content growing as the results in the length of the accessible content growing as the
session goes on. There also exist content that is dynamically built session goes on. There also exist content that is dynamically built
by another protocol than RTSP and thus also changes in steps during by another protocol than RTSP and thus also changes in steps during
the session, but maybe not continuously. Furthermore, when content the session, but maybe not continuously. Furthermore, when content
is recorded, there are cases where not the complete content is is recorded, there are cases where not the complete content is
maintained, but, for example, only the last hour. All these maintained, but, for example, only the last hour. All 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.
When the client accesses on-demand content that allows random access When the client accesses on-demand content that allows random access,
in, the client can issue the PLAY request for any point in the the client can issue the PLAY request for any point in the content
content between the start and the end. The server will deliver media between the start and the end. The server will deliver media from
from the closest random access point prior to the requested point and the closest random access point prior to the requested point and
indicate that in its PLAY response. If the client issues a PAUSE, indicate that in its PLAY response. If the client issues a PAUSE,
the delivery will be halted and the point at which the server stopped the delivery will be halted and the point at which the server stopped
will be reported back in the response. The client can later resume will be reported back in the response. The client can later resume
by a sending PLAY request without a range header. When the server is by sending a PLAY request without a range header. When the server is
about to complete the PLAY request by delivering the end of the about to complete the PLAY request by delivering the end of the
content or the requested range, the server will send a PLAY_NOTIFY content or the requested range, the server will send a PLAY_NOTIFY
request indicating this. request indicating this.
When playing live content with no extra functions, such as recording, When playing live content with no extra functions, such as recording,
the client will receive the live media from the server after having the client will receive the live media from the server after having
sent a PLAY request. Seeking in such content is not possible as the sent a PLAY request. Seeking in such content is not possible as the
server does not store it, but only forwards it from the source of the server does not store it, but only forwards it from the source of the
session. Thus delivery continues until the client sends a PAUSE session. Thus delivery continues until the client sends a PAUSE
request, tears down the session, or the content ends. request, tears down the session, or the content ends.
skipping to change at page 16, line 50 skipping to change at page 16, line 50
For live sessions that are being recorded the client will need to For live sessions that are being recorded the client will need to
keep track of how the recording progresses. Upon session keep track of how the recording progresses. Upon session
establishment the client will learn the current duration of the establishment the client will learn the current duration of the
recording from the Media-Range header. As the recording is ongoing recording from the Media-Range header. As the recording is ongoing
the content grows in direct relation to the passed time. Therefore, the content grows in direct relation to the passed time. Therefore,
each server's response to a PLAY request will contain the current each server's response to a PLAY request will contain the current
Media-Range header. The server should also regularly send every 5 Media-Range header. The server should also regularly send every 5
minutes the current media range in a PLAY_NOTIFY request. If the minutes the current media range in a PLAY_NOTIFY request. If the
live transmission ends, the server must send a PLAY_NOTIFY request live transmission ends, the server must send a PLAY_NOTIFY request
with the updated Media-Properties indicating that the content stopped with the updated Media-Properties indicating that the content stopped
being a recorded live session and instead become a on-demand content; being a recorded live session and instead became on-demand content;
the request also contains the final media range. While the live the request also contains the final media range. While the live
delivery continues the client can request to play the current live delivery continues the client can request to play the current live
point by using the NPT timescale symbol "now", or it can request a point by using the NPT timescale symbol "now", or it can request a
specific point in the available content by an explicit range request specific point in the available content by an explicit range request
for that point. If the requested point is outside of the available for that point. If the requested point is outside of the available
interval the server will adjust the position to the closest available interval the server will adjust the position to the closest available
point, i.e., either at the beginning or the end. point, i.e., either at the beginning or the end.
A special case of recording is that where the recording is not A special case of recording is that where the recording is not
retained longer than a specific time period, thus as the live retained longer than a specific time period, thus as the live
skipping to change at page 18, line 7 skipping to change at page 18, line 7
2.5. Media Delivery 2.5. Media Delivery
The delivery of media to the RTSP client is done with a protocol The delivery of media to the RTSP client is done with a protocol
outside of RTSP and this protocol is determined during the session outside of RTSP and this protocol is determined during the session
establishment. This document specifies how media is delivered with establishment. This document specifies how media is delivered with
RTP over UDP, TCP or the RTSP control connection. Additional RTP over UDP, TCP or the RTSP control connection. Additional
protocols may be specified in the future based on demand. protocols may be specified in the future based on demand.
The usage of RTP as media delivery protocol requires some additional The usage of RTP as media delivery protocol requires some additional
information to function well. The PLAY response contains information information to function well. The PLAY response contains information
to enable reliable and timely deliver of how a client should to enable reliable and timely delivery of how a client should
synchronize different sources in the different RTP sessions. It also synchronize different sources in the different RTP sessions. It also
provides a mapping between RTP timestamps and the content time scale. provides a mapping between RTP timestamps and the content time scale.
When the server want to notify the client about the completion of the When the server wants to notify the client about the completion of
media delivery, it sends a PLAY_NOTIFY request to the client. The the media delivery, it sends a PLAY_NOTIFY request to the client.
PLAY_NOTIFY request includes information about the stream end, The PLAY_NOTIFY request includes information about the stream end,
including the last RTP sequence number for each stream, thus enabling including the last RTP sequence number for each stream, thus enabling
the client to empty the buffer smoothly. the client to empty the buffer smoothly.
2.5.1. Media Delivery Manipulations 2.5.1. Media Delivery Manipulations
The basic playback functionality of RTSP enables delivery of a range The basic playback functionality of RTSP enables delivery of a range
of requested content to the client at the pace intended by the of requested content to the client at the pace intended by the
content's creator. However, RTSP can also manipulate the delivery to content's creator. However, RTSP can also manipulate the delivery to
the client in two ways. the client in two ways.
skipping to change at page 18, line 47 skipping to change at page 18, line 47
Scale = 1.0 is the default value that is used if no Scale is Scale = 1.0 is the default value that is used if no Scale is
specified, i.e., playback at the content's original rate. Scale specified, i.e., playback at the content's original rate. Scale
values between 0 and 1.0 is providing for slow motion. Scale can be values between 0 and 1.0 is providing for slow motion. Scale can be
negative to allow for reverse playback in either regular pace (Scale negative to allow for reverse playback in either regular pace (Scale
= -1.0) or fast backwards (Scale < -1.0) or slow motion backwards = -1.0) or fast backwards (Scale < -1.0) or slow motion backwards
(-1.0 < Scale < 0). Scale = 0 is equal to pause and is not allowed. (-1.0 < Scale < 0). Scale = 0 is equal to pause and is not allowed.
In most cases the realization of scale means server side manipulation In most cases the realization of scale means server side manipulation
of the media to ensure that the client can actually play it back. of the media to ensure that the client can actually play it back.
These media manipulation and when they are needed are highly media- These media manipulation and when they are needed are highly media-
type dependent. Lets exemplify with two common media types audio and type dependent. Let's consider an example with two common media
video. 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. A maximum
of 10-30% is possible by changing the pitch-rate of speech. Music of 10-30% is possible by changing the pitch-rate of speech. Music
goes out of tune if one tries to manipulate the playback rate by 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 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 structured 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
skipping to change at page 22, line 35 skipping to change at page 22, line 35
aspects (except the position of the protocol version number) to aspects (except the position of the protocol version number) to
change. A new version of the protocol must be registered through change. A new version of the protocol must be registered through
an IETF standard track document. an IETF standard track document.
The basic capability discovery mechanism can be used to both discover The basic capability discovery mechanism can be used to both discover
support for a certain feature and to ensure that a feature is support for a certain feature and to ensure that a feature is
available when performing a request. For a detailed explanation of available when performing a request. For a detailed explanation of
this see Section 11. this see Section 11.
New media delivery protocols may be added and negotiated at session New media delivery protocols may be added and negotiated at session
establishment, in addition to extension to the core protocol. establishment, in addition to extensions to the core protocol.
Certain types of protocol manipulations can be done through parameter Certain types of protocol manipulations can be done through parameter
formats using SET_PARAMETER and GET_PARAMETER. formats using SET_PARAMETER and GET_PARAMETER.
3. Document Conventions 3. Document Conventions
3.1. Notational Conventions 3.1. Notational Conventions
Since a few of the definitions are identical to HTTP/1.1, this Since a few of the definitions are identical to HTTP/1.1, this
specification only points to the section where they are defined specification only points to the section where they are defined
rather than copying it. For brevity, [HX.Y] is to be taken to refer rather than copying it. For brevity, [HX.Y] is to be taken to refer
skipping to change at page 25, line 48 skipping to change at page 25, line 48
RTSP agent: Refers to either an RTSP client, an RTSP server, or an RTSP agent: Refers to either an RTSP client, an RTSP server, or an
RTSP proxy. In this specification, there are many capabilities RTSP proxy. In this specification, there are many capabilities
that are common to these three entities such as the capability to that are common to these three entities such as the capability to
send requests or receive responses. This term will be used when send requests or receive responses. This term will be used when
describing functionality that is applicable to all three of these describing functionality that is applicable to all three of these
entities. entities.
RTSP session: A stateful abstraction upon which the main control RTSP session: A stateful abstraction upon which the main control
methods of RTSP operate. An RTSP session is a common context; it methods of RTSP operate. An RTSP session is a common context; it
is created, maintained and destroyed on client's request. It is is created and maintained on client's request and can be destroyed
established by an RTSP server upon the completion of a successful by either the client or server. It is established by an RTSP
SETUP request (when a 200 OK response is sent) and is labeled with server upon the completion of a successful SETUP request (when a
a session identifier at that time. The session exists until timed 200 OK response is sent) and is labeled with a session identifier
out by the server or explicitly removed by a TEARDOWN request. An at that time. The session exists until timed out by the server or
RTSP session is a stateful entity; an RTSP server maintains an explicitly removed by a TEARDOWN request. An RTSP session is a
explicit session state machine (see Appendix B) where most state stateful entity; an RTSP server maintains an explicit session
transitions are triggered by client requests. The existence of a state machine (see Appendix B) where most state transitions are
session implies the existence of state about the session's media triggered by client requests. The existence of a session implies
streams and their respective transport mechanisms. A given the existence of state about the session's media streams and their
session can have one or more media streams associated with it. An respective transport mechanisms. A given session can have one or
RTSP server uses the session to aggregate control over multiple more media streams associated with it. An RTSP server uses the
media streams. session to aggregate control over multiple media streams.
Origin Server: The server on which a given resource resides. Origin Server: The server on which a given resource resides.
Transport initialization: The negotiation of transport information Transport initialization: The negotiation of transport information
(e.g., port numbers, transport protocols) between the client and (e.g., port numbers, transport protocols) between the client and
the server. the server.
URI: Universal Resource Identifier, see [RFC3986]. The URIs used in URI: Universal Resource Identifier, see [RFC3986]. The URIs used in
RTSP are generally URLs as they give a location for the resource. RTSP are generally URLs as they give a location for the resource.
As URLs are a subset of URIs, they will be referred to as URIs to As URLs are a subset of URIs, they will be referred to as URIs to
skipping to change at page 27, line 38 skipping to change at page 27, line 38
lower version than RTSP/2.13, which in turn is lower than RTSP/12.3. lower version than RTSP/2.13, which in turn is lower than RTSP/12.3.
Leading zeros MUST be ignored by recipients and MUST NOT be sent. Leading zeros MUST be ignored by recipients and MUST NOT be sent.
4.2. RTSP IRI and URI 4.2. RTSP IRI and URI
RTSP 2.0 defines and registers three URI schemes "rtsp", "rtsps" and RTSP 2.0 defines and registers three URI schemes "rtsp", "rtsps" and
"rtspu". The usage of the last, "rtspu", is unspecified in RTSP 2.0, "rtspu". The usage of the last, "rtspu", is unspecified in RTSP 2.0,
and is defined here to register and reserve the URI scheme that is and is defined here to register and reserve the URI scheme that is
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 (UDP in RTSP transport of the RTSP messages over unreliable transport (UDP in RTSP
1.0). A RTSP server MUST response with an error code indicating the 1.0). An RTSP server MUST response with an error code indicating the
"rtspu" scheme is not implemented (501) to a request that carries a "rtspu" scheme is not implemented (501) to a request that carries a
"rtspu" URI scheme. The details of the syntax of "rtsp" and "rtsps" "rtspu" URI scheme. The details of the syntax of "rtsp" and "rtsps"
URIs has been changed from RTSP 1.0. URIs has been changed from RTSP 1.0.
This specification also defines the format of the RTSP IRI [RFC3987] This specification also defines the format of the RTSP IRI [RFC3987]
that can be used as RTSP resource identifiers and locators, in web that can be used as RTSP resource identifiers and locators, in web
pages, user interfaces, on paper, etc. However, the RTSP request pages, user interfaces, on paper, etc. However, the RTSP request
message format only allows usage of the absolute URI format. The message format only allows usage of the absolute URI format. The
RTSP IRI format MUST use the rules and transformation for IRIs RTSP IRI format MUST use the rules and transformation for IRIs to
defined in [RFC3987]. This way RTSP 2.0 URIs for request can be URIs, as defined in [RFC3987]. This way RTSP 2.0 URIs for request
produced from an RTSP IRI. can be produced 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 ";".
The RTSP URI and IRI is case sensitive, with the exception of those The RTSP URI and IRI are case sensitive, with the exception of those
parts that [RFC3986] and [RFC3987] defines as case-insensitive; for parts that [RFC3986] and [RFC3987] defines as case-insensitive; for
example, the scheme and host part. example, the scheme and host part.
The fragment identifier is used as defined in sections 3.5 and 4.3 of The fragment identifier is used as defined in sections 3.5 and 4.3 of
[RFC3986], i.e. the fragment is to be stripped from the IRI by the [RFC3986], i.e. the fragment is to be stripped from the IRI by the
requester and not included in the request URI. The user agent needs requester and not included in the request URI. The user agent needs
to interpret the value of the fragment based on the media type the to interpret the value of the fragment based on the media type the
request relates to; i.e., the media type indicated in Content-Type request relates to; i.e., the media type indicated in Content-Type
header in the response to DESCRIBE. header in the response to DESCRIBE.
skipping to change at page 29, line 36 skipping to change at page 29, line 36
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 length 8-128 characters. A Session identifiers are strings of length 8-128 characters. A
session identifier MUST be chosen cryptographically random (see session identifier MUST be chosen cryptographically random (see
[RFC4086]) . It is RECOMMENDED that it contains 128 bits of entropy, [RFC4086]). It is RECOMMENDED that it contains 128 bits of entropy,
i.e. approximately 22 characters from a high quality generator. (see i.e. approximately 22 characters from a high quality generator (see
Section 21.) However, note that the session identifier does not Section 21). However, note that the session identifier does not
provide any security against session hijacking unless it is kept provide any security against session hijacking unless it is kept
confidential by the client, server and trusted proxies. confidential by the client, server and trusted proxies.
4.4. SMPTE Relative Timestamps 4.4. SMPTE Relative Timestamps
A SMPTE relative timestamp expresses time relative to the start of A SMPTE relative timestamp expresses time relative to the start of
the clip. Relative timestamps are expressed as SMPTE time codes for the clip. Relative timestamps are expressed as SMPTE time codes for
frame-level access accuracy. The time code has the format frame-level access accuracy. The time code has the format
hours:minutes:seconds:frames.subframes, hours:minutes:seconds:frames.subframes,
skipping to change at page 31, line 25 skipping to change at page 31, line 25
Example for November 8, 1996 at 14h 37 min and 20 and a quarter Example for November 8, 1996 at 14h 37 min and 20 and a quarter
seconds UTC: seconds UTC:
19961108T143720.25Z 19961108T143720.25Z
4.7. Feature-Tags 4.7. Feature-Tags
Feature-tags are unique identifiers used to designate features in Feature-tags are unique identifiers used to designate features in
RTSP. These tags are used in Require (Section 16.41), Proxy-Require RTSP. These tags are used in Require (Section 16.41), Proxy-Require
(Section 16.35), Proxy-Supported (Section 16.36), and Unsupported (Section 16.35), Proxy-Supported (Section 16.36), Supported
(Section 16.53) header fields. (Section 16.49) and Unsupported (Section 16.53) header fields.
A feature-tag definition MUST indicate which combination of clients, A feature-tag definition MUST indicate which combination of clients,
servers or proxies they applies to. servers or proxies it applies to.
The creator of a new RTSP feature-tag should either prefix the The creator of a new RTSP feature-tag should either prefix the
feature-tag with a reverse domain name (e.g., feature-tag with a reverse domain name (e.g.,
"com.example.mynewfeature" is an apt name for a feature whose "com.example.mynewfeature" is an apt name for a feature whose
inventor can be reached at "example.com"), or register the new inventor can be reached at "example.com"), or register the new
feature-tag with the Internet Assigned Numbers Authority (IANA) (see feature-tag with the Internet Assigned Numbers Authority (IANA) (see
IANA Section 22). IANA Section 22).
The usage of feature-tags is further described in Section 11 that The usage of feature-tags is further described in Section 11 that
deals with capability handling. deals with capability handling.
skipping to change at page 33, line 14 skipping to change at page 33, line 14
that moves forwards while new data is made available and older that moves forwards while new data is made available and older
data is discarded. data is discarded.
To cover the above usages, the following media properties with To cover the above usages, the following media properties with
appropriate values are specified: appropriate values are specified:
4.9.1. Random Access and Seeking 4.9.1. Random Access and Seeking
Random Access is the ability to specify and get media delivered from Random Access is the ability to specify and get media delivered from
any point inside the content, an operation called seeking. This any point inside the content, an operation called seeking. This
possibility is signaled using the Seek-Style header (see Section possibility is signaled using the Seek-Style header (see
Section 16.45) which can take the following different values: Section 16.45) which can take the following different values:
Random Access: The media are seekable to any out of a large number Random Access: The media is seekable to any out of a large number of
of points within the media. Due to media encoding limitations, a points within the media. Due to media encoding limitations, a
particular point may not be reachable, but seeking to a point particular point may not be reachable, but seeking to a point
close by is enabled. A floating point number of seconds may be close by is enabled. A floating point number of seconds may be
provided to express the worst case distance between random access provided to express the worst case distance between random access
points. points.
Conditional Random Access: Based on the above Random Access but Conditional Random Access: Based on the above Random Access but
intended to handle a case where the distance in the media between intended to handle a case where the distance in the media between
random access points are large, and where small seek forward using random access points is large, and where small seek forward using
Random Access would move the client further away then the current Random Access would move the client further away than the current
point. point.
Return To Start: Seeking is only possible to the beginning of the Return To Start: Seeking is only possible to the beginning of the
content. content.
No seeking: Seeking is not possible at all. No seeking: Seeking is not possible at all.
4.9.2. Retention 4.9.2. Retention
Media may have different retention policies in place that affect the Media may have different retention policies in place that affect the
skipping to change at page 34, line 8 skipping to change at page 34, line 8
Time Limited: The media will not be removed before given wallclock Time Limited: The media will not be removed before given wallclock
time. After that time it may or may not be available any more. time. After that time it may or may not be available any more.
Duration limited: Each individual unit of the media will be retained Duration limited: Each individual unit of the media will be retained
for the specified duration. for the specified duration.
4.9.3. Content Modifications 4.9.3. Content Modifications
There is also the question of how the content may change during time There is also the question of how the content may change during time
for a give media resource: for a given media resource:
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., may change. representation, i.e., encoding, quality, etc., may change.
Dynamic: Between explicit updates the media content will not change, Dynamic: Between explicit updates the media content will not change,
but the content may change due to external methods or triggers, but the content may change due to external methods or triggers,
such as playlists. such as playlists.
Time Progressing: As times progresses new content will become Time Progressing: As times progresses new content will become
available. If the content also is retained it will become longer available. If the content also is retained it will become longer
skipping to change at page 35, line 29 skipping to change at page 35, line 29
used. This is also the encoding used for RTCP [RFC3550]. used. This is also the encoding used for RTCP [RFC3550].
Requests contain methods, the object the method is operating upon and Requests contain methods, the object the method is operating upon and
parameters to further describe the method. Methods are idempotent parameters to further describe the method. Methods are idempotent
unless otherwise noted. Methods are also designed to require little unless otherwise noted. Methods are also designed to require little
or no state maintenance at the media server. or no state maintenance at the media server.
5.1. Message Types 5.1. Message Types
RTSP messages consist of requests from client to server, or server to RTSP messages consist of requests from client to server, or server to
client, and responses in the reverse direction. Request Section 7 client, and responses in the reverse direction. Request (Section 7)
and Response Section 8 messages use a format based on the generic and Response (Section 8) messages use a format based on the generic
message format of RFC 2822 [RFC2822] for transferring bodies (the message format of RFC 2822 [RFC2822] for transferring bodies (the
payload of the message). Both types of message consist of a start- payload of the message). Both types of messages consist of a start-
line, zero or more header fields (also known as "headers"), an empty line, zero or more header fields (also known as "headers"), an empty
line (i.e., a line with nothing preceding the CRLF) indicating the line (i.e., a line with nothing preceding the CRLF) indicating the
end of the header, and possibly the data of the message-body. end of the header, and possibly the data of the message body.
generic-message = start-line generic-message = start-line
*(message-header CRLF) *(message-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, servers MUST ignore any empty line(s) In the interest of robustness, agents MUST ignore any empty line(s)
received where a Request-Line is expected. In other words, if the received where a Request-Line or Response-Line is expected. In other
server is reading the protocol stream at the beginning of a message words, if the agent is reading the protocol stream at the beginning
and receives a CRLF first, it should ignore the CRLF. of a message and receives a CRLF first, it MUST ignore the CRLF.
5.2. Message Headers 5.2. Message Headers
RTSP header fields (see Section 16) include general-header, request- RTSP header fields (see Section 16) include general-header, request-
header, response-header, and Message-body header fields. header, response-header, and message-body header fields.
The order in which header fields with differing field names are The order in which header fields with differing field names are
received is not significant. However, it is "good practice" to send received is not significant. However, it is "good practice" to send
general-header fields first, followed by request-header or response- general-header fields first, followed by request-header or response-
header fields, and ending with the Message-body header fields. header fields, and ending with the Message-body header fields.
Multiple message-header fields with the same field-name MAY be Multiple message-header fields with the same field-name MAY be
present in a message if and only if the entire field-value for that present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list. It MUST be header field is defined as a comma-separated list. It MUST be
possible to combine the multiple header fields into one "field-name: possible to combine the multiple header fields into one "field-name:
skipping to change at page 36, line 31 skipping to change at page 36, line 31
Unknown message headers MUST be ignored (skipping over the header to Unknown message headers MUST be ignored (skipping over the header to
the next protocol element, and not causing an error) by a RTSP server the next protocol element, and not causing an error) by a RTSP server
or client. An RTSP Proxy MUST forward unknown message headers. or client. An RTSP Proxy MUST forward unknown message headers.
Message headers defined outside of this specification that are Message headers defined outside of this specification that are
required to be interpreted by the RTSP agent will need to use feature required to be interpreted by the RTSP agent will need to use feature
tags (Section 4.7) and include them in the appropriate Require tags (Section 4.7) and include them in the appropriate Require
(Section 16.41) or Proxy-Require (Section 16.35) header. (Section 16.41) or Proxy-Require (Section 16.35) header.
5.3. Message Body 5.3. Message Body
The message-body (if any) of an RTSP message is used to carry further The message body (if any) of an RTSP message is used to carry further
information for a particular resource associated with the request or information for a particular resource associated with the request or
response. An example of a message body is the Session Description response. An example of a message body is the Session Description
Protocol (SDP). Protocol (SDP).
The presence of a message-body in either a request or a response MUST The presence of a message body in either a request or a response MUST
be signaled by the inclusion of a Content-Length header (see be signaled by the inclusion of a Content-Length header (see
Section 16.16). Section 16.16). A message body MUST NOT be included in a request or
response if the specification of the particular method (see Method
The presence of a message-body in a request is signaled by the Definitions (Section 13)) does not allow sending a message body.
inclusion of a Content-Length header field in the RTSP message. A
message-body MUST NOT be included in a request or response if the
specification of the particular method (see Method Definitions
(Section 13)) does not allow sending a message body.
5.4. Message Length 5.4. Message Length
When a message body is included with a message, the length of that When a message body is included in a message, the length of that body
body is determined by one of the following (in order of precedence): is determined by one of the following (in order of precedence):
1. Any response message which MUST NOT include a message body (such 1. Any response message which MUST NOT include a message body (such
as the 1xx, 204, and 304 responses) is always terminated by the as the 1xx, 204, and 304 responses) is always terminated by the
first empty line after the header fields, regardless of the first empty line after the header fields, regardless of the
message-header fields present in the message. (Note: An empty message-header fields present in the message. (Note: An empty
line is a line with nothing preceding the CRLF.) line is a line with nothing preceding the CRLF.)
2. If a Content-Length header(Section 16.16) is present, its value 2. If a Content-Length header(Section 16.16) is present, its value
in bytes represents the length of the message-body. If this in bytes represents the length of the message-body. If this
header field is not present, a value of zero is assumed. header field is not present, a value of zero is assumed.
skipping to change at page 39, line 14 skipping to change at page 39, line 14
7. Request 7. Request
A request message uses the format outlined below regardless of the A request message uses the format outlined below regardless of the
direction of a request, client to server or server to client: direction of a request, client to server or server to client:
o Request line, containing the method to be applied to the resource, o Request line, containing the method to be applied to the resource,
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, that can be of the following types: o Zero or more Header lines, that can be of the following types:
general (Section 6), request (Section 7.2), or message general headers (Section 6), request headers (Section 7.2), or
body(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 bytes is indicated by the Content- length of the message body in bytes 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
skipping to change at page 40, line 33 skipping to change at page 40, line 33
| | | | | |
| 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 is the following:
<Method> <Request-URI> <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 [RFC2616], 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
skipping to change at page 42, line 8 skipping to change at page 42, line 8
| If-Modified-Since | Section 16.24 | | If-Modified-Since | Section 16.24 |
| | | | | |
| If-None-Match | Section 16.25 | | If-None-Match | Section 16.25 |
| | | | | |
| Notify-Reason | Section 16.31 | | Notify-Reason | Section 16.31 |
| | | | | |
| Proxy-Require | Section 16.35 | | Proxy-Require | Section 16.35 |
| | | | | |
| Range | Section 16.38 | | Range | Section 16.38 |
| | | | | |
| Terminate-Reason | Section 16.50 |
| | |
| Referrer | Section 16.39 | | Referrer | Section 16.39 |
| | | | | |
| Request-Status | Section 16.40 | | Request-Status | Section 16.40 |
| | | | | |
| Require | Section 16.41 | | Require | Section 16.41 |
| | | | | |
| Scale | Section 16.44 | | Scale | Section 16.44 |
| | | | | |
| Session | Section 16.47 | | Session | Section 16.47 |
| | | | | |
| Speed | Section 16.48 | | Speed | Section 16.48 |
| | | | | |
| Supported | Section 16.49 | | Supported | Section 16.49 |
| | | | | |
| Terminate-Reason | Section 16.50 |
| | |
| Transport | Section 16.52 | | Transport | Section 16.52 |
| | | | | |
| User-Agent | Section 16.54 | | User-Agent | Section 16.54 |
+--------------------+--------------------+ +--------------------+--------------------+
Table 3: The RTSP request headers Table 3: The RTSP request headers
Detailed header definition are provided in Section 16. Detailed header definition are provided in Section 16.
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. Only responses using the response code class 1xx,
that it is allowed to send one or more 1xx response messages prior to are allowed to send one or more 1xx response messages prior to the
the final response message. 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
skipping to change at page 44, line 45 skipping to change at page 44, line 45
| 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 | reserved | 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 |
| | | | | | | |
| 405 | Method Not Allowed | all | | 405 | Method Not Allowed | all |
| | | | | | | |
| 406 | Not Acceptable | all | | 406 | Not Acceptable | all |
| | | | | | | |
skipping to change at page 46, line 14 skipping to change at page 46, line 17
| 461 | Unsupported Transport | all | | 461 | Unsupported Transport | all |
| | | | | | | |
| 462 | Destination Unreachable | all | | 462 | Destination Unreachable | all |
| | | | | | | |
| 463 | Destination Prohibited | SETUP | | 463 | Destination Prohibited | SETUP |
| | | | | | | |
| 464 | Data Transport Not Ready Yet | PLAY | | 464 | Data Transport Not Ready Yet | PLAY |
| | | | | | | |
| 465 | Notification Reason Unknown | PLAY_NOTIFY | | 465 | Notification Reason Unknown | PLAY_NOTIFY |
| | | | | | | |
| 466 | Key Management Error | all |
| | | |
| 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 | |
| | | | | | | |
| | | | | | | |
skipping to change at page 46, line 45 skipping to change at page 46, line 50
| | | | | | | |
| 551 | Option Not Support | all | | 551 | Option Not Support | all |
+------+---------------------------------+--------------------------+ +------+---------------------------------+--------------------------+
Table 4: Status codes and their usage with RTSP methods Table 4: Status codes and their usage with RTSP methods
8.2. Response Headers 8.2. Response Headers
The response-header allows the request recipient to pass additional The response-header allows the request recipient to pass additional
information about the response which cannot be placed in the Status- information about the response which cannot be placed in the Status-
Line. This header give information about the server and about Line. This header gives information about the server and about
further access to the resource identified by the Request-URI. All further access to the resource identified by the Request-URI. All
headers currently classified as response headers are listed in headers currently classified as response headers are listed in
Table 5. Table 5.
+------------------------+--------------------+ +------------------------+--------------------+
| Header | Defined in Section | | Header | Defined in Section |
+------------------------+--------------------+ +------------------------+--------------------+
| Connection-Credentials | Section 16.12 | | Connection-Credentials | Section 16.12 |
| | | | | |
| MTag | Section 16.30 |
| | |
| Location | Section 16.27 | | Location | Section 16.27 |
| | | | | |
| MTag | Section 16.30 |
| | |
| Proxy-Authenticate | Section 16.33 | | Proxy-Authenticate | Section 16.33 |
| | | | | |
| Public | Section 16.37 | | Public | Section 16.37 |
| | | | | |
| Range | Section 16.38 | | Range | Section 16.38 |
| | | | | |
| Retry-After | Section 16.42 | | Retry-After | Section 16.42 |
| | | | | |
| Scale | Section 16.44 | | Scale | Section 16.44 |
| | | | | |
skipping to change at page 47, line 47 skipping to change at page 47, line 49
+------------------------+--------------------+ +------------------------+--------------------+
Table 5: The RTSP response headers Table 5: The RTSP response headers
Response-header names can be extended reliably only in combination Response-header names can be extended reliably only in combination
with a change in the protocol version. However, the usage of with a change in the protocol version. However, the usage of
feature-tags in the request allows the responding party to learn the feature-tags in the request allows the responding party to learn the
capability of the receiver of the response. A new or experimental capability of the receiver of the response. A new or experimental
header MAY be given the semantics of response-header if all parties header MAY be given the semantics of response-header if all parties
in the communication recognize them to be response-header. in the communication recognize them to be response-header.
Unrecognized headers in responses are treated as message-headers. Unrecognized headers in responses are treated as message-headers and
hence MUST be ignored.
9. Message Body 9. Message Body
Request and Response messages MAY transfer a message body, if not Request and Response messages MAY transfer 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 message-body header fields and the The message body consists of the content data itself (see also
content data itself. Section 5.2.
The SET_PARAMETER and GET_PARAMETER request and response, and The SET_PARAMETER and GET_PARAMETER request and response, and
DESCRIBE response MAY have an message body. All 4xx and 5xx DESCRIBE response MAY have a message body. All 4xx and 5xx responses
responses MAY also have an message body. MAY also have a message body.
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.
skipping to change at page 49, line 9 skipping to change at page 49, line 9
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
RTSP message with an 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
header fields Content-Type and Content-Encoding. header fields Content-Type and Content-Encoding.
Content-Type specifies the media type of the underlying data. Content-Type specifies the media type of the underlying data.
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. There is compression, that are a property of the requested resource. There is
no default encoding. no default encoding.
skipping to change at page 50, line 29 skipping to change at page 50, line 29
for interoperable implementations. In an attempt to reduce for interoperable implementations. In an attempt to reduce
complexity and scope, and due to lack of interest, RTSP 2.0 does not complexity and scope, and due to lack of interest, RTSP 2.0 does not
attempt to define a mechanism for supporting RTSP over UDP or other attempt to define a mechanism for supporting RTSP over UDP or other
connectionless transport protocols. A side-effect of this is that connectionless transport protocols. A side-effect of this is that
RTSP requests MUST NOT be sent to multicast groups since no RTSP requests MUST NOT be sent to multicast groups since no
connection can be established with a specific receiver in multicast connection can be established with a specific receiver in multicast
environments. environments.
Certain RTSP headers, such as the CSeq header (Section 16.19), which Certain RTSP headers, such as the CSeq header (Section 16.19), which
may appear to be relevant only to connectionless transport scenarios may appear to be relevant only to connectionless transport scenarios
are still retained and must be implemented according to the are still retained and MUST be implemented according to the
specification. In the case of CSeq, it is quite useful for matching specification. In the case of CSeq, it is quite useful for matching
responses to requests if the requests are pipelined (see Section 12). responses to requests if the requests are pipelined (see Section 12).
It is also useful in proxies for keeping track of the different It is also useful in proxies for keeping track of the different
requests when aggregating several client requests on a single TCP requests when aggregating several client requests on a single TCP
connection. connection.
10.1. Reliability and Acknowledgements 10.1. Reliability and Acknowledgements
Since RTSP messages are transmitted using reliable transport Since RTSP messages are transmitted using reliable transport
protocols, they MUST NOT be retransmitted at the RTSP protocol level. protocols, they MUST NOT be retransmitted at the RTSP protocol level.
skipping to change at page 52, line 10 skipping to change at page 52, line 10
be supported only if a client establishes a persistent connection be supported only if a client establishes a persistent connection
with the server. In cases where a persistent connection does not with the server. In cases where a persistent connection does not
exist between a server and its client, due to the lack of a signaling exist between a server and its client, due to the lack of a signaling
channel the server may be forced to silently discard RTSP messages, channel the server may be forced to silently discard RTSP messages,
and may even drop an RTSP session without notifying the client. An and may even drop an RTSP session without notifying the client. An
example of such a case is when the server desires to send a REDIRECT example of such a case is when the server desires to send a REDIRECT
request for an RTSP session to the client but is not able to do so request for an RTSP session to the client but is not able to do so
because it cannot reach the client. A server that attempts to send a because it cannot reach the client. A server that attempts to send a
request to a client that has no connection currently to the server request to a client that has no connection currently to the server
SHOULD discard the request directly, but it MAY queue it for later SHOULD discard the request directly, but it MAY queue it for later
delivery. However, if the server queues the request it should when delivery. However, if the server queues the request it SHOULD when
adding additional requests to the queue ensure to remove older adding additional requests to the queue ensure to remove older
requests that are now redundant. requests that are now redundant.
Without a persistent connection between the client and the server, Without a persistent connection between the client and the server,
the media server has no reliable way of reaching the client. the media server has no reliable way of reaching the client.
Because the likely failure of server to client established Because the likely failure of server to client established
connections the server will not even attempt establishing any connections the server will not even attempt establishing any
connection. connection.
The sending of client and server requests can be asynchronous events. The sending of client and server requests can be asynchronous events.
skipping to change at page 52, line 33 skipping to change at page 52, line 33
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 timeout despite them being issue is that outstanding requests may timeout despite them being
processed by the peer due to the response is caught in the queue processed by the peer due to the response is caught in the queue
behind a number of request that the RTSP agent is processing but that behind a number of request that the RTSP agent is processing but that
take some time to complete. To avoid this problem an RTSP agent is take some time to complete. To avoid this problem an RTSP agent is
recommended to buffer incoming messages locally so that any response recommended to buffer incoming messages locally so that any response
messages can be processed immediately upon reception. If responses messages can be processed immediately upon reception. If responses
are separated from requests and directly forwarded for processing, are separated from requests and directly forwarded for processing,
not only the result be used immediately, the state associated with not only can the result be used immediately, the state associated
that outstanding request can also be released. However, buffering a with that outstanding request can also be released. However,
number of requests on the receiving RTSP agent consumes resources and buffering a number of requests on the receiving RTSP agent consumes
enables a resource exhaustion attack on the agent. Therefore this resources and enables a resource exhaustion attack on the agent.
buffer should be limited so that an unreasonable number of requests Therefore this buffer should be limited so that an unreasonable
or total message size is not allowed to consume the receiving agent's number of requests or total message size is not allowed to consume
resources. In most APIs having the receiving agent stop reading from the receiving agent's resources. In most APIs, having the receiving
the TCP socket will result in TCP's window being clamped. Thus agent stop reading from the TCP socket will result in TCP's window
forcing the buffering onto the sending agent when the load is larger being clamped. Thus forcing the buffering onto the sending agent
than expected. However, as both RTSP message sizes and frequency may when the load is larger than expected. However, as both RTSP message
be changed in the future by protocol extensions, an agent should be sizes and frequency may be changed in the future by protocol
careful against taking harsher measurements against a potential extensions, an agent should be careful against taking harsher
attack. When under attack an RTSP agent can close TCP connections measurements against a potential attack. When under attack an RTSP
and release state associated with that TCP connection. agent can close TCP connections and 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. An RTSP agent should not have more than 10 guidelines are given. It is RECOMMENDED that:
outstanding requests per RTSP session. An RTSP agent should not have
more than 10 outstanding requests that aren't related to an RTSP o an RTSP agent should not have more than 10 outstanding requests
session or that are requesting to create an RTSP session. per RTSP session;
o an RTSP agent should not have more than 10 outstanding requests
that are not related to an RTSP session or that are requesting to
create an RTSP session.
In light of the above, it is RECOMMENDED that clients use persistent In light of the above, it is RECOMMENDED that clients use persistent
connections whenever possible. A client that supports persistent connections whenever possible. A client that supports persistent
connections MAY "pipeline" its requests (see Section 12). connections MAY "pipeline" its requests (see Section 12).
10.3. Closing Connections 10.3. Closing Connections
The client MAY close a connection at any point when no outstanding The client MAY close a connection at any point when no outstanding
request/response transactions exist for any RTSP session being request/response transactions exist for any RTSP session being
managed through the connection. The server, however, SHOULD NOT managed through the connection. The server, however, SHOULD NOT
skipping to change at page 53, line 43 skipping to change at page 53, line 49
Certain error responses such as "460 Only Aggregate Operation Certain error responses such as "460 Only Aggregate Operation
Allowed" (Section 15.4.25) are used for negotiating capabilities Allowed" (Section 15.4.25) are used for negotiating capabilities
of a server with respect to content or other factors. In such of a server with respect to content or other factors. In such
cases, it is inefficient for the server to close a connection on cases, it is inefficient for the server to close a connection on
an error response. Also, such behavior would prevent an error response. Also, such behavior would prevent
implementation of advanced/special types of requests or result in implementation of advanced/special types of requests or result in
extra overhead for the client when testing for new features. On extra overhead for the client when testing for new features. On
the flip side, keeping connections open after sending an error the flip side, keeping connections open after sending an error
response poses a Denial of Service security risk (Section 21). response poses a Denial of Service security risk (Section 21).
The server MAY close a connection if he 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 waits at least 10 amount of time. It is RECOMMENDED that the server waits at least 10
second 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
otherwise starved for resources during that event consider using a otherwise starved for resources during that event MAY consider using
shorter timeout. a shorter timeout.
If a server closes a connection while the client is attempting to If a server closes a connection while the client is attempting to
send a new request, the client will have to close its current send a new request, the client will have to close its current
connection, establish a new connection and send its request over the connection, establish a new connection and send its request over the
new connection. new connection.
An RTSP message should not be terminated by closing the connection. An RTSP message SHOULD NOT be terminated by closing the connection.
Such a message MAY be considered to be incomplete by the receiver and Such a message MAY be considered to be incomplete by the receiver and
discarded. An RTSP message is properly terminated as defined in discarded. An RTSP message is properly terminated as defined in
Section 5. Section 5.
10.4. Timing Out Connections and RTSP Messages 10.4. Timing Out Connections and RTSP Messages
Receivers of a request (responder) SHOULD respond to requests in a Receivers of a request (responder) SHOULD respond to requests in a
timely manner even when a reliable transport such as TCP is used. timely manner even when a reliable transport such as TCP is used.
Similarly, the sender of a request (requester) SHOULD wait for a Similarly, the sender of a request (requester) SHOULD wait for a
sufficient time for a response before concluding that the responder sufficient time for a response before concluding that the responder
skipping to change at page 55, line 28 skipping to change at page 55, line 32
RTCP: If RTP is used for media transport RTCP SHOULD be used. If RTCP: If RTP is used for media transport RTCP SHOULD be used. If
RTCP is used to report transport statistics, it MUST also work RTCP is used to report transport statistics, it MUST also work
as keep alive. The server can determine the client by network as keep alive. The server can determine the client by network
address and port together with the fact that the client is address and port together with the fact that the client is
reporting on the servers SSRC(s). A downside of using RTCP is reporting on the servers SSRC(s). A downside of using RTCP is
that it only gives statistical guarantees to reach the server. that it only gives statistical guarantees to reach the server.
However, the probability of a false client timeout is so low However, the probability of a false client timeout is so low
that it can be ignored in most cases. For example, assume a that it can be ignored in most cases. For example, assume a
session with 60 seconds timeout and enough bitrate assigned to session with 60 seconds timeout and enough bitrate assigned to
RTCP messages to send a message from client to server on RTCP messages to send a message from client to server on
average every 5 seconds. That client have, for a network with average every 5 seconds. That client has, for a network with 5
5 % packet loss, the probability to fail showing liveness sign % packet loss, the probability to fail showing liveness sign in
in that session within the timeout interval of 2.4*E-16. In that session within the timeout interval of 2.4*E-16. Sessions
sessions with shorter timeouts, or much higher packet loss, or with shorter timeouts, or much higher packet loss, or small
small RTCP bandwidths SHOULD also use any of the mechanisms RTCP bandwidths SHOULD also use any of the mechanisms below.
below.
SET_PARAMETER: When using SET_PARAMETER for keep alive, no body SET_PARAMETER: When using SET_PARAMETER for keep alive, no body
SHOULD be included. This method is the RECOMMENDED RTSP method SHOULD be included. This method is the RECOMMENDED RTSP method
to use for a request intended only to perform keep-alive. to use for a request intended only to perform keep-alive.
GET_PARAMETER: When using GET_PARAMETER for keep alive, no body GET_PARAMETER: When using GET_PARAMETER for keep alive, no body
SHOULD be included. SHOULD be included.
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 result 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
media resource to correctly populate the Public and Allow media resource to correctly populate the Public and Allow
headers. headers.
The timeout parameter MAY be included in a SETUP response, and MUST The timeout parameter MAY be included in a SETUP response, and MUST
NOT be included in requests. The server uses it to indicate to the NOT be included in requests. The server uses it to indicate to the
client how long the server is prepared to wait between RTSP commands client how long the server is prepared to wait between RTSP commands
or other signs of life before closing the session due to lack of or other signs of life before closing the session due to lack of
activity (see Appendix B). The timeout is measured in seconds, with activity (see Appendix B). The timeout is measured in seconds, with
skipping to change at page 56, line 16 skipping to change at page 56, line 21
be changed in an established session. be changed in an established session.
10.6. Use of IPv6 10.6. Use of IPv6
Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP
2.0 has been updated for explicit IPv6 support. Implementations of 2.0 has been updated for explicit IPv6 support. Implementations of
RTSP 2.0 MUST understand literal IPv6 addresses in URIs and headers. RTSP 2.0 MUST understand literal IPv6 addresses in URIs and headers.
10.7. Overload Control 10.7. Overload Control
Overload in RTSP can occur when server and proxies have insufficient Overload in RTSP can occur when servers and proxies have insufficient
resources to complete the processing of a request. An improper resources to complete the processing of a request. An improper
handling of such an overload situation at proxies and servers can handling of such an overload situation at proxies and servers can
impact the operation of the RTSP deployment, 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 Section 15.5.4) to let servers and proxies notify requesting (Section 15.5.4) to let servers and proxies notify requesting proxies
proxies and RTSP clients about an overload situation. In conjunction and RTSP clients about an overload situation. In conjunction with
with the Retry-After header (Section Section 16.42) the server or the Retry-After header (Section 16.42) the server or proxy can
proxy can indicate the time after the requesting entity can send indicate the time after the requesting entity can send another
another request to the proxy or server. request to the proxy or server.
Simply implementing and using the 503 (Service Unavailable) is not Simply implementing and using the 503 (Service Unavailable) is not
sufficient enough for properly handling overload situations. For sufficient for properly handling overload situations. For instance,
instance, a simplistic approach would be to send the 503 response a simplistic approach would be to send the 503 response with a Retry-
with a Retry-After header set to a fixed value. However, this can After header set to a fixed value. However, this can cause the
cause the situation where multiple RTSP clients again send requests situation where multiple RTSP clients again send requests to a proxy
to a proxy or server at roughly the same time which may again cause or server at roughly the same time which may again cause an overload
an overload situation, or if the "old" overload situation is not yet situation, or if the "old" overload situation is not yet solved,
solved, i.e., the length indicated in the Retry-After header was too i.e., the length indicated in the Retry-After header was too short.
short.
An RTSP server or proxy in an overload situation must select the An RTSP server or proxy in an overload situation must select the
value of the Retry-After header carefully and in dependency of its value of the Retry-After header carefully and in dependency of its
current load situation. It is RECOMMENDED to increase the length current load situation. It is RECOMMENDED to increase the length
proportional with the current load of the server, i.e., an increasing proportional with the current load of the server, i.e., an increasing
workload should result in an increased length of the indicated workload should result in an increased length of the indicated
unavailability. It is RECOMMENDED to not send the same value in the unavailability. It is RECOMMENDED to not send the same value in the
Retry-After header to all requesting proxies and clients, but to add Retry-After header to all requesting proxies and clients, but to add
a variation the mean value of the Retry-After header. a variation to the mean value of the Retry-After header.
Another issue are load balancing RTSP proxies, i.e., where an RTSP Another issue are load balancing RTSP proxies, i.e., where an RTSP
proxy is used to select amongst a set of RTSP servers to handled the proxy is used to select amongst a set of RTSP servers to handle the
requests, or when multiple server addresses are available for a given requests, or when multiple server addresses are available for a given
server name. The proxy or client may receive a 503 (Service server name. The proxy or client may receive a 503 (Service
Unavailable) from one of its RTSP servers or a TCP timeout (if the Unavailable) from one of its RTSP servers or a TCP timeout (if the
server is even unable to handled the request message). The proxy or server is even unable to handled the request message). The proxy or
client simply retries the other addresses, but may also receive a 503 client simply retries the other addresses, but may also receive a 503
(Service Unavailable) response or TCP timeouts from those addresses. (Service Unavailable) response or TCP timeouts from those addresses.
In such a situation, where none of the RTSP servers/addresses can In such a situation, where none of the RTSP servers/addresses can
handled the request, the RTSP agent has to wait before it can send handle the request, the RTSP agent has to wait before it can send any
any new requests to the RTSP server. Any additional request to a new requests to the RTSP server. Any additional request to a
specific address MUST be delayed according to the Retry-After headers specific address MUST be delayed according to the Retry-After headers
received. For addresses where no response was received or TCP received. For addresses where no response was received or TCP
timeout occurred, an initial wait timer SHOULD be set to 5 seconds. timeout occurred, an initial wait timer SHOULD be set to 5 seconds.
That timer MUST be doubled for each additional failure to connect or That timer MUST be doubled for each additional failure to connect or
receive response. receive response. It is RECOMMENDED to not set the same value in the
timer, but to add a variation to the mean value.
11. Capability Handling 11. Capability Handling
This section describes the available capability handling mechanism This section describes the available capability handling mechanism
which allows RTSP to be extended. Extensions to this version of the which allows RTSP to be extended. Extensions to this version of the
protocol are basically done in two ways. First, new headers can be protocol are basically done in two ways. First, new headers can be
added. Secondly, new methods can be added. The capability handling added. Secondly, new methods can be added. The capability handling
mechanism is designed to handle both cases. mechanism is designed to handle both cases.
When a method is added, the involved parties can use the OPTIONS When a method is added, the involved parties can use the OPTIONS
method to discover whether it is supported. This is done by issuing method to discover whether it is supported. This is done by issuing
a OPTIONS request to the other party. Depending on the URI it will an OPTIONS request to the other party. Depending on the URI it will
either apply in regards to a certain media resource, the whole server either apply in regards to a certain media resource, the whole server
in general, or simply the next hop. The OPTIONS response MUST in general, or simply the next hop. The OPTIONS response MUST
contain a Public header which declares all methods supported for the contain a Public header which declares all methods supported for the
indicated resource. indicated resource.
It is not necessary to use OPTIONS to discover support of a method, It is not necessary to use OPTIONS to discover support of a method,
as the client could simply try the method. If the receiver of the as the client could simply try the method. If the receiver of the
request does not support the method it will respond with an error request does not support the method it will respond with an error
code indicating the method is either not implemented (501) or does code indicating the method is either not implemented (501) or does
not apply for the resource (405). The choice between the two not apply for the resource (405). The choice between the two
skipping to change at page 62, line 5 skipping to change at page 62, line 5
| | S -> C | P,S | optional | optional | | | S -> C | P,S | optional | optional |
| | | | | | | | | | | |
| TEARDOWN | C -> S | P,S | required | required | | TEARDOWN | C -> S | P,S | required | required |
| | | | | | | | | | | |
| | S -> C | P | required | required | | | S -> C | P | required | required |
+---------------+-----------+--------+-------------+-------------+ +---------------+-----------+--------+-------------+-------------+
Table 7: Overview of RTSP methods, their direction, and what objects Table 7: Overview of RTSP methods, their direction, and what objects
(P: presentation, S: stream) they operate on. (P: presentation, S: stream) they operate on.
Note on Table 7: GET_PARAMETER is recommended, but not required. Note on Table 7: GET_PARAMETER is optional. For example, a fully
For example, a fully functional server can be built to deliver functional server can be built to deliver media without any
media without any parameters. SET_PARAMETER is required, however, parameters. SET_PARAMETER is required, however, due to its usage
due to its usage for keep-alive. PAUSE is now required because it for keep-alive. PAUSE is now required because it is the only way
is the only way of leaving the Play state without terminating the of leaving the Play state without terminating the whole session.
whole session.
If an RTSP agent does not support a particular method, it MUST return If an RTSP agent does not support a particular method, it MUST return
501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD 501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD
NOT try this method again for the given agent / resource combination. NOT try this method again for the given agent / resource combination.
An RTSP proxy whose main function is to log or audit and not modify An RTSP proxy whose main function is to log or audit and not modify
transport or media handling in any way MAY forward RTSP messages with transport or media handling in any way MAY forward RTSP messages with
unknown methods. Note that the proxy still needs to perform the unknown methods. Note that the proxy still needs to perform the
minimal required processing, like adding the Via header. minimal required processing, like adding the Via header.
13.1. OPTIONS 13.1. OPTIONS
The semantics of the RTSP OPTIONS method is similar to that of the The semantics of the RTSP OPTIONS method is similar to that of the
HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is
bi-directional, in that a client can request it to a server and vice bi-directional, in that a client can request it to a server and vice
versa. A client MUST implement the capability to send an OPTIONS versa. A client MUST implement the capability to send an OPTIONS
request and a server or a proxy MUST implement the capability to request and a server or a proxy MUST implement the capability to
respond to an OPTIONS request. The client, server or proxy MAY also respond to an OPTIONS request. The client, server or proxy MAY also
implement the converse of their required capability. implement the converse of their required capability, but still retain
the prior mentioned about what is a "MUST implement".
An OPTIONS request may be issued at any time. Such a request does An OPTIONS request may be issued at any time. Such a request does
not modify the session state. However, it may prolong the session not modify the session state. However, it may prolong the session
lifespan (see below). The URI in an OPTIONS request determines the lifespan (see below). The URI in an OPTIONS request determines the
scope of the request and the corresponding response. If the Request- scope of the request and the corresponding response. If the Request-
URI refers to a specific media resource on a given host, the scope is URI refers to a specific media resource on a given host, the scope is
limited to the set of methods supported for that media resource by limited to the set of methods supported for that media resource by
the indicated RTSP agent. A Request-URI with only the host address the indicated RTSP agent. A Request-URI with only the host address
limits the scope to the specified RTSP agent's general capabilities limits the scope to the specified RTSP agent's general capabilities
without regard to any specific media. If the Request-URI is an without regard to any specific media. If the Request-URI is an
skipping to change at page 64, line 6 skipping to change at page 64, line 6
method request can be successfully fulfilled. The DESCRIBE reply- method request can be successfully fulfilled. The DESCRIBE reply-
response pair constitutes the media initialization phase of RTSP. response pair constitutes the media initialization phase of RTSP.
The DESCRIBE response SHOULD contain all media initialization The DESCRIBE response SHOULD contain all media initialization
information for the resource(s) that it describes. Servers SHOULD information for the resource(s) that it describes. Servers SHOULD
NOT use the DESCRIBE response as a means of media indirection by NOT use the DESCRIBE response as a means of media indirection by
having the description point at another server; instead, using the having the description point at another server; instead, using the
3rr responses is RECOMMENDED. 3rr responses is RECOMMENDED.
By forcing a DESCRIBE response to contain all media initialization By forcing a DESCRIBE response to contain all media initialization
for the set of streams that it describes, and discouraging the use information for the set of streams that it describes, and
of DESCRIBE for media indirection, any looping problems can be discouraging the use of DESCRIBE for media indirection, any
avoided that might have resulted from other approaches. looping problems can be avoided that might have resulted from
other approaches.
Example: Example:
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
CSeq: 312 CSeq: 312
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Accept: application/sdp, application/example Accept: application/sdp, application/example
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 312 CSeq: 312
skipping to change at page 65, line 15 skipping to change at page 65, line 16
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, and/or other means that are appropriate to the
operating environment of the clients. operating environment of the clients.
13.3. SETUP 13.3. SETUP
Note: The states described in this section and the following are
described in detail in Appendix B.
The SETUP request for an URI specifies the transport mechanism to be The SETUP request for an URI specifies the transport mechanism to be
used for the streamed media. The SETUP method may be used in two used for the streamed media. The SETUP method may be used in two
different cases; Create an RTSP session and change the transport different cases; Create an RTSP session and change the transport
parameters of already set up media stream. SETUP can be used in all parameters of already set up media stream. SETUP can be used in all
three states; Init, and Ready, for both purposes and in PLAY to three states; Init, and Ready, for both purposes and in PLAY to
change the transport parameters. There is also a third possible change the transport parameters. There is also a third possible
usage for the SETUP method which is not specified in this memo: usage for the SETUP method which is not specified in this memo:
adding a media to a session. Using SETUP to add media to an existing adding a media to a session. Using SETUP to add media to an existing
session, when the session is in Play state, is unspecified. session, when the session is in Play state, is unspecified.
The Transport header, see Section 16.52, specifies the media The Transport header, see Section 16.52, specifies the media
transport parameters acceptable to the client for data transmission; transport parameters acceptable to the client for data transmission;
the response will contain the transport parameters selected by the the response will contain the transport parameters selected by the
server. This allows the client to enumerate in descending order of server. This allows the client to enumerate in descending order of
preference the transport mechanisms and parameters acceptable to it, preference the transport mechanisms and parameters acceptable to it,
while the server can select the most appropriate. It is expected while the server can select the most appropriate. It is expected
that the session description format used will enable the client to that the session description format used will enable the client to
select a limited number possible configurations that are offered to select a limited number of possible configurations that are offered
the server to choose from. All transport related parameters shall be to the server to choose from. All transport related parameters SHALL
included in the Transport header; the use of other headers for this be included in the Transport header; the use of other headers for
purpose is discouraged due to middleboxes, such as firewalls or NATs. this purpose is NOT RECOMMENDED due to middleboxes, such as firewalls
or NATs.
For the benefit of any intervening firewalls, a client MUST indicate For the benefit of any intervening firewalls, a client MUST indicate
the known transport parameters, even if it has no influence over the known transport parameters, even if it has no influence over
these parameters, for example, where the server advertises a fixed these parameters, for example, where the server advertises a fixed
multicast address as destination. multicast address as destination.
Since SETUP includes all transport initialization information, Since SETUP includes all transport initialization information,
firewalls and other intermediate network devices (which need this firewalls and other intermediate network devices (which need this
information) are spared the more arduous task of parsing the information) are spared the more arduous task of parsing the
DESCRIBE response, which has been reserved for media DESCRIBE response, which has been reserved for media
initialization. initialization.
The client MUST include the Accept-Ranges header in the request The client MUST include the Accept-Ranges header in the request
indicating all supported unit formats in the Range header. This indicating all supported unit formats in the Range header. This
allows the server to know which format it may use in future session allows the server to know which formats it may use in future session
related responses, such as a PLAY response without any range in the related responses, such as a PLAY response without any range in the
request. If the client does not support a time format necessary for request. If the client does not support a time format necessary for
the presentation the server MUST respond using 456 (Header Field Not the presentation the server MUST respond using 456 (Header Field Not
Valid for Resource) and include the Accept-Ranges header with the Valid for Resource) and include the Accept-Ranges header with the
range unit formats supported for the resource. range unit formats supported for the resource.
In a SETUP response the server MUST include the Accept-Ranges header In a SETUP response the server MUST include the Accept-Ranges header
(see Section 16.5) to indicate which time formats are acceptable to (see Section 16.5) to indicate which time formats are acceptable to
use for this media resource. use for this media resource.
The SETUP response 200 OK MUST include the Media-Properties header The SETUP response 200 OK MUST include the Media-Properties header
(see Section 16.28 ). The combination of the parameters of the (see Section 16.28 ). The combination of the parameters of the
Media-Properties header indicate the nature of the content present in Media-Properties header indicates the nature of the content present
the session (see also Section 4.9). For example, a live stream with in the session (see also Section 4.9). For example, a live stream
time shifting is indicated by with time shifting is indicated by
o Random Access set to Random-Access, o Random Access set to Random-Access,
o Content Modifications set to Time Progressing, o Content Modifications set to Time Progressing,
o Retention set to Time-Duration (with specific recording window o Retention set to Time-Duration (with specific recording window
time value). time value).
The SETUP response 200 OK MUST include the Media-Range header (see The SETUP response 200 OK MUST include the Media-Range header (see
Section 16.29) if the media is Time-Progressing. Section 16.29) if the media is Time-Progressing.
skipping to change at page 67, line 5 skipping to change at page 67, line 27
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 is 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 RTP/ interleaved on the RTSP control channel. The server selects the RTP/
AVP/UDP transport and adds the address and ports it will send and AVP/UDP transport and adds the address and ports it will send and
received 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 an Pipelined-Requests header referencing an a session identifier or a Pipelined-Requests header referencing an
existing session context, in which case the server MUST bundle this existing session context, in which case the server MUST bundle this
setup request into the existing session (aggregated session) or setup request into the existing session (aggregated session) or
return error 459 (Aggregate Operation Not Allowed) (see return error 459 (Aggregate Operation Not Allowed) (see
Section 15.4.24). An Aggregate control URI MUST be used to control Section 15.4.24). An Aggregate control URI MUST be used to control
an aggregated session. This URI MUST be different from the stream an aggregated session. This URI MUST be different from the stream
control URIs of the individual media streams included in the control URIs of the individual media streams included in the
aggregate. The Aggregate control URI is to be specified by the aggregate (see Section 13.4.2 for aggregated sessions and for the
session description if the server supports aggregated control and particular URIs see Appendix D.1.1). The Aggregate control URI is to
aggregated control is desired for the session. However, even if be specified by the session description if the server supports
aggregated control is offered the client MAY chose to not set up the aggregated control and aggregated control is desired for the session.
session in aggregated control. If an Aggregate control URI is not However, even if aggregated control is offered the client MAY chose
specified in the session description, it is normally an indication to not set up the session in aggregated control. If an Aggregate
that non-aggregated control should be used. The SETUP of media control URI is not specified in the session description, it is
streams in an aggregate which has not been given an aggregated normally an indication that non-aggregated control should be used.
control URI is unspecified. The SETUP of media streams in an aggregate which has not been given
an aggregated control URI is unspecified.
While the session ID sometimes carries enough information for While the session ID sometimes carries enough information for
aggregate control of a session, the Aggregate control URI is still aggregate control of a session, the Aggregate control URI is still
important for some methods such as SET_PARAMETER where the control important for some methods such as SET_PARAMETER where the control
URI enables the resource in question to be easily identified. The URI enables the resource in question to be easily identified. The
Aggregate control URI is also useful for proxies, enabling them to Aggregate control URI is also useful for proxies, enabling them to
route the request to the appropriate server, and for logging, route the request to the appropriate server, and for logging,
where it is useful to note the actual resource that a request was where it is useful to note the actual resource that a request was
operating on. operating on.
skipping to change at page 68, line 30 skipping to change at page 69, line 4
server MAY allow. If it does not allow changing of parameters, it server MAY allow. If it does not allow changing of parameters, it
MUST respond with error 455 (Method Not Valid In This State). The MUST respond with error 455 (Method Not Valid In This State). The
reasons to support changing transport parameters include allowing reasons to support changing transport parameters include allowing
application layer mobility and flexibility to utilize the best application layer mobility and flexibility to utilize the best
available transport as it becomes available. If a client receives a available transport as it becomes available. If a client receives a
455 when trying to change transport parameters while the server is in 455 when trying to change transport parameters while the server is in
Play state, it MAY try to put the server in ready state using PAUSE, Play state, it MAY try to put the server in ready state using PAUSE,
before issuing the SETUP request again. If that also fails the before issuing the SETUP request again. If that also fails the
changing of transport parameters will require that the client changing of transport parameters will require that the client
performs a TEARDOWN of the affected media and then to set it up performs a TEARDOWN of the affected media and then to set it up
again. In aggregated session avoiding tearing down all the media at again. For an aggregated session avoiding tearing down all the media
the same time will avoid the creation of a new session. at the same 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 to indicate at
what point the new transport parameters will be used. Further, if what point the new transport parameters will be used. Further, if
RTP is used for delivery, the server MUST also include the RTP-Info RTP is used for delivery, the server MUST also include the RTP-Info
skipping to change at page 70, line 6 skipping to change at page 70, line 29
where the client requests a start point prior to what is retained, where the client requests a start point prior to what is retained,
the start point is adjusted to the oldest retained content. For a the start point is adjusted to the oldest retained content. For a
start point that is beyond the media front edge, i.e. beyond the start point that is beyond the media front edge, i.e. beyond the
current value for "now", the server SHALL adjust the start value to current value for "now", the server SHALL adjust the start value to
the current front edge. The Range header's stop point value may the current front edge. The Range header's stop point value may
point beyond the current media edge. In that case, the server SHALL point beyond the current media edge. In that case, the server SHALL
deliver media from the requested (and possibly adjusted) start point deliver media from the requested (and possibly adjusted) start point
until the provided stop point, or the end of the media is reached until the provided stop point, or the end of the media is reached
prior to the specified stop point. Please note that if one simply prior to the specified stop point. Please note that if one simply
wants to play from a particular start point until the end of media wants to play from a particular start point until the end of media
using an Range header with an implicit stop point is RECOMMENDED. using a Range header with an implicit stop point is RECOMMENDED.
If a client requests to start playing at the end of media, either If a client requests to start playing at the end of media, either
explicitly with a Range header or implicitly with a pause point that explicitly with a Range header or implicitly with a pause point that
is at the end of media, a 457 (Invalid Range) error MUST be sent and is at the end of media, a 457 (Invalid Range) error MUST be sent and
include the Media-Range header (Section 16.29). Below is specified include the Media-Range header (Section 16.29). It is specified
that the Range header also must be included, and will in the case of below that the Range header also must be included in the response and
Ready State carry the pause point. Note that this also applies if that it will carry the pause point in the media, in the case of the
the pause point or requested start point is at the beginning of the session being in Ready State. Note that this also applies if the
media and a Scale header (Section 16.44) is included with a negative pause point or requested start point is at the beginning of the media
value (playing backwards). and a Scale header (Section 16.44) is included with a negative value
(playing backwards).
For media with random access properties a client may express its For media with random access properties a client may express its
preference on which policy for start point selection the server shall preference on which policy for start point selection the server shall
use. This is done by including the Seek-Style header (Section 16.45) use. This is done by including the Seek-Style header (Section 16.45)
in the PLAY request. The Seek-Style applied will effect the content in the PLAY request. The Seek-Style applied will effect the content
of the Range header as it will be adjusted to indicate from what of the Range header as it will be adjusted to indicate from what
point the media actually is delivered. point the media actually is delivered.
A client desiring to play the media from the beginning MUST send a A client desiring to play the media from the beginning MUST send a
PLAY request with a Range header pointing at the beginning, e.g. PLAY request with a Range header pointing at the beginning, e.g.
skipping to change at page 72, line 40 skipping to change at page 73, line 23
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.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, the presentation does NOT transition After playing the desired range, the presentation does NOT change to
to the Ready state, media delivery simply stops. A PAUSE request the Ready state, media delivery simply stops. A PAUSE request MUST
MUST be issued before the stream enters the Ready state. A PLAY be issued to make the stream enter the Ready state. A PLAY request
request while the stream is still in the Play state is legal, and can while the stream is still in the Play state is legal, and can be
be issued without an intervening PAUSE request. Such a request MUST issued without an intervening PAUSE request. Such a request MUST
replace the current PLAY action with the new one requested, i.e. replace the current PLAY action with the new one requested, i.e.
being handle the same as the request was received in Ready state. In being handled the same as the request was received in Ready state.
the case the range in Range header has a implicit start time In the case the range in Range header has an implicit start time
(-endtime), the server MUST continue to play from where it currently (-endtime), the server MUST continue to play from where it currently
was until the specified end point. This is useful to change end at was until the specified end point. This is useful to change end at
another point than in the previous request. another point than 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 has been broken into several lines, where following lines headers has been broken into several lines, where following 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
skipping to change at page 74, line 31 skipping to change at page 75, line 27
13.4.3. Updating current PLAY Requests 13.4.3. Updating current PLAY Requests
Clients can issue PLAY requests while the stream is in Play state and Clients can issue PLAY requests while the stream is in Play state and
thus updating their request. thus updating their request.
The important difference compared to a PLAY request in Ready state is The important difference compared to a PLAY request in Ready state is
the handling of the current play point and how the Range header in the handling of the current play point and how the Range header in
request is constructed. The session is actively playing media and request is constructed. The session is actively playing media and
the play point will be moving, making the exact time a request will the play point will be moving, making the exact time a request will
take action is hard to predict. Depending on how the PLAY header take action hard to predict. Depending on how the PLAY header
appears two different cases exist: total replacement or continuation. appears two different cases exist: total replacement or continuation.
A total replacement is signaled by having the first range A total replacement is signaled by having the first range
specification have an explicit start value, e.g. npt=45- or specification have an explicit start value, e.g. npt=45- or
npt=45-60, in which case the server stops playout at the current npt=45-60, in which case the server stops playout at the current
playout point and then starts delivering media according to the Range playout point and then starts delivering media according to the Range
header. This is equivalent to having the client first send a PAUSE header. This is equivalent to having the client first send a PAUSE
and then a new play request that isn't based on the pause point. In and then a new PLAY request that isn't based on the pause point. In
the case of continuation the first range specifier has an implicit the case of continuation the first range specifier has an implicit
start point and a explicit stop value (Z), e.g. npt=-60, which start point and an explicit stop value (Z), e.g. npt=-60, which
indicate that it MUST convert the range specifier being played prior indicate that it MUST convert the range specifier being played prior
to this PLAY request (X to Y) into (X to Z) and continue as this was to this PLAY request (X to Y) into (X to Z) and continue as this was
the request originally played. If the current delivery point is the request originally played. If the current delivery point is
beyond the stop point, the server SHALL immediately pause delivery. beyond the stop point, the server SHALL immediately pause delivery.
As the request has been completed successfully it shall be responded As the request has been completed successfully it shall be responded
with 200 OK. A PLAY_NOTIFY with end-of-stream is also sent to with 200 OK. A PLAY_NOTIFY with end-of-stream is also sent to
indicate the actual stop point. The pause point is set to the indicate the actual stop point. The pause point is set to the
requested stop point. requested stop point.
Following is an example of this behavior: The server has received Following is an example of this behavior: The server has received
skipping to change at page 76, line 4 skipping to change at page 76, line 47
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 from fast forward or scale of the media, i.e., entering or leaving from fast forward or
fast rewind. The client can issue an updating PLAY request that is fast rewind. The client can issue an updating PLAY request that is
either a continuation or a complete replacement, as discussed above either a continuation or a complete replacement, as discussed above
this section. We give an example of a client that is requesting a this section. We give an example of a client that is requesting a
fast forward without giving a stop point and the change from fast fast forward (scale=2) without giving a stop point and then change
forward to regular playout (scale = 1). from fast forward to regular playout (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: 2034 CSeq: 2034
Session: 12345678 Session: 12345678
Range: npt=now- Range: npt=now-
Scale: 2.0 Scale: 2.0
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 2034 CSeq: 2034
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: 12345678 Session: 12345678
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Range: npt=2:17:21.394- Range: npt=2:17:21.394-
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
[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: 12345678
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: 12345678
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Range: npt=2:19:32.144- Range: npt=2:17:27.144-
Seek-Style: Next Seek-Style: Next
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934239921, ssrc=0D12F123:seq=5712;rtptime=934239921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792842193 ssrc=789DAF12:seq=57654;rtptime=2792842193
13.4.4. Playing On-Demand Media 13.4.4. Playing On-Demand Media
On-demand media is indicated by the content of the Media-Properties On-demand media is indicated by the content of the Media-Properties
header in the SETUP response by (see also Section 16.28): header in the SETUP response by (see also Section 16.28):
skipping to change at page 78, line 4 skipping to change at page 78, line 43
header (see Section 16.29). header (see Section 16.29).
13.4.6. Playing Live Media 13.4.6. Playing Live Media
Live media is indicated by the content of the Media-Properties header Live media is indicated by the content of the Media-Properties header
in the SETUP response by (see also Section 16.28): in the SETUP response by (see also Section 16.28):
o Random-Access set to No-Seeking; o Random-Access set to No-Seeking;
o Content Modifications set to Time-Progressing; o Content Modifications set to Time-Progressing;
o Retention with Time-Duration set to 0.0. o Retention with Time-Duration set to 0.0.
For live media, the SETUP response 200 OK MUST include the Media- For live media, the SETUP response 200 OK MUST include the Media-
Range header (see Section 16.29). Range header (see Section 16.29).
A client MAY send PLAY requests without the Range header. If the A client MAY send PLAY requests without the Range header. If the
request includes the Range header it MUST use a symbolic value request includes the Range header it MUST use a symbolic value
representing "now". For NPT that range specification is "npt=now-". representing "now". For NPT that range specification is "npt=now-".
The server MUST include the Range header in the response and it MUST The server MUST include the Range header in the response and it MUST
indicate an explicit time value and not a symbolic value. In other indicate an explicit time value and not a symbolic value. In other
words, "npt=now-" is not a valid to use in the response. Instead the words, "npt=now-" is not valid to be used in the response. Instead
time since session start is recommended expressed as an open the time since session start is recommended expressed as an open
interval, e.g. "npt=96.23-". An absolute time value (clock) for the interval, e.g. "npt=96.23-". An absolute time value (clock) for the
corresponding time MAY be given, i.e. "clock=20030213T143205Z-". The corresponding time MAY be given, i.e. "clock=20030213T143205Z-". The
UTC clock format can only be used if client has shown support for it UTC clock format can only be used if client has shown support for it
using the Accept-Ranges header. using the Accept-Ranges header.
13.4.7. Playing Live with Recording 13.4.7. Playing Live with Recording
Certain media server may offer recording services of live sessions to Certain media servers may offer recording services of live sessions
their clients. This recording would normally be from the beginning to their clients. This recording would normally be from the
of the media session. Clients can randomly access the media between beginning of the media session. Clients can randomly access the
now and the beginning of the media session. This live media with media between now and the beginning of the media session. This live
recording is indicated by the content of the Media-Properties header media with recording is indicated by the content of the Media-
in the SETUP response by (see also Section 16.28): Properties header in the SETUP response by (see also Section 16.28):
o Random-Access set to Random-Access; o Random-Access set to Random-Access;
o Content Modifications set to Time-Progressing; o Content Modifications set to Time-Progressing;
o Retention set to Time-limited or Unlimited o Retention set to Time-limited or Unlimited
The SETUP response 200 OK MUST include the Media-Range header (see The SETUP response 200 OK MUST include the Media-Range header (see
Section 16.29) for this type of media. For live media with Section 16.29) for this type of media. For live media with
recording, the Range header indicates the current delivery point in recording, the Range header indicates the current delivery point in
skipping to change at page 79, line 7 skipping to change at page 79, line 46
the media). The server adjusts the delivery point to the requested the media). The server adjusts the delivery point to the requested
border of the window, if the client requests a delivery point that is border of the window, if the client requests a delivery point that is
located outside the recording windows, e.g., if requested to far in located outside the recording windows, e.g., if requested to far in
the past, the server selects the oldest range in the recording. The the past, the server selects the oldest range in the recording. The
considerations in Section 13.5.3 apply, if a client requests delivery considerations in Section 13.5.3 apply, if a client requests delivery
with Scale (Section 16.44) values other than 1.0 (Normal playback with Scale (Section 16.44) values other than 1.0 (Normal playback
rate) while delivering live media with recording. rate) while delivering live media with recording.
13.4.8. Playing Live with Time-Shift 13.4.8. Playing Live with Time-Shift
Certain media server may offer time-shift services to their clients. Certain media servers may offer time-shift services to their clients.
This time shift records a fixed interval in the past, i.e., a sliding This time shift records a fixed interval in the past, i.e., a sliding
window recording mechanism, but not past this interval. Clients can window recording mechanism, but not past this interval. Clients can
randomly access the media between now and the interval. This live randomly access the media between now and the interval. This live
media with recording is indicated by the content of the Media- media with recording is indicated by the content of the Media-
Properties header in the SETUP response by (see also Section 16.28): Properties header in the SETUP response by (see also Section 16.28):
o Random-Access set to Random-Access; o Random-Access set to Random-Access;
o Content Modifications set to Time-Progressing; o Content Modifications set to Time-Progressing;
skipping to change at page 80, line 15 skipping to change at page 81, line 7
when adding new Notify-Reasons that intend to use a message body: the when adding new Notify-Reasons that intend to use a message body: the
server can send any type of message body, but it is not ensured that server can send any type of message body, but it is not ensured that
the client can understand the received message body. This is related the client can understand the received message body. This is related
to DESCRIBE (see Section 13.2 ), but in this particular case the to DESCRIBE (see Section 13.2 ), but in this particular case the
client can state its acceptable message bodies by using the Accept client can state its acceptable message bodies by using the Accept
header. In the case of PLAY_NOTIFY, the server does not know which header. In the case of PLAY_NOTIFY, the server does not know which
message bodies are understood by the client. message bodies are understood by the client.
The Notify-Reason header (see Section 16.31) specifies the reason why The Notify-Reason header (see Section 16.31) specifies the reason why
the server sends the PLAY_NOTIFY request. This is extensible and new the server sends the PLAY_NOTIFY request. This is extensible and new
reasons MAY be added in the future. In case the client does not reasons MAY be added in the future (see Section 22.8). In case the
understand the reason for the notification it MUST respond with an client does not understand the reason for the notification it MUST
465 (Notification Reason Unknown) (Section 15.4.30) error code. respond with an 465 (Notification Reason Unknown) (Section 15.4.30)
Servers can send PLAY_NOTIFY with these types: error code. Servers can send PLAY_NOTIFY with these types:
o end-of-stream (see Section 13.5.1); o end-of-stream (see Section 13.5.1);
o media-properties-update (see Section 13.5.2); o media-properties-update (see Section 13.5.2);
o scale-change (see Section 13.5.3). o scale-change (see Section 13.5.3).
13.5.1. End-of-Stream 13.5.1. End-of-Stream
A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream
skipping to change at page 82, line 45 skipping to change at page 83, line 37
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
13.5.3. Scale-Change 13.5.3. Scale-Change
The server may be forced to change the rate, when a client request The server may be forced to change the rate, when a client request
delivery using a Scale (Section 16.44) value other than 1.0 (normal delivery using a Scale (Section 16.44) value other than 1.0 (normal
playback rate). For time progressing media with some retention, i.e. playback rate). For time progressing media with some retention, i.e.
the server stores already sent content, a client requesting to play the server stores already sent content, a client requesting to play
with Scale values larger than 1 may catch up with the front end of with Scale values larger than 1 may catch up with the front end of
the media. The server will then be unable to continue to provide the media. The server will then be unable to continue to provide
with content at Scale larger than 1 as content is only made available content at Scale larger than 1 as content is only made available by
by the server at Scale=1. Another case is when Scale < 1 and the the server at Scale=1. Another case is when Scale < 1 and the media
media retention is time-duration limited. In this case the delivery retention is time-duration limited. In this case the delivery point
point can reach the oldest media unit available, and further playback can reach the oldest media unit available, and further playback at
at this scale becomes impossible as there will be no media available. this scale becomes impossible as there will be no media available.
To avoid having the client lose any media, the scale will need to be To avoid having the client lose any media, the scale will need to be
adjusted to the same rate at which the media is removed from the adjusted to the same rate at which the media is removed from the
storage buffer, commonly Scale = 1.0. storage 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 to 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 another. In this case the server will pick the closest value and
inform the client of what it has picked. In these case 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 used Scale value. This enables a client to adjust the used Scale value.
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 and set Scale to a supportable MUST modify the playback properties and set Scale to a supportable
value and continue delivery the media. When doing this modification value and continue delivery of the media. When doing this
it MUST send a PLAY_NOTIFY message with the Notify-Reason header set modification it MUST send a PLAY_NOTIFY message with the Notify-
to "scale-change". The request MUST contain a Range header with the Reason header set to "scale-change". The request MUST contain a
media time where the change took effect, a Scale header with the new Range header with the media time where the change took effect, a
value in use, Session header with the ID for the session it applies Scale header with the new value in use, Session header with the ID
to and a Date header with the server wallclock time of the change. for the session it applies to and a Date header with the server
For time progressing content also the Media-Range and the Media- wallclock time of the change. For time progressing content also the
Properties at this point in time MUST be included. The Media- Media-Range and the Media-Properties at this point in time MUST be
Properties header MUST be included if the scale change was due to the included. The Media-Properties header MUST be included if the scale
content changing what scale values that is supported. change was due to the content changing what scale values that is
supported.
For media streams being delivered using RTP also a RTP-Info header For media streams being delivered using RTP also a RTP-Info header
MUST be included. It MUST contain the rtptime parameter with a value MUST be included. It MUST contain the rtptime parameter with a value
corresponding to the point of change in that media and optionally corresponding to the point of change in that media and optionally
also the sequence number. also the sequence number.
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
skipping to change at page 84, line 11 skipping to change at page 84, line 51
CSeq: 854 CSeq: 854
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
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 done either with the interrupted (halted). A PAUSE request MUST be done 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 the media URI for non-aggregated sessions. media being halted, or the media URI for non-aggregated sessions.
Any attempt to do muting of a single media with an PAUSE request in Any attempt to do muting of a single media with a PAUSE request in an
an aggregated session MUST be responded to with error 460 (Only aggregated session MUST be responded to with error 460 (Only
Aggregate Operation Allowed). After resuming playback, Aggregate Operation Allowed). After resuming playback,
synchronization of the tracks MUST be maintained. Any server synchronization of the tracks MUST be maintained. Any server
resources are kept, though servers MAY close the session and free resources are kept, though servers MAY close the session and free
resources after being paused for the duration specified with the resources after being paused for the duration specified with the
timeout parameter of the Session header in the SETUP message. timeout parameter of the 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
skipping to change at page 84, line 35 skipping to change at page 85, line 26
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
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 stream needs to be maintained. A subsequent PLAY request without
Range header resume from the pause point and play until media end. Range header resume 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 include 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, will need to use "npt=now-" request to start media delivery again, will need to use "npt=now-"
and not the answer given in the response to PAUSE. and not the 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: 12345678
Range: npt=10-30 Range: npt=10-30
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
skipping to change at page 85, line 31 skipping to change at page 86, line 31
Session: 12345678 Session: 12345678
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: 12345678
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:09 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: 12345678
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:
skipping to change at page 87, line 36 skipping to change at page 88, line 36
When a RTSP client has maintained a RTSP session that otherwise is When a RTSP client has maintained a RTSP session that otherwise is
inactive for an extended period of time the server may reclaim the inactive for an extended period of time the server may reclaim the
resources. That is done by issuing a TEARDOWN request with the resources. That is done by issuing a TEARDOWN request with the
Terminate-Reason set to "Session-Timeout". This MAY be done when the Terminate-Reason set to "Session-Timeout". This MAY be done when the
client has been inactive in the RTSP session for more than one client has been inactive in the RTSP session for more than one
Session Timeout period (Section 16.47). However, the server is Session Timeout period (Section 16.47). However, the server is
RECOMMENDED to not perform this operation until an extended period of RECOMMENDED to not perform this operation until an extended period of
inactivity has passed. The time period is considered extended when inactivity has passed. The time period is considered extended when
it is 10 times the Session Timeout period. Consideration of the it is 10 times the Session Timeout period. Consideration of the
application of the server and its content should be performed when application of the server and its content should be performed when
configuring what is considered as extended periods of time. configuring what is considered as extended period of time.
In case the server needs to stop providing service to the established In case the server needs to stop providing service to the established
sessions and their is no server to point at in a REDIRECT request sessions and there is no server to point at in a REDIRECT request,
TEARDOWN shall be used to terminate the session. This method can then TEARDOWN SHALL be used to terminate the session. This method
also be used when non-recoverable internal errors have happened and can also be used when non-recoverable internal errors have happened
the server has no other option then to terminate the sessions. and the server has no other option then to terminate the sessions.
The TEARDOWN request MUST be only done on the session aggregate The TEARDOWN request MUST be done only on the session aggregate
control URI (i.e., it is not allowed to terminate individual media control URI (i.e., it is not allowed to terminate individual media
streams) and MUST include the following headers; Session and streams, if it is a session aggregate) and MUST include the following
Terminate-Reason headers. The request only applies to the session headers; Session and Terminate-Reason headers. The request only
identified in the Session header. The server may include a message applies to the session identified in the Session header. The server
to the client's user with the "user-msg" parameter. may include a message to the client's user with the "user-msg"
parameter.
The TEARDOWN request may alternatively be done on the wild card URI * The TEARDOWN request may alternatively be done on the wild card URI *
and without any session header. The scope of such a request is and without any session header. The scope of such a request is
limited to the next-hop (i.e. the RTSP agent in direct communication limited to the next-hop (i.e. the RTSP agent in direct communication
with the server) and applies, as well, to the control connection with the server) and applies, as well, to the control connection
between the next-hop RTSP agent and the server. This request between the next-hop RTSP agent and the server. This request
indicates that all sessions and pending requests being managed via indicates that all sessions and pending requests being managed via
the control connection are terminated. Any intervening proxies the control connection are terminated. Any intervening proxies
SHOULD do all of the following in the order listed: SHOULD do all of the following in the order listed:
skipping to change at page 88, line 49 skipping to change at page 90, line 4
body has. body has.
The headers that MAY be used for retrieving their current value using The headers that MAY be used for retrieving their current value using
GET_PARAMETER are: GET_PARAMETER are:
o Accept-Ranges o Accept-Ranges
o Media-Range o Media-Range
o Media-Properties o Media-Properties
o Range o Range
o RTP-Info o RTP-Info
The method MAY also be used without a message body or any header that The method MAY also be used without a message body or any header that
request parameters for keep-alive purpose. Any request that is request parameters for keep-alive purpose. The keep-alive timer has
successful, i.e., a 200 OK response is received, then the keep-alive been updated for any request that is successful, i.e., a 200 OK
timer has been updated. Any non-required header present in such a response is received. Any non-required header present in such a
request may or may not been processed. Normally the presence of request may or may not have been processed. Normally the presence of
filled out values in the header will be indication that the header filled out values in the header will be indication that the header
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. Due to this reason it is usually easier if any parameters to header. Due to 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.
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 these parameters that weren't understood. including a body listing these parameters that weren't understood.
skipping to change at page 90, line 8 skipping to change at page 91, line 14
13.9. SET_PARAMETER 13.9. SET_PARAMETER
This method requests to set the value of a parameter or a set of This method requests to set the value of a parameter or a set of
parameters for a presentation or stream specified by the URI. The parameters for a presentation or stream specified by the URI. The
method MAY also be used without a message body. It is the method MAY also be used without a message body. It is the
RECOMMENDED method to be used in a request sent for the sole purpose RECOMMENDED method to be used in a request sent for the sole purpose
of updating the keep-alive timer. If this request is successful, of updating the keep-alive timer. If this request is successful,
i.e. a 200 OK response is received, then the keep-alive timer has i.e. a 200 OK response is received, then the keep-alive timer has
been updated. Any non-required header present in such a request may been updated. Any non-required header present in such a request may
or may not been processed. To allow a client to determine if any or may not have been processed. To allow a client to determine if
such header has been processed, it is necessary to use a feature tag any such header has been processed, it is necessary to use a feature
and the Require header. Due to this reason it is RECOMMENDED that tag and the Require header. Due to this reason it is RECOMMENDED
any parameters are sent in the body, rather than using any header. that any parameters are sent in the body, rather than using any
header.
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
request does not understand or cannot locate a parameter, error 451 request does not understand or cannot locate a parameter, error 451
(Parameter Not Understood) MUST be used. In the case a parameter is (Parameter Not Understood) MUST be used. In the case a parameter is
not allowed to change, the error code is 458 (Parameter Is Read- not allowed to change, the error code is 458 (Parameter Is Read-
skipping to change at page 91, line 20 skipping to change at page 92, line 20
Content-length: 20 Content-length: 20
Content-type: text/parameters Content-type: text/parameters
barparam: barstuff barparam: barstuff
S->C: RTSP/2.0 451 Parameter Not Understood S->C: RTSP/2.0 451 Parameter Not Understood
CSeq: 421 CSeq: 421
Session: iixT43KLc Session: iixT43KLc
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Mon, 08 Mar 2010 14:44:56 GMT Date: Mon, 08 Mar 2010 14:44:56 GMT
Content-length: 10 Content-length: 20
Content-type: text/parameters Content-type: text/parameters
barparam: barstuff barparam: barstuff
13.10. REDIRECT 13.10. REDIRECT
The REDIRECT method is issued by a server to inform a client that the The REDIRECT method is issued by a server to inform a client that the
service provided will be terminated and where a corresponding service service provided will be terminated and where a corresponding service
can be provided instead. This may happen for different reasons. One can be provided instead. This may happen for different reasons. One
is that the server is being administrated such that it must stop is that the server is being administered such that it must stop
providing service. Thus the client is required to connect to another providing service. Thus the client is required to connect to another
server location to access the resource indicated by the Request-URI. server location to access the resource indicated by the Request-URI.
The REDIRECT request SHALL contain a Terminate-Reason header The REDIRECT request SHALL contain a Terminate-Reason header
(Section 16.50) to inform the client of the reason for the request. (Section 16.50) to inform the client of the reason for the request.
Additional parameters related to the reason may also be included. Additional parameters related to the reason may also be included.
The intention here is to allow a server administrator to do a The intention here is to allow a server administrator to do a
controlled shutdown of the RTSP server. That requires sufficient controlled shutdown of the RTSP server. That requires sufficient
time to inform all entities having associated state with the server time to inform all entities having associated state with the server
and for them to perform a controlled migration from this server to a and for them to perform a controlled migration from this server to a
skipping to change at page 92, line 49 skipping to change at page 93, line 49
receives the successful (2xx) response. The server MAY close the receives the successful (2xx) response. The server MAY close the
signaling connection upon receiving the response and the client signaling connection upon receiving the response and the client
SHOULD close the signaling connection after sending the 2xx response. SHOULD close the signaling connection after sending the 2xx response.
The exception to this is when the client has several sessions on the The exception to this is when the client has several sessions on the
server being managed by the given signaling connection. In this server being managed by the given signaling connection. In this
case, the client SHOULD close the connection when it has received and case, the client SHOULD close the connection when it has received and
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 when the redirection MUST have take place. To the wallclock time by when the redirection MUST have taken place. To
allow a client to determine that redirect time without being time 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 before the redirection time- in the request. The client should have before the redirection time-
line terminated the session and close the control connection. The line terminated the session and closed the control connection. The
server MAY simple cease to provide service when the deadline time has server MAY simple cease to provide service when the deadline time has
been reached, or it may issue TEARDOWN requests to the remaining been reached, or it may issue TEARDOWN requests to the remaining
sessions. sessions.
If the REDIRECT request times out following the rules in Section 10.4 If the REDIRECT request times out following the rules in Section 10.4
the server MAY terminate the session or transport connection that the server MAY terminate the session or transport connection that
would be redirected by the request. This is a safeguard against would be redirected by the request. This is a safeguard against
misbehaving clients that refuse to respond to a REDIRECT request. misbehaving clients that refuse to respond to a REDIRECT request.
That should not provide any benefit. That should not provide any benefit.
skipping to change at page 94, line 37 skipping to change at page 95, line 37
| "$" = 36 | Channel ID | Length in bytes | | "$" = 36 | Channel ID | Length in bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Length number of bytes of binary data : : Length number of bytes of binary data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The channel identifier is defined in the Transport header with the The channel identifier is defined in the Transport header with the
interleaved parameter (Section 16.52). interleaved parameter (Section 16.52).
When the transport choice is RTP, RTCP messages are also interleaved When the transport choice is RTP, RTCP messages are also interleaved
by the server over the TCP connection. The usage of RTCP messages is by the server over the TCP connection. The usage of RTCP messages is
indicated by including a interval containing a second channel in the indicated by including an interval containing a second channel in the
interleaved parameter of the Transport header, see Section 16.52. If interleaved parameter of the Transport header, see Section 16.52. If
RTCP is used, packets MUST be sent on the first available channel RTCP is used, packets MUST be sent on the first available channel
higher than the RTP channel. The channels are bi-directional, using higher than the RTP channel. The channels are bi-directional, using
the same ChannelD in both directions, and therefore RTCP traffic are the same ChannelD in both directions, and therefore RTCP traffic are
sent on the second channel in both directions. sent on the second channel in both directions.
RTCP is sometime needed for synchronization when two or more RTCP is sometimes needed for synchronization when two or more
streams are interleaved in such a fashion. Also, this provides a streams are interleaved in such a fashion. Also, this provides a
convenient way to tunnel RTP/RTCP packets through the TCP control convenient way to tunnel RTP/RTCP packets through the TCP control
connection when required by the network configuration and transfer connection when required by the network configuration and transfer
them onto UDP when possible. them onto UDP when possible.
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, UTC Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
skipping to change at page 96, line 8 skipping to change at page 97, line 8
Range: npt=0-56.8 Range: npt=0-56.8
Seek-Style: RAP Seek-Style: RAP
S->C: $005{2 byte length}{"length" bytes data, w/RTP header} S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
S->C: $005{2 byte length}{"length" bytes data, w/RTP header} S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
S->C: $006{2 byte length}{"length" bytes RTCP packet} S->C: $006{2 byte length}{"length" bytes RTCP packet}
15. Status Code Definitions 15. Status Code Definitions
Where applicable, HTTP status [H10] codes are reused. Status codes Where applicable, HTTP status [H10] codes are reused. Status codes
that have the same meaning are not repeated here. See Table 4 for a that have the same meaning are not repeated here. See Table 4 in
listing of which status codes may be returned by which requests. All Section 8.1 for a listing of which status codes may be returned by
error messages, 4xx and 5xx MAY return a body containing further which requests. All error messages, 4xx and 5xx MAY return a body
information about the error. containing further information about the error.
15.1. Success 1xx 15.1. Success 1xx
15.1.1. 100 Continue 15.1.1. 100 Continue
The client SHOULD continue with its request. This interim response The client SHOULD continue with its request. This interim response
is used to inform the client that the initial part of the request has is used to inform the client that the initial part of the request has
been received and has not yet been rejected by the server. The been received and has not yet been rejected by the server. The
client SHOULD continue by sending the remainder of the request or, if client SHOULD continue by sending the remainder of the request or, if
the request has already been completed, ignore this response. The the request has already been completed, ignore this response. The
skipping to change at page 97, line 14 skipping to change at page 98, line 14
an established session, the client SHOULD send a TEARDOWN request for an established session, the client SHOULD send a TEARDOWN request for
the session, and MAY reestablish the session using the resource the session, and MAY reestablish the session using the resource
indicated by the Location. indicated by the Location.
If the Location header is used in a response it MUST contain an If the Location header is used in a response it MUST contain an
absolute URI pointing out the media resource the client is redirected absolute URI pointing out the media resource the client is redirected
to, the URI MUST NOT only contain the host name. to, the URI MUST NOT only contain the host name.
15.3.1. 301 Moved Permanently 15.3.1. 301 Moved Permanently
The request resource are moved permanently and resides now at the URI The requested resource is moved permanently and resides now at the
given by the location header. The user client SHOULD redirect URI given by the location header. The user client SHOULD redirect
automatically to the given URI. This response MUST NOT contain a automatically to the given URI. This response MUST NOT contain a
message-body. The Location header MUST be included in the response. message-body. The Location header MUST be included in the response.
15.3.2. 302 Found 15.3.2. 302 Found
The requested resource resides temporarily at the URI given by the The requested resource resides temporarily at the URI given by the
Location header. The Location header MUST be included in the Location header. The Location header MUST be included in the
response. This response is intended to be used for many types of response. This response is intended to be used for many types of
temporary redirects; e.g., load balancing. It is RECOMMENDED that temporary redirects; e.g., load balancing. It is RECOMMENDED that
the server set the reason phrase to something more meaningful than the server set the reason phrase to something more meaningful than
skipping to change at page 99, line 44 skipping to change at page 100, line 44
The method specified in the request is not allowed for the resource The method specified in the request is not allowed for the resource
identified by the Request-URI. The response MUST include an Allow identified by the Request-URI. The response MUST include an Allow
header containing a list of valid methods for the requested resource. header containing a list of valid methods for the requested resource.
This status code is also to be used if a request attempts to use a This status code is also to be used if a request attempts to use a
method not indicated during SETUP. method not indicated during SETUP.
15.4.7. 406 Not Acceptable 15.4.7. 406 Not Acceptable
The resource identified by the request is only capable of generating The resource identified by the request is only capable of generating
response message bodies which have content characteristics not response message bodies which have content characteristics not
acceptable according to the accept headers sent in the request. acceptable according to the Accept headers sent in the request.
The response SHOULD include an 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
skipping to change at page 103, line 34 skipping to change at page 104, line 34
15.4.29. 464 Data Transport Not Ready Yet 15.4.29. 464 Data Transport Not Ready Yet
The data transmission channel to the media destination is not yet The data transmission channel to the media destination is not yet
ready for carrying data. However, the responding agent still expects ready for carrying data. However, the responding agent still expects
that the data transmission channel will be established at some point that the data transmission channel will be established at some point
in time. Note, however, that this may result in a permanent failure in time. Note, however, that this may result in a permanent failure
like 462 "Destination Unreachable". like 462 "Destination Unreachable".
An example when this error may occur is in the case a client sends a An example when this error may occur is in the case a client sends a
PLAY request to a server prior to ensuring that the TCP connections PLAY request to a server prior to ensuring that the TCP connections
negotiated for carrying media data was successful established (In negotiated for carrying media data was successfully established (In
violation of this specification). The server would use this error violation of this specification). The server would use this error
code to indicate that the requested action could not be performed due code to indicate that the requested action could not be performed due
to the failure of completing the connection establishment. to the failure of completing the connection establishment.
15.4.30. 465 Notification Reason Unknown 15.4.30. 465 Notification Reason Unknown
This indicates that the client has received a PLAY_NOTIFY This indicates that the client has received a PLAY_NOTIFY
(Section 13.5) with a Notify-Reason header (Section 16.31) unknown to (Section 13.5) with a Notify-Reason header (Section 16.31) unknown to
the client. the client.
skipping to change at page 104, line 13 skipping to change at page 105, line 13
MIKEY according to Appendix C.1.4.1 may result in this error. MIKEY according to Appendix C.1.4.1 may result in this error.
15.4.32. 470 Connection Authorization Required 15.4.32. 470 Connection Authorization Required
The secured connection attempt needs user or client authorization The secured connection attempt needs user or client authorization
before proceeding. The next hops certificate is included in this before proceeding. The next hops certificate is included in this
response in the Accept-Credentials header. response in the Accept-Credentials header.
15.4.33. 471 Connection Credentials not accepted 15.4.33. 471 Connection Credentials not accepted
When performing a secure connection over multiple connections, a When performing a secure connection over multiple connections, an
intermediary has refused to connect to the next hop and carry out the intermediary has refused to connect to the next hop and carry out the
request due to unacceptable credentials for the used policy. request due to unacceptable credentials for the used policy.
15.4.34. 472 Failure to establish secure connection 15.4.34. 472 Failure to establish secure connection
A proxy fails to establish a secure connection to the next hop RTSP A proxy fails to establish a secure connection to the next hop RTSP
agent. This is primarily caused by a fatal failure at the TLS agent. This is primarily caused by a fatal failure at the TLS
handshake, for example due to server not accepting any cipher suits. handshake, for example due to server not accepting any cipher suites.
15.5. Server Error 5xx 15.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 an message body performing the request The server SHOULD include a message body
containing an explanation of the error situation, and whether it is a containing an explanation of the error situation, and whether it is a
temporary or permanent condition. User agents SHOULD display any temporary or permanent condition. User agents SHOULD display any
included message body to the user. These response codes are included message body to the user. These response codes are
applicable to any request method. applicable to any request method.
15.5.1. 500 Internal Server Error 15.5.1. 500 Internal Server Error
The server encountered an unexpected condition which prevented it The server encountered an unexpected condition which prevented it
from fulfilling the request. from fulfilling the request.
skipping to change at page 105, line 23 skipping to change at page 106, line 23
honor the length, if given in the Retry-After header. honor the length, if given in the Retry-After header.
Note: The existence of the 503 status code does not imply that Note: The existence of the 503 status code does not imply that
a server must use it when becoming overloaded. Some servers a server must use it when becoming overloaded. Some servers
may wish to simply refuse the connection. may wish to simply refuse the connection.
15.5.5. 504 Gateway Timeout 15.5.5. 504 Gateway Timeout
The server, while acting as a proxy, did not receive a timely The server, while acting as a proxy, did not receive a timely
response from the upstream server specified by the URI or some other response from the upstream server specified by the URI or some other
auxiliary server (e.g. DNS) it needed to access in attempting to auxiliary server (e.g., DNS) it needed to access in attempting to
complete the request. complete the request.
15.5.6. 505 RTSP Version Not Supported 15.5.6. 505 RTSP Version Not Supported
The server does not support, or refuses to support, the RTSP protocol The server does not support, or refuses to support, the RTSP protocol
version that was used in the request message. The server is version that was used in the request message. The server is
indicating that it is unable or unwilling to complete the request indicating that it is unable or unwilling to complete the request
using the same major version as the client other than with this error using the same major version as the client other than with this error
message. The response SHOULD contain an message body describing why message. The response SHOULD contain a message body describing why
that version is not supported and what other protocols are supported that version is not supported and what other protocols are supported
by that server. by that server.
15.5.7. 551 Option not supported 15.5.7. 551 Option not supported
A feature-tag given in the Require or the Proxy-Require fields was A feature-tag given in the Require or the Proxy-Require fields was
not supported. The Unsupported header MUST be returned stating the not supported. The Unsupported header MUST be returned stating the
feature for which there is no support. feature for which there is no support.
16. Header Field Definitions 16. Header Field Definitions
skipping to change at page 108, line 4 skipping to change at page 109, line 4
*: The header field MUST be present if the message body is not *: The header field MUST be present if the message body is not
empty. See Section 16.16, Section 16.18 and Section 5.3 for empty. See Section 16.16, Section 16.18 and Section 5.3 for
details. details.
-: The header field is not applicable. -: The header field is not applicable.
"Optional" means that a Client/Server MAY include the header field in "Optional" means that a Client/Server MAY include the header field in
a request or response. The Client/Server behavior when receiving a request or response. The Client/Server behavior when receiving
such headers varies, for some it may ignore the header field, in such headers varies, for some it may ignore the header field, in
other case it is request to process the header. This is regulated by other cases it is a request to process the header. This is regulated
the method and header descriptions. Example of headers that require by the method and header descriptions. Example of headers that
processing are the Require and Proxy-Require header fields discussed require processing are the Require and Proxy-Require header fields
in Section 16.41 and Section 16.35. A "mandatory" header field MUST discussed in Section 16.41 and Section 16.35. A "mandatory" header
be present in a request, and MUST be understood by the Client/Server field MUST be present in a request, and MUST be understood by the
receiving the request. A mandatory response header field MUST be Client/Server receiving the request. A mandatory response header
present in the response, and the header field MUST be understood by field MUST be present in the response, and the header field MUST be
the Client/Server processing the response. "Not applicable" means understood by the Client/Server processing the response. "Not
that the header field MUST NOT be present in a request. If one is applicable" means that the header field MUST NOT be present in a
placed in a request by mistake, it MUST be ignored by the Client/ request. If one is placed in a request by mistake, it MUST be
Server receiving the request. Similarly, a header field labeled "not ignored by the Client/Server receiving the request. Similarly, a
applicable" for a response means that the Client/Server MUST NOT header field labeled "not applicable" for a response means that the
place the header field in the response, and the Client/Server MUST Client/Server MUST NOT place the header field in the response, and
ignore the header field in the response. the Client/Server 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 an URI. If the URI The From and Location header fields contain an URI. If the URI
contains a comma, or semicolon, the URI MUST be enclosed in double contains a comma, or semicolon, the URI MUST be enclosed in double
quotes ("). Any URI parameters are contained within these quotes. quotes ("). Any URI parameters are contained within these quotes.
If the URI is not enclosed in double quotas, any semicolon- delimited If the URI is not enclosed in double quote, any semicolon-delimited
parameters are header-parameters, not URI parameters. parameters are header-parameters, not URI parameters.
+------------------+-------+-----+----+-----+-----+-----+-----+-----+ +------------------+-------+-----+----+-----+-----+-----+-----+-----+
| Header | Where | Pro | DE | OPT | STP | PLY | PSE | TRD | | Header | Where | Pro | DE | OPT | STP | PLY | PSE | TRD |
| | | xy | S | | | | | | | | | xy | S | | | | | |
+------------------+-------+-----+----+-----+-----+-----+-----+-----+ +------------------+-------+-----+----+-----+-----+-----+-----+-----+
| Accept | R | | o | - | - | - | - | - | | Accept | R | | o | - | - | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Accept-Credentia | R | rm | o | o | o | o | o | o | | Accept-Credentia | R | rm | o | o | o | o | o | o |
| ls | | | | | | | | | | ls | | | | | | | | |
skipping to change at page 110, line 26 skipping to change at page 111, line 26
| 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 | | o | o | o | o | o | o |
+------------------+-------+-----+----+-----+-----+-----+-----+-----+ +------------------+-------+-----+----+-----+-----+-----+-----+-----+
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 | Prox | DES | OPT | STP | PLY | PSE | TRD | | Header | Where | Prox | DES | OPT | STP | PLY | PSE | TRD |
| | | y | | | | | | | | | | y | | | | | | |
+---------------+--------+------+-----+-----+-----+-----+-----+-----+ +----------------+-------+------+-----+-----+-----+-----+-----+-----+
| Media- | | | - | - | m | m | m | - | | Media- | | | - | - | m | m | m | - |
| Properties | | | | | | | | | | Properties | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Media-Range | | | - | - | m | m | m | - | | Media-Range | | | - | - | m | m | m | - |
| | | | | | | | | | | | | | | | | | | |
| MTag | r | r | o | - | o | - | - | - | | MTag | r | r | o | - | o | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Pipelined- | | amdr | - | o | o | o | o | o | | Pipelined-Requ | | amdr | - | o | o | o | o | o |
| Requests | | | | | | | | | | ests | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Proxy- | 407 | amr | m | m | m | m | m | m | | Proxy- | 407 | amr | m | m | m | m | m | m |
| Authenticate | | | | | | | | | | Authenticate | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Proxy- | R | rd | o | o | o | o | o | o | | Proxy- | R | rd | o | o | o | o | o | o |
| Authorization | | | | | | | | | | Authorization | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Proxy- | R | ar | o | o | o | o | o | o | | Proxy- Require | R | ar | o | o | o | o | o | o |
| Require | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Proxy- Require | r | r | c | c | c | c | c | c |
| Proxy- | r | r | c | c | c | c | c | c | | | | | | | | | | |
| Require | | | | | | | | | | Proxy- | R | amr | c | c | c | c | c | c |
| | | | | | | | | | | Supported | | | | | | | | |
| Proxy- | R | amr | c | c | c | c | c | c | | Proxy- | r | | c | c | c | c | c | c |
| Supported | | | | | | | | | | Supported | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Proxy- | r | | c | c | c | c | c | c | | Public | r | amr | - | m | - | - | - | - |
| Supported | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Public | 501 | amr | m | m | m | m | m | m |
| Public | r | amr | - | m | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Range | R | | - | - | - | o | - | - |
| Public | 501 | amr | m | m | m | m | m | m | | | | | | | | | | |
| | | | | | | | | | | Range | r | | - | - | c | m | m | - |
| Range | R | | - | - | - | o | - | - | | | | | | | | | | |
| | | | | | | | | | | Referrer | R | | o | o | o | o | o | o |
| Range | r | | - | - | c | m | m | - | | | | | | | | | | |
| | | | | | | | | | | Request- | R | | - | - | - | - | - | - |
| Terminate-Rea | R | r | - | - | - | - | - | - | | Status | | | | | | | | |
| son | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Require | R | | o | o | o | o | o | o |
| Referrer | R | | o | o | o | o | o | o | | | | | | | | | | |
| | | | | | | | | | | Retry-After | 3rr,5 | | o | o | o | o | o | - |
| Request- | R | | - | - | - | - | - | - | | | 03 | | | | | | | |
| Status | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Retry-After | 413 | | o | - | - | - | - | - |
| Require | R | | o | o | o | o | o | o | | | | | | | | | | |
| | | | | | | | | | | RTP-Info | r | | - | - | c | c | - | - |
| Retry-After | 3rr,50 | | o | o | o | o | o | - | | | | | | | | | | |
| | 3 | | | | | | | | | Scale | R | r | - | - | - | o | - | - |
| | | | | | | | | | | | | | | | | | | |
| Retry-After | 413 | | o | - | - | - | - | - | | Scale | r | amr | - | - | - | c | - | - |
| | | | | | | | | | | | | | | | | | | |
| RTP-Info | r | | - | - | c | c | - | - | | Seek-Style | R | | - | - | - | o | - | - |
| | | | | | | | | | | | | | | | | | | |
| Scale | R | r | - | - | - | o | - | - | | Seek-Style | r | | - | - | - | m | - | - |
| | | | | | | | | | | | | | | | | | | |
| Scale | r | amr | - | - | - | c | - | - | | Server | R | r | - | o | - | - | - | o |
| | | | | | | | | | | | | | | | | | | |
| Seek-Style | R | | - | - | - | o | - | - | | Server | r | r | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Seek-Style | r | | - | - | - | m | - | - | | Session | R | r | - | o | o | m | m | m |
| | | | | | | | | | | | | | | | | | | |
| Server | R | r | - | o | - | - | - | o | | Session | r | r | - | c | m | m | m | o |
| | | | | | | | | | | | | | | | | | | |
| Server | r | r | o | o | o | o | o | o | | Speed | R | admr | - | - | - | o | - | - |
| | | | | | | | | | | | | | | | | | | |
| Session | R | r | - | o | o | m | m | m | | Speed | r | admr | - | - | - | c | - | - |
| | | | | | | | | | | | | | | | | | | |
| Session | r | r | - | c | m | m | m | o | | Supported | R | amr | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Speed | R | admr | - | - | - | o | - | - | | Supported | r | amr | c | c | c | c | c | c |
| Speed | r | admr | - | - | - | c | - | - | | Terminate-Reas | R | r | - | - | - | - | - | - |
| | | | | | | | | | | on | | | | | | | | |
| Supported | R | amr | o | o | o | o | o | o | | | | | | | | | | |
| | | | | | | | | | | Timestamp | R | admr | o | o | o | o | o | o |
| Supported | r | amr | c | c | c | c | c | c | | | | | | | | | | |
| | | | | | | | | | | Timestamp | c | admr | m | m | m | m | m | m |
| Timestamp | R | admr | o | o | o | o | o | o | | | | | | | | | | |
| | | | | | | | | | | Transport | | mr | - | - | m | - | - | - |
| Timestamp | c | admr | m | m | m | m | m | m | | | | | | | | | | |
| | | | | | | | | | | Unsupported | r | | c | c | c | c | c | c |
| Transport | | mr | - | - | m | - | - | - | | | | | | | | | | |
| | | | | | | | | | | User-Agent | R | | m* | m* | m* | m* | m* | m* |
| Unsupported | r | | c | c | c | c | c | c | | | | | | | | | | |
| | | | | | | | | | | Vary | r | | c | c | c | c | c | c |
| User-Agent | R | | m* | m* | m* | m* | m* | m* | | | | | | | | | | |
| | | | | | | | | | | Via | R | amr | o | o | o | o | o | o |
| Vary | r | | c | c | c | c | c | c | | | | | | | | | | |
| | | | | | | | | | | Via | c | dr | m | m | m | m | m | m |
| Via | R | amr | o | o | o | o | o | o | | | | | | | | | | |
| | | | | | | | | | | WWW- | 401 | | m | m | m | m | m | m |
| Via | c | dr | m | m | m | m | m | m | | Authenticate | | | | | | | | |
| | | | | | | | | | +----------------+-------+------+-----+-----+-----+-----+-----+-----+
| WWW- | 401 | | m | m | m | m | m | m |
| Authenticate | | | | | | | | |
+---------------+--------+------+-----+-----+-----+-----+-----+-----+
Table 10: Overview of RTSP header fields (P-W) related to methods Table 10: Overview of RTSP header fields (M-W) related to methods
DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.
+------------------------+---------+-------+-----+-----+-----+-----+ +------------------------+---------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY | | Header | Where | Proxy | GPR | SPR | RDR | PNY |
+------------------------+---------+-------+-----+-----+-----+-----+ +------------------------+---------+-------+-----+-----+-----+-----+
| Accept | R | arm | o | o | - | - | | Accept | R | arm | o | o | - | - |
| | | | | | | | | | | | | | | |
| Accept-Credentials | R | rm | o | o | o | - | | Accept-Credentials | R | rm | o | o | o | - |
| | | | | | | | | | | | | | | |
| Accept-Encoding | TBD | TBD | TBD | TBD | TBD | TBD |
| | | | | | | |
| Accept-Language | TBD | TBD | TBD | TBD | TBD | TBD |
| | | | | | | |
| Accept-Ranges | | rm | o | - | - | - | | Accept-Ranges | | rm | o | - | - | - |
| | | | | | | | | | | | | | | |
| Allow | 405 | amr | m | m | m | - | | Allow | 405 | amr | m | m | m | - |
| | | | | | | | | | | | | | | |
| Authorization | R | | o | o | o | - | | Authorization | R | | o | o | o | - |
| | | | | | | | | | | | | | | |
| Bandwidth | R | | - | o | - | - | | Bandwidth | R | | - | o | - | - |
| | | | | | | | | | | | | | | |
| Blocksize | R | | - | o | - | - | | Blocksize | R | | - | o | - | - |
| | | | | | | | | | | | | | | |
| Connection | | | o | o | o | o |
| | | | | | | |
| Cache-Control | | r | o | o | - | - | | Cache-Control | | r | o | o | - | - |
| Connection | | | o | o | o | o |
| | | | | | | | | | | | | | | |
| Connection-Credentials | 470,407 | ar | o | o | o | - | | Connection-Credentials | 470,407 | ar | o | o | o | - |
| | | | | | | | | | | | | | | |
| Content-Base | R | | o | o | - | - | | Content-Base | R | | o | o | - | - |
| | | | | | | | | | | | | | | |
| Content-Base | r | | o | o | - | - | | Content-Base | r | | o | o | - | - |
| | | | | | | | | | | | | | | |
| Content-Base | 4xx,5xx | | o | o | o | o | | Content-Base | 4xx,5xx | | o | o | o | o |
| | | | | | | | | | | | | | | |
| Content-Encoding | R | r | o | o | - | - | | Content-Encoding | R | r | o | o | - | - |
skipping to change at page 113, line 50 skipping to change at page 114, line 50
| Content-Type | r | | * | * | - | - | | Content-Type | r | | * | * | - | - |
| | | | | | | | | | | | | | | |
| Content-Type | 4xx,5xx | | * | * | * | * | | Content-Type | 4xx,5xx | | * | * | * | * |
| | | | | | | | | | | | | | | |
| CSeq | R,c | mr | m | m | m | m | | CSeq | R,c | mr | m | m | m | m |
| | | | | | | | | | | | | | | |
| Date | R | a | o | o | m | o | | Date | R | a | o | o | m | o |
| | | | | | | | | | | | | | | |
| Date | r | am | o | o | o | o | | Date | r | am | o | o | o | o |
| | | | | | | | | | | | | | | |
| Expires | TBD | TBD | TBD | TBD | TBD | TBD |
| | | | | | | |
| From | R | r | o | o | o | - |
| | | | | | | |
| If-Match | TBD | TBD | TBD | TBD | TBD | TBD |
| | | | | | | |
| If-Modified-Since | R | am | o | - | - | - | | If-Modified-Since | R | am | o | - | - | - |
| | | | | | | | | | | | | | | |
| If-None-Match | R | am | o | - | - | - | | If-None-Match | R | am | o | - | - | - |
| | | | | | | | | | | | | | | |
| From | R | r | o | o | o | - |
| | | | | | | |
| Last-Modified | R | r | - | - | - | - | | Last-Modified | R | r | - | - | - | - |
| | | | | | | | | | | | | | | |
| Last-Modified | r | r | o | - | - | - | | Last-Modified | r | r | o | - | - | - |
| | | | | | | | | | | | | | | |
| Location | 3rr | | o | o | o | - | | Location | 3rr | | o | o | o | - |
| | | | | | | | | | | | | | | |
| Location | R | | - | - | m | - | | Location | R | | - | - | m | - |
| | | | | | | | | | | | | | | |
| Media-Properties | R | amr | o | - | - | c | | Media-Properties | R | amr | o | - | - | c |
| | | | | | | | | | | | | | | |
| Media-Properties | r | mr | c | - | - | - | | Media-Properties | r | mr | c | - | - | - |
| | | | | | | | | | | | | | | |
| Media-Range | R | | o | - | - | c | | Media-Range | R | | o | - | - | c |
| | | | | | | | | | | | | | | |
| Media-Range | r | | c | - | - | - | | Media-Range | r | | c | - | - | - |
| | | | | | | | | | | | | | | |
| MTag | TBD | TBD | TBD | TBD | TBD | TBD |
| | | | | | | |
| Notify-Reason | R | | - | - | - | m | | Notify-Reason | R | | - | - | - | m |
| | | | | | | | | | | | | | | |
| Pipelined-Requests | R | amdr | o | o | - | - | | Pipelined-Requests | R | amdr | o | o | - | - |
| | | | | | | | | | | | | | | |
| Proxy-Authenticate | 407 | amr | m | m | m | - | | Proxy-Authenticate | 407 | amr | m | m | m | - |
| | | | | | | | | | | | | | | |
| Proxy-Authorization | R | rd | o | o | o | - | | Proxy-Authorization | R | rd | o | o | o | - |
| | | | | | | | | | | | | | | |
| Proxy-Require | R | ar | o | o | o | - | | Proxy-Require | R | ar | o | o | o | - |
| | | | | | | | | | | | | | | |
skipping to change at page 115, line 4 skipping to change at page 116, line 11
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 | - | o | m |
| | | | | | | | | | | | | | | |
| Referrer | R | | o | o | o | - | | Referrer | R | | o | o | o | - |
| | | | | | | |
| Request-Status | R | | - | - | - | c | | Request-Status | R | | - | - | - | c |
| | | | | | | | | | | | | | | |
| Require | R | r | o | o | o | - | | Require | R | r | o | o | o | - |
| | | | | | | | | | | | | | | |
| Retry-After | 3rr,503 | | o | o | - | - | | Retry-After | 3rr,503 | | o | o | - | - |
| | | | | | | | | | | | | | | |
| Retry-After | 413 | | o | o | - | - | | Retry-After | 413 | | o | o | - | - |
| | | | | | | | | | | | | | | |
| RTP-Info | R | r | o | - | - | C | | RTP-Info | R | r | o | - | - | C |
| | | | | | | | | | | | | | | |
| RTP-Info | r | r | c | - | - | - | | RTP-Info | r | r | c | - | - | - |
| | | | | | | | | | | | | | | |
| Scale | | | - | - | - | c | | Scale | | | - | - | - | c |
| | | | | | | | | | | | | | | |
| Seek-Style | | | - | - | - | - | | Seek-Style | | | - | - | - | - |
| | | | | | | | | | | | | | | |
| Session | R | r | o | o | o | m |
| | | | | | | |
| Session | r | r | c | c | o | m |
| | | | | | | |
| Server | R | r | o | o | o | o | | Server | R | r | o | o | o | o |
| | | | | | | | | | | | | | | |
| Server | r | r | o | o | - | - | | Server | r | r | o | o | - | - |
| | | | | | | | | | | | | | | |
| Session | R | r | o | o | o | m |
| | | | | | | |
| Session | r | r | c | c | o | m |
| | | | | | | |
| Speed | | | - | - | - | - | | Speed | | | - | - | - | - |
| | | | | | | | | | | | | | | |
| Supported | R | adrm | o | o | o | - | | Supported | R | adrm | o | o | o | - |
| | | | | | | | | | | | | | | |
| Supported | r | adrm | c | c | c | - | | Supported | r | adrm | c | c | c | - |
| | | | | | | | | | | | | | | |
| Terminate-Reason | R | r | - | - | m | - | | Terminate-Reason | R | r | - | - | m | - |
| | | | | | | | | | | | | | | |
| Timestamp | R | adrm | o | o | o | - | | Timestamp | R | adrm | o | o | o | - |
| | | | | | | | | | | | | | | |
| Timestamp | c | adrm | m | m | m | - | | Timestamp | c | adrm | m | m | m | - |
| | | | | | | | | | | | | | | |
| Transport | TBD | TBD | TBD | TBD | TBD | TBD |
| | | | | | | |
| Unsupported | r | arm | c | c | c | - | | Unsupported | r | arm | c | c | c | - |
| | | | | | | | | | | | | | | |
| User-Agent | R | r | m* | m* | - | - | | User-Agent | R | r | m* | m* | - | - |
| | | | | | | |
| User-Agent | r | r | m* | m* | m* | m* | | User-Agent | r | r | m* | m* | m* | m* |
| | | | | | | | | | | | | | | |
| Vary | r | | c | c | - | - | | Vary | r | | c | c | - | - |
| | | | | | | | | | | | | | | |
| Via | R | amr | o | o | o | - | | Via | R | amr | o | o | o | - |
| | | | | | | | | | | | | | | |
| Via | c | dr | m | m | m | - | | Via | c | dr | m | m | m | - |
| | | | | | | | | | | | | | | |
| WWW-Authenticate | 401 | | m | m | m | - | | WWW-Authenticate | 401 | | m | m | m | - |
+------------------+---------+-------+-----+-----+-----+-----+ +------------------+---------+-------+-----+-----+-----+-----+
skipping to change at page 116, line 31 skipping to change at page 117, line 39
16.2. Accept-Credentials 16.2. Accept-Credentials
The Accept-Credentials header is a request header used to indicate to The Accept-Credentials header is a request header used to indicate to
any trusted intermediary how to handle further secured connections to any trusted intermediary how to handle further secured connections to
proxies or servers. See Section 19 for the usage of this header. It proxies or servers. See Section 19 for the usage of this header. It
MUST NOT be included in server to client requests. MUST NOT be included in server to client requests.
In a request the header MUST contain the method (User, Proxy, or Any) In a request the header MUST contain the method (User, Proxy, or Any)
for approving credentials selected by the requester. The method MUST for approving credentials selected by the requester. The method MUST
NOT be changed by any proxy, unless it is "proxy" when a proxy MAY NOT be changed by any proxy, unless it is "Proxy" when a proxy MAY
change it to "user" to take the role of user approving each further change it to "user" to take the role of user approving each further
hop. If the method is "User" the header contains zero or more of hop. If the method is "User" the header contains zero or more of
credentials that the client accepts. The header may contain zero credentials that the client accepts. The header may contain zero
credentials in the first RTSP request to a RTSP server when using the credentials in the first RTSP request to a RTSP server when using the
"User" method. This as the client has not yet received any "User" method. This as the client has not yet received any
credentials to accept. Each credential MUST consist of one URI credentials to accept. Each credential MUST consist of one URI
identifying the proxy or server, the hash algorithm identifier, and identifying the proxy or server, the hash algorithm identifier, and
the hash over that agent's DER encoded certificate [RFC5280] in the hash over that agent's DER encoded certificate [RFC5280] in
Base64 [RFC4648]. All RTSP clients and proxies MUST implement the Base64 [RFC4648]. All RTSP clients and proxies MUST implement the
SHA-256[FIPS-pub-180-2] algorithm for computation of the hash of the SHA-256[FIPS-pub-180-2] algorithm for computation of the hash of the
skipping to change at page 117, line 13 skipping to change at page 118, line 20
exist. exist.
Example: Example:
Accept-Credentials:User Accept-Credentials:User
"rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=, "rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=,
"rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M= "rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M=
16.3. Accept-Encoding 16.3. Accept-Encoding
The Accept-Encoding request-header field is similar to Accept, but The Accept-Encoding request-header field is similar to Accept, but
restricts the content-codings, i.e. transformation codings of the restricts the content-codings (see Section 16.14),i.e. transformation
message body like gzip compression, that are acceptable in the codings of the message body, such as gzip compression, that are
response. acceptable in the response.
A server tests whether a content-coding is acceptable, according to A server tests whether a content-coding is acceptable, according to
an Accept-Encoding field, using these rules: an Accept-Encoding field, using these rules:
1. If the content-coding is one of the content-codings listed in the 1. If the content-coding is one of the content-codings listed in the
Accept-Encoding field, then it is acceptable, unless it is Accept-Encoding field, then it is acceptable, unless it is
accompanied by a qvalue of 0. (As defined in section 3.9, a accompanied by a qvalue of 0. (As defined in [H3.9], a qvalue of
qvalue of 0 means "not acceptable.") 0 means "not acceptable.")
2. The special "*" symbol in an Accept-Encoding field matches any 2. The special "*" symbol in an Accept-Encoding field matches any
available content-coding not explicitly listed in the header available content-coding not explicitly listed in the header
field. field.
3. If multiple content-codings are acceptable, then the acceptable 3. If multiple content-codings are acceptable, then the acceptable
content-coding with the highest non-zero qvalue is preferred. content-coding with the highest non-zero qvalue is preferred.
4. The "identity" content-coding is always acceptable, i.e. no 4. The "identity" content-coding is always acceptable, i.e. no
transformation at all, unless specifically refused because the transformation at all, unless specifically refused because the
skipping to change at page 118, line 28 skipping to change at page 119, line 32
Each language-range MAY be given an associated quality value which Each language-range MAY be given an associated quality value which
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
example: example:
Accept-Language: da, en-gb;q=0.8, en;q=0.7 Accept-Language: da, en-gb;q=0.8, en;q=0.7
would mean: "I prefer Danish, but will accept British English and would mean: "I prefer Danish, but will accept British English and
other types of English." A language-range matches a language-tag if other types of English." A language-range matches a language-tag if
it exactly equals the tag, or if it exactly equals a prefix of the it exactly equals the full tag, or if it exactly equals a prefix of
tag such that the first tag character following the prefix is "-". the tag, i.e., the primary-tag in the ABNF, such that the character
The special range "*", if present in the Accept-Language field, following primary-tag is "-". The special range "*", if present in
matches every tag not matched by any other range present in the the Accept-Language field, matches every tag not matched by any other
Accept-Language field. range present in the Accept-Language field.
Note: This use of a prefix matching rule does not imply that Note: This use of a prefix matching rule does not imply that
language tags are assigned to languages in such a way that it is language tags are assigned to languages in such a way that it is
always true that if a user understands a language with a certain always true that if a user understands a language with a certain
tag, then this user will also understand all languages with tags tag, then this user will also understand all languages with tags
for which this tag is a prefix. The prefix rule simply allows the for which this tag is a prefix. The prefix rule simply allows the
use of prefix tags if this is the case. use of prefix tags if this is the case.
The language quality factor assigned to a language-tag by the Accept- In the process of selecting a language, each language-tag is assigned
Language field is the quality value of the longest language-range in a qualification factor, i.e., if a language being supported by the
the field that matches the language-tag. If no language-range in the client is actually supported by the server and what "preference"
field matches the tag, the language quality factor assigned is 0. If level the language achieves. The quality value (q-value) of the
no Accept-Language header is present in the request, the server longest language-range in the field that matches the language-tag is
SHOULD assume that all languages are equally acceptable. If an assigned as the qualification factor for a particalr language-tag.
Accept-Language header is present, then all languages which are If no language-range in the field matches the tag, the language
assigned a quality factor greater than 0 are acceptable. qualification factor assigned is 0. If no Accept-Language header is
present in the request, the server SHOULD assume that all languages
are equally acceptable. If an Accept-Language header is present,
then all languages which are assigned a qualification factor greater
than 0 are acceptable.
16.5. Accept-Ranges 16.5. Accept-Ranges
The Accept-Ranges general-header field allows indication of the The Accept-Ranges general-header field allows indication of the
format supported in the Range header. The client MUST include the format supported in the Range header. The client MUST include the
header in SETUP requests to indicate which formats it support to header in SETUP requests to indicate which formats it support to
receive in PLAY and PAUSE responses, and REDIRECT requests. The receive in PLAY and PAUSE responses, and REDIRECT requests. The
server MUST include the header in SETUP and 456 error responses to server MUST include the header in SETUP and 456 error responses to
indicate the formats supported for the resource indicated by the indicate the formats supported for the resource indicated by the
request URI. The header MAY be included in GET_PARAMETER request and request URI. The header MAY be included in GET_PARAMETER request and
response pairs. The GET_PARAMETER request MUST contain a Session response pairs. The GET_PARAMETER request MUST contain a Session
header to identify the session context the request are related to. header to identify the session context the request is related to.
The requester and responder will indicate their capabilities The requester and responder will indicate their capabilities
regarding Range formats respectively. regarding Range formats respectively.
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
The syntax is defined in Section 20.2.3. The syntax is defined in Section 20.2.3.
16.6. Allow 16.6. Allow
The Allow message-header field lists the methods supported by the The Allow message-header field lists the methods supported by the
resource identified by the Request-URI. The purpose of this field is resource identified by the Request-URI. The purpose of this field is
to strictly inform the recipient of valid methods associated with the to strictly inform the recipient of valid methods associated with the
resource. An Allow header field MUST be present in a 405 (Method Not resource. An Allow header field MUST be present in a 405 (Method Not
Allowed) response. The Allow header MUST also be present in all Allowed) response. The Allow header MUST also be present in all
OPTIONS responses where the content of the header will not include OPTIONS responses where the content of the header will not include
exactly the same methods as listed in the Public header. exactly the same methods as listed in the Public header.
The Allow MUST also be included in SETUP and DESCRIBE responses, if The Allow MUST also be included in SETUP and DESCRIBE responses, if
the methods allowed for the resource is different than the minimal the methods allowed for the resource is different than the complete
implementation set. set of methods defined in this memo.
Example of use: Example of use:
Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE
16.7. Authorization 16.7. Authorization
An RTSP client that wishes to authenticate itself with a server using An RTSP client that wishes to authenticate itself with a server using
authentication mechanism from HTTP [RFC2617] , usually, but not authentication mechanism from HTTP [RFC2617] , usually, but not
necessarily, after receiving a 401 response, does so by including an necessarily, after receiving a 401 response, does so by including an
Authorization request-header field with the request. The Authorization request-header field with the request. The
skipping to change at page 120, line 45 skipping to change at page 121, line 51
in kilobits per second. The bandwidth available to the client may in kilobits per second. The bandwidth available to the client may
change during an RTSP session, e.g., due to mobility, congestion, change during an RTSP session, e.g., due to mobility, congestion,
etc. etc.
Clients may not be able to accurately determine the available Clients may not be able to accurately determine the available
bandwidth, for example due to that first hop is not a bottleneck. bandwidth, for example due to that first hop is not a bottleneck.
For example most local area networks (LAN) will not be a bottleneck For example most local area networks (LAN) will not be a bottleneck
if the server is not in the same LAN. Thus link speeds of WLAN or if the server is not in the same LAN. Thus link speeds of WLAN or
Ethernet networks are normally not a basis for estimating the Ethernet networks are normally not a basis for estimating the
available bandwidth. Cellular devices or other devices directly available bandwidth. Cellular devices or other devices directly
connected to an modem or connection enabling device may more connected to a modem or connection enabling device may more
accurately estimate the bottleneck bandwidth and what is reasonable accurately estimate the bottleneck bandwidth and what is reasonable
share of it for RTSP controlled media. The client will also need to share of it for RTSP controlled media. The client will also need to
take into account other traffic sharing the bottleneck. For example take into account other traffic sharing the bottleneck. For example
by only assigning a certain fraction to RTSP and its media streams. by only assigning a certain fraction to RTSP and its media streams.
It is RECOMMENDED that only clients that has accurate and explicit It is RECOMMENDED that only clients that has accurate and explicit
information about bandwidth bottlenecks uses this header. information about bandwidth bottlenecks uses this header.
This header is not a substitute for proper congestion control. Only This header is not a substitute for proper congestion control. Only
a method providing an initial estimate and coarsely determine if the a method providing an initial estimate and coarsely determine if the
selected content can be delivered at all. selected content can be delivered at all.
skipping to change at page 123, line 11 skipping to change at page 124, line 17
plus the specified time in seconds. That is, the client wants plus the specified time in seconds. That is, the client wants
a response that will still be fresh for at least the specified a response that will still be fresh for at least the specified
number of seconds. number of seconds.
must-revalidate: When the must-revalidate directive is present in a must-revalidate: When the must-revalidate directive is present in a
SETUP response received by a cache, that cache MUST NOT use the SETUP response received by a cache, that cache MUST NOT use the
entry after it becomes stale to respond to a subsequent request entry after it becomes stale to respond to a subsequent request
without first revalidating it with the origin server. That is, without first revalidating it with the origin server. That is,
the cache is required to do an end-to-end revalidation every the cache is required to do an end-to-end revalidation every
time, if, based solely on the origin server's Expires, the time, if, based solely on the origin server's Expires, the
cached response is stale.) cached response is stale.
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
skipping to change at page 126, line 9 skipping to change at page 127, line 17
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, a non-transparent proxy MAY modify the content-coding if the However, a non-transparent proxy MAY modify the content-coding if the
new coding is known to be acceptable to the recipient, unless the new coding is known to be acceptable to the recipient, unless the
"no-transform" cache-control directive is present in the message. "no-transform" cache-control directive is present in the message.
If the content-coding of an message body is not "identity", then the If the content-coding of a message body is not "identity", then the
response MUST include a Content-Encoding Message-body header that response 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 an message body in a request message is not If the content-coding of a message body in a request message is not
acceptable to the origin server, the server SHOULD respond with a acceptable to the origin server, the server SHOULD respond with a
status code of 415 (Unsupported Media Type). status code of 415 (Unsupported Media Type).
If multiple encodings have been applied to a message body, the If multiple encodings have been applied to a message body, the
content codings MUST be listed in the order in which they were content codings MUST be listed in the order in which they were
applied, first to last from left to right. Additional information applied, first to last from left to right. Additional information
about the encoding parameters MAY be provided by other header fields about the encoding parameters MAY be provided by other header fields
not defined by this specification. not defined by this specification.
16.15. Content-Language 16.15. Content-Language
skipping to change at page 127, line 4 skipping to change at page 128, line 7
If no Content-Language is specified, the default is that the content If no Content-Language is specified, the default is that the content
is intended for all language audiences. This might mean that the is intended for all language audiences. This might mean that the
sender does not consider it to be specific to any natural language, sender does not consider it to be specific to any natural language,
or that the sender does not know for which language it is intended. or that the sender does not know for which language it is intended.
Multiple languages MAY be listed for content that is intended for Multiple languages MAY be listed for content that is intended for
multiple audiences. For example, a rendition of the "Treaty of multiple audiences. For example, a rendition of the "Treaty of
Waitangi," presented simultaneously in the original Maori and English Waitangi," presented simultaneously in the original Maori and English
versions, would call for versions, would call for
Content-Language: mi, en Content-Language: mi, en
However, just because multiple languages are present within an However, just because multiple languages are present within a message
message body does not mean that it is intended for multiple body does not mean that it is intended for multiple linguistic
linguistic audiences. An example would be a beginner's language audiences. An example would be a beginner's language primer, such as
primer, such as "A First Lesson in Latin," which is clearly intended "A First Lesson in Latin," which is clearly intended to be used by an
to be used by an English-literate audience. In this case, the English-literate audience. In this case, the Content-Language would
Content-Language would properly only include "en". properly only include "en".
Content-Language MAY be applied to any media type -- it is not Content-Language MAY be applied to any media type -- it is not
limited to textual documents. limited to textual documents.
16.16. Content-Length 16.16. Content-Length
The Content-Length general-header field contains the length of the The Content-Length general-header field contains the length of the
message body of the RTSP message (i.e. after the double CRLF message body of the RTSP message (i.e. after the double CRLF
following the last header). Unlike HTTP, it MUST be included in all following the last header). Unlike HTTP, it MUST be included in all
messages that carry a message body beyond the header portion of the messages that carry a message body beyond the header portion of the
skipping to change at page 127, line 42 skipping to change at page 128, line 46
where a resource has multiple variants associated with it, and those where a resource has multiple variants associated with it, and those
entities actually have separate locations by which they might be entities actually have separate locations by which they might be
individually accessed, the server SHOULD provide a Content-Location individually accessed, the server SHOULD provide a Content-Location
for the particular variant which is returned. for the particular variant which is returned.
The Content-Location value is not a replacement for the original The Content-Location value is not a replacement for the original
requested URI; it is only a statement of the location of the resource requested URI; it is only a statement of the location of the resource
corresponding to this particular variant at the time of the request. corresponding to this particular variant at the time of the request.
Future requests MAY specify the Content-Location URI as the request Future requests MAY specify the Content-Location URI as the request
URI if the desire is to identify the source of that particular URI if the desire is to identify the source of that particular
variant. This is useful if the RTSP agent desires verify if the variant. This is useful if the RTSP agent desires to verify if the
resource variant is current through a conditional request. resource variant is current through a conditional request.
A cache cannot assume that an message body with a Content-Location A cache cannot assume that a message body with a Content-Location
different from the URI used to retrieve it can be used to respond to different from the URI used to retrieve it can be used to respond to
later requests on that Content-Location URI. However, the Content- later requests on that Content-Location URI. However, the Content-
Location can be used to differentiate between multiple variants Location can be used to differentiate between multiple variants
retrieved from a single requested resource. retrieved from a single requested resource.
If the Content-Location is a relative URI, the relative URI is If the Content-Location is a relative URI, the relative URI is
interpreted relative to the Request-URI. interpreted relative to the Request-URI.
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 present in session description formats. base-URI for relative URI 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-Location Note also, when using Media Tags in conjunction with Content-Location
it is important that the different versions have different MTags, it is important that the different versions have different MTags,
even if provided under different Content-Location URIs. This as they even if provided under different Content-Location URIs. This as they
have still been provided under the same request URI. have still been provided under the same request URI.
Note also, as in most cases as the URI used in the DESCRIBE and the Note also, as in most cases the URI used in the DESCRIBE and the
SETUP requests are different the URI provided in a DESCRIBE Content- SETUP requests are different, the URI provided in a DESCRIBE Content-
Location response can't directly be used in a SETUP request. Instead Location response can't directly be used in a SETUP request. Instead
the extra step of resolving URIs combined with the media descriptions the extra step of resolving URIs combined with the media descriptions
indication, like with SDP's a=control attribute. indication, like with SDP's a=control attribute.
16.18. Content-Type 16.18. Content-Type
The Content-Type header indicates the media type of the message body The Content-Type header indicates the media type of the message body
sent to the recipient. Note that the content types suitable for RTSP sent to the recipient. Note that the content types suitable for RTSP
are likely to be restricted in practice to presentation descriptions are likely to be restricted in practice to presentation descriptions
and parameter-value types. and parameter-value types.
16.19. CSeq 16.19. CSeq
The CSeq general-header field specifies the sequence number for an The CSeq general-header field specifies the sequence number for an
RTSP request-response pair. This field MUST be present in all RTSP request-response pair. This field MUST be present in all
requests and responses. For every RTSP request containing the given requests and responses. For every RTSP request containing the given
sequence number, the corresponding response will have the same sequence number, the corresponding response will have the same
number. Any retransmitted request MUST contain the same sequence number. Any retransmitted request MUST contain the same sequence
number as the original (i.e. the sequence number is not incremented number as the original (i.e., the sequence number is not incremented
for retransmissions of the same request). For each new RTSP request for retransmissions of the same request). For each new RTSP request
the CSeq value MUST be incremented by one. The initial sequence the CSeq value MUST be incremented by one. The initial sequence
number MAY be any number, however, it is RECOMMENDED to start at 0. number MAY be any number, however, it is RECOMMENDED to start at 0.
Each sequence number series is unique between each requester and Each sequence number series is unique between each requester and
responder, i.e. the client has one series for its request to a server responder, i.e., the client has one series for its request to a
and the server has another when sending request to the client. Each server and the server has another when sending request to the client.
requester and responder is identified with its network address. Each requester and responder is identified with its socket address
(IP address and port number).
Proxies that aggregate several sessions on the same transport will Proxies that aggregate several sessions on the same transport will
have to ensure that the requests sent towards a particular server have to ensure that the requests sent towards a particular server
have a joint sequence number space, i.e., they will regularly need to have a joint sequence number space, i.e., they will regularly need to
renumber the CSeq header field in requests (from proxy to server) and renumber the CSeq header field in requests (from proxy to server) and
responses (from server to proxy) to fulfill the rules for the header. responses (from server to proxy) to fulfill the rules for the header.
The proxy MUST increase the CSeq by one for each request it The proxy MUST increase the CSeq by one for each request it
transmits, without regard of different sessions. transmits, without regard of different sessions.
Example: Example:
skipping to change at page 129, line 27 skipping to change at page 130, line 32
has a clock; has a clock;
o Clients and servers are RECOMMENDED to include a Date header in o Clients and servers are RECOMMENDED to include a Date header in
all other RTSP messages, if the sending host has a clock; all other RTSP messages, if the sending host has a clock;
o If the server does not have a clock that can provide a reasonable o If the server does not have a clock that can provide a reasonable
approximation of the current time, its responses MUST NOT include approximation of the current time, its responses MUST NOT include
a Date header field. In this case, this rule MUST be followed: a Date header field. In this case, this rule MUST be followed:
Some origin server implementations might not have a clock Some origin server implementations might not have a clock
available. An origin server without a clock MUST NOT assign available. An origin server without a clock MUST NOT assign
Expires or Last- Modified values to a response, unless these Expires or Last-Modified values to a response, unless these values
values were associated with the resource by a system or user with were associated with the resource by a system or user with a
a reliable clock. It MAY assign an Expires value that is known, reliable clock. It MAY assign an Expires value that is known, at
at or before server configuration time, to be in the past (this or before server configuration time, to be in the past (this
allows "pre-expiration" of responses without storing separate allows "pre-expiration" of responses without storing separate
Expires values for each resource). Expires values for each resource).
A received message that does not have a Date header field MUST be A received message that does not have a Date header field MUST be
assigned one by the recipient if the message will be cached by that assigned one by the recipient if the message will be cached by that
recipient . An RTSP implementation without a clock MUST NOT cache recipient . An RTSP implementation without a clock MUST NOT cache
responses without revalidating them on every use. An RTSP cache, responses without revalidating them on every use. An RTSP cache,
especially a shared cache, SHOULD use a mechanism, such as NTP, to especially a shared cache, SHOULD use a mechanism, such as NTP, to
synchronize its clock with a reliable external standard. synchronize its clock with a reliable external standard.
skipping to change at page 131, line 31 skipping to change at page 132, line 35
16.23. If-Match 16.23. If-Match
The If-Match request-header field is especially useful for ensuring The If-Match request-header field is especially useful for ensuring
the integrity of the presentation description, independent of how the the integrity of the presentation description, independent of how the
presentation description was received. The presentation description presentation description was received. The presentation description
can be fetched via means external to RTSP (such as HTTP) or via the can be fetched via means external to RTSP (such as HTTP) or via the
DESCRIBE message. In the case of retrieving the presentation DESCRIBE message. In the case of retrieving the presentation
description via RTSP, the server implementation is guaranteeing the description via RTSP, the server implementation is guaranteeing the
integrity of the description between the time of the DESCRIBE message integrity of the description between the time of the DESCRIBE message
and the SETUP message. By including the MTag given in or with the and the SETUP message. By including the MTag given in or with the
session description in a If-Match header part of the SETUP request, session description in an If-Match header part of the SETUP request,
the client ensures that resources set up are matching the the client ensures that resources set up are matching the
description. A SETUP request with the If-Match header for which the description. A SETUP request with the If-Match header for which the
MTag validation check fails, MUST response using 412 (Precondition MTag validation check fails, MUST response using 412 (Precondition
Failed). Failed).
This validation check is also very useful if a session has been This validation check is also very useful if a session has been
redirected from one server to another. redirected from one server to another.
16.24. If-Modified-Since 16.24. If-Modified-Since
skipping to change at page 132, line 17 skipping to change at page 133, line 20
This request header can be used with one or several message body tags This request header can be used with one or several message body tags
to make DESCRIBE requests conditional. A client that has one or more to make DESCRIBE requests conditional. A client that has one or more
message bodies previously obtained from the resource, can verify that message bodies previously obtained from the resource, can verify that
none of those entities is current by including a list of their none of those entities is current by including a list of their
associated message body tags in the If-None-Match header field. The associated message body tags in the If-None-Match header field. The
purpose of this feature is to allow efficient updates of cached purpose of this feature is to allow efficient updates of cached
information with a minimum amount of transaction overhead. As a information with a minimum amount of transaction overhead. As a
special case, the value "*" matches any current entity of the special case, the value "*" matches any current entity of the
resource. resource.
if any of the message body tags match the message body tag of the If any of the message body tags match the message body tag of the
message body that would have been returned in the response to a message body that would have been returned in the response to a
similar DESCRIBE request (without the If-None-Match header) on that similar DESCRIBE request (without the If-None-Match header) on that
resource, or if "*" is given and any current entity exists for that resource, or if "*" is given and any current entity exists for that
resource, then the server MUST NOT perform the requested method, resource, then the server MUST NOT perform the requested method,
unless required to do so because the resource's modification date unless required to do so because the resource's modification date
fails to match that supplied in an If-Modified-Since header field in fails to match that supplied in an If-Modified-Since header field in
the request. Instead, if the request method was DESCRIBE, the server the request. Instead, if the request method was DESCRIBE, the server
SHOULD respond with a 304 (Not Modified) response, including the SHOULD respond with a 304 (Not Modified) response, including the
cache-related header fields (particularly MTag) of one of the message cache-related header fields (particularly MTag) of one of the message
bodies that matched. For all other request methods, the server MUST bodies that matched. For all other request methods, the server MUST
skipping to change at page 133, line 44 skipping to change at page 134, line 49
therefore possible for a response to contain header fields for both therefore possible for a response to contain header fields for both
Location and Content-Location. Also, see Section 18.2 for cache Location and Content-Location. Also, see Section 18.2 for cache
requirements of some methods. requirements of some methods.
16.28. Media-Properties 16.28. Media-Properties
This general header is used in SETUP response or PLAY_NOTIFY requests This general header is used in SETUP response or PLAY_NOTIFY requests
to indicate the media's properties that currently are applicable to to indicate the media's properties that currently are applicable to
the RTSP session. PLAY_NOTIFY MAY be used to modify these properties the RTSP session. PLAY_NOTIFY MAY be used to modify these properties
at any point. However, the client SHOULD have received the update at any point. However, the client SHOULD have received the update
prior to that any action related to the new media properties take prior to any action related to the new media properties take effect.
effect. For aggregated sessions, the Media-Properties header will be For aggregated sessions, the Media-Properties header will be returned
returned in each SETUP response. The header received in the latest in each SETUP response. The header received in the latest response
response is the one that applies on the whole session from this point is the one that applies on the whole session from this point until
until any future update. The header MAY be included without value in any future update. The header MAY be included without value in
GET_PARAMETER requests to the server with a Session header included GET_PARAMETER requests to the server with a Session header included
to query the current Media-Properties for the session. The responder to query the current Media-Properties for the session. The responder
MUST include the current session's media properties. MUST include the current session's media properties.
The media properties expressed by this header is the one applicable The media properties expressed by this header is the one applicable
to all media in the RTSP session. For aggregated sessions, the to all media in the RTSP session. For aggregated sessions, the
header expressed the combined media-properties. As a result header expressed the combined media-properties. As a result,
aggregation of media MAY result in a change of the media properties, aggregation of media MAY result in a change of the media properties,
and thus the content of the Media-Properties header contained in and thus the content of the Media-Properties header contained in
subsequent SETUP responses. subsequent SETUP responses.
The header contains a list of property values that are applicable to The header contains a list of property values that are applicable to
the currently setup media or aggregate of media as indicated by the the currently setup media or aggregate of media as indicated by the
RTSP URI in the request. No ordering are enforced within the header. RTSP URI in the request. No ordering is enforced within the header.
Property values should be grouped into a single group that handles a Property values should be grouped into a single group that handles a
particular orthogonal property. Values or groups that express particular orthogonal property. Values or groups that express
multiple properties SHOULD NOT be used. The list of properties that multiple properties SHOULD NOT be used. The list of properties that
can be expressed MAY be extended at any time. Unknown property can be expressed MAY be extended at any time. Unknown property
values MUST be ignored. values MUST be ignored.
This specification defines the following 4 groups and their property This specification defines the following 4 groups and their property
values: values:
Random Access: Random Access:
skipping to change at page 134, line 43 skipping to change at page 135, line 47
No-Seeking: No seeking is possible. No-Seeking: No seeking is possible.
Content Modifications: Content Modifications:
Immutable: The content will not be changed during the life-time Immutable: The content will not be changed during the life-time
of the RTSP session. of the RTSP session.
Dynamic: The content may be changed based on external methods or Dynamic: The content may be changed based on external methods or
triggers triggers
Time-Progressing The media accessible progress as wallclock time Time-Progressing The media accessible progresses as wallclock
progresses. time progresses.
Retention: Retention:
Unlimited: Content will be retained for the duration of the life- Unlimited: Content will be retained for the duration of the life-
time of the RTSP session. time of the RTSP session.
Time-Limited: Content will be retained at least until the Time-Limited: Content will be retained at least until the
specified wallclock time. The time must be provided in the specified wallclock time. The time must be provided in the
absolute time format specified in Section 4.6. absolute time format specified in Section 4.6.
skipping to change at page 135, line 24 skipping to change at page 136, line 29
a time-progressing session. a time-progressing session.
Supported Scale: Supported Scale:
Scales: A quoted comma separated list of one or more decimal Scales: A quoted comma separated list of one or more decimal
values or ranges of scale values supported by the content in values or ranges of scale values supported by the content in
arbitrary order. A range has a start and stop value separated arbitrary order. A range has a start and stop value separated
by a colon. A range indicates that the content supports fine by a colon. A range indicates that the content supports fine
grained selection of scale values. Fine grained allows for grained selection of scale values. Fine grained allows for
steps at least as small as one tenth of a scale value. steps at least as small as one tenth of a scale value.
Negative values are supported. The value 0 have no meaning and Negative values are supported. The value 0 has no meaning and
must not be used. MUST NOT be used.
Examples of this header for on-demand content and a live stream Examples of this header for on-demand content and a live stream
without recording are: without recording are:
On-demand: On-demand:
Media-Properties: Random-Access=2.5s, Unlimited, Immutable, Media-Properties: Random-Access=2.5s, Unlimited, Immutable,
Scales="-20, -10, -4, 0.5:1.5, 4, 8, 10, 15, 20" Scales="-20, -10, -4, 0.5:1.5, 4, 8, 10, 15, 20"
Live stream without recording/timeshifting: Live stream without recording/timeshifting:
Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0 Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0
skipping to change at page 136, line 9 skipping to change at page 137, line 14
The header MUST include range specifications for all time formats The header MUST include range specifications for all time formats
supported for the media, as indicated in Accept-Ranges header supported for the media, as indicated in Accept-Ranges header
(Section 16.5) when setting up the media. The server MAY include (Section 16.5) when setting up the media. The server MAY include
more than one range specification of any given time format to more than one range specification of any given time format to
indicate media that has non-continuous range. indicate media that has non-continuous range.
For media that has the Time-Progressing property, the Media-Range For media that has the Time-Progressing property, the Media-Range
values will only be valid for the particular point in time when it values will only be valid for the particular point in time when it
was issued. As wallclock progresses so will also the media range. was issued. As wallclock progresses so will also the media range.
However, it shall be assumed that media time progress in direct However, it shall be assumed that media time progresses in direct
relationship to wallclock time (with the exception of clock skew) so relationship to wallclock time (with the exception of clock skew) so
that a reasonably accurate estimation of the media range can be that a reasonably accurate estimation of the media range can be
calculated. calculated.
16.30. MTag 16.30. MTag
The MTag response header MAY be included in DESCRIBE, GET_PARAMETER The MTag response header MAY be included in DESCRIBE, GET_PARAMETER
or SETUP responses. The message body tags (Section 4.8) returned in or SETUP responses. The message body tags (Section 4.8) returned in
a DESCRIBE response, and the one in SETUP refers to the presentation, a DESCRIBE response, and the one in SETUP refers to the presentation,
i.e. both the returned session description and the media stream. i.e. both the returned session description and the media stream.
skipping to change at page 137, line 28 skipping to change at page 138, line 32
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 will be required to be a containing a new unique Pipelined-Requests will be required to be a
SETUP request (unless the protocol is extended with new methods of SETUP request (unless the protocol is extended with new methods of
creating a session). After that first one, additional SETUP requests creating a session). After that first one, additional SETUP requests
or request of any type using the RTSP session context may include the or request of any type using the RTSP session context may include the
Pipelined-Requests header. 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 binding header the server MUST also include the Session header when a binding
to a session context exist. A RTSP agent that knows the session ID to a session context exist. An RTSP agent that knows the session ID
SHOULD NOT use the Pipelined-Requests header in any request and only SHOULD NOT use the Pipelined-Requests header in any request and only
use the Session header. This as the Session identifier is persistent use the Session header. This as the Session identifier is persistent
across transport contexts, like TCP connections, which the Pipelined- across transport contexts, like TCP connections, which the Pipelined-
Requests identifier is not. Requests identifier is not.
The RTSP agent sending the request with a Pipelined-Requests header The RTSP agent sending the request with a Pipelined-Requests header
has the responsibility for using a unique and previously unused has the responsibility for using a unique and previously unused
identifier within the transport context. Currently only a TCP identifier within the transport context. Currently only a TCP
connection is defined as such transport context. A server MUST connection is defined as such transport context. A server MUST
delete the Pipelined-Requests identifier and its binding to a session delete the Pipelined-Requests identifier and its binding to a session
skipping to change at page 138, line 25 skipping to change at page 139, line 31
The Proxy-Authorization request-header field allows the client to The Proxy-Authorization request-header field allows the client to
identify itself (or its user) to a proxy which requires identify itself (or its user) to a proxy which requires
authentication. The Proxy-Authorization field value consists of authentication. The Proxy-Authorization field value consists of
credentials containing the authentication information of the user credentials containing the authentication information of the user
agent for the proxy and/or realm of the resource being requested. agent for the proxy and/or realm of the resource being requested.
The HTTP access authentication process is described in [RFC2617]. The HTTP access authentication process is described in [RFC2617].
Unlike Authorization, the Proxy-Authorization header field applies Unlike Authorization, the Proxy-Authorization header field applies
only to the next outbound proxy that demanded authentication using only to the next outbound proxy that demanded authentication using
the Proxy- Authenticate field. When multiple proxies are used in a the Proxy-Authenticate field. When multiple proxies are used in a
chain, the Proxy-Authorization header field is consumed by the first chain, the Proxy-Authorization header field is consumed by the first
outbound proxy that was expecting to receive credentials. A proxy outbound proxy that was expecting to receive credentials. A proxy
MAY relay the credentials from the client request to the next proxy MAY relay the credentials from the client request to the next proxy
if that is the mechanism by which the proxies cooperatively if that is the mechanism by which the proxies cooperatively
authenticate a given request. authenticate a given request.
16.35. Proxy-Require 16.35. Proxy-Require
The Proxy-Require request-header field is used to indicate proxy- The Proxy-Require request-header field is used to indicate proxy-
sensitive features that MUST be supported by the proxy. Any Proxy- sensitive features that MUST be supported by the proxy. Any Proxy-
skipping to change at page 139, line 16 skipping to change at page 140, line 20
The Proxy-Supported header field enumerates all the extensions The Proxy-Supported header field enumerates all the extensions
supported by the proxy using feature-tags. The header carries the supported by the proxy using feature-tags. The header carries the
intersection of extensions supported by the forwarding proxies. The intersection of extensions supported by the forwarding proxies. The
Proxy-Supported header MAY be included in any request by a proxy. It Proxy-Supported header MAY be included in any request by a proxy. It
MUST be added by any proxy if the Supported header is present in a MUST be added by any proxy if the Supported header is present in a
request. When present in a request, the receiver MUST in the request. When present in a request, the receiver MUST in the
response copy the received Proxy-Supported header. response copy the received Proxy-Supported header.
The Proxy-Supported header field contains a list of feature-tags The Proxy-Supported header field contains a list of feature-tags
applicable to proxies, as described in Section 4.7. The list are the applicable to proxies, as described in Section 4.7. The list is the
intersection of all feature-tags understood by the proxies. To intersection of all feature-tags understood by the proxies. To
achieve an intersection, the proxy adding the Proxy-Supported header achieve an intersection, the proxy adding the Proxy-Supported header
includes all proxy feature-tags it understands. Any proxy receiving includes all proxy feature-tags it understands. Any proxy receiving
a request with the header, checks the list and removes any feature- a request with the header, MUST check the list and removes any
tag it do not support. A Proxy-Supported header present in the feature-tag(s) it does not support. A Proxy-Supported header present
response MUST NOT be touched by the proxies. in the response MUST NOT be touched by the proxies.
Example: Example:
C->P1: OPTIONS rtsp://example.com/ RTSP/2.0 C->P1: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech Supported: foo, bar, blech
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0 P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech Supported: foo, bar, blech
Proxy-Supported: proxy-foo, proxy-bar, proxy-blech Proxy-Supported: proxy-foo, proxy-bar, proxy-blech
Via: 2.0 pro.example.com Via: 2.0 pro.example.com
skipping to change at page 142, line 39 skipping to change at page 143, line 47
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.
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 Referee and From information. enable/disable the sending of Referrer and From information.
Clients SHOULD NOT include a Referee header field in a (non-secure) Clients SHOULD NOT include a Referrer header field in a (non-secure)
RTSP request if the referring page was transferred with a secure RTSP request if the referring page was transferred with a secure
protocol. protocol.
16.40. Request-Status 16.40. Request-Status
This request header is used to indicate the end result for requests This request header is used to indicate the end result for requests
that takes time to complete, such a PLAY (Section 13.4). It is sent that takes time to complete, such a PLAY (Section 13.4). It is sent
in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report
how the PLAY request concluded, either in success or in failure. The how the PLAY request concluded, either in success or in failure. The
header carries a reference to the request it reports on using the header carries a reference to the request it reports on using the
skipping to change at page 143, line 24 skipping to change at page 144, line 32
ensure that the other end-point supports features that are required ensure that the other end-point supports features that are required
in respect to this request. It can also be used to query if the in respect to this request. It can also be used to query if the
other end-point supports certain features, however, the use of the other end-point supports certain features, however, the use of the
Supported (Section 16.49) is much more effective in this purpose. Supported (Section 16.49) is much more effective in this purpose.
The server MUST respond to this header by using the Unsupported The server MUST respond to this header by using the Unsupported
header to negatively acknowledge those feature-tags which are NOT header to negatively acknowledge those feature-tags which are NOT
supported. The response MUST use the error code 551 (Option Not supported. The response MUST use the error code 551 (Option Not
Supported). This header does not apply to proxies, for the same Supported). This header does not apply to proxies, for the same
functionality in respect to proxies see Proxy-Require header functionality in respect to proxies see Proxy-Require header
(Section 16.35) with the exception of media modifying proxies. Media (Section 16.35) with the exception of media modifying proxies. Media
modifying proxies due to their nature of handling media in a way that modifying proxies, due to their nature of handling media in a way
is very similar to what a server, do need to understand also the that is very similar to a server, do need to understand also the
server features to correctly serve the client. server features to correctly serve the client.
This is to make sure that the client-server interaction will This is to make sure that the client-server interaction will
proceed without delay when all features are understood by both proceed without delay when all features are understood by both
sides, and only slow down if features are not understood (as in sides, and only slow down if features are not understood (as in
the example below). For a well-matched client-server pair, the the example below). For a well-matched client-server pair, the
interaction proceeds quickly, saving a round-trip often required interaction proceeds quickly, saving a round-trip often required
by negotiation mechanisms. In addition, it also removes state by negotiation mechanisms. In addition, it also removes state
ambiguity when the client requires features that the server does ambiguity when the client requires features that the server does
not understand. not understand.
skipping to change at page 144, line 19 skipping to change at page 145, line 34
(see Section 16.35). See discussion in the proxies section (see Section 16.35). See discussion in the proxies section
(Section 17.1) about when to consider that a feature requires proxy (Section 17.1) about when to consider that a feature requires proxy
support. support.
16.42. Retry-After 16.42. Retry-After
The Retry-After response-header field can be used with a 503 (Service The Retry-After response-header field can be used with a 503 (Service
Unavailable) response to indicate how long the service is expected to Unavailable) response to indicate how long the service is expected to
be unavailable to the requesting client. This field MAY also be used be unavailable to the requesting client. This field MAY also be used
with any 3xx (Redirection) response to indicate the minimum time the with any 3xx (Redirection) response to indicate the minimum time the
user-agent is asked wait before issuing the redirected request. The user-agent is asked to wait before issuing the redirected request.
value of this field can be either an RTSP-date or an integer number The value of this field can be either an RTSP-date or an integer
of seconds (in decimal) after the time of the response. number of seconds (in decimal) after the time of the response.
Example: Example:
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120 Retry-After: 120
In the latter example, the delay is 2 minutes. In the latter example, the delay is 2 minutes.
16.43. RTP-Info 16.43. RTP-Info
The RTP-Info general field is used to set RTP-specific parameters in The RTP-Info general header field is used to set RTP-specific
the PLAY and GET_PARAMETER responses or a PLAY_NOTIFY and parameters in the PLAY and GET_PARAMETER responses or a PLAY_NOTIFY
GET_PARAMETER requests. For streams using RTP as transport protocol and GET_PARAMETER requests. For streams using RTP as transport
the RTP-Info header SHOULD be part of a 200 response to PLAY. protocol the RTP-Info header SHOULD be part of a 200 response to
PLAY.
The exclusion of the RTP-Info in a PLAY response for RTP The exclusion of the RTP-Info in a PLAY response for RTP
transported media will result in that a client needs to transported media will result in that a client needs to
synchronize the media streams using RTCP. This may have negative synchronize the media streams using RTCP. This may have negative
impact as the RTCP can be lost, and does not need to be impact as the RTCP can be lost, and does not need to be
particularly timely in their arrival. Also functionality as particularly timely in its arrival. Also functionality as
informing the client from which packet a seek has occurred is informing the client from which packet a seek has occurred is
affected. affected.
The RTP-Info MAY be included in SETUP responses to provide The RTP-Info MAY be included in SETUP responses to provide
synchronization information when changing transport parameters, see synchronization information when changing transport parameters, see
Section 13.3. The RTP-Info header and the Range header MAY be Section 13.3. The RTP-Info header and the Range header MAY be
included in a GET_PARAMETER request from client to server without any included in a GET_PARAMETER request from client to server without any
values to request the current playback point and corresponding. RTP values to request the current playback point and corresponding RTP
synchronization information. When the RTP-Info header is included in synchronization information. When the RTP-Info header is included in
a Request also the Range header MUST be included (Note, Range header a Request also the Range header MUST be included (Note, Range header
only MAY be used). The server response SHALL include both the Range only MAY be used). The server response SHALL include both the Range
header and the RTP-Info header. If the session is in Play state, header and the RTP-Info header. If the session is in Play state,
then the value of the Range header SHALL be filled in with the then the value of the Range header SHALL be filled in with the
current playback point and with the corresponding RTP-Info values. current playback point and with the corresponding RTP-Info values.
If the server is another state, no values are included in the RTP- If the server is another state, no values are included in the RTP-
Info header. The header is included in PLAY_NOTIFY requests with the Info header. The header is included in PLAY_NOTIFY requests with the
Notify-Reason of end-of-stream to provide RTP information about the Notify-Reason of end-of-stream to provide RTP information about the
end of the stream. end of the stream.
The header can carry the following parameters: The header can carry the following parameters:
url: Indicates the stream URI which for which the following RTP url: Indicates the stream URI for which the following RTP parameters
parameters correspond, this URI MUST be the same used in the correspond, this URI MUST be the same as used in the SETUP
SETUP request for this media stream. Any relative URI MUST use request for this media stream. Any relative URI MUST use the
the Request-URI as base URI. This parameter MUST be present. Request-URI as base URI. This parameter MUST be present.
ssrc: The Synchronization source (SSRC) that the RTP timestamp and ssrc: The Synchronization source (SSRC) that the RTP timestamp and
sequence number provide applies to. This parameter MUST be sequence number provided applies to. This parameter MUST be
present. present.
seq: Indicates the sequence number of the first packet of the stream seq: Indicates the sequence number of the first packet of the stream
that is direct result of the request. This allows clients to that is direct result of the request. This allows clients to
gracefully deal with packets when seeking. The client uses gracefully deal with packets when seeking. The client uses
this value to differentiate packets that originated before the this value to differentiate packets that originated before the
seek from packets that originated after the seek. Note that a seek from packets that originated after the seek. Note that a
client may not receive the packet with the expressed sequence client may not receive the packet with the expressed sequence
number, and instead packets with a higher sequence number, due number, and instead packets with a higher sequence number, due
to packet loss or reordering. This parameter is RECOMMENDED to to packet loss or reordering. This parameter is RECOMMENDED to
be present. be present.
rtptime: MUST indicate the RTP timestamp value corresponding to the rtptime: MUST indicate the RTP timestamp value corresponding to the
start time value in the Range response header, or if not start time value in the Range response header, or if not
explicitly given the implied start point. The client uses this explicitly given the implied start point. The client uses this
value to calculate the mapping of RTP time to NPT or other value to calculate the mapping of RTP time to NPT or other
media timescale. This parameter SHOULD be present to ensure media timescale. This parameter SHOULD be present to ensure
inter-media synchronization is achieved. There exist no inter-media synchronization is achieved. There exists no
requirement that any received RTP packet will have the same RTP requirement that any received RTP packet will have the same RTP
timestamp value as the one in the parameter used to establish timestamp value as the one in the parameter used to establish
synchronization. synchronization.
A mapping from RTP timestamps to NTP timestamps (wallclock) is A mapping from RTP timestamps to NTP timestamps (wallclock) is
available via RTCP. However, this information is not sufficient available via RTCP. However, this information is not sufficient
to generate a mapping from RTP timestamps to media clock time to generate a mapping from RTP timestamps to media clock time
(NPT, etc.). Furthermore, in order to ensure that this (NPT, etc.). Furthermore, in order to ensure that this
information is available at the necessary time (immediately at information is available at the necessary time (immediately at
startup or after a seek), and that it is delivered reliably, this startup or after a seek), and that it is delivered reliably, this
skipping to change at page 147, line 43 skipping to change at page 149, line 19
will pick the first media samples or the first random access point will pick the first media samples or the first random access point
prior to the request range. Depending on use case, the client may prior to the request range. Depending on use case, the client may
have a strong preference. To express this preference and provide the have a strong preference. To express this preference and provide the
client with information on how the server actually acted on that client with information on how the server actually acted on that
preference the Seek-Style header is defined. preference the Seek-Style header is defined.
Seek-Style is a general header that MAY be included in any PLAY Seek-Style is a general header that MAY be included in any PLAY
request to indicate the client's preference for any media stream that request to indicate the client's preference for any media stream that
has random access properties. The server MUST always include the has random access properties. The server MUST always include the
header in any PLAY response for media with random access properties header in any PLAY response for media with random access properties
to indicate what policy was applied. A server that receives a to indicate what policy was applied. A server that receives an
unknown Seek-Style policy MUST ignore it and select the server unknown Seek-Style policy MUST ignore it and select the server
default policy. A client receiving an unknown policy MUST ignore it default policy. A client receiving an unknown policy MUST ignore it
and use the Range header and any media synchronization information as and use the Range header and any media synchronization information as
basis to determine what the server did. basis to determine what the server did.
This specification defines the following seek policies that may be This specification defines the following seek policies that may be
requested (see also Section Section 4.9.1): requested (see also Section 4.9.1):
RAP: Random Access Point (RAP) is the behavior of requesting the RAP: Random Access Point (RAP) is the behavior of requesting the
server to locate the closest previous random access point that server to locate the closest previous random access point that
exist in the media aggregate and deliver from that. By requesting exists in the media aggregate and deliver from that. By
a RAP, media quality will be the best possible as all media will requesting a RAP, media quality will be the best possible as all
be delivered from a point where full media state can be media will be delivered from a point where full media state can be
established in the media decoder. established in the media decoder.
CoRAP: Conditional Random Access Point (CoRAP) is a variant of the CoRAP: Conditional Random Access Point (CoRAP) is a variant of the
above RAP behavior. This policy is primarily intended for cases above RAP behavior. This policy is primarily intended for cases
where there are larger distance between the random access points where there is larger distance between the random access points in
in the media. CoRAP is conditioned on that there is a Random the media. CoRAP is conditioned on that there is a Random Access
Access Point closer to the requested start point than to the Point closer to the requested start point than to the current
current pause point. This policy assumes that the media state pause point. This policy assumes that the media state existing
existing prior to the pause is usable if delivery is continued. prior to the pause is usable if delivery is continued. If the
If the client or server knows that this is not the fact the RAP client or server knows that this is not the fact the RAP policy
policy should be used. In other words: in most cases when the should be used. In other words: in most cases when the client
client requests a start point prior to the current pause point, a requests a start point prior to the current pause point, a valid
valid decoding dependency chain from the media delivered prior to decoding dependency chain from the media delivered prior to the
the pause and to the requested media unit will not exist. If the pause and to the requested media unit will not exist. If the
server searched to a random access point the server MUST return server searched to a random access point the server MUST return
the CoRAP policy in the Seek-Style header and adjust the Range the CoRAP policy in the Seek-Style header and adjust the Range
header to reflect the position of the picked RAP. In case the header to reflect the position of the picked RAP. In case the
random access point is further away and the server selects to random access point is further away and the server selects to
continue from the current pause point it MUST include the "Next" continue from the current pause point it MUST include the "Next"
policy in the Seek-Style header and adjust the Range header start policy in the Seek-Style header and adjust the Range header start
point to the current pause point. point to the current pause point.
First-Prior: The first-prior policy will start delivery with the First-Prior: The first-prior policy will start delivery with the
media unit that has a playout time first prior to the requested media unit that has a playout time first prior to the requested
time. For discrete media that would only include media units that time. For discrete media that would only include media units that
would still be rendered at the request time. For continuous media would still be rendered at the request time. For continuous media
that is media that will be render during the requested start time that is media that will be rendered during the requested start
of the range. time of the range.
Next: The next media units after the provided start time of the Next: The next media units after the provided start time of the
range. For continuous framed media that would mean the first next range. For continuous framed media that would mean the first next
frame after the provided time. For discrete media the first unit frame after the provided time. For discrete media the first unit
that is to be rendered after the provided time. The main usage is that is to be rendered after the provided time. The main usage
for this case is when the client knows it has all media up to a for this case is when the client knows it has all media up to a
certain point and would like to continue delivery so that a certain point and would like to continue delivery so that a
complete non-interrupted media playback can be achieved. Example complete non-interrupted media playback can be achieved. Example
of such scenarios include switching from a broadcast/multicast of such scenarios include switching from a broadcast/multicast
delivery to a unicast based delivery. This policy MUST only be delivery to a unicast based delivery. This policy MUST only be
used on the client's explicit request. used on the client's explicit request.
Please note that these expressed preferences exist for optimizing the Please note that these expressed preferences exist for optimizing the
startup time or the media quality. The "Next" policy breaks the startup time or the media quality. The "Next" policy breaks the
normal definition of the Range header to enable a client to request normal definition of the Range header to enable a client to request
skipping to change at page 149, line 26 skipping to change at page 150, line 49
can contain multiple product tokens and comments identifying the can contain multiple product tokens and comments identifying the
server and any significant subproducts. The product tokens are server and any significant subproducts. The product tokens are
listed in order of their significance for identifying the listed in order of their significance for identifying the
application. application.
Example: Example:
Server: PhonyServer/1.0 Server: PhonyServer/1.0
If the response is being forwarded through a proxy, the proxy If the response is being forwarded through a proxy, the proxy
application MUST NOT modify the Server response-header. Instead, it application MUST NOT modify the Server response-header. Instead, it
SHOULD include a Via field (Section 16.56). SHOULD include a Via field (Section 16.56). If the response is
generated by the proxy, the proxy application MUST return the Server
response-header as previously returned by the server.
16.47. Session 16.47. Session
The Session request-header and response-header field identifies an The Session request-header and response-header field identifies an
RTSP session. An RTSP session is created by the server as a result RTSP session. An RTSP session is created by the server as a result
of a successful SETUP request and in the response the session of a successful SETUP request and in the response the session
identifier is given to the client. The RTSP session exist until identifier is given to the client. The RTSP session exists until
destroyed by a TEARDOWN, REDIRECT or timed out by the server. destroyed by a TEARDOWN, REDIRECT or timed out by the server.
The session identifier is chosen by the server (see Section 4.3) and The session identifier is chosen by the server (see Section 4.3) and
MUST be returned in the SETUP response. Once a client receives a MUST be returned in the SETUP response. Once a client receives a
session identifier, it MUST be included in any request related to session identifier, it MUST be included in any request related to
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, and a request, using the following methods: PLAY, PAUSE, and TEARDOWN,
MAY be included in SETUP, OPTIONS, SET_PARAMETER, GET_PARAMETER, and and MAY be included in SETUP, OPTIONS, SET_PARAMETER, GET_PARAMETER,
REDIRECT, and MUST NOT be included in DESCRIBE. In an RTSP response and REDIRECT, and MUST NOT be included in DESCRIBE. The Session
the session header MUST be included in methods, SETUP, PLAY, and header MUST NOT be included in the following methods, if these
PAUSE, and MAY be included in methods, TEARDOWN, and REDIRECT, and if requests are pipelined and if the session identifier is not yet
included in the request of the following methods it MUST also be known: PLAY, PAUSE, TEARDOWN, SETUP, OPTIONS SET_PARAMETER, and
included in the response, OPTIONS, GET_PARAMETER, and SET_PARAMETER, GET_PARAMETER.
and MUST NOT be included in DESCRIBE.
In an RTSP response the session header MUST be included in methods,
SETUP, PLAY, and PAUSE, and MAY be included in methods, TEARDOWN, and
REDIRECT, and if included in the request of the following methods it
MUST also be included in the response, OPTIONS, GET_PARAMETER, and
SET_PARAMETER, and 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 which URIs that are there are restrictions depending on the session which URIs that 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 150, line 23 skipping to change at page 152, line 6
identifier is invalid. identifier is invalid.
The header MAY include the session timeout period. If not explicitly The header MAY include the session timeout period. If not explicitly
provided this value is set to 60 seconds. As this affects how often provided this value is set to 60 seconds. As this affects how often
session keep-alives are needed values smaller than 30 seconds are not session keep-alives are needed values smaller than 30 seconds are not
recommended. However, larger than default values can be useful in recommended. However, larger than default values can be useful in
applications of RTSP that have inactive but established sessions for applications of RTSP that have inactive but established sessions for
longer time periods. longer time periods.
60 seconds was chosen as session timeout value due to: Resulting 60 seconds was chosen as session timeout value due to: Resulting
in not to frequent keep-alive messages and having low sensitivity in not too frequent keep-alive messages and having low sensitivity
to variations in request response timing. If one reduces the to variations in request response timing. If one reduces the
timeout value to below 30 seconds the corresponding request timeout value to below 30 seconds the corresponding request
response timeout becomes a significant part of the session response timeout becomes a significant part of the session
timeout. 60 seconds also allows for reasonably rapid recovery of timeout. 60 seconds also allows for reasonably rapid recovery of
committed server resources in case of client failure. committed server resources in case of client failure.
16.48. Speed 16.48. Speed
The Speed request-header field requests the server to deliver The Speed request-header field requests the server to deliver
specific amounts of nominal media time per unit of delivery time, specific amounts of nominal media time per unit of delivery time,
contingent on the server's ability and desire to serve the media contingent on the server's ability and desire to serve the media
stream at the given speed. The client requests the delivery speed to stream at the given speed. The client requests the delivery speed to
be within a given range with an lower and upper bound. The server be within a given range with a lower and upper bound. The server
SHALL deliver at the highest possible speed within the range, but not SHALL deliver at the highest possible speed within the range, but not
faster than the upper-bound, for which the underlying network path faster than the upper-bound, for which the underlying network path
can support the resulting transport data rates. As long as any speed can support the resulting transport data rates. As long as any speed
value within the given range can be provided the server SHALL NOT value within the given range can be provided the server SHALL NOT
modify the media quality. Only if the server is unable to delivery modify the media quality. Only if the server is unable to deliver
media at the speed value provided by the lower bound shall it reduce media at the speed value provided by the lower bound shall it reduce
the media quality. the media quality.
Implementation of the Speed functionality by the server is OPTIONAL. Implementation of the Speed functionality by the server is OPTIONAL.
The server can indicate its support through a feature-tag, The server can indicate its support through a feature-tag,
play.speed. The lack of a Speed header in the response is an play.speed. The lack of a Speed header in the response is an
indication of lack of support of this functionality. indication of lack of support of this functionality.
The speed parameter values are expressed as a positive decimal value, The speed parameter values are expressed as a positive decimal value,
e.g., a value of 2.0 indicates that data is to be delivered twice as e.g., a value of 2.0 indicates that data is to be delivered twice as
skipping to change at page 151, line 35 skipping to change at page 153, line 17
Thus the media transport needs to support feedback so that the server Thus the media transport needs to support feedback so that the server
can react and adapt to the available bitrate. can react and adapt to the available bitrate.
16.49. Supported 16.49. Supported
The Supported header enumerates all the extensions supported by the The Supported header enumerates all the extensions supported by the
client or server using feature tags. The header carries the client or server using feature tags. The header carries the
extensions supported by the message sending client or server. The extensions supported by the message sending client or server. The
Supported header MAY be included in any request. When present in a Supported header MAY be included in any request. When present in a
request, the receiver MUST respond with its corresponding Supported request, the receiver MUST respond with its corresponding Supported
header. Note that the supported headers is also included in 4xx and header. Note that the Supported header is also included in 4xx and
5xx responses. 5xx responses.
The Supported header contains a list of feature-tags, described in The Supported header contains a list of feature-tags, described in
Section 4.7, that are understood by the client or server. Section 4.7, that are understood by the client or server.
Example: Example:
C->S: OPTIONS rtsp://example.com/ RTSP/2.0 C->S: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech Supported: foo, bar, blech
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
skipping to change at page 152, line 42 skipping to change at page 154, line 21
16.51. Timestamp 16.51. Timestamp
The Timestamp general-header describes when the agent sent the The Timestamp general-header describes when the agent sent the
request. The value of the timestamp is of significance only to the request. The value of the timestamp is of significance only to the
agent and may use any timescale. The responding agent MUST echo the agent and may use any timescale. The responding agent MUST echo the
exact same value and MAY, if it has accurate information about this, exact same value and MAY, if it has accurate information about this,
add a floating point number indicating the number of seconds that has add a floating point number indicating the number of seconds that has
elapsed since it has received the request. The timestamp can be used elapsed since it has received the request. The timestamp can be used
by the agent to compute the round-trip time to the responding agent by the agent to compute the round-trip time to the responding agent
so that it can adjust the timeout value for retransmissions when so that it can adjust the timeout value for retransmissions when
running over a unreliable protocol. It also resolves retransmission running over an unreliable protocol. It also resolves retransmission
ambiguities for unreliable transport of RTSP. ambiguities for unreliable transport of RTSP.
Note that the present specification provides only for reliable Note that the present specification provides only for reliable
transport of RTSP messages. The Timestamp general-header is transport of RTSP messages. The Timestamp general-header is
specified in case the protocol is extended in the future to use specified in case the protocol is extended in the future to use
unreliable transport. unreliable transport.
16.52. Transport 16.52. Transport
The Transport request and response header indicates which transport The Transport request and response header indicates which transport
skipping to change at page 153, line 42 skipping to change at page 155, line 18
A transport specification may only contain one of any given parameter A transport specification may only contain one of any given parameter
within it. Parameters MAY be given in any order. Additionally, it within it. Parameters MAY be given in any order. Additionally, it
may only contain either of the unicast or the multicast transport may only contain either of the unicast or the multicast transport
type parameter. All parameters need to be understood in a transport type parameter. All parameters need to be understood in a transport
specification, if not, the transport specification MUST be ignored. specification, if not, the transport specification MUST be ignored.
RTSP proxies of any type that uses or modifies the transport RTSP proxies of any type that uses or modifies the transport
specification, e.g. access proxy or security proxy, MUST remove specification, e.g. access proxy or security proxy, MUST remove
specifications with unknown parameters before forwarding the RTSP specifications with unknown parameters before forwarding the RTSP
message. If that result in no remaining transport specification the message. If that result in no remaining transport specification the
proxy shall send a 461 (Unsupported Transport) (Section 15.4.26) proxy SHALL send a 461 (Unsupported Transport) (Section 15.4.26)
response without any Transport header. response without any Transport header.
The Transport header is restricted to describing a single media The Transport header is restricted to describing a single media
stream. (RTSP can also control multiple streams as a single stream. (RTSP can also control multiple streams as a single
entity.) Making it part of RTSP rather than relying on a entity.) Making it part of RTSP rather than relying on a
multitude of session description formats greatly simplifies multitude of session description formats greatly simplifies
designs of firewalls. designs of firewalls.
The general syntax for the transport specifier is a list of slash The general syntax for the transport specifier is a list of slash
separated tokens: separated tokens:
skipping to change at page 154, line 24 skipping to change at page 155, line 48
dest_addr: The presence of this parameter and its values indicates dest_addr: The presence of this parameter and its values indicates
the destination address or addresses (host address and port the destination address or addresses (host address and port
pairs for IP flows) necessary for the media transport. pairs for IP flows) necessary for the media transport.
No dest_addr: The lack of the dest_addr parameter indicates that the No dest_addr: The lack of the dest_addr parameter indicates that the
server MUST send media to same address for which the RTSP server MUST send media to same address for which the RTSP
messages originates. messages originates.
The choice of method for indicating where the media is to be The choice of method for indicating where the media is to be
delivered depends on the use case. In some case the only allowed delivered depends on the use case. In some cases the only allowed
method will be to use no explicit address indication and have the method will be to use no explicit address indication and have the
server deliver media to the source of the RTSP messages. server deliver media to the source of the RTSP messages.
For Multicast there is several methods for specifying addresses but For Multicast there is several methods for specifying addresses but
they are different in how they work compared with unicast: they are different in how they work compared with unicast:
dest_addr with client picked address: The address and relevant dest_addr with client picked address: The address and relevant
parameters like TTL (scope) for the actual multicast group to parameters like TTL (scope) for the actual multicast group to
deliver the media to. There are security implications deliver the media to. There are security implications
(Section 21) with this method that needs to be addressed if (Section 21) with this method that needs to be addressed if
using this method because a RTSP server can be used as a DoS using this method because a RTSP server can be used as a DoS
attacker on a existing multicast group. attacker on an existing multicast group.
dest_addr using Session Description Information: The information dest_addr using Session Description Information: The information
included in the transport header can all be coming from the included in the transport header can all be coming from the
session description, e.g. the SDP c= and m= line. This session description, e.g. the SDP c= and m= line. This
mitigates some of the security issues of the previous methods mitigates some of the security issues of the previous methods
as it is the session provider that picks the multicast group as it is the session provider that picks the multicast group
and scope. The client MUST include the information if it is and scope. The client MUST include the information if it is
available in the session description. available in the session description.
No dest_addr: The behavior when no explicit multicast group is No dest_addr: The behavior when no explicit multicast group is
skipping to change at page 155, line 28 skipping to change at page 156, line 51
at the dest_addr address. If the parameter is not included, it at the dest_addr address. If the parameter is not included, it
defaults to a single layer. defaults to a single layer.
dest_addr: A general destination address parameter that can contain dest_addr: A general destination address parameter that can contain
one or more address specifications. Each combination of one or more address specifications. Each combination of
protocol/profile/lower transport needs to have the format and protocol/profile/lower transport needs to have the format and
interpretation of its address specification defined. For RTP/ interpretation of its address specification defined. For RTP/
AVP/UDP and RTP/AVP/TCP, the address specification is a tuple AVP/UDP and RTP/AVP/TCP, the address specification is a tuple
containing a host address and port. Note, only a single containing a host address and port. Note, only a single
destination parameter per transport spec is intended. The destination parameter per transport spec is intended. The
usage of multiple destination to distribute a single media to usage of multiple destinations to distribute a single media to
multiple entities is unspecified. multiple entities is unspecified.
The client originating the RTSP request MAY specify the The client originating the RTSP request MAY specify the
destination address of the stream recipient with the host destination address of the stream recipient with the host
address part of the tuple. When the destination address is address part of the tuple. When the destination address is
specified, the recipient may be a different party than the specified, the recipient may be a different party than the
originator of the request. To avoid becoming the unwitting originator of the request. To avoid becoming the unwitting
perpetrator of a remote-controlled denial-of-service attack, a perpetrator of a remote-controlled denial-of-service attack, a
server MUST perform security checks (see Section 21.1) and server MUST perform security checks (see Section 21.1) and
SHOULD log such attempts before allowing the client to direct a SHOULD log such attempts before allowing the client to direct a
skipping to change at page 156, line 16 skipping to change at page 157, line 39
more address specifications. Each combination of protocol/ more address specifications. Each combination of protocol/
profile/lower transport needs to have the format and profile/lower transport needs to have the format and
interpretation of its address specification defined. For RTP/ interpretation of its address specification defined. For RTP/
AVP/UDP and RTP/AVP/TCP, the address specification is a tuple AVP/UDP and RTP/AVP/TCP, the address specification is a tuple
containing a host address and port. containing a host address and port.
This parameter MUST be specified by the server if it transmits This parameter MUST be specified by the server if it transmits
media packets from another address than the one RTSP messages media packets from another address than the one RTSP messages
are sent to. This will allow the client to verify source are sent to. This will allow the client to verify source
address and give it a destination address for its RTCP feedback address and give it a destination address for its RTCP feedback
packets if RTP is used. The address or addresses indicated in packets, if RTP is used. The address or addresses indicated in
the src_addr parameter SHOULD be used both for sending and the src_addr parameter SHOULD be used both for sending and
receiving of the media streams data packets. The main reasons receiving of the media streams data packets. The main reasons
are threefold: First, indicating the port and source address(s) are threefold: First, indicating the port and source address(s)
lets the receiver know where from the packets is expected to lets the receiver know where from the packets is expected to
originate. Secondly, traversal of NATs are greatly simplified originate. Secondly, traversal of NATs is greatly simplified
when traffic is flowing symmetrically over a NAT binding. when traffic is flowing symmetrically over an NAT binding.
Thirdly, certain NAT traversal mechanisms, needs to know to Thirdly, certain NAT traversal mechanisms, needs to know to
which address and port to send so called "binding packets" from which address and port to send so called "binding packets" from
the receiver to the sender, thus creating a address binding in the receiver to the sender, thus creating an address binding in
the NAT that the sender to receiver packet flow can use. the NAT that the sender to receiver packet flow can use.
This information may also be available through SDP. This information may also be available through SDP.
However, since this is more a feature of transport than However, since this is more a feature of transport than
media initialization, the authoritative source for this media initialization, the authoritative source for this
information should be in the SETUP response. information should be in the SETUP response.
mode: The mode parameter indicates the methods to be supported for mode: The mode parameter indicates the methods to be supported for
this session. Currently defined valid values are "PLAY". If this session. Currently defined valid values are "PLAY". If
not provided, the default is "PLAY". The "RECORD" value was not provided, the default is "PLAY". The "RECORD" value was
defined in RFC 2326 and is in this specification unspecified defined in RFC 2326 and is in this specification unspecified
but reserved. RECORD and other values may be specified in the but reserved. RECORD and other values may be specified in the
future. future.
interleaved: The interleaved parameter implies mixing the media interleaved: The interleaved parameter implies mixing the media
stream with the control stream in whatever protocol is being stream with the control stream in whatever protocol is being
used by the control stream, using the mechanism defined in used by the control stream, using the mechanism defined in
Section 14. The argument provides the channel number to be Section 14. The argument provides the channel number to be
used in the $ statement and MUST be present. This parameter used in the $ block Section 14 and MUST be present. This
MAY be specified as a interval, e.g., interleaved=4-5 in cases parameter MAY be specified as a interval, e.g., interleaved=4-5
where the transport choice for the media stream requires it, in cases where the transport choice for the media stream
e.g. for RTP with RTCP. The channel number given in the requires it, e.g., for RTP with RTCP. The channel number given
request are only a guidance from the client to the server on in the request is only a guidance from the client to the server
what channel number(s) to use. The server MAY set any valid on what channel number(s) to use. The server MAY set any valid
channel number in the response. The declared channel(s) are channel number in the response. The declared channel(s) are
bi-directional, so both end-parties MAY send data on the given bi-directional, so both end-parties MAY send data on the given
channel. One example of such usage is the second channel used channel. One example of such usage is the second channel used
for RTCP, where both server and client sends RTCP packets on for RTCP, where both server and client send RTCP packets on the
the same channel. same channel.
This allows RTP/RTCP to be handled similarly to the way This allows RTP/RTCP to be handled similarly to the way
that it is done with UDP, i.e., one channel for RTP and that it is done with UDP, i.e., one channel for RTP and
the other for RTCP. the other for RTCP.
MIKEY: This parameter is used in conjunction with transport MIKEY: This parameter is used in conjunction with transport
specifications that can utilize MIKEY for security context specifications that can utilize MIKEY for security context
establishment. So far only the SRTP based RTP profiles SAVP establishment. So far only the SRTP based RTP profiles SAVP
and SAVPF can utilize MIKEY and this is defined in and SAVPF can utilize MIKEY and this is defined in
Appendix C.1.4.1. This parameter can be included both in Appendix C.1.4.1. This parameter can be included both in
skipping to change at page 157, line 33 skipping to change at page 159, line 10
ttl: multicast time-to-live for IPv4. When included in requests the ttl: multicast time-to-live for IPv4. When included in requests the
value indicate the TTL value that the client request the server value indicate the TTL value that the client request the server
to use. In a response, the value actually being used by the to use. In a response, the value actually being used by the
server is returned. A server will need to consider what values server is returned. A server will need to consider what values
that are reasonable and also the authority of the user to set that are reasonable and also the authority of the user to set
this value. Corresponding functions are not needed for IPv6 as this value. Corresponding functions are not needed for IPv6 as
the scoping is part of the address. the scoping is part of the address.
RTP-specific: RTP-specific:
These parameters are MAY only be used if the media transport protocol These parameters MAY only be used if the media transport protocol is
is RTP. RTP.
ssrc: The ssrc parameter, if included in a SETUP response, indicates ssrc: The ssrc parameter, if included in a SETUP response, indicates
the RTP SSRC [RFC3550] value(s) that will be used by the media the RTP SSRC [RFC3550] value(s) that will be used by the media
server for RTP packets within the stream. It is expressed as server for RTP packets within the stream. It is expressed as
an eight digit hexadecimal value. an eight digit hexadecimal value.
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 in RFC 3550[RFC3550]. If the parameter is
included in the Transport header of a SETUP request, the server included in the Transport header of a SETUP request, the server
MAY ignore it, and choose appropriate SSRCs for the stream. SHOULD ignore it, and choose appropriate SSRCs for the stream.
The server MAY set the ssrc parameter in the Transport header The server SHOULD set the ssrc parameter in the Transport
of the response. header of the response.
RTCP-mux: Use to negotiate the usage of RTP and RTCP multiplexing RTCP-mux: Use 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
clients support and requires the server to use RTP and RTCP clients 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.
skipping to change at page 163, line 7 skipping to change at page 164, line 7
The HTTP access authentication process is described in [RFC2617]. The HTTP access authentication process is described in [RFC2617].
User agents are advised to take special care in parsing the WWW- User agents are advised to take special care in parsing the WWW-
Authenticate field value as it might contain more than one challenge, Authenticate field value as it might contain more than one challenge,
or if more than one WWW-Authenticate header field is provided, the or if more than one WWW-Authenticate header field is provided, the
contents of a challenge itself can contain a comma-separated list of contents of a challenge itself can contain a comma-separated list of
authentication parameters. authentication parameters.
17. Proxies 17. Proxies
RTSP Proxies are RTSP agents that sit in between a client and a RTSP Proxies are RTSP agents that are located in between a client and
server. A proxy can take on both the role as a client and as server a server. A proxy can take on both the role as a client and as
depending on what it tries to accomplish. Proxies are also server depending on what it tries to accomplish. Proxies are also
introduced for several different reasons and the below are often introduced for several different reasons and the below listed are
combined. often combined.
In general there are two categories of RTSP proxies, transparent (of
which the client is not aware) and the non-transparent proxies (of
which the client is aware). Transparent proxies are not visible to
the client in terms of that the transport layer connection, e.g., TCP
for RTSP, as there is only a single transport connection which is
terminated at the RTSP client and the RTSP server. In the case of
non-transparent proxies, there are two transport layer connections,
one from the RTSP client to the RTSP proxy and a second from the RTSP
proxy to the RTSP server.
There are these types of RTSP proxies:
Caching Proxy: This type of proxy is used to reduce the workload on Caching Proxy: This type of proxy is used to reduce the workload on
servers and connections. By caching the description and media servers and connections. By caching the description and media
streams, i.e., the presentation, the proxy can serve a client streams, i.e., the presentation, the proxy can serve a client
with content, but without requesting it from the server once it with content, but without requesting it from the server once it
has been cached and has not become stale. See the caching has been cached and has not become stale. See the caching
Section 18. This type of proxy is also expected to understand Section 18. This type of proxy is also expected to understand
RTSP end-point functionality, i.e., functionality identified in RTSP end-point functionality, i.e., functionality identified in
the Require header in addition to what Proxy-Require demands. the Require header in addition to what Proxy-Require demands.
Translator Proxy: This type of proxy is used to ensure that an RTSP Translator Proxy: This type of proxy is used to ensure that an RTSP
client get access to servers and content on an external network client gets access to servers and content on an external
or using content encodings not supported by the client. The network or using content encodings not supported by the client.
proxy performs the necessary translation of addresses, The proxy performs the necessary translation of addresses,
protocols or encodings. This type of proxy is expected to also protocols or encodings. This type of proxy is expected to also
understand RTSP end-point functionality, i.e. functionality understand RTSP end-point functionality, i.e. functionality
identified in the Require header in addition to what Proxy- identified in the Require header in addition to what Proxy-
Require demands. Require demands.
Access Proxy: This type of proxy is used to ensure that a RTSP Access Proxy: This type of proxy is used to ensure that an RTSP
client get access to servers on an external network. Thus this clients get access to servers on an external network. Thus
proxy is placed on the border between two domains, e.g. a this proxy is placed on the border between two domains, e.g. a
private address space and the public Internet. The proxy private address space and the public Internet. The proxy
performs the necessary translation, usually addresses. This performs the necessary translation, usually addresses. This
type of proxies are required to redirect the media to type of proxy is required to redirect the media to itself or a
themselves or a controlled gateway that perform the translation controlled gateway that performs the translation before the
before the media can reach the client. media can reach the client.
Security Proxy: This type of proxy is used to help facilitate Security Proxy: This type of proxy is used to help facilitate
security functions around RTSP. For example when having a security functions around RTSP. For example when having a
firewalled network, the security proxy request that the firewalled network, the security proxy request that the
necessary pinholes in the firewall is opened when a client in necessary pinholes in the firewall are opened when a client in
the protected network want to access media streams on the the protected network wants to access media streams on the
external side. This proxy can also limit the clients access to external side. This proxy can also limit the clients access to
certain type of content. This proxy can perform its function certain types of content. This proxy can perform its function
without redirecting the media between the server and client. without redirecting the media between the server and client.
However, in deployments with private address spaces this proxy However, in deployments with private address spaces this proxy
is likely to be combined with the access proxy. Anyway, the is likely to be combined with the access proxy. Anyway, the
functionality of this proxy is usually closely tied into functionality of this proxy is usually closely tied into
understand all aspects of the media transport. understanding all aspects of the media transport.
Auditing Proxy: RTSP proxies can also provide network owners with a Auditing Proxy: RTSP proxies can also provide network owners with a
logging and audit point for RTSP sessions, e.g. for logging and audit point for RTSP sessions, e.g. for
corporations that tracks their employees usage of the network. corporations that track their employees usage of the network.
This type of proxy can perform its function without inserting This type of proxy can perform its function without inserting
itself or any other node in the media transport. This proxy itself or any other node in the media transport. This proxy
type can also accept unknown methods as it doesn't interfere type can also accept unknown methods as it doesn't interfere
with the clients' requests. with the clients' requests.
All type of proxies can be used also when using secured communication All types of proxies can be used also when using secured
with TLS as RTSP 2.0 allows the client to approve certificate chains communication with TLS as RTSP 2.0 allows the client to approve
used for connection establishment from a proxy, see Section 19.3.2. certificate chains used for connection establishment from a proxy,
However, that trust model may not be suitable for all type of see Section 19.3.2. However, that trust model may not be suitable
deployment. In those cases, the secured sessions do by-pass of the for all types of deployment. In those cases, the secured sessions do
proxies. by-pass of the proxies.
Access proxies SHOULD NOT be used in equipment like NATs and Access proxies SHOULD NOT be used in equipment like NATs and
firewalls that aren't expected to be regularly maintained, like home firewalls that aren't expected to be regularly maintained, like home
or small office equipment. In these cases it is better to use the or small office equipment. In these cases it is better to use the
NAT traversal procedures defined for RTSP 2.0 NAT traversal procedures defined for RTSP 2.0
[I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is [I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is
that any extensions of RTSP resulting in new media transport that any extensions of RTSP resulting in new media transport
protocols or profiles, new parameters etc may fail in a proxy that protocols or profiles, new parameters, etc. may fail in a proxy that
isn't maintained. This would impede RTSP's future development and isn't maintained. This would impede RTSP's future development and
usage. usage.
17.1. Proxies and Protocol Extensions 17.1. Proxies and Protocol Extensions
The existence of proxies must always be considered when developing The existence of proxies must always be considered when developing
new RTSP extensions. Most types of proxies will need to implement new RTSP extensions. Most types of proxies will need to implement
any new method to operate correctly in the presence of that any new method to operate correctly in the presence of that
extension. New headers can be introduced and will not be blocked by extension. New headers can be introduced and will not be blocked by
older proxies. However, it is important to consider if this header older proxies. However, it is important to consider if this header
and its function is required to be understood by the proxy or can be and its function is required to be understood by the proxy or can be
forwarded. If the header needs to be understood a feature-tag forwarded. If the header needs to be understood, a feature-tag
representing the functionality needs to be included in the Proxy- representing the functionality MUST be included in the Proxy-Require
Require header. Below are guidelines for analysis if the header header. Below are guidelines for analysis if the header needs to be
needs to be understood. The transport header and its parameters also understood. The transport header and its parameters also shows that
shows that headers that are extensible and require correct headers that are extensible and require correct interpretation in the
interpretation in the proxy also require handling rules. proxy also require handling rules.
Whether a proxy needs to understand a header is not easy to Whether a proxy needs to understand a header is not easy to
determine, as they serve a broad variety of functions. When determine, as they serve a broad variety of functions. When
evaluating if a header needs to be understood, one can divide the evaluating if a header needs to be understood, one can divide the
functionality into three main categories: functionality into three main categories:
Media modifying: The caching and translator proxies are modifying Media modifying: The caching and translator proxies are modifying
the actual media and therefore needs to understand also request the actual media and therefore needs to understand also request
directed to the server that affects how the media is rendered. directed to the server that affects how the media is rendered.
Thus, this type of proxies needs to also understand the server Thus, this type of proxy needs to also understand the server side
side functionality. functionality.
Transport modifying: The access and the security proxy both need to Transport modifying: The access and the security proxy both need to
understand how the transport is performed, either for opening understand how the transport is performed, either for opening
pinholes or to translate the outer headers, e.g. IP and UDP. pinholes or to translate the outer headers, e.g. IP and UDP.
Non-modifying: The audit proxy is special in that it do not modify Non-modifying: The audit proxy is special in that it does not modify
the messages in other ways than to insert the Via header. That the messages in other ways than to insert the Via header. That
makes it possible for this type to forward RTSP message that makes it possible for this type to forward RTSP messages that
contains different type of unknown methods, headers or header contain different types of unknown methods, headers or header
parameters. parameters.
Based on the above classification, one should evaluate if the new Based on the above classification, one should evaluate if the new
functionality requires the Transport modifying type of proxies to functionality requires the Transport modifying type of proxies to
understand it or not. understand it or not.
17.2. Multiplexing and Demultiplexing of Messages 17.2. Multiplexing and Demultiplexing of Messages
RTSP proxies may have to multiplex multiple RTSP sessions from their RTSP proxies may have to multiplex multiple 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 are multiplexed onto a common connection for multiple clients are multiplexed onto a common connection for
requests outgoing to a RTSP server and on the way back the responses requests outgoing to an RTSP server and on the way back the responses
are demultiplexed from the server to per client responses. On the are demultiplexed from the server to per client responses. On the
protocol level this requires that request and response messages are protocol level this requires that request and response messages are
handled in both ways, requiring that there is a mechanism to handled in both ways, requiring that there is a mechanism to
correlated what request/response pair exchanged between proxy and correlate what request/response pair exchanged between proxy and
server is mapped to what client (or client request). server is mapped to what 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 (see Section 16.19). The proxy has to by using the CSeq header field (see Section 16.19). The proxy has to
rewrite the CSeq in requests to the server and responses from the rewrite the CSeq in requests to the server and responses from the
server and remember what CSeq is mapped to what client. server and remember what CSeq is mapped to what client.
18. Caching 18. Caching
In HTTP, response-request pairs are cached. RTSP differs In HTTP, request-response pairs are cached. RTSP differs
significantly in that respect. Responses are not cacheable, with the significantly in that respect. Responses are not cacheable, with the
exception of the presentation description returned by DESCRIBE. exception of the presentation description returned by DESCRIBE.
(Since the responses for anything but DESCRIBE and GET_PARAMETER do (Since the responses for anything but DESCRIBE and GET_PARAMETER do
not return any data, caching is not really an issue for these not return any data, caching is not really an issue for these
requests.) However, it is desirable for the continuous media data, requests.) However, it is desirable for the continuous media data,
typically delivered out-of-band with respect to RTSP, to be cached, typically delivered out-of-band with respect to RTSP, to be cached,
as well as the session description. as well as the session description.
On receiving a SETUP or PLAY request, a proxy ascertains whether it On receiving a SETUP or PLAY request, a proxy ascertains whether it
has an up-to-date copy of the continuous media content and its has an up-to-date copy of the continuous media content and its
skipping to change at page 166, line 42 skipping to change at page 167, line 42
Note that an RTSP cache, is of the "cut-through" variety. Rather Note that an RTSP cache, is of the "cut-through" variety. Rather
than retrieving the whole resource from the origin server, the cache than retrieving the whole resource from the origin server, the cache
simply copies the streaming data as it passes by on its way to the simply copies the streaming data as it passes by on its way to the
client. Thus, it does not introduce additional latency. client. Thus, it does not introduce additional latency.
To the client, an RTSP proxy cache appears like a regular media To the client, an RTSP proxy cache appears like a regular media
server, to the media origin server like a client. Just as an HTTP server, to the media origin server like a client. Just as an HTTP
cache has to store the content type, content language, and so on for cache has to store the content type, content language, and so on for
the objects it caches, a media cache has to store the presentation the objects it caches, a media cache has to store the presentation
description. Typically, a cache eliminates all transport-references description. Typically, a cache eliminates all transport-references
(that is, e.g. multicast information) from the presentation (e.g., multicast information) from the presentation description,
description, since these are independent of the data delivery from since these are independent of the data delivery from the cache to
the cache to the client. Information on the encodings remains the the client. Information on the encodings remains the same. If the
same. If the cache is able to translate the cached media data, it cache is able to translate the cached media data, it would create a
would create a new presentation description with all the encoding new presentation description with all the encoding possibilities it
possibilities it can offer. can offer.
18.1. Validation Model 18.1. Validation Model
When a cache has a stale entry that it would like to use as a When a cache has a stale entry that it would like to use as a
response to a client's request, it first has to check with the origin response to a client's request, it first has to check with the origin
server (or possibly an intermediate cache with a fresh response) to server (or possibly an intermediate cache with a fresh response) to
see if its cached entry is still usable. We call this "validating" see if its cached entry is still usable. We call this "validating"
the cache entry. Since we do not want to have to pay the overhead of the cache entry. Since we do not want to have to pay the overhead of
retransmitting the full response if the cached entry is good, and we retransmitting the full response if the cached entry is good, and we
do not want to pay the overhead of an extra round trip if the cached do not want to pay the overhead of an extra round trip if the cached
skipping to change at page 168, line 14 skipping to change at page 169, line 14
18.1.1. Last-Modified Dates 18.1.1. Last-Modified Dates
The Last-Modified header (Section 16.26) value is often used as a The Last-Modified header (Section 16.26) 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 content has not been modified since the Last-Modified valid if the content has not been modified since the Last-Modified
value. value.
18.1.2. Message Body Tag Cache Validators 18.1.2. Message Body Tag Cache Validators
The MTag response-header field value, an 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 5.3 Message body tags are described in Section 4.8
18.1.3. Weak and Strong Validators 18.1.3. Weak and Strong Validators
Since both origin servers and caches will compare two validators to Since both origin servers and caches will compare two validators to
decide if they represent the same or different entities, one normally decide if they represent the same or different entities, one normally
would expect that if the message body (i.e., the presentation would expect that if the message body (i.e., the presentation
description) or any associated message body headers changes in any description) or any associated message body headers changes in any
way, then the associated validator would change as well. If this is way, then the associated validator would change as well. If this is
true, then we call this validator a "strong validator." We call true, then we call this validator a "strong validator." We call
message bo