draft-ietf-mmusic-rfc2326bis-32.txt   draft-ietf-mmusic-rfc2326bis-33.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 23, 2013 R. Lanphier Expires: September 23, 2013 R. Lanphier
M. Westerlund M. Westerlund
Ericsson AB Ericsson AB
M. Stiemerling (Ed.) M. Stiemerling (Ed.)
NEC NEC
March 22, 2013 March 22, 2013
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-32 draft-ietf-mmusic-rfc2326bis-33
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 defined in RFC 2326. 1.0 defined in RFC 2326.
The Real Time Streaming Protocol, or RTSP, is an application-level The Real Time Streaming Protocol, or RTSP, is an application-level
protocol for setup and control of the delivery of data with real-time protocol for setup and control of the delivery of data with real-time
properties. RTSP provides an extensible framework to enable properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and controlled, on-demand delivery of real-time data, such as audio and
video. Sources of data can include both live data feeds and stored video. Sources of data can include both live data feeds and stored
clips. This protocol is intended to control multiple data delivery clips. This protocol is intended to control multiple data delivery
sessions, provide a means for choosing delivery channels such as UDP, sessions, provide a means for choosing delivery channels such as UDP,
multicast UDP and TCP, and provide a means for choosing delivery multicast UDP and TCP, and provide a means for choosing delivery
mechanisms based upon RTP (RFC 3550). mechanisms based upon RTP (RFC 3550).
Status of This Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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
skipping to change at page 2, line 34 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 11
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 13
2.1. Presentation Description . . . . . . . . . . . . . . . . 11 2.1. Presentation Description . . . . . . . . . . . . . . . . 13
2.2. Session Establishment . . . . . . . . . . . . . . . . . . 12 2.2. Session Establishment . . . . . . . . . . . . . . . . . 14
2.3. Media Delivery Control . . . . . . . . . . . . . . . . . 13 2.3. Media Delivery Control . . . . . . . . . . . . . . . . . 15
2.4. Session Parameter Manipulations . . . . . . . . . . . . . 15 2.4. Session Parameter Manipulations . . . . . . . . . . . . 17
2.5. Media Delivery . . . . . . . . . . . . . . . . . . . . . 16 2.5. Media Delivery . . . . . . . . . . . . . . . . . . . . . 17
2.5.1. Media Delivery Manipulations . . . . . . . . . . . . 16 2.5.1. Media Delivery Manipulations . . . . . . . . . . . . 18
2.6. Session Maintenance and Termination . . . . . . . . . . . 19 2.6. Session Maintenance and Termination . . . . . . . . . . 20
2.7. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 20 2.7. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 21
3. Document Conventions . . . . . . . . . . . . . . . . . . . . 21 3. Document Conventions . . . . . . . . . . . . . . . . . . . . 23
3.1. Notational Conventions . . . . . . . . . . . . . . . . . 21 3.1. Notational Conventions . . . . . . . . . . . . . . . . . 23
3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 21 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 23
4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 24 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 27
4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 24 4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 27
4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 25 4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 27
4.3. Session Identifiers . . . . . . . . . . . . . . . . . . . 27 4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 29
4.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . . 27 4.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . 29
4.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 27 4.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 30
4.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . . 28 4.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . 31
4.7. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 29 4.7. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 31
4.8. Message Body Tags . . . . . . . . . . . . . . . . . . . . 29 4.8. Message Body Tags . . . . . . . . . . . . . . . . . . . 31
4.9. Media Properties . . . . . . . . . . . . . . . . . . . . 29 4.9. Media Properties . . . . . . . . . . . . . . . . . . . . 32
4.9.1. Random Access and Seeking . . . . . . . . . . . . . . 30 4.9.1. Random Access and Seeking . . . . . . . . . . . . . 33
4.9.2. Retention . . . . . . . . . . . . . . . . . . . . . . 31 4.9.2. Retention . . . . . . . . . . . . . . . . . . . . . 33
4.9.3. Content Modifications . . . . . . . . . . . . . . . . 31 4.9.3. Content Modifications . . . . . . . . . . . . . . . 34
4.9.4. Supported Scale Factors . . . . . . . . . . . . . . . 32 4.9.4. Supported Scale Factors . . . . . . . . . . . . . . 34
4.9.5. Mapping to the Attributes . . . . . . . . . . . . . . 32 4.9.5. Mapping to the Attributes . . . . . . . . . . . . . 34
5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 32 5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 33 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 35
5.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 33 5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 35
5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 34 5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 36
5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 34 5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 36
6. General Header Fields . . . . . . . . . . . . . . . . . . . . 34 6. General Header Fields . . . . . . . . . . . . . . . . . . . . 38
7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 36 7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 39
7.2. Request Header Fields . . . . . . . . . . . . . . . . . . 37 7.2. Request Header Fields . . . . . . . . . . . . . . . . . 41
8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 38 8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 39 8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 43
8.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 39 8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 43
8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 43 8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 46
9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 44 9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 48
9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 44 9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 48
9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 45 9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 49
10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 45 10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 50
10.1. Reliability and Acknowledgements . . . . . . . . . . . . 46 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 50
10.2. Using Connections . . . . . . . . . . . . . . . . . . . 46 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 51
10.3. Closing Connections . . . . . . . . . . . . . . . . . . 48 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 53
10.4. Timing Out Connections and RTSP Messages . . . . . . . . 49 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 54
10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 50 10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 55
10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 51 10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 56
10.7. Overload Control . . . . . . . . . . . . . . . . . . . . 51 10.7. Overload Control . . . . . . . . . . . . . . . . . . . . 56
11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 53 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 58
12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 54 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 60
13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 55 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 61
13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 56 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 62
13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 58 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 63
13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 59 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 65
13.3.1. Changing Transport Parameters . . . . . . . . . . . 63 13.3.1. Changing Transport Parameters . . . . . . . . . . . 68
13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 63 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 69
13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 63 13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 69
13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 68 13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 74
13.4.3. Updating current PLAY Requests . . . . . . . . . . . 69 13.4.3. Updating current PLAY Requests . . . . . . . . . . . 75
13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 72 13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 77
13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 72 13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 78
13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 72 13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 78
13.4.7. Playing Live with Recording . . . . . . . . . . . . 73 13.4.7. Playing Live with Recording . . . . . . . . . . . . 79
13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 74 13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 79
13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 74 13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 80
13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 75 13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 81
13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 76 13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 82
13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 77 13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 83
13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 79 13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 84
13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 81 13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 87
13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 81 13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 87
13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 82 13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 88
13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 83 13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 89
13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 84 13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 91
13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 86 13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 92
14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 88 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 95
15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
15.1. Proxies and Protocol Extensions . . . . . . . . . . . . 92 15.1. Proxies and Protocol Extensions . . . . . . . . . . . . 98
15.2. Multiplexing and Demultiplexing of Messages . . . . . . 93 15.2. Multiplexing and Demultiplexing of Messages . . . . . . 99
16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
16.1. Validation Model . . . . . . . . . . . . . . . . . . . 94 16.1. Validation Model . . . . . . . . . . . . . . . . . . . . 100
16.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 95 16.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 102
16.1.2. Message Body Tag Cache Validators . . . . . . . . . 95 16.1.2. Message Body Tag Cache Validators . . . . . . . . . 102
16.1.3. Weak and Strong Validators . . . . . . . . . . . . . 95 16.1.3. Weak and Strong Validators . . . . . . . . . . . . . 102
16.1.4. Rules for When to Use Message Body Tags and Last- 16.1.4. Rules for When to Use Message Body Tags and
Modified Dates . . . . . . . . . . . . . . . . . . . 98 Last-Modified Dates . . . . . . . . . . . . . . . . 104
16.1.5. Non-validating Conditionals . . . . . . . . . . . . 99 16.1.5. Non-validating Conditionals . . . . . . . . . . . . 106
16.2. Invalidation After Updates or Deletions . . . . . . . . 99 16.2. Invalidation After Updates or Deletions . . . . . . . . 106
17. Status Code Definitions . . . . . . . . . . . . . . . . . . . 100 17. Status Code Definitions . . . . . . . . . . . . . . . . . . . 108
17.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 100 17.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 108
17.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 100 17.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 108
17.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 101 17.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 108
17.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 101 17.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 108
17.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 101 17.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 108
17.3.1. 301 Moved Permanently . . . . . . . . . . . . . . . 101 17.3.1. 301 Moved Permanently . . . . . . . . . . . . . . . 109
17.3.2. 302 Found . . . . . . . . . . . . . . . . . . . . . 102 17.3.2. 302 Found . . . . . . . . . . . . . . . . . . . . . 109
17.3.3. 303 See Other . . . . . . . . . . . . . . . . . . . 102 17.3.3. 303 See Other . . . . . . . . . . . . . . . . . . . 109
17.3.4. 304 Not Modified . . . . . . . . . . . . . . . . . . 102 17.3.4. 304 Not Modified . . . . . . . . . . . . . . . . . . 109
17.3.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 103 17.3.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 110
17.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 103 17.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 110
17.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 103 17.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 110
17.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 103 17.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 110
17.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 103 17.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 111
17.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 103 17.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 111
17.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 104 17.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 111
17.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 104 17.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 111
17.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 104 17.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 111
17.4.8. 407 Proxy Authentication Required . . . . . . . . . 104 17.4.8. 407 Proxy Authentication Required . . . . . . . . . 112
17.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 105 17.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 112
17.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 105 17.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 112
17.4.11. 411 Length Required . . . . . . . . . . . . . . . . 105 17.4.11. 411 Length Required . . . . . . . . . . . . . . . . 112
17.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 105 17.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 113
17.4.13. 413 Request Message Body Too Large . . . . . . . . . 106 17.4.13. 413 Request Message Body Too Large . . . . . . . . . 113
17.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 106 17.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 113
17.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 106 17.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 113
17.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 106 17.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 113
17.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 106 17.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 114
17.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 106 17.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 114
17.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 107 17.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 114
17.4.20. 455 Method Not Valid in This State . . . . . . . . . 107 17.4.20. 455 Method Not Valid in This State . . . . . . . . . 114
17.4.21. 456 Header Field Not Valid for Resource . . . . . . 107 17.4.21. 456 Header Field Not Valid for Resource . . . . . . 114
17.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 107 17.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 114
17.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 107 17.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 114
17.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 107 17.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 114
17.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 107 17.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 115
17.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 108 17.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 115
17.4.27. 462 Destination Unreachable . . . . . . . . . . . . 108 17.4.27. 462 Destination Unreachable . . . . . . . . . . . . 115
17.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 108 17.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 115
17.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 108 17.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 115
17.4.30. 465 Notification Reason Unknown . . . . . . . . . . 108 17.4.30. 465 Notification Reason Unknown . . . . . . . . . . 115
17.4.31. 466 Key Management Error . . . . . . . . . . . . . . 108 17.4.31. 466 Key Management Error . . . . . . . . . . . . . . 116
17.4.32. 470 Connection Authorization Required . . . . . . . 109 17.4.32. 470 Connection Authorization Required . . . . . . . 116
17.4.33. 471 Connection Credentials not accepted . . . . . . 109 17.4.33. 471 Connection Credentials not accepted . . . . . . 116
17.4.34. 472 Failure to establish secure connection . . . . . 109 17.4.34. 472 Failure to establish secure connection . . . . . 116
17.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 109 17.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 116
17.5.1. 500 Internal Server Error . . . . . . . . . . . . . 109 17.5.1. 500 Internal Server Error . . . . . . . . . . . . . 116
17.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 109 17.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 116
17.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 109 17.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 117
17.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 109 17.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 117
17.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 110 17.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 117
17.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 110 17.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 117
17.5.7. 551 Option not supported . . . . . . . . . . . . . . 110 17.5.7. 551 Option not supported . . . . . . . . . . . . . . 117
18. Header Field Definitions . . . . . . . . . . . . . . . . . . 110 18. Header Field Definitions . . . . . . . . . . . . . . . . . . 118
18.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 121 18.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 128
18.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 121 18.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 128
18.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 122 18.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 129
18.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 122 18.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 130
18.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 123 18.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 131
18.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 124 18.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 131
18.7. Authorization . . . . . . . . . . . . . . . . . . . . . 124 18.7. Authorization . . . . . . . . . . . . . . . . . . . . . 131
18.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 125 18.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 132
18.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 126 18.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 133
18.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 126 18.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 133
18.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 129 18.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 136
18.12. Connection-Credentials . . . . . . . . . . . . . . . . . 129 18.12. Connection-Credentials . . . . . . . . . . . . . . . . . 136
18.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 130 18.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 137
18.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 131 18.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 137
18.15. Content-Language . . . . . . . . . . . . . . . . . . . . 131 18.15. Content-Language . . . . . . . . . . . . . . . . . . . . 138
18.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 132 18.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 139
18.17. Content-Location . . . . . . . . . . . . . . . . . . . . 132 18.17. Content-Location . . . . . . . . . . . . . . . . . . . . 139
18.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 134 18.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 140
18.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 134 18.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 140
18.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 134 18.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 141
18.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 135 18.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 142
18.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 136 18.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 143
18.23. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 137 18.23. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 143
18.24. If-Modified-Since . . . . . . . . . . . . . . . . . . . 137 18.24. If-Modified-Since . . . . . . . . . . . . . . . . . . . 144
18.25. If-None-Match . . . . . . . . . . . . . . . . . . . . . 137 18.25. If-None-Match . . . . . . . . . . . . . . . . . . . . . 144
18.26. Last-Modified . . . . . . . . . . . . . . . . . . . . . 138 18.26. Last-Modified . . . . . . . . . . . . . . . . . . . . . 145
18.27. Location . . . . . . . . . . . . . . . . . . . . . . . . 139 18.27. Location . . . . . . . . . . . . . . . . . . . . . . . . 145
18.28. Media-Properties . . . . . . . . . . . . . . . . . . . . 139 18.28. Media-Properties . . . . . . . . . . . . . . . . . . . . 146
18.29. Media-Range . . . . . . . . . . . . . . . . . . . . . . 141 18.29. Media-Range . . . . . . . . . . . . . . . . . . . . . . 148
18.30. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 142 18.30. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 148
18.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 142 18.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 149
18.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 142 18.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 149
18.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 143 18.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 150
18.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 144 18.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 150
18.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 144 18.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 151
18.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 144 18.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 151
18.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 145 18.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 152
18.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 146 18.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 153
18.39. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 148 18.39. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 154
18.40. Request-Status . . . . . . . . . . . . . . . . . . . . . 149 18.40. Request-Status . . . . . . . . . . . . . . . . . . . . . 155
18.41. Require . . . . . . . . . . . . . . . . . . . . . . . . 149 18.41. Require . . . . . . . . . . . . . . . . . . . . . . . . 155
18.42. Retry-After . . . . . . . . . . . . . . . . . . . . . . 150 18.42. Retry-After . . . . . . . . . . . . . . . . . . . . . . 156
18.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 150 18.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 157
18.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 153 18.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 159
18.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 154 18.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 160
18.46. Server . . . . . . . . . . . . . . . . . . . . . . . . . 156 18.46. Server . . . . . . . . . . . . . . . . . . . . . . . . . 162
18.47. Session . . . . . . . . . . . . . . . . . . . . . . . . 156 18.47. Session . . . . . . . . . . . . . . . . . . . . . . . . 162
18.48. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 157 18.48. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 163
18.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 158 18.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 164
18.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 159 18.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 165
18.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 159 18.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 165
18.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 160 18.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 166
18.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 167 18.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 173
18.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 167 18.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 173
18.55. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 168 18.55. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 174
18.56. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 168 18.56. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 174
19. Security Framework . . . . . . . . . . . . . . . . . . . . . 168 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 175
19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 169 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 175
19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 169 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 175
19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 170 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 176
19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 171 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 177
19.3.2. User approved TLS procedure . . . . . . . . . . . . 172 19.3.2. User approved TLS procedure . . . . . . . . . . . . 178
20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 174 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 181
20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 176 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 183
20.2.1. Generic Protocol elements . . . . . . . . . . . . . 176 20.2.1. Generic Protocol elements . . . . . . . . . . . . . 183
20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 179 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 186
20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 182 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 190
20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 190 20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 199
21. Security Considerations . . . . . . . . . . . . . . . . . . . 190 21. Security Considerations . . . . . . . . . . . . . . . . . . . 200
21.1. Signaling Protocol Threats . . . . . . . . . . . . . . . 190 21.1. Signaling Protocol Threats . . . . . . . . . . . . . . . 200
21.2. Media Stream Delivery Threats . . . . . . . . . . . . . 193 21.2. Media Stream Delivery Threats . . . . . . . . . . . . . 203
21.2.1. Remote Denial of Service Attack . . . . . . . . . . 194 21.2.1. Remote Denial of Service Attack . . . . . . . . . . 204
21.2.2. RTP Security analysis . . . . . . . . . . . . . . . 195 21.2.2. RTP Security analysis . . . . . . . . . . . . . . . 205
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 197 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 207
22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 198 22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 207
22.1.1. Description . . . . . . . . . . . . . . . . . . . . 198 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 208
22.1.2. Registering New Feature-tags with IANA . . . . . . . 198 22.1.2. Registering New Feature-tags with IANA . . . . . . . 208
22.1.3. Registered entries . . . . . . . . . . . . . . . . . 198 22.1.3. Registered entries . . . . . . . . . . . . . . . . . 208
22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 199 22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 209
22.2.1. Description . . . . . . . . . . . . . . . . . . . . 199 22.2.1. Description . . . . . . . . . . . . . . . . . . . . 209
22.2.2. Registering New Methods with IANA . . . . . . . . . 199 22.2.2. Registering New Methods with IANA . . . . . . . . . 209
22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 199 22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 209
22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 200 22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 210
22.3.1. Description . . . . . . . . . . . . . . . . . . . . 200 22.3.1. Description . . . . . . . . . . . . . . . . . . . . 210
22.3.2. Registering New Status Codes with IANA . . . . . . . 200 22.3.2. Registering New Status Codes with IANA . . . . . . . 210
22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 200 22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 210
22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 200 22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 210
22.4.1. Description . . . . . . . . . . . . . . . . . . . . 200 22.4.1. Description . . . . . . . . . . . . . . . . . . . . 210
22.4.2. Registering New Headers with IANA . . . . . . . . . 201 22.4.2. Registering New Headers with IANA . . . . . . . . . 211
22.4.3. Registered entries . . . . . . . . . . . . . . . . . 201 22.4.3. Registered entries . . . . . . . . . . . . . . . . . 211
22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 202
22.5.1. Accept-Credentials policies . . . . . . . . . . . . 202 22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 212
22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 203 22.5.1. Accept-Credentials policies . . . . . . . . . . . . 212
22.6. Cache-Control Cache Directive Extensions . . . . . . . . 203 22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 213
22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 204 22.6. Cache-Control Cache Directive Extensions . . . . . . . . 213
22.7.1. Description . . . . . . . . . . . . . . . . . . . . 204 22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 214
22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 205 22.7.1. Description . . . . . . . . . . . . . . . . . . . . 214
22.7.3. Registered Values . . . . . . . . . . . . . . . . . 205 22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 215
22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 205 22.7.3. Registered Values . . . . . . . . . . . . . . . . . 215
22.8.1. Description . . . . . . . . . . . . . . . . . . . . 205 22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 215
22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 205 22.8.1. Description . . . . . . . . . . . . . . . . . . . . 215
22.8.3. Registered Values . . . . . . . . . . . . . . . . . 206 22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 215
22.9. Range header formats . . . . . . . . . . . . . . . . . . 206 22.8.3. Registered Values . . . . . . . . . . . . . . . . . 216
22.9.1. Description . . . . . . . . . . . . . . . . . . . . 206 22.9. Range header formats . . . . . . . . . . . . . . . . . . 216
22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 206 22.9.1. Description . . . . . . . . . . . . . . . . . . . . 216
22.9.3. Registered Values . . . . . . . . . . . . . . . . . 207 22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 216
22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 207 22.9.3. Registered Values . . . . . . . . . . . . . . . . . 216
22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . 207 22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 217
22.10.2. Terminate-Reason Header Parameters . . . . . . . . 207 22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 217
22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 208 22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 217
22.11.1. Description . . . . . . . . . . . . . . . . . . . . 208 22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 218
22.11.2. Registration Rules . . . . . . . . . . . . . . . . 208 22.11.1. Description . . . . . . . . . . . . . . . . . . . . 218
22.11.3. Registered Values . . . . . . . . . . . . . . . . . 208 22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 218
22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 208 22.11.3. Registered Values . . . . . . . . . . . . . . . . . 218
22.12.1. Description . . . . . . . . . . . . . . . . . . . . 209 22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 218
22.12.2. Registration Rules . . . . . . . . . . . . . . . . 209 22.12.1. Description . . . . . . . . . . . . . . . . . . . . 218
22.12.3. Registered Values . . . . . . . . . . . . . . . . . 209 22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 219
22.13. Transport Header Registries . . . . . . . . . . . . . . 209 22.12.3. Registered Values . . . . . . . . . . . . . . . . . 219
22.13.1. Transport Protocol Specification . . . . . . . . . 209 22.13. Transport Header Registries . . . . . . . . . . . . . . 219
22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 211 22.13.1. Transport Protocol Specification . . . . . . . . . . 219
22.13.3. Transport Parameters . . . . . . . . . . . . . . . 211 22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 221
22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 212 22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 221
22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 212 22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 222
22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . 213 22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 222
22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . 214 22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 223
22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 215 22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 224
22.16. Media Type Registration for text/parameters . . . . . . 216 22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 225
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 217 22.16. Media Type Registration for text/parameters . . . . . . 226
23.1. Normative References . . . . . . . . . . . . . . . . . . 217 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 228
23.2. Informative References . . . . . . . . . . . . . . . . . 220 23.1. Normative References . . . . . . . . . . . . . . . . . . 228
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 221 23.2. Informative References . . . . . . . . . . . . . . . . . 230
A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . . 222 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 233
A.2. Media on Demand using Pipelining . . . . . . . . . . . . 225 A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 233
A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . . 227 A.2. Media on Demand using Pipelining . . . . . . . . . . . . 237
A.4. Single Stream Container Files . . . . . . . . . . . . . . 230 A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 239
A.5. Live Media Presentation Using Multicast . . . . . . . . . 232 A.4. Single Stream Container Files . . . . . . . . . . . . . 243
A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 234 A.5. Live Media Presentation Using Multicast . . . . . . . . 245
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 235 A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 246
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 235 Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 248
B.2. State variables . . . . . . . . . . . . . . . . . . . . . 236 B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 248
B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 236 B.2. State variables . . . . . . . . . . . . . . . . . . . . 248
B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 236 B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 248
Appendix C. Media Transport Alternatives . . . . . . . . . . . . 241 B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 249
C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Appendix C. Media Transport Alternatives . . . . . . . . . . . . 255
C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . . 241 C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 255
C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . . 242 C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 255
C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 243 C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 255
C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 243 C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 257
C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 246 C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 257
C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 246 C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 259
C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 248 C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 260
C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 248 C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 261
C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 248 C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 262
C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 252 C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 262
C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . . 256 C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 266
C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 258 C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 270
C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 258 C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 272
C.7. Maintaining NPT synchronization with RTP timestamps . . . 258 C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 272
C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 258 C.7. Maintaining NPT synchronization with RTP timestamps . . 272
C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 258 C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 272
C.10. Usage of SSRCs and the RTCP BYE Message During an RTSP C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 272
Session . . . . . . . . . . . . . . . . . . . . . . . . . 259 C.10. Usage of SSRCs and the RTCP BYE Message During an
C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 259 RTSP Session . . . . . . . . . . . . . . . . . . . . . . 272
Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 260 C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 273
D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 260 Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 274
D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . . 260 D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 274
D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . . 262 D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 274
D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . . 262 D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 275
D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 263 D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 276
D.1.5. Directionality of media stream . . . . . . . . . . . 263 D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 276
D.1.6. Range of Presentation . . . . . . . . . . . . . . . . 263 D.1.5. Directionality of media stream . . . . . . . . . . . 276
D.1.7. Time of Availability . . . . . . . . . . . . . . . . 264 D.1.6. Range of Presentation . . . . . . . . . . . . . . . 277
D.1.8. Connection Information . . . . . . . . . . . . . . . 265 D.1.7. Time of Availability . . . . . . . . . . . . . . . . 278
D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 265 D.1.8. Connection Information . . . . . . . . . . . . . . . 278
D.2. Aggregate Control Not Available . . . . . . . . . . . . . 266 D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 279
D.3. Aggregate Control Available . . . . . . . . . . . . . . . 266 D.2. Aggregate Control Not Available . . . . . . . . . . . . 279
D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 267 D.3. Aggregate Control Available . . . . . . . . . . . . . . 280
D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 268 D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 281
Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 268 D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 281
E.1. On-demand Playback of Stored Content . . . . . . . . . . 268 Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 282
E.2. Unicast Distribution of Live Content . . . . . . . . . . 270 E.1. On-demand Playback of Stored Content . . . . . . . . . . 282
E.3. On-demand Playback using Multicast . . . . . . . . . . . 270 E.2. Unicast Distribution of Live Content . . . . . . . . . . 283
E.4. Inviting an RTSP server into a conference . . . . . . . . 271 E.3. On-demand Playback using Multicast . . . . . . . . . . . 284
E.5. Live Content using Multicast . . . . . . . . . . . . . . 272 E.4. Inviting an RTSP server into a conference . . . . . . . 284
Appendix F. Text format for Parameters . . . . . . . . . . . . . 272 E.5. Live Content using Multicast . . . . . . . . . . . . . . 285
Appendix G. Requirements for Unreliable Transport of RTSP . . . 273 Appendix F. Text format for Parameters . . . . . . . . . . . . . 287
Appendix H. Backwards Compatibility Considerations . . . . . . . 274 Appendix G. Requirements for Unreliable Transport of RTSP . . . 288
H.1. Play Request in Play State . . . . . . . . . . . . . . . 275 Appendix H. Backwards Compatibility Considerations . . . . . . . 290
H.2. Using Persistent Connections . . . . . . . . . . . . . . 275 H.1. Play Request in Play State . . . . . . . . . . . . . . . 290
Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 275 H.2. Using Persistent Connections . . . . . . . . . . . . . . 290
I.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 275 Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 291
I.2. Detailed List of Changes . . . . . . . . . . . . . . . . 277 I.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 291
Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 283 I.2. Detailed List of Changes . . . . . . . . . . . . . . . . 292
J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 283 Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 299
Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 284 J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 299
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 284 Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 301
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 302
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 17, line 46 skipping to change at page 19, line 34
updating the media properties and the currently used scale factor updating the media properties and the currently used scale factor
exist. exist.
Speed affects how much of the playback timeline is delivered in a Speed affects how much of the playback timeline is delivered in a
given wallclock period. The default is Speed = 1 which means to given wallclock period. The default is Speed = 1 which means to
deliver at the same rate the media is consumed. Speed > 1 means that deliver at the same rate the media is consumed. Speed > 1 means that
the receiver will get content faster than it regularly would consume the receiver will get content faster than it regularly would consume
it. Speed < 1 means that delivery is slower than the regular media it. Speed < 1 means that delivery is slower than the regular media
rate. Speed values of 0 or lower have no meaning and are not rate. Speed values of 0 or lower have no meaning and are not
allowed. This mechanism enables two general functionalities. One is allowed. This mechanism enables two general functionalities. One is
client side scale operations, i.e. the client receives all the client side scale operations, i.e. the client receives all the frames
frames and makes the adjustment to the playback locally. The second and makes the adjustment to the playback locally. The second is
is delivery control for buffering of media. By specifying a speed delivery control for buffering of media. By specifying a speed over
over 1.0 the client can build up the amount of playback time it has 1.0 the client can build up the amount of playback time it has
present in its buffers to a level that is sufficient for its needs. present in its buffers to a level that is sufficient for its needs.
A naive implementation of Speed would only affect the transmission A naive implementation of Speed would only affect the transmission
schedule of the media and has a clear impact on the needed bandwidth. schedule of the media and has a clear impact on the needed bandwidth.
This would result in the data rate being proportional to the speed This would result in the data rate being proportional to the speed
factor. Speed = 1.5, i.e., 50% faster than normal delivery, would factor. Speed = 1.5, i.e., 50% faster than normal delivery, would
result in a 50% increase in the data transport rate. If that can be result in a 50% increase in the data transport rate. If that can be
supported or not depends solely on the underlying network path. supported or not depends solely on the underlying network path.
Scale may also have some impact on the required bandwidth due to the Scale may also have some impact on the required bandwidth due to the
manipulation of the content in the new playback schedule. An example manipulation of the content in the new playback schedule. An example
skipping to change at page 27, line 14 skipping to change at page 29, line 37
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
skipping to change at page 27, line 40 skipping to change at page 30, line 14
through the use of "smpte-type". For SMPTE 30, the "frames" field in through the use of "smpte-type". For SMPTE 30, the "frames" field in
the time value can assume the values 0 through 29. The difference the time value can assume the values 0 through 29. The difference
between 30 and 29.97 frames per second is handled by dropping the between 30 and 29.97 frames per second is handled by dropping the
first two frame indices (values 00 and 01) of every minute, except first two frame indices (values 00 and 01) of every minute, except
every tenth minute. If the frame and the subframe values are zero, every tenth minute. If the frame and the subframe values are zero,
they may be omitted. Subframes are measured in one-hundredth of a they may be omitted. Subframes are measured in one-hundredth of a
frame. frame.
Examples: Examples:
smpte=10:12:33:20- smpte=10:12:33:20-
smpte=10:07:33- smpte=10:07:33-
smpte=10:07:00-10:07:33:05.01 smpte=10:07:00-10:07:33:05.01
smpte-25=10:07:00-10:07:33:05.01 smpte-25=10:07:00-10:07:33:05.01
4.5. Normal Play Time 4.5. Normal Play Time
Normal play time (NPT) indicates the stream absolute position Normal play time (NPT) indicates the stream absolute position
relative to the beginning of the presentation, not to be confused relative to the beginning of the presentation, not to be confused
with the Network Time Protocol (NTP) [RFC5905]. The timestamp with the Network Time Protocol (NTP) [RFC5905]. The timestamp
consists of two parts: the mandatory first part may be expressed in consists of two parts: the mandatory first part may be expressed in
either seconds or hours, minutes, and seconds. The optional second either seconds or hours, minutes, and seconds. The optional second
part consists of a decimal point and decimal figures and indicates part consists of a decimal point and decimal figures and indicates
fractions of a second. fractions of a second.
skipping to change at page 28, line 24 skipping to change at page 30, line 46
NPT is defined as in DSM-CC [ISO.13818-6.1995]: "Intuitively, NPT is NPT is defined as in DSM-CC [ISO.13818-6.1995]: "Intuitively, NPT is
the clock the viewer associates with a program. It is often the clock the viewer associates with a program. It is often
digitally displayed on a VCR. NPT advances normally when in normal digitally displayed on a VCR. NPT advances normally when in normal
play mode (scale = 1), advances at a faster rate when in fast scan play mode (scale = 1), advances at a faster rate when in fast scan
forward (high positive scale ratio), decrements when in scan reverse forward (high positive scale ratio), decrements when in scan reverse
(negative scale ratio) and is fixed in pause mode. NPT is (negative scale ratio) and is fixed in pause mode. NPT is
(logically) equivalent to SMPTE time codes." (logically) equivalent to SMPTE time codes."
Examples: Examples:
npt=123.45-125 npt=123.45-125
npt=12:05:35.3- npt=12:05:35.3-
npt=now- npt=now-
The syntax conforms to ISO 8601 [ISO.8601.2000]. The npt-sec The syntax conforms to ISO 8601 [ISO.8601.2000]. The npt-sec
notation is optimized for automatic generation, the npt-hhmmss notation is optimized for automatic generation, the npt-hhmmss
notation for consumption by human readers. The "now" constant notation for consumption by human readers. The "now" constant
allows clients to request to receive the live feed rather than the allows clients to request to receive the live feed rather than the
stored or time-delayed version. This is needed since neither stored or time-delayed version. This is needed since neither
absolute time nor zero time are appropriate for this case. absolute time nor zero time are appropriate for this case.
4.6. Absolute Time 4.6. Absolute Time
Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps, Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps,
using UTC (GMT). Fractions of a second may be indicated. using UTC (GMT). Fractions of a second may be indicated.
Example for November 8, 1996 at 14h 37 min and 20 and a quarter Example for November 8, 1996 at 14h 37 min and 20 and a quarter
seconds UTC: seconds UTC:
19961108T143720.25Z 19961108T143720.25Z
4.7. Feature-Tags 4.7. Feature-Tags
Feature-tags are unique identifiers used to designate features in Feature-tags are unique identifiers used to designate features in
RTSP. These tags are used in Require (Section 18.41), Proxy-Require RTSP. These tags are used in Require (Section 18.41), Proxy-Require
(Section 18.35), Proxy-Supported (Section 18.36), Supported (Section 18.35), Proxy-Supported (Section 18.36), Supported
(Section 18.49) and Unsupported (Section 18.53) header fields. (Section 18.49) and Unsupported (Section 18.53) header fields.
A feature-tag definition MUST indicate which combination of clients, A feature-tag definition MUST indicate which combination of clients,
servers or proxies it applies to. servers or proxies it applies to.
skipping to change at page 30, line 13 skipping to change at page 32, line 30
different properties a media instance for delivery and playback can different properties a media instance for delivery and playback can
have. This specification considers the below listed media properties have. This specification considers the below listed media properties
in its protocol operations. They are derived from the differences in its protocol operations. They are derived from the differences
between a number of supported usages. between a number of supported usages.
On-demand: Media that has a fixed (given) duration that doesn't On-demand: Media that has a fixed (given) duration that doesn't
change during the life time of the RTSP session and is known at change during the life time of the RTSP session and is known at
the time of the creation of the session. It is expected that the the time of the creation of the session. It is expected that the
content of the media will not change, even if the representation, content of the media will not change, even if the representation,
i.e encoding, quality, etc, may change. Generally one can seek, i.e encoding, quality, etc, may change. Generally one can seek,
i.e. request any range, within the media. i.e. request any range, within the media.
Dynamic On-demand: This is a variation of the on-demand case where Dynamic On-demand: This is a variation of the on-demand case where
external methods are used to manipulate the actual content of the external methods are used to manipulate the actual content of the
media setup for the RTSP session. The main example is a content media setup for the RTSP session. The main example is a content
defined by a playlist. defined by a playlist.
Live: Live media represents a progressing content stream (such as Live: Live media represents a progressing content stream (such as
broadcast TV) where the duration may or may not be known. It is broadcast TV) where the duration may or may not be known. It is
not seekable, only the content presently being delivered can be not seekable, only the content presently being delivered can be
accessed. accessed.
skipping to change at page 32, line 8 skipping to change at page 34, line 27
Time Progressing: As time progresses new content will become Time Progressing: As time 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
as everything between the start point and the point currently as everything between the start point and the point currently
being made available can be accessed. If the media server uses a being made available can be accessed. If the media server uses a
sliding window policy for retention, the start point will also sliding window policy for retention, the start point will also
change as time progresses. change as time progresses.
4.9.4. Supported Scale Factors 4.9.4. Supported Scale Factors
Content often supports only a limited set or range of scales when Content often supports only a limited set or range of scales when
delivering the media.. To enable the client to know what values or delivering the media.. To enable the client to know what values or
ranges of scale operations that the whole content or the current ranges of scale operations that the whole content or the current
position supports, a media properties attribute for this is defined position supports, a media properties attribute for this is defined
which contains a list with the values and/or ranges that are which contains a list with the values and/or ranges that are
supported. The attribute is named "Scales". It may be updated at supported. The attribute is named "Scales". It may be updated at
any point in the content due to content consisting of spliced pieces any point in the content due to content consisting of spliced pieces
or content being dynamically updated by out-of-band mechanisms. or content being dynamically updated by out-of-band mechanisms.
4.9.5. Mapping to the Attributes 4.9.5. Mapping to the Attributes
This section shows examples of how one would map the above usages to This section shows examples of how one would map the above usages to
skipping to change at page 40, line 5 skipping to change at page 44, line 8
3rr: Redirection - Further action needs to be taken in order to 3rr: Redirection - Further action needs to be taken in order to
complete the request complete the request
4xx: Client Error - The request contains bad syntax or cannot be 4xx: Client Error - The request contains bad syntax or cannot be
fulfilled fulfilled
5xx: Server Error - The server failed to fulfill an apparently valid 5xx: Server Error - The server failed to fulfill an apparently valid
request request
The individual values of the numeric status codes defined for RTSP/ The individual values of the numeric status codes defined for
2.0, and an example set of corresponding Reason-Phrases, are RTSP/2.0, and an example set of corresponding Reason-Phrases, are
presented in Table 4. The reason phrases listed here are only presented in Table 4. The reason phrases listed here are only
recommended; they may be replaced by local equivalents without recommended; they may be replaced by local equivalents without
affecting the protocol. Note that RTSP adopts most HTTP/1.1 affecting the protocol. Note that RTSP adopts most HTTP/1.1
[RFC2616] status codes and adds RTSP-specific status codes starting [RFC2616] status codes and adds RTSP-specific status codes starting
at x50 to avoid conflicts with future HTTP status codes that are at x50 to avoid conflicts with future HTTP status codes that are
desirable to import into RTSP. desirable to import into RTSP.
RTSP status codes are extensible. RTSP applications are not required RTSP status codes are extensible. RTSP applications are not required
to understand the meaning of all registered status codes, though such to understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST understanding is obviously desirable. However, applications MUST
skipping to change at page 40, line 29 skipping to change at page 44, line 32
x00 status code of that class, with the exception that an x00 status code of that class, with the exception that an
unrecognized response MUST NOT be cached. For example, if an unrecognized response MUST NOT be cached. For example, if an
unrecognized status code of 431 is received by the client, it can unrecognized status code of 431 is received by the client, it can
safely assume that there was something wrong with its request and safely assume that there was something wrong with its request and
treat the response as if it had received a 400 status code. In such treat the response as if it had received a 400 status code. In such
cases, user agents SHOULD present to the user the message body cases, user agents SHOULD present to the user the message body
returned with the response, since that message body is likely to returned with the response, since that message body is likely to
include human-readable information which will explain the unusual include human-readable information which will explain the unusual
status. status.
+---------+------------------------------+--------------------------+ +------+---------------------------------+--------------------------+
| Code | Reason | Method | | Code | Reason | Method |
+---------+------------------------------+--------------------------+ +------+---------------------------------+--------------------------+
| 100 | Continue | all | | 100 | Continue | all |
| | | | | | | |
| | | | | | | |
| | | | | 200 | OK | all |
| 200 | OK | all | | | | |
| | | | | | | |
| | | | | 301 | Moved Permanently | all |
| | | | | | | |
| 301 | Moved Permanently | all | | 302 | Found | all |
| | | | | | | |
| 302 | Found | all | | 303 | reserved | n/a |
| | | | | | | |
| 303 | reserved | n/a | | 304 | Not Modified | all |
| | | | | | | |
| 304 | Not Modified | all | | 305 | Use Proxy | all |
| | | | | | | |
| 305 | Use Proxy | all | | | | |
| | | | | 400 | Bad Request | all |
| | | | | 401 | Unauthorized | all |
| | | | | | | |
| 400 | Bad Request | all | | 402 | Payment Required | all |
| | | | | | | |
| 401 | Unauthorized | all | | 403 | Forbidden | all |
| | | | | | | |
| 402 | Payment Required | all | | 404 | Not Found | all |
| | | | | | | |
| 403 | Forbidden | all | | 405 | Method Not Allowed | all |
| | | | | | | |
| 404 | Not Found | all | | 406 | Not Acceptable | all |
| | | | | | | |
| 405 | Method Not Allowed | all | | 407 | Proxy Authentication Required | all |
| | | | | | | |
| 406 | Not Acceptable | all | | 408 | Request Timeout | all |
| | | | | | | |
| 407 | Proxy Authentication | all | | 410 | Gone | all |
| | Required | | | | | |
| | | | | 411 | Length Required | all |
| 408 | Request Timeout | all | | | | |
| | | | | 412 | Precondition Failed | DESCRIBE, SETUP |
| 410 | Gone | all | | | | |
| | | | | 413 | Request Message Body Too Large | all |
| 411 | Length Required | all | | | | |
| | | | | 414 | Request-URI Too Long | all |
| 412 | Precondition Failed | DESCRIBE, SETUP | | | | |
| | | | | 415 | Unsupported Media Type | all |
| 413 | Request Message Body Too | all | | | | |
| | Large | | | 451 | Parameter Not Understood | SET_PARAMETER, |
| | | | | | | GET_PARAMETER |
| 414 | Request-URI Too Long | all | | | | |
| | | | | 452 | reserved | n/a |
| 415 | Unsupported Media Type | all | | | | |
| | | | | 453 | Not Enough Bandwidth | SETUP |
| 451 | Parameter Not Understood | SET_PARAMETER, | | | | |
| | | GET_PARAMETER | | 454 | Session Not Found | all |
| | | | | | | |
| 452 | reserved | n/a | | 455 | Method Not Valid In This State | all |
| | | | | | | |
| 453 | Not Enough Bandwidth | SETUP | | 456 | Header Field Not Valid | all |
| | | | | | | |
| 454 | Session Not Found | all | | 457 | Invalid Range | PLAY, PAUSE |
| | | | | | | |
| 455 | Method Not Valid In This | all | | 458 | Parameter Is Read-Only | SET_PARAMETER |
| | State | | | | | |
| | | | | 459 | Aggregate Operation Not Allowed | all |
| 456 | Header Field Not Valid | all | | | | |
| | | | | 460 | Only Aggregate Operation | all |
| 457 | Invalid Range | PLAY, PAUSE | | | Allowed | |
| | | | | | | |
| 458 | Parameter Is Read-Only | SET_PARAMETER | | 461 | Unsupported Transport | all |
| | | | | | | |
| 459 | Aggregate Operation Not | all | | 462 | Destination Unreachable | all |
| | Allowed | | | | | |
| | | | | 463 | Destination Prohibited | SETUP |
| 460 | Only Aggregate Operation | all | | | | |
| | Allowed | | | 464 | Data Transport Not Ready Yet | PLAY |
| | | | | | | |
| 461 | Unsupported Transport | all | | 465 | Notification Reason Unknown | PLAY_NOTIFY |
| | | | | | | |
| 462 | Destination Unreachable | all | | 466 | Key Management Error | all |
| | | | | | | |
| 463 | Destination Prohibited | SETUP | | 470 | Connection Authorization | all |
| | | | | | Required | |
| 464 | Data Transport Not Ready Yet | PLAY | | | | |
| | | | | 471 | Connection Credentials not | all |
| 465 | Notification Reason Unknown | PLAY_NOTIFY | | | accepted | |
| | | | | | | |
| 466 | Key Management Error | all | | 472 | Failure to establish secure | all |
| | | | | | connection | |
| 470 | Connection Authorization | all | | | | |
| | Required | | | | | |
| | | | | 500 | Internal Server Error | all |
| 471 | Connection Credentials not | all | | | | |
| | accepted | | | 501 | Not Implemented | all |
| | | | | | | |
| 472 | Failure to establish secure | all | | 502 | Bad Gateway | all |
| | connection | | | | | |
| | | | | 503 | Service Unavailable | all |
| | | | | | | |
| | | | | 504 | Gateway Timeout | all |
| 500 | Internal Server Error | all | | | | |
| | | | | 505 | RTSP Version Not Supported | all |
| 501 | Not Implemented | all | | | | |
| | | | | 551 | Option Not Support | all |
| 502 | Bad Gateway | all | +------+---------------------------------+--------------------------+
| | | |
| 503 | Service Unavailable | all |
| | | |
| 504 | Gateway Timeout | all |
| | | |
| 505 | RTSP Version Not Supported | 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-headers allow the request recipient to pass additional The response-headers allow the request recipient to pass additional
information about the response which cannot be placed in the Status- information about the response which cannot be placed in the Status-
Line. This header gives information about the server and about Line. This header gives information about the server and about
further access to the resource identified by the Request-URI. All further access to the resource identified by the Request-URI. All
headers currently classified as response headers are listed in Table headers currently classified as response headers are listed in
5. Table 5.
+------------------------+--------------------+ +------------------------+--------------------+
| Header | Defined in Section | | Header | Defined in Section |
+------------------------+--------------------+ +------------------------+--------------------+
| Connection-Credentials | Section 18.12 | | Connection-Credentials | Section 18.12 |
| | | | | |
| Location | Section 18.27 | | Location | Section 18.27 |
| | | | | |
| MTag | Section 18.30 | | MTag | Section 18.30 |
| | | | | |
skipping to change at page 46, line 41 skipping to change at page 51, line 19
10.2. Using Connections 10.2. Using Connections
A TCP transport can be used for both persistent connections (for A TCP transport can be used for both persistent connections (for
several message exchanges) and transient connections (for a single several message exchanges) and transient connections (for a single
message exchange). Implementations of this specification MUST message exchange). Implementations of this specification MUST
support RTSP over TCP. The scheme of the RTSP URI (Section 4.2) support RTSP over TCP. The scheme of the RTSP URI (Section 4.2)
indicates the default port that the server will listen on if the port indicates the default port that the server will listen on if the port
is not explicitly given. is not explicitly given.
In addition to the registered default ports, i.e. 554 (rtsp) and 322 In addition to the registered default ports, i.e. 554 (rtsp) and 322
(rtsps), there are an alternative port 8554 registered. This port (rtsps), there are an alternative port 8554 registered. This port
may provide some benefits from non-registered ports if a RTSP server may provide some benefits from non-registered ports if a RTSP server
is unable to use the default ports. The benefits may include pre- is unable to use the default ports. The benefits may include pre-
configured security policies as well as classifiers in network configured security policies as well as classifiers in network
monitoring tools. monitoring tools.
A server MUST handle both persistent and transient connections. A server MUST handle both persistent and transient connections.
Transient connections facilitate mechanisms for fault tolerance. Transient connections facilitate mechanisms for fault tolerance.
They also allow for application layer mobility. A server and They also allow for application layer mobility. A server and
skipping to change at page 49, line 13 skipping to change at page 53, line 41
close a connection immediately after responding to a session-level close a connection immediately after responding to a session-level
TEARDOWN request for the last RTSP session being controlled through TEARDOWN request for the last RTSP session being controlled through
the connection. Instead, it should wait for a reasonable amount of the connection. Instead, it should wait for a reasonable amount of
time for the client to receive the TEARDOWN response, take time for the client to receive the TEARDOWN response, take
appropriate action, and initiate the connection closing. The server appropriate action, and initiate the connection closing. The server
SHOULD wait at least 10 seconds after sending the TEARDOWN response SHOULD wait at least 10 seconds after sending the TEARDOWN response
before closing the connection. before closing the connection.
This is to ensure that the client has time to issue a SETUP for a This is to ensure that the client has time to issue a SETUP for a
new session on the existing connection after having torn the last new session on the existing connection after having torn the last
one down. 10 seconds should give the client ample opportunity to one down. 10 seconds should give the client ample opportunity to
get its message to the server. get its message to the server.
A server SHOULD NOT close the connection directly as a result of A server SHOULD NOT close the connection directly as a result of
responding to a request with an error code. responding to a request with an error code.
Certain error responses such as "460 Only Aggregate Operation Certain error responses such as "460 Only Aggregate Operation
Allowed" (Section 17.4.25) are used for negotiating capabilities Allowed" (Section 17.4.25) are used for negotiating capabilities
of a server with respect to content or other factors. In such of a server with respect to content or other factors. In such
cases, it is inefficient for the server to close a connection on cases, it is inefficient for the server to close a connection on
an error response. Also, such behavior would prevent an error response. Also, such behavior would prevent
skipping to change at page 54, line 14 skipping to change at page 59, line 14
Proxy-Supported: This header is used similarly to the Supported Proxy-Supported: This header is used similarly to the Supported
header, but instead of giving the supported functionality of header, but instead of giving the supported functionality of
the client or server it provides both the requester and the the client or server it provides both the requester and the
responder a view of what functionality the proxy chain between responder a view of what functionality the proxy chain between
the two supports. Proxies are required to add this header the two supports. Proxies are required to add this header
whenever the Supported header is present, but proxies may also whenever the Supported header is present, but proxies may also
add it independently of the requester. add it independently of the requester.
Require: This header can be included in any request where the end- Require: This header can be included in any request where the end-
point, i.e. the client or server, is required to understand point, i.e. the client or server, is required to understand the
the feature to correctly perform the request. This can, for feature to correctly perform the request. This can, for
example, be a SETUP request where the server is required to example, be a SETUP request where the server is required to
understand a certain parameter to be able to set up the media understand a certain parameter to be able to set up the media
delivery correctly. Ignoring this parameter would not have the delivery correctly. Ignoring this parameter would not have the
desired effect and is not acceptable. Therefore the end-point desired effect and is not acceptable. Therefore the end-point
receiving a request containing a Require MUST negatively receiving a request containing a Require MUST negatively
acknowledge any feature that it does not understand and not acknowledge any feature that it does not understand and not
perform the request. The response in cases where features are perform the request. The response in cases where features are
not supported are 551 (Option Not Supported). Also the not supported are 551 (Option Not Supported). Also the
features that are not supported are given in the Unsupported features that are not supported are given in the Unsupported
header in the response. header in the response.
skipping to change at page 57, line 21 skipping to change at page 62, line 40
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
asterisk ("*"), the scope is limited to the general capabilities of asterisk ("*"), the scope is limited to the general capabilities of
the next hop (i.e. the RTSP agent in direct communication with the the next hop (i.e. the RTSP agent in direct communication with the
request sender). request sender).
Regardless of scope of the request, the Public header MUST always be Regardless of scope of the request, the Public header MUST always be
included in the OPTIONS response listing the methods that are included in the OPTIONS response listing the methods that are
supported by the responding RTSP agent. In addition, if the scope of supported by the responding RTSP agent. In addition, if the scope of
the request is limited to a media resource, the Allow header MUST be the request is limited to a media resource, the Allow header MUST be
included in the response to enumerate the set of methods that are included in the response to enumerate the set of methods that are
allowed for that resource unless the set of methods completely allowed for that resource unless the set of methods completely
matches the set in the Public header. If the given resource is not matches the set in the Public header. If the given resource is not
available, the RTSP agent SHOULD return an appropriate response code available, the RTSP agent SHOULD return an appropriate response code
skipping to change at page 64, line 35 skipping to change at page 70, line 21
What range values are valid depends on the type of content. For What range values are valid depends on the type of content. For
content that isn't time progressing the range value is valid if the content that isn't time progressing the range value is valid if the
given range is part of any media within the aggregate. In other given range is part of any media within the aggregate. In other
words the valid media range for the aggregate is the union of all of words the valid media range for the aggregate is the union of all of
the media components in the aggregate. If a given range value points the media components in the aggregate. If a given range value points
outside of the media, the response MUST be the 457 (Invalid Range) outside of the media, the response MUST be the 457 (Invalid Range)
error code and include the Media-Range header (Section 18.29) with error code and include the Media-Range header (Section 18.29) with
the valid range for the media. Except for time progressing content the valid range for the media. Except for time progressing content
where the client requests a start point prior to what is retained, where the client requests a start point prior to what is retained,
the start point is adjusted to the oldest retained content. For a the start point is adjusted to the oldest retained content. For a
start point that is beyond the media front edge, i.e. beyond the start point that is beyond the media front edge, i.e. beyond the
current value for "now", the server SHALL adjust the start value to current value for "now", the server SHALL adjust the start value to
the current front edge. The Range header's stop point value may the current front edge. The Range header's stop point value may
point beyond the current media edge. In that case, the server SHALL point beyond the current media edge. In that case, the server SHALL
deliver media from the requested (and possibly adjusted) start point deliver media from the requested (and possibly adjusted) start point
until the provided stop point, or the end of the media is reached until the provided stop point, or the end of the media is reached
prior to the specified stop point. Please note that if one simply prior to the specified stop point. Please note that if one simply
wants to play from a particular start point until the end of media wants to play from a particular start point until the end of media
using a Range header with an implicit stop point is RECOMMENDED. using a Range header with an implicit stop point is RECOMMENDED.
If a client requests to start playing at the end of media, either If a client requests to start playing at the end of media, either
skipping to change at page 65, line 23 skipping to change at page 71, line 9
point the media actually is delivered. point the media actually is delivered.
A client desiring to play the media from the beginning MUST send a A client desiring to play the media from the beginning MUST send a
PLAY request with a Range header pointing at the beginning, e.g. PLAY request with a Range header pointing at the beginning, e.g.
"npt=0-". If a PLAY request is received without a Range header and "npt=0-". If a PLAY request is received without a Range header and
media delivery has stopped at the end, the server SHOULD respond with media delivery has stopped at the end, the server SHOULD respond with
a 457 "Invalid Range" error response. In that response, the current a 457 "Invalid Range" error response. In that response, the current
pause point MUST be included in a Range header. pause point MUST be included in a Range header.
All range specifiers in this specification allow for ranges with an All range specifiers in this specification allow for ranges with an
implicit start point (e.g. "npt=-30"). When used in a PLAY request, implicit start point (e.g. "npt=-30"). When used in a PLAY request,
the server treats this as a request to start or resume delivery from the server treats this as a request to start or resume delivery from
the current pause point, ending at the end time specified in the the current pause point, ending at the end time specified in the
Range header. If the pause point is located later than the given end Range header. If the pause point is located later than the given end
value, a 457 (Invalid Range) response MUST be given. value, a 457 (Invalid Range) response MUST be given.
The example below will play seconds 10 through 25. It also requests The example below will play seconds 10 through 25. It also requests
the server to deliver media from the first Random Access Point prior the server to deliver media from the first Random Access Point prior
to the indicated start point. to the indicated start point.
C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0 C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Range: npt=10-25 Range: npt=10-25
Seek-Style: RAP Seek-Style: RAP
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Servers MUST include a "Range" header in any PLAY response, even if Servers MUST include a "Range" header in any PLAY response, even if
no Range header was present in the request. The response MUST use no Range header was present in the request. The response MUST use
the same format as the request's range header contained. If no Range the same format as the request's range header contained. If no Range
header was in the request, the format used in any previous PLAY header was in the request, the format used in any previous PLAY
request within the session SHOULD be used. If no format has been request within the session SHOULD be used. If no format has been
indicated in a previous request the server MAY use any time format indicated in a previous request the server MAY use any time format
supported by the media and indicated in the Accept-Ranges header in supported by the media and indicated in the Accept-Ranges header in
the SETUP request. It is RECOMMENDED that NPT is used if supported the SETUP request. It is RECOMMENDED that NPT is used if supported
by the media. by the media.
skipping to change at page 69, line 32 skipping to change at page 75, line 30
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
the request is constructed. The session is actively playing media the request is constructed. The session is actively playing media
and the play point will be moving, making the exact time a request and the play point will be moving, making the exact time a request
will take action hard to predict. Depending on how the PLAY header will 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 an 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
requests to play ranges 10 to 15. If the new PLAY request arrives at requests to play ranges 10 to 15. If the new PLAY request arrives at
the server 4 seconds after the previous one, it will take effect the server 4 seconds after the previous one, it will take effect
while the server still plays the first range (10-15). The server while the server still plays the first range (10-15). The server
changes the current play to continue to 25 seconds, i.e. the changes the current play to continue to 25 seconds, i.e. the
equivalent single request would be PLAY with "range: npt=10-25". equivalent single request would be PLAY with "range: npt=10-25".
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
Range: npt=10-15 Range: npt=10-15
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 834 CSeq: 834
skipping to change at page 73, line 14 skipping to change at page 79, line 4
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 18.29). Range header (see Section 18.29).
A client MAY send PLAY requests without the Range header. If the A client MAY send PLAY requests without the Range header. If the
request includes the Range header it MUST use a symbolic value request includes the Range header it MUST use a symbolic value
representing "now". For NPT that range specification is "npt=now-". representing "now". For NPT that range specification is "npt=now-".
The server MUST include the Range header in the response and it MUST The server MUST include the Range header in the response and it MUST
indicate an explicit time value and not a symbolic value. In other indicate an explicit time value and not a symbolic value. In other
words, "npt=now-" is not valid to be used in the response. Instead words, "npt=now-" is not valid to be used in the response. Instead
the time since session start is recommended expressed as an open the time since session start is recommended expressed as an open
interval, e.g. "npt=96.23-". An absolute time value (clock) for the interval, e.g. "npt=96.23-". An absolute time value (clock) for the
corresponding time MAY be given, i.e. "clock=20030213T143205Z-". corresponding time MAY be given, i.e. "clock=20030213T143205Z-". The
The UTC clock format can only be used if client has shown support for UTC clock format can only be used if client has shown support for it
it using the Accept-Ranges header. using the Accept-Ranges header.
13.4.7. Playing Live with Recording 13.4.7. Playing Live with Recording
Certain media servers may offer recording services of live sessions Certain media servers may offer recording services of live sessions
to their clients. This recording would normally be from the to their clients. This recording would normally be from the
beginning of the media session. Clients can randomly access the beginning of the media session. Clients can randomly access the
media between now and the beginning of the media session. This live media between now and the beginning of the media session. This live
media with recording is indicated by the content of the Media- media with recording is indicated by the content of the Media-
Properties header in the SETUP response by (see also Section 18.28): Properties header in the SETUP response by (see also Section 18.28):
skipping to change at page 74, line 44 skipping to change at page 80, line 35
13.5. PLAY_NOTIFY 13.5. PLAY_NOTIFY
The PLAY_NOTIFY method is issued by a server to inform a client about The PLAY_NOTIFY method is issued by a server to inform a client about
an asynchronous event for a session in Play state. The Session an asynchronous event for a session in Play state. The Session
header MUST be presented in a PLAY_NOTIFY request and indicates the header MUST be presented in a PLAY_NOTIFY request and indicates the
scope of the request. Sending of PLAY_NOTIFY requests requires a scope of the request. Sending of PLAY_NOTIFY requests requires a
persistent connection between server and client, otherwise there is persistent connection between server and client, otherwise there is
no way for the server to send this request method to the client. no way for the server to send this request method to the client.
PLAY_NOTIFY requests have an end-to-end (i.e. server to client) PLAY_NOTIFY requests have an end-to-end (i.e. server to client)
scope, as they carry the Session header, and apply only to the given scope, as they carry the Session header, and apply only to the given
session. The client SHOULD immediately return a response to the session. The client SHOULD immediately return a response to the
server. server.
PLAY_NOTIFY requests MAY be used with a message body, depending on PLAY_NOTIFY requests MAY be used with a message body, depending on
the value of the Notify-Reason header. It is described in the the value of the Notify-Reason header. It is described in the
particular section for each Notify-Reason if a message body is used. particular section for each Notify-Reason if a message body is used.
However, currently there is no Notify-Reason that allows using a However, currently there is no Notify-Reason that allows using a
message body. In this case, there is a need to obey some limitations message body. In this case, there is a need to obey some limitations
when adding new Notify-Reasons that intend to use a message body: the when adding new Notify-Reasons that intend to use a message body: the
skipping to change at page 82, line 44 skipping to change at page 89, line 7
The TEARDOWN request MUST be done only 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, if it is a session aggregate) and MUST include the following streams, if it is a session aggregate) and MUST include the following
headers; Session and Terminate-Reason headers. The request only headers; Session and Terminate-Reason headers. The request only
applies to the session identified in the Session header. The server applies to the session identified in the Session header. The server
may include a message to the client's user with the "user-msg" may include a message to the client's user with the "user-msg"
parameter. 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:
1. respond to the TEARDOWN request 1. respond to the TEARDOWN request
2. disconnect the control channel from the requesting server 2. disconnect the control channel from the requesting server
skipping to change at page 84, line 46 skipping to change at page 91, line 12
packets_received: 10 packets_received: 10
jitter: 0.3838 jitter: 0.3838
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 have been processed. To allow a client to determine if or may not have been processed. To allow a client to determine if
any such header has been processed, it is necessary to use a feature any such header has been processed, it is necessary to use a feature
tag and the Require header. Due to this reason it is RECOMMENDED tag and the Require header. Due to this reason it is RECOMMENDED
that any parameters are sent in the body, rather than using any that any parameters are sent in the body, rather than using any
header. 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
skipping to change at page 86, line 24 skipping to change at page 92, line 43
The REDIRECT request SHALL contain a Terminate-Reason header The REDIRECT request SHALL contain a Terminate-Reason header
(Section 18.50) to inform the client of the reason for the request. (Section 18.50) to inform the client of the reason for the request.
Additional parameters related to the reason may also be included. Additional parameters related to the reason may also be included.
The intention here is to allow a server administrator to do a The intention here is to allow a server administrator to do a
controlled shutdown of the RTSP server. That requires sufficient controlled shutdown of the RTSP server. That requires sufficient
time to inform all entities having associated state with the server time to inform all entities having associated state with the server
and for them to perform a controlled migration from this server to a and for them to perform a controlled migration from this server to a
fall back server. fall back server.
A REDIRECT request with a Session header has end-to-end (i.e. server A REDIRECT request with a Session header has end-to-end (i.e. server
to client) scope and applies only to the given session. Any to client) scope and applies only to the given session. Any
intervening proxies SHOULD NOT disconnect the control channel while intervening proxies SHOULD NOT disconnect the control channel while
there are other remaining end-to-end sessions. The REQUIRED Location there are other remaining end-to-end sessions. The REQUIRED Location
header MUST contain a complete absolute URI pointing to the resource header MUST contain a complete absolute URI pointing to the resource
to which the client SHOULD reconnect. Specifically, the Location to which the client SHOULD reconnect. Specifically, the Location
MUST NOT contain just the host and port. A client may receive a MUST NOT contain just the host and port. A client may receive a
REDIRECT request with a Session header, if and only if, an end-to-end REDIRECT request with a Session header, if and only if, an end-to-end
session has been established. session has been established.
A client may receive a REDIRECT request without a Session header at A client may receive a REDIRECT request without a Session header at
skipping to change at page 88, line 11 skipping to change at page 94, line 26
Request-URI will have to establish a new session with the designated Request-URI will have to establish a new session with the designated
host. If the URI given in the Location header is a valid resource host. If the URI given in the Location header is a valid resource
URI, a client SHOULD issue a DESCRIBE request for the URI. URI, a client SHOULD issue a DESCRIBE request for the URI.
Note: The media resource indicated by the Location header can be Note: The media resource indicated by the Location header can be
identical, slightly different or totally different. This is the identical, slightly different or totally different. This is the
reason why a new DESCRIBE request SHOULD be issued. reason why a new DESCRIBE request SHOULD be issued.
If the Location header contains only a host address, the client MAY If the Location header contains only a host address, the client MAY
assume that the media on the new server is identical to the media on assume that the media on the new server is identical to the media on
the old server, i.e. all media configuration information from the the old server, i.e. all media configuration information from the old
old session is still valid except for the host address. However, the session is still valid except for the host address. However, the
usage of conditional SETUP using MTag identifiers are RECOMMENDED to usage of conditional SETUP using MTag identifiers are RECOMMENDED to
verify the assumption. verify the assumption.
This example request redirects traffic for this session to the new This example request redirects traffic for this session to the new
server at the given absolute time: server at the given absolute time:
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 732 CSeq: 732
Location: rtsp://s2.example.com:8001 Location: rtsp://s2.example.com:8001
Terminate-Reason: Server-Admin ;time=19960213T143205Z Terminate-Reason: Server-Admin ;time=19960213T143205Z
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
Date: Thu, 13 Feb 1996 14:30:43 GMT Date: Thu, 13 Feb 1996 14:30:43 GMT
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 732 CSeq: 732
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
14. Embedded (Interleaved) Binary Data 14. Embedded (Interleaved) Binary Data
In order to fulfill certain requirements on the network side, e.g. In order to fulfill certain requirements on the network side, e.g. in
in conjunction with network address translators that block RTP conjunction with network address translators that block RTP traffic
traffic over UDP, it may be necessary to interleave RTSP messages and over UDP, it may be necessary to interleave RTSP messages and media
media stream data. This interleaving should generally be avoided stream data. This interleaving should generally be avoided unless
unless necessary since it complicates client and server operation and necessary since it complicates client and server operation and
imposes additional overhead. Also, head of line blocking may cause imposes additional overhead. Also, head of line blocking may cause
problems. Interleaved binary data SHOULD only be used if RTSP is problems. Interleaved binary data SHOULD only be used if RTSP is
carried over TCP. Interleaved data is not allowed inside RTSP carried over TCP. Interleaved data is not allowed inside RTSP
messages. messages.
Stream data such as RTP packets is encapsulated by an ASCII dollar Stream data such as RTP packets is encapsulated by an ASCII dollar
sign (36 decimal), followed by a one-byte channel identifier, sign (36 decimal), followed by a one-byte channel identifier,
followed by the length of the encapsulated binary data as a binary, followed by the length of the encapsulated binary data as a binary,
two-byte integer in network byte order. The stream data follows two-byte integer in network byte order. The stream data follows
immediately afterwards, without a CRLF, but including the upper-layer immediately afterwards, without a CRLF, but including the upper-layer
protocol headers. Each $ block MUST contain exactly one upper-layer protocol headers. Each $ block MUST contain exactly one upper-layer
protocol data unit, e.g., one RTP packet. protocol data unit, e.g., one RTP packet.
0 1 2 3
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | "$" = 36 | Channel ID | Length in bytes |
| "$" = 36 | Channel ID | Length in bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Length number of bytes of binary data :
: Length number of bytes of binary data : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The channel identifier is defined in the Transport header with the The channel identifier is defined in the Transport header with the
interleaved parameter (Section 18.52). interleaved parameter (Section 18.52).
When the transport choice is RTP, RTCP messages are also interleaved When the transport choice is RTP, RTCP messages are also interleaved
by the server over the TCP connection. The usage of RTCP messages is by the server over the TCP connection. The usage of RTCP messages is
indicated by including an interval containing a second channel in the indicated by including an interval containing a second channel in the
interleaved parameter of the Transport header, see Section 18.52. If interleaved parameter of the Transport header, see Section 18.52. If
RTCP is used, packets MUST be sent on the first available channel RTCP is used, packets MUST be sent on the first available channel
higher than the RTP channel. The channels are bi-directional, using higher than the RTP channel. The channels are bi-directional, using
skipping to change at page 91, line 10 skipping to change at page 97, line 39
has been cached and has not become stale. See the caching has been cached and has not become stale. See the caching
Section 16. This type of proxy is also expected to understand Section 16. 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 gets access to servers and content on an external client gets access to servers and content on an external
network or using content encodings not supported by the client. network or using content encodings not supported by the client.
The 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 an RTSP Access Proxy: This type of proxy is used to ensure that an RTSP
client gets access to servers on an external network. Thus client gets access to servers on an external network. Thus
this 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 proxy is required to redirect the media to itself or a type of proxy is required to redirect the media to itself or a
controlled gateway that performs the translation before the controlled gateway that performs the translation 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 requests that the firewalled network, the security proxy requests that the
necessary pinholes in the firewall are opened when a client in necessary pinholes in the firewall are opened when a client in
the protected network wants to access media streams on the the protected network wants to access media streams on the
external side. This proxy can also limit the client's access external side. This proxy can also limit the client's access
to certain types of content. This proxy can perform its to certain types of content. This proxy can perform its
function without redirecting the media between the server and function without redirecting the media between the server and
client. However, in deployments with private address spaces client. However, in deployments with private address spaces
this proxy is likely to be combined with the access proxy. this proxy is likely to be combined with the access proxy.
Anyway, the functionality of this proxy is usually closely tied Anyway, the functionality of this proxy is usually closely tied
into understanding all aspects of the media transport. into 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 track 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 types of proxies can be used also when using secured All types of proxies can be used also when using secured
communication with TLS as RTSP 2.0 allows the client to approve communication with TLS as RTSP 2.0 allows the client to approve
certificate chains used for connection establishment from a proxy, certificate chains used for connection establishment from a proxy,
see Section 19.3.2. However, that trust model may not be suitable see Section 19.3.2. However, that trust model may not be suitable
for all types of deployment. In those cases, the secured sessions do for all types of deployment. In those cases, the secured sessions do
by-pass the proxies. by-pass 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.
15.1. Proxies and Protocol Extensions 15.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
skipping to change at page 94, line 17 skipping to change at page 100, line 49
a client. Just as an HTTP cache has to store the content type, a client. Just as an HTTP cache has to store the content type,
content language, and so on for the objects it caches, a media cache content language, and so on for the objects it caches, a media cache
has to store the presentation description. Typically, a cache has to store the presentation description. Typically, a cache
eliminates all transport-references (e.g., multicast information) eliminates all transport-references (e.g., multicast information)
from the presentation description, since these are independent of the from the presentation description, since these are independent of the
data delivery from the cache to the client. Information on the data delivery from the cache to the client. Information on the
encodings remains the same. If the cache is able to translate the encodings remains the same. If the cache is able to translate the
cached media data, it would create a new presentation description cached media data, it would create a new presentation description
with all the encoding possibilities it can offer. with all the encoding possibilities it can offer.
16.1. Validation Model 16.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
entry is invalid, the RTSP protocol supports the use of conditional entry is invalid, the RTSP protocol supports the use of conditional
methods. methods.
skipping to change at page 103, line 14 skipping to change at page 110, line 28
content is unchanged (only the session description) and a 304 content is unchanged (only the session description) and a 304
response to SETUP does NOT imply that the resource description is response to SETUP does NOT imply that the resource description is
unchanged. The MTag and If-Match headers may be used to link the unchanged. The MTag and If-Match headers may be used to link the
DESCRIBE and SETUP in this manner. DESCRIBE and SETUP in this manner.
17.3.5. 305 Use Proxy 17.3.5. 305 Use Proxy
The requested resource MUST be accessed through the proxy given by The requested resource MUST be accessed through the proxy given by
the Location field. The Location field gives the URI of the proxy. the Location field. The Location field gives the URI of the proxy.
The recipient is expected to repeat this single request via the The recipient is expected to repeat this single request via the
proxy. 305 responses MUST only be generated by origin servers. proxy. 305 responses MUST only be generated by origin servers.
17.4. Client Error 4xx 17.4. Client Error 4xx
17.4.1. 400 Bad Request 17.4.1. 400 Bad Request
The request could not be understood by the server due to malformed The request could not be understood by the server due to malformed
syntax. The client SHOULD NOT repeat the request without syntax. The client SHOULD NOT repeat the request without
modifications. If the request does not have a CSeq header, the modifications. If the request does not have a CSeq header, the
server MUST NOT include a CSeq in the response. server MUST NOT include a CSeq in the response.
skipping to change at page 111, line 20 skipping to change at page 118, line 34
| SETUP | C -> S | S | STP | | | SETUP | C -> S | S | STP | |
| | | | | | | | | | | |
| SET_PARAMETER | C -> S, S -> C | P,S | SPR | R,r | | SET_PARAMETER | C -> S, S -> C | P,S | SPR | R,r |
| | | | | | | | | | | |
| TEARDOWN | C -> S | P,S | TRD | | | TEARDOWN | C -> S | P,S | TRD | |
| | | | | | | | | | | |
| | S -> C | P | TRD | | | | S -> C | P | TRD | |
+---------------+----------------+--------+---------+------+ +---------------+----------------+--------+---------+------+
Table 8: Overview of RTSP methods, their direction, and what objects Table 8: Overview of RTSP methods, their direction, and what objects
(P: presentation, S: stream) they operate on. Body notes if a method (P: presentation, S: stream) they operate on. Body notes if a method
is allowed to carry body and in which direction, R = Request, is allowed to carry body and in which direction, R = Request,
r=response. Note: It is allowed for all error messages 4xx and 5xx r=response. Note: It is allowed for all error messages 4xx and 5xx to
to have a body have a body
The general syntax for header fields is covered in Section 5.2. This The general syntax for header fields is covered in Section 5.2. This
section lists the full set of header fields along with notes on section lists the full set of header fields along with notes on
meaning, and usage. The syntax definition for header fields are meaning, and usage. The syntax definition for header fields are
present in Section 20.2.3. Throughout this section, we use [HX.Y] to present in Section 20.2.3. Throughout this section, we use [HX.Y] to
informational refer to Section X.Y of the current HTTP/1.1 informational refer to Section X.Y of the current HTTP/1.1
specification RFC 2616 [RFC2616]. Examples of each header field are specification RFC 2616 [RFC2616]. Examples of each header field are
given. given.
Information about header fields in relation to methods and proxy Information about header fields in relation to methods and proxy
processing is summarized in Table 9, Table 10, Table 11, and Table processing is summarized in Table 9, Table 10, Table 11, and
12. Table 12.
The "where" column describes the request and response types in which The "where" column describes the request and response types in which
the header field can be used. Values in this column are: the header field can be used. Values in this column are:
R: header field may only appear in requests; R: header field may only appear in requests;
r: header field may only appear in responses; r: header field may only appear in responses;
2xx, 4xx, etc.: A numerical value or range indicates response codes 2xx, 4xx, etc.: A numerical value or range indicates response codes
with which the header field can be used; with which the header field can be used;
skipping to change at page 113, line 15 skipping to change at page 120, line 27
the Client/Server MUST 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 quote, 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 | DES | OPT | STP | PL | PS | TR | | Header | Where | Pro | DE | OPT | STP | PLY | PSE | TRD |
| | | xy | | | | Y | E | D | | | | xy | S | | | | | |
+--------------------+-------+-----+-----+-----+-----+----+----+----+ +------------------+-------+-----+----+-----+-----+-----+-----+-----+
| Accept | R | | o | - | - | - | - | - | | Accept | R | | o | - | - | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Accept-Credentials | R | rm | o | o | o | o | o | o | | Accept-Credentia | R | rm | o | o | o | o | o | o |
| | | | | | | | | | | ls | | | | | | | | |
| Accept-Encoding | R | r | o | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Accept-Encoding | R | r | o | - | - | - | - | - |
| Accept-Language | R | r | o | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Accept-Language | R | r | o | - | - | - | - | - |
| Accept-Ranges | R | r | - | - | m | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Accept-Ranges | R | r | - | - | m | - | - | - |
| Accept-Ranges | r | r | - | - | m | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Accept-Ranges | r | r | - | - | m | - | - | - |
| Accept-Ranges | 456 | r | - | - | - | m | - | - | | | | | | | | | | |
| | | | | | | | | | | Accept-Ranges | 456 | r | - | - | - | m | - | - |
| Allow | r | am | c | c | c | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Allow | r | am | c | c | c | - | - | - |
| Allow | 405 | am | m | m | m | m | m | m | | | | | | | | | | |
| | | | | | | | | | | Allow | 405 | am | m | m | m | m | m | m |
| Authorization | R | | o | o | o | o | o | o | | | | | | | | | | |
| | | | | | | | | | | Authorization | R | | o | o | o | o | o | o |
| Bandwidth | R | | o | o | o | o | - | - | | | | | | | | | | |
| | | | | | | | | | | Bandwidth | R | | o | o | o | o | - | - |
| Blocksize | R | | o | - | o | o | - | - | | | | | | | | | | |
| | | | | | | | | | | Blocksize | R | | o | - | o | o | - | - |
| Cache-Control | | r | o | - | o | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Cache-Control | | r | o | - | o | - | - | - |
| Connection | | ad | o | o | o | o | o | o | | | | | | | | | | |
| | | | | | | | | | | Connection | | ad | o | o | o | o | o | o |
| Connection- | 470,4 | ar | o | o | o | o | o | o | | | | | | | | | | |
| Credentials | 07 | | | | | | | | | Connection-Crede | 470,4 | ar | o | o | o | o | o | o |
| | | | | | | | | | | ntials | 07 | | | | | | | |
| Content-Base | r | | o | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Content-Base | r | | o | - | - | - | - | - |
| Content-Base | 4xx,5 | | o | o | o | o | o | o | | | | | | | | | | |
| | xx | | | | | | | | | Content-Base | 4xx,5 | | o | o | o | o | o | o |
| | | | | | | | | | | | xx | | | | | | | |
| Content-Encoding | R | r | - | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Content-Encoding | R | r | - | - | - | - | - | - |
| Content-Encoding | r | r | o | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Content-Encoding | r | r | o | - | - | - | - | - |
| Content-Encoding | 4xx,5 | r | o | o | o | o | o | o | | | | | | | | | | |
| | xx | | | | | | | | | Content-Encoding | 4xx,5 | r | o | o | o | o | o | o |
| | | | | | | | | | | | xx | | | | | | | |
| Content-Language | R | r | - | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Content-Language | R | r | - | - | - | - | - | - |
| Content-Language | r | r | o | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Content-Language | r | r | o | - | - | - | - | - |
| Content-Language | 4xx,5 | r | o | o | o | o | o | o | | | | | | | | | | |
| | xx | | | | | | | | | Content-Language | 4xx,5 | r | o | o | o | o | o | o |
| | | | | | | | | | | | xx | | | | | | | |
| Content-Length | r | r | * | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Content-Length | r | r | * | - | - | - | - | - |
| Content-Length | 4xx,5 | r | * | * | * | * | * | * | | | | | | | | | | |
| | xx | | | | | | | | | Content-Length | 4xx,5 | r | * | * | * | * | * | * |
| | | | | | | | | | | | xx | | | | | | | |
| Content-Location | r | r | o | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Content-Location | r | r | o | - | - | - | - | - |
| Content-Location | 4xx,5 | r | o | o | o | o | o | o | | | | | | | | | | |
| | xx | | | | | | | | | Content-Location | 4xx,5 | r | o | o | o | o | o | o |
| | | | | | | | | | | | xx | | | | | | | |
| Content-Type | r | r | * | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Content-Type | r | r | * | - | - | - | - | - |
| Content-Type | 4xx,5 | ar | * | * | * | * | * | * | | | | | | | | | | |
| | xx | | | | | | | | | Content-Type | 4xx,5 | ar | * | * | * | * | * | * |
| | | | | | | | | | | | xx | | | | | | | |
| CSeq | Rc | rm | m | m | m | m | m | m | | | | | | | | | | |
| | | | | | | | | | | CSeq | Rc | rm | m | m | m | m | m | m |
| Date | | am | o/* | o/* | o/* | o/ | o/ | o/ | | | | | | | | | | |
| | | | | | | * | * | * | | Date | | am | o/ | o/* | o/* | o/* | o/* | o/* |
| | | | | | | | | | | | | | * | | | | | |
| Expires | r | r | o | - | o | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Expires | r | r | o | - | o | - | - | - |
| From | R | r | o | o | o | o | o | o | | | | | | | | | | |
| | | | | | | | | | | From | R | r | o | o | o | o | o | o |
| If-Match | R | r | - | - | o | - | - | - | | | | | | | | | | |
| | | | | | | | | | | If-Match | R | r | - | - | o | - | - | - |
| If-Modified-Since | R | r | o | - | o | - | - | - | | | | | | | | | | |
| | | | | | | | | | | If-Modified-Sinc | R | r | o | - | o | - | - | - |
| If-None-Match | R | r | o | - | o | - | - | - | | e | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Last-Modified | r | r | o | - | o | - | - | - | | If-None-Match | R | r | o | - | o | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Location | 3rr | | o | o | o | o | o | o | | Last-Modified | r | r | 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 | Proxy | DES | OPT | STP | PL | PS | TR | | Header | Where | Prox | DES | OPT | STP | PLY | PSE | TRD |
| | | | | | | Y | E | D | | | | 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- Require | R | ar | o | o | o | o | o | o | | Proxy- Require | R | ar | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Proxy- Require | r | r | c | c | c | c | c | c | | Proxy- Require | r | r | c | c | c | c | c | c |
| | | | | | | | | | | | | | | | | | | |
| Proxy- Supported | R | amr | c | c | c | c | c | c | | Proxy- | R | amr | c | c | c | c | c | c |
| | | | | | | | | | | Supported | | | | | | | | |
| Proxy- Supported | r | | c | c | c | c | c | c | | Proxy- | r | | c | c | c | c | c | c |
| | | | | | | | | | | Supported | | | | | | | | |
| Public | r | amr | - | m | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Public | r | amr | - | m | - | - | - | - |
| Public | 501 | amr | m | m | m | m | m | m | | | | | | | | | | |
| | | | | | | | | | | Public | 501 | amr | m | m | m | m | m | m |
| Range | R | | - | - | - | o | - | - | | | | | | | | | | |
| | | | | | | | | | | Range | R | | - | - | - | o | - | - |
| Range | r | | - | - | c | m | m | - | | | | | | | | | | |
| | | | | | | | | | | Range | r | | - | - | c | m | m | - |
| Referrer | R | | o | o | o | o | o | o | | | | | | | | | | |
| | | | | | | | | | | Referrer | R | | o | o | o | o | o | o |
| Request- Status | R | | - | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Request- | R | | - | - | - | - | - | - |
| Require | R | | o | o | o | o | o | o | | Status | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Retry-After | 3rr,5 | | o | o | o | o | o | - | | Require | R | | o | o | o | o | o | o |
| | 03 | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Retry-After | 3rr,5 | | o | o | o | o | o | - |
| Retry-After | 413 | | o | - | - | - | - | - | | | 03 | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| RTP-Info | r | | - | - | c | c | - | - | | Retry-After | 413 | | o | - | - | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Scale | R | r | - | - | - | o | - | - | | RTP-Info | r | | - | - | c | c | - | - |
| | | | | | | | | | | | | | | | | | | |
| Scale | r | amr | - | - | - | c | - | - | | Scale | R | r | - | - | - | o | - | - |
| | | | | | | | | | | | | | | | | | | |
| Seek-Style | R | | - | - | - | o | - | - | | Scale | r | amr | - | - | - | c | - | - |
| | | | | | | | | | | | | | | | | | | |
| Seek-Style | r | | - | - | - | m | - | - | | Seek-Style | R | | - | - | - | o | - | - |
| | | | | | | | | | | | | | | | | | | |
| Server | R | r | - | o | - | - | - | o | | Seek-Style | r | | - | - | - | m | - | - |
| | | | | | | | | | | | | | | | | | | |
| Server | r | r | o | o | o | o | o | o | | Server | R | r | - | o | - | - | - | o |
| | | | | | | | | | | | | | | | | | | |
| Session | R | r | - | o | o | m | m | m | | Server | r | r | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Session | r | r | - | c | m | m | m | o | | Session | R | r | - | o | o | m | m | m |
| | | | | | | | | | | | | | | | | | | |
| Speed | R | admr | - | - | - | o | - | - | | Session | r | r | - | c | m | m | m | o |
| | | | | | | | | | | | | | | | | | | |
| Speed | r | admr | - | - | - | c | - | - | | Speed | R | admr | - | - | - | o | - | - |
| | | | | | | | | | | | | | | | | | | |
| Supported | R | amr | o | o | o | o | o | o | | Speed | r | admr | - | - | - | c | - | - |
| | | | | | | | | | | | | | | | | | | |
| Supported | r | amr | c | c | c | c | c | c | | Supported | R | amr | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Terminate-Reason | R | r | - | - | - | - | - | - | | Supported | r | amr | c | c | c | c | c | c |
| | | | | | | | | | | Terminate-Reas | R | r | - | - | - | - | - | - |
| Timestamp | R | admr | o | o | o | o | o | o | | on | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| 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 |
| | | | | | | | | | | | | | | | | | | |
| Via | R | amr | o | o | o | o | o | o | | User-Agent | R | | m* | m* | m* | m* | m* | m* |
| | | | | | | | | | | | | | | | | | | |
| 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 (M-W) related to methods Table 10: Overview of RTSP header fields (M-W) related to methods
DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.
+------------------------+---------+-------+-----+-----+-----+-----+ +------------------------+---------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY | | Header | Where | Proxy | GPR | SPR | RDR | PNY |
+------------------------+---------+-------+-----+-----+-----+-----+ +------------------------+---------+-------+-----+-----+-----+-----+
| Accept | R | arm | o | o | - | - | | Accept | R | arm | o | o | - | - |
| | | | | | | | | | | | | | | |
| Accept-Credentials | R | rm | o | o | o | - | | Accept-Credentials | R | rm | o | o | o | - |
skipping to change at page 117, line 35 skipping to change at page 125, line 4
| | | | | | | | | | | | | | | |
| Authorization | R | | o | o | o | - | | Authorization | R | | o | o | o | - |
| | | | | | | | | | | | | | | |
| Bandwidth | R | | - | o | - | - | | Bandwidth | R | | - | o | - | - |
| | | | | | | | | | | | | | | |
| Blocksize | R | | - | o | - | - | | Blocksize | R | | - | o | - | - |
| | | | | | | | | | | | | | | |
| Cache-Control | | r | o | o | - | - | | Cache-Control | | r | o | o | - | - |
| | | | | | | | | | | | | | | |
| Connection | | | o | o | o | o | | Connection | | | o | o | o | o |
| | | | | | | |
| Connection-Credentials | 470,407 | ar | o | o | o | - | | Connection-Credentials | 470,407 | ar | o | o | o | - |
| | | | | | | | | | | | | | | |
| Content-Base | R | | o | o | - | - | | Content-Base | R | | o | o | - | - |
| | | | | | | | | | | | | | | |
| Content-Base | r | | o | o | - | - | | Content-Base | r | | o | o | - | - |
| | | | | | | | | | | | | | | |
| Content-Base | 4xx,5xx | | o | o | o | o | | Content-Base | 4xx,5xx | | o | o | o | o |
| | | | | | | | | | | | | | | |
| Content-Encoding | R | r | o | o | - | - | | Content-Encoding | R | r | o | o | - | - |
| | | | | | | | | | | | | | | |
skipping to change at page 120, line 34 skipping to change at page 128, line 4
| | | | | | | | | | | | | | | |
| 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 | | mr | - | - | - | - | | Transport | | mr | - | - | - | - |
| | | | | | | | | | | | | | | |
| Unsupported | r | arm | c | c | c | - | | Unsupported | r | arm | c | c | c | - |
| | | | | | | | | | | | | | | |
| User-Agent | R | r | m* | m* | - | - | | User-Agent | R | r | m* | m* | - | - |
| | | | | | | |
| User-Agent | r | r | m* | m* | m* | m* | | User-Agent | r | r | m* | m* | m* | m* |
| | | | | | | | | | | | | | | |
| Via | R | amr | o | o | o | - | | Via | R | amr | o | o | o | - |
| | | | | | | | | | | | | | | |
| Via | c | dr | m | m | m | - | | Via | c | dr | m | m | m | - |
| | | | | | | | | | | | | | | |
| WWW-Authenticate | 401 | | m | m | m | - | | WWW-Authenticate | 401 | | m | m | m | - |
+------------------+---------+-------+-----+-----+-----+-----+ +------------------+---------+-------+-----+-----+-----+-----+
Table 12: Overview of RTSP header fields (R-W) related to methods Table 12: Overview of RTSP header fields (R-W) related to methods
GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY. GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY.
18.1. Accept 18.1. Accept
The Accept request-header field can be used to specify certain The Accept request-header field can be used to specify certain
presentation description and parameter media types [RFC6838] which presentation description and parameter media types [RFC6838] which
are acceptable for the response to DESCRIBE and GET_PARAMETER are acceptable for the response to DESCRIBE and GET_PARAMETER
requests. requests.
See Section 20.2.3 for the syntax. See Section 20.2.3 for the syntax.
Example of use: Example of use:
Accept: application/example ;q=1.0, application/sdp
Accept: application/example ;q=1.0, application/sdp
18.2. Accept-Credentials 18.2. Accept-Credentials
The Accept-Credentials header is a request header used to indicate to The Accept-Credentials header is a request header used to indicate to
any trusted intermediary how to handle further secured connections to any trusted intermediary how to handle further secured connections to
proxies or servers. 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
skipping to change at page 121, line 49 skipping to change at page 129, line 11
token "sha-256". token "sha-256".
The intention with allowing for other hash algorithms is to enable The intention with allowing for other hash algorithms is to enable
the future retirement of algorithms that are not implemented the future retirement of algorithms that are not implemented
somewhere else than here. Thus the definition of future algorithms somewhere else than here. Thus the definition of future algorithms
for this purpose is intended to be extremely limited. A feature tag for this purpose is intended to be extremely limited. A feature tag
can be used to ensure that support for the replacement algorithm can be used to ensure that support for the replacement algorithm
exist. exist.
Example: Example:
Accept-Credentials:User Accept-Credentials:User
"rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=, "rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=,
"rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M= "rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M=
18.3. Accept-Encoding 18.3. Accept-Encoding
The Accept-Encoding request-header field is similar to Accept, but The Accept-Encoding request-header field is similar to Accept, but
restricts the content-codings (see Section 18.14),i.e. restricts the content-codings (see Section 18.14),i.e. transformation
transformation codings of the message body, such as gzip compression, codings of the message body, such as gzip compression, that are
that are acceptable in the response. acceptable in the response.
A server tests whether a content-coding is acceptable, according to A server tests whether a content-coding is acceptable, according to
an Accept-Encoding field, using these rules: an Accept-Encoding field, using these rules:
1. If the content-coding is one of the content-codings listed in the 1. If the content-coding is one of the content-codings listed in the
Accept-Encoding field, then it is acceptable, unless it is Accept-Encoding field, then it is acceptable, unless it is
accompanied by a qvalue of 0. (As defined in [H3.9], a qvalue of accompanied by a qvalue of 0. (As defined in [H3.9], a qvalue of
0 means "not acceptable.") 0 means "not acceptable.")
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
Accept-Encoding field includes "identity;q=0", or because the Accept-Encoding field includes "identity;q=0", or because the
field includes "*;q=0" and does not explicitly include the field includes "*;q=0" and does not explicitly include the
"identity" content-coding. If the Accept-Encoding field-value is "identity" content-coding. If the Accept-Encoding field-value is
empty, then only the "identity" encoding is acceptable. empty, then only the "identity" encoding is acceptable.
If an Accept-Encoding field is present in a request, and if the If an Accept-Encoding field is present in a request, and if the
server cannot send a response which is acceptable according to the server cannot send a response which is acceptable according to the
Accept-Encoding header, then the server SHOULD send an error response Accept-Encoding header, then the server SHOULD send an error response
with the 406 (Not Acceptable) status code. with the 406 (Not Acceptable) status code.
skipping to change at page 124, line 16 skipping to change at page 131, line 23
header in SETUP requests to indicate which formats it support to header in SETUP requests to indicate which formats it support to
receive in PLAY and PAUSE responses, and REDIRECT requests. The receive in PLAY and PAUSE responses, and REDIRECT requests. The
server MUST include the header in SETUP and 456 error responses to server MUST include the header in SETUP and 456 error responses to
indicate the formats supported for the resource indicated by the indicate the formats supported for the resource indicated by the
request URI. The header MAY be included in GET_PARAMETER request and request URI. The header MAY be included in GET_PARAMETER request and
response pairs. The GET_PARAMETER request MUST contain a Session response pairs. The GET_PARAMETER request MUST contain a Session
header to identify the session context the request is related to. header to identify the session context the request is related to.
The requester and responder will indicate their capabilities The requester and responder will indicate their capabilities
regarding Range formats respectively. regarding Range formats respectively.
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
The syntax is defined in Section 20.2.3. The syntax is defined in Section 20.2.3.
18.6. Allow 18.6. Allow
The Allow message-header field lists the methods supported by the The Allow message-header field lists the methods supported by the
resource identified by the Request-URI. The purpose of this field is resource identified by the Request-URI. The purpose of this field is
to strictly inform the recipient of valid methods associated with the to strictly inform the recipient of valid methods associated with the
resource. An Allow header field MUST be present in a 405 (Method Not resource. An Allow header field MUST be present in a 405 (Method Not
Allowed) response. The Allow header MUST also be present in all Allowed) response. The Allow header MUST also be present in all
OPTIONS responses where the content of the header will not include OPTIONS responses where the content of the header will not include
exactly the same methods as listed in the Public header. exactly the same methods as listed in the Public header.
The Allow MUST also be included in SETUP and DESCRIBE responses, if The Allow MUST also be included in SETUP and DESCRIBE responses, if
the methods allowed for the resource is different than the complete the methods allowed for the resource is different than the complete
set of methods defined in this memo. set of methods defined in this memo.
Example of use: Example of use:
Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE
Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE
18.7. Authorization 18.7. Authorization
An RTSP client that wishes to authenticate itself with a server using An RTSP client that wishes to authenticate itself with a server using
authentication mechanism from HTTP [RFC2617] , usually, but not authentication mechanism from HTTP [RFC2617] , usually, but not
necessarily, after receiving a 401 response, does so by including an necessarily, after receiving a 401 response, does so by including an
Authorization request-header field with the request. The Authorization request-header field with the request. The
Authorization field value consists of credentials containing the Authorization field value consists of credentials containing the
authentication information of the user agent for the realm of the authentication information of the user agent for the realm of the
resource being requested. resource being requested.
skipping to change at page 126, line 24 skipping to change at page 133, line 15
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 have accurate and explicit It is RECOMMENDED that only clients that have 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. It is This header is not a substitute for proper congestion control. It is
only a method providing an initial estimate and coarsely determines only a method providing an initial estimate and coarsely determines
if the selected content can be delivered at all. if the selected content can be delivered at all.
Example: Example:
Bandwidth: 62360
Bandwidth: 62360
18.9. Blocksize 18.9. Blocksize
The Blocksize request-header field is sent from the client to the The Blocksize request-header field is sent from the client to the
media server asking the server for a particular media packet size. media server asking the server for a particular media packet size.
This packet size does not include lower-layer headers such as IP, This packet size does not include lower-layer headers such as IP,
UDP, or RTP. The server is free to use a blocksize which is lower UDP, or RTP. The server is free to use a blocksize which is lower
than the one requested. The server MAY truncate this packet size to than the one requested. The server MAY truncate this packet size to
the closest multiple of the minimum, media-specific block size, or the closest multiple of the minimum, media-specific block size, or
override it with the media-specific size if necessary. The block override it with the media-specific size if necessary. The block
skipping to change at page 132, line 31 skipping to change at page 139, line 23
"A First Lesson in Latin," which is clearly intended to be used by an "A First Lesson in Latin," which is clearly intended to be used by an
English-literate audience. In this case, the Content-Language would English-literate audience. In this case, the Content-Language would
properly only include "en". properly only include "en".
Content-Language MAY be applied to any media type -- it is not Content-Language MAY be applied to any media type -- it is not
limited to textual documents. limited to textual documents.
18.16. Content-Length 18.16. Content-Length
The Content-Length general-header field contains the length of the The Content-Length general-header field contains the length of the
message body of the RTSP message (i.e. after the double CRLF message body of the RTSP message (i.e. after the double CRLF
following the last header). Unlike HTTP, it MUST be included in all following the last header). Unlike HTTP, it MUST be included in all
messages that carry a message body beyond the header portion of the messages that carry a message body beyond the header portion of the
RTSP message. If it is missing, a default value of zero is assumed. RTSP message. If it is missing, a default value of zero is assumed.
Any Content-Length greater than or equal to zero is a valid value. Any Content-Length greater than or equal to zero is a valid value.
18.17. Content-Location 18.17. Content-Location
The Content-Location header field MAY be used to supply the resource The Content-Location header field MAY be used to supply the resource
location for the message body enclosed in the message when that body location for the message body enclosed in the message when that body
is accessible from a location separate from the requested resource's is accessible from a location separate from the requested resource's
skipping to change at page 133, line 7 skipping to change at page 139, line 47
entities actually have separate locations by which they might be entities actually have separate locations by which they might be
individually accessed, the server SHOULD provide a Content-Location individually accessed, the server SHOULD provide a Content-Location
for the particular variant which is returned. for the particular variant which is returned.
As example, if an RTSP client performs a DESCRIBE request on a given As example, if an RTSP client performs a DESCRIBE request on a given
resource, e.g., "rtsp://a.example.com/movie/Plan9FromOuterSpace", resource, e.g., "rtsp://a.example.com/movie/Plan9FromOuterSpace",
then the server may use additional information, such as the User- then the server may use additional information, such as the User-
Agent header, to determine the capabilities of the agent. The server Agent header, to determine the capabilities of the agent. The server
will then return a media description tailored to that class of RTSP will then return a media description tailored to that class of RTSP
agents. To indicate which specific description the agent receives agents. To indicate which specific description the agent receives
the resource identifier ("rtsp://a.example.com/movie/ the resource identifier
Plan9FromOuterSpace/FullHD.sdp") is provided in Content-Location, ("rtsp://a.example.com/movie/Plan9FromOuterSpace/FullHD.sdp") is
while the description is still a valid response for the generic provided in Content-Location, while the description is still a valid
resource identifier. Thus enabling both debugging and cache response for the generic resource identifier. Thus enabling both
operation as discussed below. debugging and cache operation as discussed below.
The Content-Location value is not a replacement for the original The Content-Location value is not a replacement for the original
requested URI; it is only a statement of the location of the resource requested URI; it is only a statement of the location of the resource
corresponding to this particular variant at the time of the request. corresponding to this particular variant at the time of the request.
Future requests MAY specify the Content-Location URI as the request Future requests MAY specify the Content-Location URI as the request
URI if the desire is to identify the source of that particular URI if the desire is to identify the source of that particular
variant. This is useful if the RTSP agent desires to verify if the variant. This is useful if the RTSP agent desires to verify if the
resource variant is current through a conditional request. resource variant is current through a conditional request.
A cache cannot assume that a message body with a Content-Location A cache cannot assume that a message body with a Content-Location
skipping to change at page 136, line 17 skipping to change at page 142, line 43
the origin server (or with an intermediate cache that has a fresh the origin server (or with an intermediate cache that has a fresh
copy of the message body). See Section 16 for further discussion of copy of the message body). See Section 16 for further discussion of
the expiration model. the expiration model.
The presence of an Expires field does not imply that the original The presence of an Expires field does not imply that the original
resource will change or cease to exist at, before, or after that resource will change or cease to exist at, before, or after that
time. time.
The format is an absolute date and time as defined by RTSP-date. An The format is an absolute date and time as defined by RTSP-date. An
example of its use is example of its use is
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Expires: Thu, 01 Dec 1994 16:00:00 GMT
RTSP/2.0 clients and caches MUST treat other invalid date formats, RTSP/2.0 clients and caches MUST treat other invalid date formats,
especially including the value "0", as having occurred in the past especially including the value "0", as having occurred in the past
(i.e., already expired). (i.e., already expired).
To mark a response as "already expired," an origin server should use To mark a response as "already expired," an origin server should use
an Expires date that is equal to the Date header value. To mark a an Expires date that is equal to the Date header value. To mark a
response as "never expires," an origin server SHOULD use an Expires response as "never expires," an origin server SHOULD use an Expires
date approximately one year from the time the response is sent. RTSP date approximately one year from the time the response is sent.
/2.0 servers SHOULD NOT send Expires dates more than one year in the RTSP/2.0 servers SHOULD NOT send Expires dates more than one year in
future. the future.
18.22. From 18.22. From
The From request-header field, if given, SHOULD contain an Internet The From request-header field, if given, SHOULD contain an Internet
e-mail address for the human user who controls the requesting user e-mail address for the human user who controls the requesting user
agent. The address SHOULD be machine-usable, as defined by "mailbox" agent. The address SHOULD be machine-usable, as defined by "mailbox"
in [RFC1123]. in [RFC1123].
This header field MAY be used for logging purposes and as a means for This header field MAY be used for logging purposes and as a means for
identifying the source of invalid or unwanted requests. It SHOULD identifying the source of invalid or unwanted requests. It SHOULD
skipping to change at page 137, line 40 skipping to change at page 144, line 16
18.24. If-Modified-Since 18.24. If-Modified-Since
The If-Modified-Since request-header field is used with the DESCRIBE The If-Modified-Since request-header field is used with the DESCRIBE
and SETUP methods to make them conditional. If the requested variant and SETUP methods to make them conditional. If the requested variant
has not been modified since the time specified in this field, a has not been modified since the time specified in this field, a
description will not be returned from the server (DESCRIBE) or a description will not be returned from the server (DESCRIBE) or a
stream will not be set up (SETUP). Instead, a 304 (Not Modified) stream will not be set up (SETUP). Instead, a 304 (Not Modified)
response MUST be returned without any message-body. response MUST be returned without any message-body.
An example of the field is: An example of the field is:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
18.25. If-None-Match 18.25. If-None-Match
This request header can be used with one or several message body tags This request header can be used with one or several message body tags
to make DESCRIBE requests conditional. A client that has one or more to make DESCRIBE requests conditional. A client that has one or more
message bodies previously obtained from the resource, can verify that message bodies previously obtained from the resource, can verify that
none of those entities is current by including a list of their none of those entities is current by including a list of their
associated message body tags in the If-None-Match header field. The associated message body tags in the If-None-Match header field. The
purpose of this feature is to allow efficient updates of cached purpose of this feature is to allow efficient updates of cached
information with a minimum amount of transaction overhead. As a information with a minimum amount of transaction overhead. As a
skipping to change at page 140, line 17 skipping to change at page 146, line 42
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:
Random-Access: Indicates that random access is possible. May Random-Access: Indicates that random access is possible. May
optionally include a floating point value in seconds optionally include a floating point value in seconds indicating
indicating the longest duration between any two random the longest duration between any two random access points in
access points in the media. the media.
Begining-Only: Seeking is limited to the beginning only. Begining-Only: Seeking is limited to the beginning only.
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 progresses as wallclock Time-Progressing The media accessible progresses as wallclock
time 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.
Time-Duration Each individual media unit is retained for at least Time-Duration Each individual media unit is retained for at least
the specified time duration. This definition allows for the specified time duration. This definition allows for
retaining data with a time based sliding window. The time retaining data with a time based sliding window. The time
duration is expressed as floating point number in seconds. duration is expressed as floating point number in seconds. 0.0
0.0 is a valid value as this indicates that no data is is a valid value as this indicates that no data is retained in
retained in a time-progressing session. a time-progressing session.
Supported Scale: Supported Scale:
Scales: A quoted comma separated list of one or more decimal Scales: A quoted comma separated list of one or more decimal
values or ranges of scale values supported by the content in values or ranges of scale values supported by the content in
arbitrary order. A range has a start and stop value arbitrary order. A range has a start and stop value separated
separated by a colon. A range indicates that the content by a colon. A range indicates that the content supports fine
supports fine grained selection of scale values. Fine grained selection of scale values. Fine grained allows for
grained allows for steps at least as small as one tenth of a steps at least as small as one tenth of a scale value. A
scale value. A content is considered to support fine content is considered to support fine grained selection when
grained selection when the server in response to a given the server in response to a given scale value can produce
scale value can produce content with an actual scale that is content with an actual scale that is less than 1 tenth of scale
less than 1 tenth of scale unit, i.e., 0.1, from the unit, i.e., 0.1, from the requested value. Negative values are
requested value. Negative values are supported. The value supported. The value 0 has no meaning and MUST NOT be used.
0 has no meaning and MUST NOT be used.
Examples of this header for on-demand content and a live stream Examples of this header for on-demand content and a live stream
without recording are: without recording are:
On-demand: On-demand:
Media-Properties: Random-Access=2.5s, Unlimited, Immutable, Media-Properties: Random-Access=2.5s, Unlimited, Immutable,
Scales="-20, -10, -4, 0.5:1.5, 4, 8, 10, 15, 20" Scales="-20, -10, -4, 0.5:1.5, 4, 8, 10, 15, 20"
Live stream without recording/timeshifting: Live stream without recording/timeshifting:
Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0 Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0
skipping to change at page 142, line 13 skipping to change at page 148, line 43
However, it shall be assumed that media time progresses in direct However, it shall be assumed that media time progresses in direct
relationship to wallclock time (with the exception of clock skew) so relationship to wallclock time (with the exception of clock skew) so
that a reasonably accurate estimation of the media range can be that a reasonably accurate estimation of the media range can be
calculated. calculated.
18.30. MTag 18.30. MTag
The MTag response header MAY be included in DESCRIBE, GET_PARAMETER The MTag response header MAY be included in DESCRIBE, GET_PARAMETER
or SETUP responses. The message body tags (Section 4.8) returned in or SETUP responses. The message body tags (Section 4.8) returned in
a DESCRIBE response, and the one in SETUP refers to the presentation, a DESCRIBE response, and the one in SETUP refers to the presentation,
i.e. both the returned session description and the media stream. i.e. both the returned session description and the media stream.
This allows for verification that one has the right session This allows for verification that one has the right session
description to a media resource at the time of the SETUP request. description to a media resource at the time of the SETUP request.
However, it has the disadvantage that a change in any of the parts However, it has the disadvantage that a change in any of the parts
results in invalidation of all the parts. results in invalidation of all the parts.
If the MTag is provided both inside the message body, e.g. within If the MTag is provided both inside the message body, e.g. within the
the "a=mtag" attribute in SDP, and in the response message, then both "a=mtag" attribute in SDP, and in the response message, then both
tags MUST be identical. It is RECOMMENDED that the MTag is primarily tags MUST be identical. It is RECOMMENDED that the MTag is primarily
given in the RTSP response message, to ensure that caches can use the given in the RTSP response message, to ensure that caches can use the
MTag without requiring content inspection. However, for session MTag without requiring content inspection. However, for session
descriptions that are distributed outside of RTSP, for example using descriptions that are distributed outside of RTSP, for example using
HTTP, etc. it will be necessary to include the message body tag in HTTP, etc. it will be necessary to include the message body tag in
the session description as specified in Appendix D.1.9. the session description as specified in Appendix D.1.9.
SETUP and DESCRIBE requests can be made conditional upon the MTag SETUP and DESCRIBE requests can be made conditional upon the MTag
using the headers If-Match (Section 18.23) and If-None-Match ( using the headers If-Match (Section 18.23) and If-None-Match (
Section 18.25). Section 18.25).
18.31. Notify-Reason 18.31. Notify-Reason
The Notify Reason header is solely used in the PLAY_NOTIFY method. The Notify Reason header is solely used in the PLAY_NOTIFY method.
It indicates the reason why the server has sent the asynchronous It indicates the reason why the server has sent the asynchronous
skipping to change at page 144, line 44 skipping to change at page 151, line 25
the Proxy-Require does not apply to the end-point (server or client). the Proxy-Require does not apply to the end-point (server or client).
To ensure that a feature is supported by both proxies and servers the To ensure that a feature is supported by both proxies and servers the
tag needs to be included in also a Require header. tag needs to be included in also a Require header.
See Section 18.41 for more details on the mechanics of this message See Section 18.41 for more details on the mechanics of this message
and a usage example. See discussion in the proxies section and a usage example. See discussion in the proxies section
(Section 15.1) about when to consider that a feature requires proxy (Section 15.1) about when to consider that a feature requires proxy
support. support.
Example of use: Example of use:
Proxy-Require: play.basic
Proxy-Require: play.basic
18.36. Proxy-Supported 18.36. Proxy-Supported
The Proxy-Supported header field enumerates all the extensions The Proxy-Supported header field enumerates all the extensions
supported by the proxy using feature-tags. The header carries the supported by the proxy using feature-tags. The header carries the
intersection of extensions supported by the forwarding proxies. The intersection of extensions supported by the forwarding proxies. The
Proxy-Supported header MAY be included in any request by a proxy. It Proxy-Supported header MAY be included in any request by a proxy. It
MUST be added by any proxy if the Supported header is present in a MUST be added by any proxy if the Supported header is present in a
request. When present in a request, the receiver MUST in the request. When present in a request, the receiver MUST in the
response copy the received Proxy-Supported header. response copy the received Proxy-Supported header.
skipping to change at page 146, line 6 skipping to change at page 152, line 36
The Public response header field lists the set of methods supported The Public response header field lists the set of methods supported
by the response sender. This header applies to the general by the response sender. This header applies to the general
capabilities of the sender and its only purpose is to indicate the capabilities of the sender and its only purpose is to indicate the
sender's capabilities to the recipient. The methods listed may or sender's capabilities to the recipient. The methods listed may or
may not be applicable to the Request-URI; the Allow header field may not be applicable to the Request-URI; the Allow header field
(Section 18.6) MAY be used to indicate methods allowed for a (Section 18.6) MAY be used to indicate methods allowed for a
particular URI. particular URI.
Example of use: Example of use:
Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
In the event that there are proxies between the sender and the In the event that there are proxies between the sender and the
recipient of a response, each intervening proxy MUST modify the recipient of a response, each intervening proxy MUST modify the
Public header field to remove any methods that are not supported via Public header field to remove any methods that are not supported via
that proxy. The resulting Public header field will contain an that proxy. The resulting Public header field will contain an
intersection of the sender's methods and the methods allowed through intersection of the sender's methods and the methods allowed through
by the intervening proxies. by the intervening proxies.
In general, proxies should allow all methods to transparently pass In general, proxies should allow all methods to transparently pass
through from the sending RTSP agent to the receiving RTSP agent, through from the sending RTSP agent to the receiving RTSP agent,
skipping to change at page 147, line 6 skipping to change at page 153, line 34
(Section 4.6) range units. While byte ranges [H14.35.1] and other (Section 4.6) range units. While byte ranges [H14.35.1] and other
extended units MAY be used, their behavior is unspecified since they extended units MAY be used, their behavior is unspecified since they
are not normally meaningful in RTSP. Servers supporting the Range are not normally meaningful in RTSP. Servers supporting the Range
header MUST understand the NPT range format and SHOULD understand the header MUST understand the NPT range format and SHOULD understand the
SMPTE range format. If the Range header is sent in a time format SMPTE range format. If the Range header is sent in a time format
that is not understood, the recipient SHOULD return 456 (Header Field that is not understood, the recipient SHOULD return 456 (Header Field
Not Valid for Resource) and include an Accept-Ranges header Not Valid for Resource) and include an Accept-Ranges header
indicating the supported time formats for the given resource. indicating the supported time formats for the given resource.
Example: Example:
Range: clock=19960213T143205Z-
Range: clock=19960213T143205Z-
The Range header contains a range of one single range format. A The Range header contains a range of one single range format. A
range is a half-open interval with a start and an end point, range is a half-open interval with a start and an end point,
including the start point, but excluding the end point. A range may including the start point, but excluding the end point. A range may
either be fully specified with explicit values for start point and either be fully specified with explicit values for start point and
end point, or have either start or end point be implicit. An end point, or have either start or end point be implicit. An
implicit start point indicates the session's pause point, and if no implicit start point indicates the session's pause point, and if no
pause point is set the start of the content. An implicit end point pause point is set the start of the content. An implicit end point
indicates the end of the content. The usage of both implicit start indicates the end of the content. The usage of both implicit start
and end point is not allowed in the same range header, however, the and end point is not allowed in the same range header, however, the
exclusion of the range header has that meaning, i.e. from pause exclusion of the range header has that meaning, i.e. from pause point
point (or start) until end of content. (or start) until end of content.
Regarding the half-open intervals; a range of A-B starts exactly Regarding the half-open intervals; a range of A-B starts exactly
at time A, but ends just before B. Only the start time of a media at time A, but ends just before B. Only the start time of a media
unit such as a video or audio frame is relevant. For example, unit such as a video or audio frame is relevant. For example,
assume that video frames are generated every 40 ms. A range of assume that video frames are generated every 40 ms. A range of
10.0-10.1 would include a video frame starting at 10.0 or later 10.0-10.1 would include a video frame starting at 10.0 or later
time and would include a video frame starting at 10.08, even time and would include a video frame starting at 10.08, even
though it lasted beyond the interval. A range of 10.0-10.08, on though it lasted beyond the interval. A range of 10.0-10.08, on
the other hand, would exclude the frame at 10.08. the other hand, would exclude the frame at 10.08.
Please note the difference between NPT time scales' "now" and an Please note the difference between NPT time scales' "now" and an
implicit start value. Implicit value reference the current pause- implicit start value. Implicit value reference the current pause-
point. While "now" is the currently ongoing time. In a time- point. While "now" is the currently ongoing time. In a time-
progressing session with recording (retention for some or full progressing session with recording (retention for some or full
time) the pause point may be 2 min into the session while now time) the pause point may be 2 min into the session while now
could be 1 hour into the session. could be 1 hour into the session.
By default, range intervals increase, where the second point is By default, range intervals increase, where the second point is
larger than the first point. larger than the first point.
Example: Example:
Range: npt=10-15
Range: npt=10-15
However, range intervals can also decrease if the Scale header (see However, range intervals can also decrease if the Scale header (see
Section 18.44) indicates a negative scale value. For example, this Section 18.44) indicates a negative scale value. For example, this
would be the case when a playback in reverse is desired. would be the case when a playback in reverse is desired.
Example: Example:
Scale: -1
Scale: -1 Range: npt=15-10
Range: npt=15-10
Decreasing ranges are still half open intervals as described above. Decreasing ranges are still half open intervals as described above.
Thus, for range A-B, A is closed and B is open. In the above Thus, for range A-B, A is closed and B is open. In the above
example, 15 is closed and 10 is open. An exception to this rule is example, 15 is closed and 10 is open. An exception to this rule is
the case when B=0 in a decreasing range. In this case, the range is the case when B=0 in a decreasing range. In this case, the range is
closed on both ends, as otherwise there would be no way to reach 0 on closed on both ends, as otherwise there would be no way to reach 0 on
a reverse playback for formats that have such a notion, like NPT and a reverse playback for formats that have such a notion, like NPT and
SMPTE. SMPTE.
Example: Example:
Scale: -1
Scale: -1 Range: npt=15-0
Range: npt=15-0
In this range both 15 and 0 are closed. In this range both 15 and 0 are closed.
A decreasing range interval without a corresponding negative Scale A decreasing range interval without a corresponding negative Scale
header is not valid. header is not valid.
18.39. Referrer 18.39. Referrer
The Referrer request-header field allows the client to specify, for The Referrer request-header field allows the client to specify, for
the server's benefit, the address (URI) of the resource from which the server's benefit, the address (URI) of the resource from which
skipping to change at page 148, line 46 skipping to change at page 155, line 18
a source that does not have its own URI, such as input from the user a source that does not have its own URI, such as input from the user
keyboard. keyboard.
If the field value is a relative URI, it SHOULD be interpreted If the field value is a relative URI, it SHOULD be interpreted
relative to the Request-URI. The URI MUST NOT include a fragment. relative to the Request-URI. The URI MUST NOT include a fragment.
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 enable toggle switch for openly/anonymously, which would respectively
/disable the sending of Referrer and From information. enable/disable the sending of Referrer and From information.
Clients SHOULD NOT include a Referrer header field in a (non-secure) Clients SHOULD NOT include a Referrer header field in a (non-secure)
RTSP request if the referring page was transferred with a secure RTSP request if the referring page was transferred with a secure
protocol. protocol.
18.40. Request-Status 18.40. Request-Status
This request header is used to indicate the end result for requests This request header is used to indicate the end result for requests
that takes time to complete, such a PLAY (Section 13.4). It is sent that takes time to complete, such a PLAY (Section 13.4). It is sent
in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report
skipping to change at page 154, line 21 skipping to change at page 160, line 20
If the server does not implement the possibility to scale, it will If the server does not implement the possibility to scale, it will
not return a Scale header. A server supporting Scale operations for not return a Scale header. A server supporting Scale operations for
PLAY MUST indicate this with the use of the "play.scale" feature-tag. PLAY MUST indicate this with the use of the "play.scale" feature-tag.
When indicating a negative scale for a reverse playback, the Range When indicating a negative scale for a reverse playback, the Range
header MUST indicate a decreasing range as described in header MUST indicate a decreasing range as described in
Section 18.38. Section 18.38.
Example of playing in reverse at 3.5 times normal rate: Example of playing in reverse at 3.5 times normal rate:
Scale: -3.5
Scale: -3.5 Range: npt=15-10
Range: npt=15-10
18.45. Seek-Style 18.45. Seek-Style
When a client sends a PLAY request with a Range header to perform a When a client sends a PLAY request with a Range header to perform a
random access to the media, the client does not know if the server random access to the media, the client does not know if the server
will pick the first media samples or the first random access point will pick the first media samples or the first random access point
prior to the request range. Depending on use case, the client may prior to the request range. Depending on use case, the client may
have a strong preference. To express this preference and provide the have a strong preference. To express this preference and provide the
client with information on how the server actually acted on that client with information on how the server actually acted on that
preference the Seek-Style header is defined. preference the Seek-Style header is defined.
skipping to change at page 157, line 33 skipping to change at page 163, line 26
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 too frequent keep-alive messages and having low sensitivity in not too frequent keep-alive messages and having low sensitivity
to variations in request response timing. If one reduces the to variations in request response timing. If one reduces the
timeout value to below 30 seconds the corresponding request timeout value to below 30 seconds the corresponding request
response timeout becomes a significant part of the session response timeout becomes a significant part of the session
timeout. 60 seconds also allows for reasonably rapid recovery of timeout. 60 seconds also allows for reasonably rapid recovery of
committed server resources in case of client failure. committed server resources in case of client failure.
18.48. Speed 18.48. Speed
The Speed request-header field requests the server to deliver The Speed request-header field requests the server to deliver
specific amounts of nominal media time per unit of delivery time, specific amounts of nominal media time per unit of delivery time,
contingent on the server's ability and desire to serve the media contingent on the server's ability and desire to serve the media
stream at the given speed. The client requests the delivery speed to stream at the given speed. The client requests the delivery speed to
be within a given range with a lower and upper bound. The server be within a given range with a lower and upper bound. The server
SHALL deliver at the highest possible speed within the range, but not SHALL deliver at the highest possible speed within the range, but not
skipping to change at page 158, line 23 skipping to change at page 164, line 14
specified in the form "lower bound - upper bound". The lower bound specified in the form "lower bound - upper bound". The lower bound
value may be smaller or equal to the upper bound. All speeds may not value may be smaller or equal to the upper bound. All speeds may not
be possible to support. Therefore the server MAY modify the be possible to support. Therefore the server MAY modify the
requested values to the closest supported. The actual supported requested values to the closest supported. The actual supported
speed MUST be included in the response. Note, however, that the use speed MUST be included in the response. Note, however, that the use
cases may vary and that Speed value ranges such as 0.7 - 0.8, cases may vary and that Speed value ranges such as 0.7 - 0.8,
0.3-2.0, 1.0-2.5, 2.5-2.5 all have their usage. 0.3-2.0, 1.0-2.5, 2.5-2.5 all have their usage.
Example: Example:
Speed: 1.0-2.5 Speed: 1.0-2.5
Use of this header changes the bandwidth used for data delivery. It Use of this header changes the bandwidth used for data delivery. It
is meant for use in specific circumstances where delivery of the is meant for use in specific circumstances where delivery of the
presentation at a higher or lower rate is desired. The main use presentation at a higher or lower rate is desired. The main use
cases are buffer operations or local scale operations. Implementors cases are buffer operations or local scale operations. Implementors
should keep in mind that bandwidth for the session may be negotiated should keep in mind that bandwidth for the session may be negotiated
beforehand (by means other than RTSP), and therefore re-negotiation beforehand (by means other than RTSP), and therefore re-negotiation
may be necessary. To perform Speed operations the server needs to may be necessary. To perform Speed operations the server needs to
ensure that the network path can support the resulting bit-rate. ensure that the network path can support the resulting bit-rate.
Thus the media transport needs to support feedback so that the server Thus the media transport needs to support feedback so that the server
skipping to change at page 160, line 44 skipping to change at page 166, line 39
The Transport header MAY also be used in subsequent SETUP requests to The Transport header MAY also be used in subsequent SETUP requests to
change transport parameters. A server MAY refuse to change change transport parameters. A server MAY refuse to change
parameters of an existing stream. parameters of an existing stream.
A transport specification may only contain one of any given parameter A transport specification may only contain one of any given parameter
within it. Parameters MAY be given in any order. Additionally, it within it. Parameters MAY be given in any order. Additionally, it
may only contain either of the unicast or the multicast transport may only contain either of the unicast or the multicast transport
type parameter. All parameters need to be understood in a transport type parameter. All parameters need to be understood in a transport
specification, if not, the transport specification MUST be ignored. specification, if not, the transport specification MUST be ignored.
An RTSP proxy of any type that uses or modifies the transport An RTSP proxy 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 results in no remaining transport specification the message. If that results in no remaining transport specification the
proxy SHALL send a 461 (Unsupported Transport) (Section 17.4.26) proxy SHALL send a 461 (Unsupported Transport) (Section 17.4.26)
response without any Transport header. response without any Transport header.
The Transport header is restricted to describing a single media The Transport header is restricted to describing a single media
stream. (RTSP can also control multiple streams as a single stream. (RTSP can also control multiple streams as a single
entity.) Making it part of RTSP rather than relying on a entity.) Making it part of RTSP rather than relying on a
multitude of session description formats greatly simplifies multitude of session description formats greatly simplifies
designs of firewalls. designs of firewalls.
skipping to change at page 161, line 47 skipping to change at page 167, line 40
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 need to be addressed if (Section 21) with this method that need 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 an 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
present in a request is not defined. present in a request is not defined.
An RTSP proxy will need to take care. If the media is not desired to An RTSP proxy will need to take care. If the media is not desired to
be routed through the proxy, the proxy will need to introduce the be routed through the proxy, the proxy will need to introduce the
skipping to change at page 171, line 32 skipping to change at page 177, line 28
enforce policies to each trusted proxy of whether it should accept enforce policies to each trusted proxy of whether it should accept
the next agent in the chain. However, it should be noted that not the next agent in the chain. However, it should be noted that not
all deployments will return the chain of certificates used to all deployments will return the chain of certificates used to
authenticate any intermediate proxies as well as the server. An authenticate any intermediate proxies as well as the server. An
operator of such a deployment may want to hide its topology from the operator of such a deployment may want to hide its topology from the
client. It should be noted well that the client does not have any client. It should be noted well that the client does not have any
insight into the proxy's operation. Even if the proxy is trusted, it insight into the proxy's operation. Even if the proxy is trusted, it
can still return an incomplete chain of certificates. can still return an incomplete chain of certificates.
A proxy MUST use TLS for the next hop if the RTSP request includes a A proxy MUST use TLS for the next hop if the RTSP request includes a
"rtsps" URI. TLS MAY be applied on intermediate links (e.g. between "rtsps" URI. TLS MAY be applied on intermediate links (e.g. between
client and proxy, or between proxy and proxy), even if the resource client and proxy, or between proxy and proxy), even if the resource
and the end server are not required to use it. The proxy MUST, when and the end server are not required to use it. The proxy MUST, when
initiating the next hop TLS connection, use the incoming TLS initiating the next hop TLS connection, use the incoming TLS
connections cipher suite list, only modified by removing any cipher connections cipher suite list, only modified by removing any cipher
suites that the proxy does not support. In case a proxy fails to suites that the proxy does not support. In case a proxy fails to
establish a TLS connection due to cipher suite mismatch between proxy establish a TLS connection due to cipher suite mismatch between proxy
and next hop proxy or server, this is indicated using error code 472 and next hop proxy or server, this is indicated using error code 472
(Failure to establish secure connection). (Failure to establish secure connection).
19.3.1. Accept-Credentials 19.3.1. Accept-Credentials
skipping to change at page 183, line 18 skipping to change at page 190, line 51
/ ( m-type SLASH m-subtype ) / ( m-type SLASH m-subtype )
) *( SEMI m-parameter ) ) *( SEMI m-parameter )
accept-params = "q" EQUAL qvalue *(SEMI generic-param ) accept-params = "q" EQUAL qvalue *(SEMI generic-param )
qvalue = ( "0" [ "." *3DIGIT ] ) qvalue = ( "0" [ "." *3DIGIT ] )
/ ( "1" [ "." *3("0") ] ) / ( "1" [ "." *3("0") ] )
Accept-Credentials = "Accept-Credentials" HCOLON cred-decision Accept-Credentials = "Accept-Credentials" HCOLON cred-decision
cred-decision = ("User" [LWS cred-info]) cred-decision = ("User" [LWS cred-info])
/ "Proxy" / "Proxy"
/ "Any" / "Any"
/ (token [LWS 1*header-value]) / (token [LWS 1*header-value])
; For future extensions ; For future extensions
cred-info = cred-info-data *(COMMA cred-info-data) cred-info = cred-info-data *(COMMA cred-info-data)
cred-info-data = DQUOTE RTSP-REQ-URI DQUOTE SEMI hash-alg cred-info-data = DQUOTE RTSP-REQ-URI DQUOTE SEMI hash-alg
SEMI base64 SEMI base64
hash-alg = "sha-256" / extension-alg hash-alg = "sha-256" / extension-alg
extension-alg = token extension-alg = token
Accept-Encoding = "Accept-Encoding" HCOLON Accept-Encoding = "Accept-Encoding" HCOLON
[ encoding *(COMMA encoding) ] [ encoding *(COMMA encoding) ]
encoding = codings [SEMI accept-params] encoding = codings [SEMI accept-params]
codings = content-coding / "*" codings = content-coding / "*"
skipping to change at page 192, line 27 skipping to change at page 201, line 45
The following are added considerations for RTSP implementations. The following are added considerations for RTSP implementations.
Session hijacking: Since there is no or little relation between a Session hijacking: Since there is no or little relation between a
transport layer connection and an RTSP session, it is possible transport layer connection and an RTSP session, it is possible
for a malicious client to issue requests with random session for a malicious client to issue requests with random session
identifiers which could affect other clients of an unsuspecting identifiers which could affect other clients of an unsuspecting
server. To mitigate this the server SHALL use a large, random server. To mitigate this the server SHALL use a large, random
and non-sequential session identifier to minimize the and non-sequential session identifier to minimize the
possibility of this kind of attack. However, unless the RTSP possibility of this kind of attack. However, unless the RTSP
signaling is always confidentiality protected, e.g. using TLS, signaling is always confidentiality protected, e.g. using TLS,
an on-path attacker will be able to hijack a session. To an on-path attacker will be able to hijack a session. To
prevent session hijacking client authentication needs to be prevent session hijacking client authentication needs to be
performed and only the authenticated client creating the performed and only the authenticated client creating the
session SHALL be able to access that session. session SHALL be able to access that session.
Authentication: Servers SHOULD implement both basic and digest Authentication: Servers SHOULD implement both basic and digest
[RFC2617] authentication. In environments requiring tighter [RFC2617] authentication. In environments requiring tighter
security for the control messages, the transport layer security for the control messages, the transport layer
mechanism TLS [RFC5246] SHOULD be used. mechanism TLS [RFC5246] SHOULD be used.
skipping to change at page 203, line 19 skipping to change at page 213, line 16
o A registration is required to name a contact person. o A registration is required to name a contact person.
o Name of the policy. o Name of the policy.
o A describing text that explains how the policy works for handling o A describing text that explains how the policy works for handling
the certificates. the certificates.
This specification registers the following values: This specification registers the following values:
Any Any
Proxy Proxy
User User
22.5.2. Accept-Credentials hash algorithms 22.5.2. Accept-Credentials hash algorithms
The Accept-Credentials header (See Section 18.2) allows for the usage The Accept-Credentials header (See Section 18.2) allows for the usage
of other algorithms for hashing the DER records of accepted entities. of other algorithms for hashing the DER records of accepted entities.
The registration of any future algorithm is expected to be extremely The registration of any future algorithm is expected to be extremely
rare and could also cause interoperability problems. Therefore the rare and could also cause interoperability problems. Therefore the
bar for registering new algorithms is intentionally placed high. bar for registering new algorithms is intentionally placed high.
Any registration of a new hash algorithm MUST fulfill the following Any registration of a new hash algorithm MUST fulfill the following
skipping to change at page 204, line 21 skipping to change at page 214, line 14
o Name of the directive and a definition of the value, if any. o Name of the directive and a definition of the value, if any.
o Specification if it is a request or response directive. o Specification if it is a request or response directive.
o A describing text that explains how the cache directive is used o A describing text that explains how the cache directive is used
for RTSP controlled media streams. for RTSP controlled media streams.
This specification registers the following values: This specification registers the following values:
no-cache: no-cache:
public: public:
private: private:
no-transform: no-transform:
only-if-cached: only-if-cached:
max-stale: max-stale:
min-fresh: min-fresh:
must-revalidate: must-revalidate:
proxy-revalidate: proxy-revalidate:
max-age: max-age:
The registry should be represented as: Name of the directive, contact The registry should be represented as: Name of the directive, contact
person and reference. person and reference.
22.7. Media Properties 22.7. Media Properties
22.7.1. Description 22.7.1. Description
The media streams being controlled by RTSP can have many different The media streams being controlled by RTSP can have many different
properties. The media properties required to cover the use cases properties. The media properties required to cover the use cases
skipping to change at page 216, line 23 skipping to change at page 226, line 40
Purpose: RFC XXXX Purpose: RFC XXXX
Reference: RFC XXXX Reference: RFC XXXX
Values: See ABNF definition Values: See ABNF definition
22.16. Media Type Registration for text/parameters 22.16. Media Type Registration for text/parameters
Type name: text Type name: text
Subtype name: parameters Subtype name: parameters
Required parameters:
Optional parameters: charset: The charset parameter is applicable to Optional parameters: charset: The charset parameter is applicable to
the encoding of the parameter values. The default charset is the encoding of the parameter values. The default charset is
UTF-8, if the 'charset' parameter is not present. UTF-8, if the 'charset' parameter is not present.
Encoding considerations: 8bit Encoding considerations: 8bit
Security considerations: This format may carry any type of Security considerations: This format may carry any type of
parameters. Some can have security requirements, like privacy, parameters. Some can have security requirements, like privacy,
confidentiality or integrity requirements. The format has no confidentiality or integrity requirements. The format has no
built in security protection. For the usage it was defined the built in security protection. For the usage it was defined the
skipping to change at page 217, line 5 skipping to change at page 227, line 22
fictional example in [RFC2326], but was not formally specified. fictional example in [RFC2326], but was not formally specified.
This has resulted in usage of this media type which may not match This has resulted in usage of this media type which may not match
its formal definition. its formal definition.
Published specification: RFC XXXX, Appendix F. Published specification: RFC XXXX, Appendix F.
Applications that use this media type: Applications that use RTSP Applications that use this media type: Applications that use RTSP
and have additional parameters they like to read and set using the and have additional parameters they like to read and set using the
RTSP GET_PARAMETER and SET_PARAMETER methods. RTSP GET_PARAMETER and SET_PARAMETER methods.
Person & email address to contact for further information: Magnus We Additional information:
sterlund (magnus.westerlund@ericsson.com)
Magic number(s):
File extension(s):
Macintosh file type code(s):
Person & email address to contact for further information: Magnus
Westerlund (magnus.westerlund@ericsson.com)
Intended usage: Common Intended usage: Common
Restrictions on usage: None Restrictions on usage: None
Author: Magnus Westerlund (magnus.westerlund@ericsson.com) Author: Magnus Westerlund (magnus.westerlund@ericsson.com)
Change controller: IETF Change controller: IETF
Addition Notes:
23. References 23. References
23.1. Normative References 23.1. Normative References
[FIPS-pub-180-2] [FIPS-pub-180-2]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Federal Information Processing Standards Publications "Federal Information Processing Standards Publications
(FIPS PUBS) 180-2: Secure Hash Standard", August 2002. (FIPS PUBS) 180-2: Secure Hash Standard", August 2002.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
793, September 1981. RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
6 (IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P.M., Hostetler, J.L., Lawrence, [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
S.D., Leach, P.J., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
skipping to change at page 218, line 17 skipping to change at page 229, line 4
July 2003. July 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66,
3986, January 2005. RFC 3986, January 2005.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005. Identifiers (IRIs)", RFC 3987, January 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35, RFC Registration Procedures for New URI Schemes", BCP 35,
4395, February 2006. RFC 4395, February 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006. Protocol (RTSP)", RFC 4567, July 2006.
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
and RTP Control Protocol (RTCP) Packets over Connection- and RTP Control Protocol (RTCP) Packets over Connection-
Oriented Transport", RFC 4571, July 2006. Oriented Transport", RFC 4571, July 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
2006. July 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-
RSA-R: An Additional Mode of Key Distribution in RSA-R: An Additional Mode of Key Distribution in
Multimedia Internet KEYing (MIKEY)", RFC 4738, November Multimedia Internet KEYing (MIKEY)", RFC 4738,
2006. November 2006.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008. (RTP/SAVPF)", RFC 5124, February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
skipping to change at page 219, line 46 skipping to change at page 230, line 34
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. Specification", RFC 5751, January 2010.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010. Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC Specifications and Registration Procedures", BCP 13,
6838, January 2013. RFC 6838, January 2013.
[TS-26234] [TS-26234]
Third Generation Partnership Project (3GPP), "Transparent Third Generation Partnership Project (3GPP), "Transparent
end-to-end Packet-switched Streaming Service (PSS); end-to-end Packet-switched Streaming Service (PSS);
Protocols and codecs; Technical Specification 26.234", Protocols and codecs; Technical Specification 26.234",
December 2002. December 2002.
23.2. Informative References 23.2. Informative References
[I-D.ietf-mmusic-rtsp-nat] [I-D.ietf-mmusic-rtsp-nat]
Goldberg, J., Westerlund, M., and T. Zeng, "A Network Goldberg, J., Westerlund, M., and T. Zeng, "A Network
Address Translator (NAT) Traversal mechanism for media Address Translator (NAT) Traversal mechanism for media
controlled by Real-Time Streaming Protocol (RTSP)", draft- controlled by Real-Time Streaming Protocol (RTSP)",
ietf-mmusic-rtsp-nat-14 (work in progress), November 2012. draft-ietf-mmusic-rtsp-nat-14 (work in progress),
November 2012.
[ISO.13818-6.1995] [ISO.13818-6.1995]
International Organization for Standardization, International Organization for Standardization,
"Information technology - Generic coding of moving "Information technology - Generic coding of moving
pictures and associated audio information - part 6: pictures and associated audio information - part 6:
Extension for digital storage media and control", ISO Extension for digital storage media and control",
Draft Standard 13818-6, November 1995. ISO Draft Standard 13818-6, November 1995.
[ISO.8601.2000] [ISO.8601.2000]
International Organization for Standardization, "Data International Organization for Standardization, "Data
elements and interchange formats - Information interchange elements and interchange formats - Information interchange
- Representation of dates and times", ISO/IEC Standard - Representation of dates and times", ISO/IEC Standard
8601, December 2000. 8601, December 2000.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, January 1997. RFC 2068, January 1997.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC Translator (NAT) Terminology and Considerations",
2663, August 1999. RFC 2663, August 1999.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
2001. April 2001.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June with Session Description Protocol (SDP)", RFC 3264,
2002. June 2002.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload [RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007. Formats", RFC 4855, February 2007.
[RFC4856] Casner, S., "Media Type Registration of Payload Formats in [RFC4856] Casner, S., "Media Type Registration of Payload Formats in
the RTP Profile for Audio and Video Conferences", RFC the RTP Profile for Audio and Video Conferences",
4856, February 2007. RFC 4856, February 2007.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008. with Feedback (AVPF)", RFC 5104, February 2008.
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding
Dependency in the Session Description Protocol (SDP)", RFC Dependency in the Session Description Protocol (SDP)",
5583, July 2009. RFC 5583, July 2009.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, June "Computing TCP's Retransmission Timer", RFC 6298,
2011. June 2011.
[Stevens98] [Stevens98]
Stevens, W. R., "Unix Networking Programming - Volume 1, Stevens, W., "Unix Networking Programming - Volume 1,
second edition", 1998. second edition", 1998.
Appendix A. Examples Appendix A. Examples
This section contains several different examples trying to illustrate This section contains several different examples trying to illustrate
possible ways of using RTSP. The examples can also help with the possible ways of using RTSP. The examples can also help with the
understanding of how functions of RTSP work. However, remember that understanding of how functions of RTSP work. However, remember that
these are examples and the normative and syntax description in the these are examples and the normative and syntax description in the
other sections take precedence. Please also note that many of the other sections take precedence. Please also note that many of the
examples contain syntax illegal line breaks to accommodate the examples contain syntax illegal line breaks to accommodate the
skipping to change at page 222, line 42 skipping to change at page 233, line 49
multiple streams. It also illustrates the use of aggregate URIs. In multiple streams. It also illustrates the use of aggregate URIs. In
a container file it is also desirable to not write any URI parts a container file it is also desirable to not write any URI parts
which are not kept, when the container is distributed, like the host which are not kept, when the container is distributed, like the host
and most of the path element. Therefore this example also uses the and most of the path element. Therefore this example also uses the
"*" and relative URI in the delivered SDP. "*" and relative URI in the delivered SDP.
Also this presentation description (SDP) is not cachable, as the Also this presentation description (SDP) is not cachable, as the
Expires header is set to an equal value with date indicating Expires header is set to an equal value with date indicating
immediate expiration of its valididty. immediate expiration of its valididty.
Client C requests a presentation from media server M. The movie is Client C requests a presentation from media server M. The movie is
stored in a container file. The client has obtained an RTSP URI to stored in a container file. The client has obtained an RTSP URI to
the container file. the container file.
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Server: PhonyServer/1.0 Server: PhonyServer/1.0
skipping to change at page 225, line 41 skipping to change at page 237, line 21
A.2. Media on Demand using Pipelining A.2. Media on Demand using Pipelining
This example is basically the example above (Appendix A.1), but now This example is basically the example above (Appendix A.1), but now
utilizing pipelining to speed up the setup. It requires only two utilizing pipelining to speed up the setup. It requires only two
round trip times until the media starts flowing. First of all, the round trip times until the media starts flowing. First of all, the
session description is retrieved to determine what media resources session description is retrieved to determine what media resources
need to be setup. In the second step, one sends the necessary SETUP need to be setup. In the second step, one sends the necessary SETUP
requests and the PLAY request to initiate media delivery. requests and the PLAY request to initiate media delivery.
Client C requests a presentation from media server M. The movie is Client C requests a presentation from media server M. The movie is
stored in a container file. The client has obtained an RTSP URI to stored in a container file. The client has obtained an RTSP URI to
the container file. the container file.
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Server: PhonyServer/1.0 Server: PhonyServer/1.0
skipping to change at page 227, line 48 skipping to change at page 239, line 26
url="rtsp://example.com/twister.3gp/trackID=1" url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889 ssrc=4F312DD8:seq=54321;rtptime=2876889
Pipelined-Requests: 7654 Pipelined-Requests: 7654
A.3. Media on Demand (Unicast) A.3. Media on Demand (Unicast)
An alternative example of media on demand with a bit more tweaks is An alternative example of media on demand with a bit more tweaks is
the following. Client C requests a movie distributed from two the following. Client C requests a movie distributed from two
different media servers A (audio.example.com) and V ( different media servers A (audio.example.com) and V (
video.example.com). The media description is stored on a web server video.example.com). The media description is stored on a web server
W. The media description contains descriptions of the presentation W. The media description contains descriptions of the presentation
and all its streams, including the codecs that are available, dynamic and all its streams, including the codecs that are available, dynamic
RTP payload types, the protocol stack, and content information such RTP payload types, the protocol stack, and content information such
as language or copyright restrictions. It may also give an as language or copyright restrictions. It may also give an
indication about the timeline of the movie. indication about the timeline of the movie.
In this example, the client is only interested in the last part of In this example, the client is only interested in the last part of
the movie. the movie.
C->W: GET /twister.sdp HTTP/1.1 C->W: GET /twister.sdp HTTP/1.1
Host: www.example.com Host: www.example.com
skipping to change at page 236, line 5 skipping to change at page 248, line 31
B.1. States B.1. States
The state machine contains three states, described below. For each The state machine contains three states, described below. For each
state there exists a table which shows which requests and events are state there exists a table which shows which requests and events are
allowed and whether they will result in a state change. allowed and whether they will result in a state change.
Init: Initial state no session exists. Init: Initial state no session exists.
Ready: Session is ready to start playing. Ready: Session is ready to start playing.
Play: Session is playing, i.e. sending media stream data in the Play: Session is playing, i.e. sending media stream data in the
direction S->C. direction S->C.
B.2. State variables B.2. State variables
This representation of the state machine needs more than its state to This representation of the state machine needs more than its state to
work. A small number of variables are also needed and they are work. A small number of variables are also needed and they are
explained below. explained below.
NRM: The number of media streams part of this session. NRM: The number of media streams part of this session.
skipping to change at page 237, line 34 skipping to change at page 250, line 12
The server will timeout the session after the period of time The server will timeout the session after the period of time
specified in the SETUP response, if no activity from the client is specified in the SETUP response, if no activity from the client is
detected. Therefore there exists a timeout event for all states detected. Therefore there exists a timeout event for all states
except Init. except Init.
In the case that NRM = 1 the presentation URI is equal to the media In the case that NRM = 1 the presentation URI is equal to the media
URI or a specified presentation URI. For NRM > 1 the presentation URI or a specified presentation URI. For NRM > 1 the presentation
URI needs to be other than any of the medias that are part of the URI needs to be other than any of the medias that are part of the
session. This applies to all states. session. This applies to all states.
+--------------------+--------------------+-------------------------+ +---------------+-----------------+---------------------------------+
| Event | Prerequisite | Response | | Event | Prerequisite | Response |
+--------------------+--------------------+-------------------------+ +---------------+-----------------+---------------------------------+
| DESCRIBE | Needs REDIRECT | 3rr, Redirect | | DESCRIBE | Needs REDIRECT | 3rr, Redirect |
| | | | | | | |
| DESCRIBE | | 200, Session | | DESCRIBE | | 200, Session description |
| | | description | | | | |
| | | | | OPTIONS | Session ID | 200, Reset session timeout |
| OPTIONS | Session ID | 200, Reset session | | | | timer |
| | | timeout timer | | | | |
| | | | | OPTIONS | | 200 |
| OPTIONS | | 200 | | | | |
| | | | | SET_PARAMETER | Valid parameter | 200, change value of parameter |
| SET_PARAMETER | Valid parameter | 200, change value of | | | | |
| | | parameter | | GET_PARAMETER | Valid parameter | 200, return value of parameter |
| | | | +---------------+-----------------+---------------------------------+
| GET_PARAMETER | Valid parameter | 200, return value of |
| | | parameter |
+--------------------+--------------------+-------------------------+
Table 13: None state-machine changing events Table 13: None state-machine changing events
The methods in Table 13 do not have any effect on the state machine The methods in Table 13 do not have any effect on the state machine
or the state variables. However, some methods do change other or the state variables. However, some methods do change other
session related parameters, for example SET_PARAMETER which will set session related parameters, for example SET_PARAMETER which will set
the parameter(s) specified in its body. Also all of these methods the parameter(s) specified in its body. Also all of these methods
that allow Session header will also update the keep-alive timer for that allow Session header will also update the keep-alive timer for
the session. the session.
+------------------+----------------+-----------+-------------------+ +------------------+----------------+-----------+-------------------+
skipping to change at page 238, line 31 skipping to change at page 251, line 8
+------------------+----------------+-----------+-------------------+ +------------------+----------------+-----------+-------------------+
Table 14: State: Init Table 14: State: Init
The initial state of the state machine, see Table 14 can only be left The initial state of the state machine, see Table 14 can only be left
by processing a correct SETUP request. As seen in the table the two by processing a correct SETUP request. As seen in the table the two
state variables are also set by a correct request. This table also state variables are also set by a correct request. This table also
shows that a correct SETUP can in some cases be redirected to another shows that a correct SETUP can in some cases be redirected to another
URI and/or server by a 3rr response. URI and/or server by a 3rr response.
+---------------+------------------------+----------+---------------+ +-------------+------------------------+---------+------------------+
| Action | Requisite | New | Response | | Action | Requisite | New | Response |
| | | State | | | | | State | |
+---------------+------------------------+----------+---------------+ +-------------+------------------------+---------+------------------+
| SETUP | New URI | Ready | NRM +=1 | | SETUP | New URI | Ready | NRM +=1 |
| | | | | | | | | |
| SETUP | URI Setup prior | Ready | Change | | SETUP | URI Setup prior | Ready | Change transport |
| | | | transport | | | | | param |
| | | | param | | | | | |
| | | | | | TEARDOWN | Prs URI, | Init | No session hdr, |
| TEARDOWN | Prs URI, | Init | No session | | | | | NRM = 0 |
| | | | hdr, NRM = 0 | | | | | |
| | | | | | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, |
| TEARDOWN | md URI,NRM=1 | Init | No Session | | | | | NRM = 0 |
| | | | hdr, NRM = 0 | | | | | |
| | | | | | TEARDOWN | md URI,NRM>1 | Ready | Session hdr, NRM |
| TEARDOWN | md URI,NRM>1 | Ready | Session hdr, | | | | | -= 1 |
| | | | NRM -= 1 | | | | | |
| | | | | | PLAY | Prs URI, No range | Play | Play from RP |
| PLAY | Prs URI, No range | Play | Play from RP | | | | | |
| | | | | | PLAY | Prs URI, Range | Play | According to |
| PLAY | Prs URI, Range | Play | According to | | | | | range |
| | | | range | | | | | |
| | | | | | PLAY | md URI, NRM=1, Range | Play | According to |
| PLAY | md URI, NRM=1, Range | Play | According to | | | | | range |
| | | | range | | | | | |
| | | | | | PLAY | md URI, NRM=1 | Play | Play from RP |
| PLAY | md URI, NRM=1 | Play | Play from RP | | | | | |
| | | | | | PAUSE | Prs URI | Ready | Return PP |
| PAUSE | Prs URI | Ready | Return PP | | | | | |
| | | | | | SC:REDIRECT | Terminate-Reason | Ready | Set RedP |
| SC:REDIRECT | Terminate-Reason | Ready | Set RedP | | | | | |
| | | | | | SC:REDIRECT | No Terminate-Reason | Init | Session is |
| SC:REDIRECT | No Terminate-Reason | Init | Session is | | | time parameter | | removed |
| | time parameter | | removed | | | | | |
| | | | | | Timeout | | Init | |
| Timeout | | Init | | | | | | |
| | | | | | RedP | | Init | TEARDOWN of |
| RedP reached | | Init | TEARDOWN of | | reached | | | session |
| | | | session | +-------------+------------------------+---------+------------------+
+---------------+------------------------+----------+---------------+
Table 15: State: Ready Table 15: State: Ready
In the Ready state, see Table 15, some of the actions are depending In the Ready state, see Table 15, some of the actions are depending
on the number of media streams (NRM) in the session, i.e., aggregated on the number of media streams (NRM) in the session, i.e., aggregated
or non-aggregated control. A SETUP request in the Ready state can or non-aggregated control. A SETUP request in the Ready state can
either add one more media stream to the session or, if the media either add one more media stream to the session or, if the media
stream (same URI) already is part of the session, change the stream (same URI) already is part of the session, change the
transport parameters. TEARDOWN is depending on both the Request-URI transport parameters. TEARDOWN is depending on both the Request-URI
and the number of media streams within the session. If the Request- and the number of media streams within the session. If the Request-
URI is the presentations URI the whole session is torn down. If a URI is the presentations URI the whole session is torn down. If a
media URI is used in the TEARDOWN request and more than one media media URI is used in the TEARDOWN request and more than one media
exists in the session, the session will remain and a session header exists in the session, the session will remain and a session header
is returned in the response. If only a single media stream remains is returned in the response. If only a single media stream remains
in the session when performing a TEARDOWN with a media URI the in the session when performing a TEARDOWN with a media URI the
session is removed. The number of media streams remaining after session is removed. The number of media streams remaining after
tearing down a media stream determines the new state. tearing down a media stream determines the new state.
+--------------------+-------------------+---------+----------------+ +----------------+-----------------------+--------+-----------------+
| Action | Requisite | New | Response | | Action | Requisite | New | Response |
| | | State | | | | | State | |
+--------------------+-------------------+---------+----------------+ +----------------+-----------------------+--------+-----------------+
| PAUSE | Prs URI | Ready | Set RP to | | PAUSE | Prs URI | Ready | Set RP to |
| | | | present point | | | | | present point |
| | | | | | | | | |
| End of media | All media | Play | Set RP = End | | End of media | All media | Play | Set RP = End of |
| | | | of media | | | | | media |
| | | | | | | | | |
| End of range | | Play | Set RP = End | | End of range | | Play | Set RP = End of |
| | | | of range | | | | | range |
| | | | | | | | | |
| PLAY | Prs URI, No range | Play | Play from | | PLAY | Prs URI, No range | Play | Play from |
| | | | present point | | | | | present point |
| | | | | | | | | |
| PLAY | Prs URI, Range | Play | According to | | PLAY | Prs URI, Range | Play | According to |
| | | | range | | | | | range |
| | | | | | | | | |
| SC:PLAY_NOTIFY | | Play | 200 | | SC:PLAY_NOTIFY | | Play | 200 |
| | | | | | | | | |
| SETUP | New URI | Play | 455 | | SETUP | New URI | Play | 455 |
| | | | | | | | | |
| SETUP | Setuped URI | Play | 455 | | SETUP | Setuped URI | Play | 455 |
| | | | | | | | | |
| SETUP | Setuped URI, IFI | Play | Change | | SETUP | Setuped URI, IFI | Play | Change |
| | | | transport | | | | | transport |
| | | | param. | | | | | param. |
| | | | | | | | | |
| TEARDOWN | Prs URI | Init | No session hdr | | TEARDOWN | Prs URI | Init | No session hdr |
| | | | | | | | | |
| TEARDOWN | md URI,NRM=1 | Init | No Session | | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, |
| | | | hdr, NRM=0 | | | | | NRM=0 |
| | | | | | | | | |
| TEARDOWN | md URI | Play | 455 | | TEARDOWN | md URI | Play | 455 |
| | | | | | | | | |
| SC:REDIRECT | Terminate Reason | Play | Set RedP | | SC:REDIRECT | Terminate Reason with | Play | Set RedP |
| | with Time | | | | | Time parameter | | |
| | parameter | | | | | | | |
| | | | | | SC:REDIRECT | | Init | Session is |
| SC:REDIRECT | | Init | Session is | | | | | removed |
| | | | removed | | | | | |
| | | | | | RedP reached | | Init | TEARDOWN of |
| RedP reached | | Init | TEARDOWN of | | | | | session |
| | | | session | | | | | |
| | | | | | Timeout | | Init | Stop Media |
| Timeout | | Init | Stop Media | | | | | playout |
| | | | playout | +----------------+-----------------------+--------+-----------------+
+--------------------+-------------------+---------+----------------+
Table 16: State: Play Table 16: State: Play
The Play state table, see Table 16, contains a number of requests The Play state table, see Table 16, contains a number of requests
that need a presentation URI (labeled as Prs URI) to work on (i.e., that need a presentation URI (labeled as Prs URI) to work on (i.e.,
the presentation URI has to be used as the Request-URI). This is due the presentation URI has to be used as the Request-URI). This is due
to the exclusion of non-aggregated stream control in sessions with to the exclusion of non-aggregated stream control in sessions with
more than one media stream. more than one media stream.
To avoid inconsistencies between the client and server, automatic To avoid inconsistencies between the client and server, automatic
state transitions are avoided. This can be seen at for example "End state transitions are avoided. This can be seen at for example "End
skipping to change at page 250, line 38 skipping to change at page 264, line 22
client over the RTP TCP connection, and RTCP packets flow client over the RTP TCP connection, and RTCP packets flow
bidirectionally over the RTCP TCP connection. Unless RTP and RTCP bidirectionally over the RTCP TCP connection. Unless RTP and RTCP
multiplexing has been negotiated in which case RTP and RTCP will flow multiplexing has been negotiated in which case RTP and RTCP will flow
over a common TCP connection. As in the RTP/UDP case, client to over a common TCP connection. As in the RTP/UDP case, client to
server traffic on a RTP only TCP session is unspecified by this memo. server traffic on a RTP only TCP session is unspecified by this memo.
The packets that travel on these connections MUST be framed using the The packets that travel on these connections MUST be framed using the
protocol defined in [RFC4571], not by the framing defined for protocol defined in [RFC4571], not by the framing defined for
interleaving RTP over the RTSP control connection defined in interleaving RTP over the RTSP control connection defined in
Section 14. Section 14.
A successful PAUSE request for a media being transported over RTP/AVP A successful PAUSE request for a media being transported over RTP/
/TCP pauses the flow of packets over the connections, without closing AVP/TCP pauses the flow of packets over the connections, without
the connections. A successful TEARDOWN request signals that the TCP closing the connections. A successful TEARDOWN request signals that
connections for RTP and RTCP are to be closed by the RTSP client as the TCP connections for RTP and RTCP are to be closed by the RTSP
soon as possible. client as soon as possible.
Subsequent SETUP requests on an already-SETUP RTP/AVP/TCP URI may be Subsequent SETUP requests on an already-SETUP RTP/AVP/TCP URI may be
ambiguous in the following way: does the client wish to open up new ambiguous in the following way: does the client wish to open up new
TCP connection for RTP or RTCP for the URI, or does the client wish TCP connection for RTP or RTCP for the URI, or does the client wish
to continue using the existing TCP connections? The client SHOULD to continue using the existing TCP connections? The client SHOULD
use the "connection" parameter (defined in Section 18.52) on the use the "connection" parameter (defined in Section 18.52) on the
Transport line to make its intention clear (by setting "connection" Transport line to make its intention clear (by setting "connection"
to "new" if new connections are needed, and by setting "connection" to "new" if new connections are needed, and by setting "connection"
to "existing" if the existing connections are to be used). After a to "existing" if the existing connections are to be used). After a
2xx reply for a SETUP request for a new connection, parties should 2xx reply for a SETUP request for a new connection, parties should
skipping to change at page 253, line 4 skipping to change at page 267, line 5
completed PLAY request perform a new PLAY request. This will result completed PLAY request perform a new PLAY request. This will result
in some gap in the media layer. The below text will look into both in some gap in the media layer. The below text will look into both
cases. cases.
A PLAY request that replaces an ongoing request allows the media A PLAY request that replaces an ongoing request allows the media
layer rendering the RTP stream without being affected by jumps in layer rendering the RTP stream without being affected by jumps in
media clock time. The RTP timestamps for the new media range is set media clock time. The RTP timestamps for the new media range is set
so that they become continuous with the previous media range in the so that they become continuous with the previous media range in the
previous request. The RTP sequence number for the first packet in previous request. The RTP sequence number for the first packet in
the new range will be the next following the last packet in the the new range will be the next following the last packet in the
previous range, i.e. monotonically increasing. The goal is to allow previous range, i.e. monotonically increasing. The goal is to allow
the media rendering layer to work without interruption or the media rendering layer to work without interruption or
reconfiguration across the jumps in media clock. This should be reconfiguration across the jumps in media clock. This should be
possible in all cases of replaced PLAY requests for media that has possible in all cases of replaced PLAY requests for media that has
random-access properties. In this case care is needed to align random-access properties. In this case care is needed to align
frames or similar media dependent structures. frames or similar media dependent structures.
In cases where jumps in media clock time are a result of RTSP In cases where jumps in media clock time are a result of RTSP
signaling operations arriving after a completed PLAY operation, the signaling operations arriving after a completed PLAY operation, the
request timing will result in that media becomes non-continuous. The request timing will result in that media becomes non-continuous. The
server becomes unable to send the media so that it arrives timely and server becomes unable to send the media so that it arrives timely and
skipping to change at page 253, line 47 skipping to change at page 267, line 48
the server itself. For this type of basic delivery of live streams the server itself. For this type of basic delivery of live streams
to multiple users over unicast, individual rewriting of RTP sequence to multiple users over unicast, individual rewriting of RTP sequence
numbers becomes quite a burden. For solutions that anyway caches numbers becomes quite a burden. For solutions that anyway caches
media, timeshifts, etc, the rewriting should be a minor issue. media, timeshifts, etc, the rewriting should be a minor issue.
The goal when handling jumps in media clock time is that the provided The goal when handling jumps in media clock time is that the provided
stream is continuous without gaps in RTP timestamp or sequence stream is continuous without gaps in RTP timestamp or sequence
number. However, when delivery has been halted for some reason the number. However, when delivery has been halted for some reason the
RTP timestamp when resuming MUST represent the duration the delivery RTP timestamp when resuming MUST represent the duration the delivery
was halted. RTP sequence number MUST generally be the next number, was halted. RTP sequence number MUST generally be the next number,
i.e. monotonically increasing modulo 65536. For media resources i.e. monotonically increasing modulo 65536. For media resources with
with the properties Time-Progressing and Time-Duration=0.0 the server the properties Time-Progressing and Time-Duration=0.0 the server MAY
MAY create RTP media streams with RTP sequence number jumps in them create RTP media streams with RTP sequence number jumps in them due
due to the client first halting delivery and later resuming it (PAUSE to the client first halting delivery and later resuming it (PAUSE and
and then later PLAY). However, servers utilizing this exception must then later PLAY). However, servers utilizing this exception must
take into consideration the resulting RTCP receiver reports that take into consideration the resulting RTCP receiver reports that
likely contain loss reports for all the packets part of the likely contain loss reports for all the packets part of the
discontinuity. A client cannot rely on that a server will align when discontinuity. A client cannot rely on that a server will align when
resuming playing even if it is RECOMMENDED. The RTP-Info header will resuming playing even if it is RECOMMENDED. The RTP-Info header will
provide information on how the server acts in each case. provide information on how the server acts in each case.
We cannot assume that the RTSP client can communicate with the RTP We cannot assume that the RTSP client can communicate with the RTP
media agent, as the two may be independent processes. If the RTP media agent, as the two may be independent processes. If the RTP
timestamp shows the same gap as the NPT, the media agent will timestamp shows the same gap as the NPT, the media agent will
assume that there is a pause in the presentation. If the jump in assume that there is a pause in the presentation. If the jump in
skipping to change at page 255, line 33 skipping to change at page 269, line 35
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 6 CSeq: 6
Session: abcdefg Session: abcdefg
Range: npt=18-20 Range: npt=18-20
RTP-Info: url="rtsp://example.com/fizzle/audiotrack" RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=50;rtptime=40100 ssrc=0D12F123:seq=50;rtptime=40100
The ensuing RTP data stream is depicted below: The ensuing RTP data stream is depicted below:
S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s
S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s
. . . . . .
S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s
In this example, first, NPT 10 through 15 is played, then the client In this example, first, NPT 10 through 15 is played, then the client
requests the server to skip ahead and play NPT 18 through 20. The requests the server to skip ahead and play NPT 18 through 20. The
first segment is presented as RTP packets with sequence numbers 0 first segment is presented as RTP packets with sequence numbers 0
through 49 and timestamp 0 through 39,200. The second segment through 49 and timestamp 0 through 39,200. The second segment
consists of RTP packets with sequence number 50 through 69, with consists of RTP packets with sequence number 50 through 69, with
timestamps 40,100 through 55,200. While there is a gap in the NPT, timestamps 40,100 through 55,200. While there is a gap in the NPT,
there is no gap in the sequence number space of the RTP data stream. there is no gap in the sequence number space of the RTP data stream.
The RTP timestamp gap is present in the above example due to the time The RTP timestamp gap is present in the above example due to the time
skipping to change at page 256, line 48 skipping to change at page 270, line 47
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 4 CSeq: 4
Session: abcdefg Session: abcdefg
Range: npt=10-15 Range: npt=10-15
RTP-Info: url="rtsp://example.com/fizzle/audiotrack" RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=0;rtptime=0 ssrc=0D12F123:seq=0;rtptime=0
The ensuing RTP data stream is depicted below: The ensuing RTP data stream is depicted below:
S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s
S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s
S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s
S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s
The client then sends a PAUSE request: The client then sends a PAUSE request:
C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0
CSeq: 5 CSeq: 5
Session: abcdefg Session: abcdefg
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 5 CSeq: 5
skipping to change at page 257, line 35 skipping to change at page 271, line 32
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 6 CSeq: 6
Session: abcdefg Session: abcdefg
Range: npt=10.4-15 Range: npt=10.4-15
RTP-Info: url="rtsp://example.com/fizzle/audiotrack" RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=4;rtptime=164400 ssrc=0D12F123:seq=4;rtptime=164400
The ensuing RTP data stream is depicted below: The ensuing RTP data stream is depicted below:
S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s
S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s
S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s
First, NPT 10 through 10.3 is played, then a PAUSE is received by the First, NPT 10 through 10.3 is played, then a PAUSE is received by the
server. After 20 seconds a PLAY is received by the server which server. After 20 seconds a PLAY is received by the server which
takes 15 ms to process. The duration of time for which the session takes 15 ms to process. The duration of time for which the session
was paused is reflected in the RTP timestamp of the RTP packets sent was paused is reflected in the RTP timestamp of the RTP packets sent
after this PLAY request. after this PLAY request.
A client can use the RTSP range header and RTP-Info header to map NPT A client can use the RTSP range header and RTP-Info header to map NPT
time of a presentation with the RTP timestamp. time of a presentation with the RTP timestamp.
skipping to change at page 261, line 20 skipping to change at page 274, line 52
media level URI. The presence of a session level control attribute media level URI. The presence of a session level control attribute
MUST be interpreted as support for aggregated control. The control MUST be interpreted as support for aggregated control. The control
attribute MUST be present on media level unless the presentation only attribute MUST be present on media level unless the presentation only
contains a single media stream, in which case the attribute MAY be contains a single media stream, in which case the attribute MAY be
present on the session level only and then also apply to that single present on the session level only and then also apply to that single
media stream. media stream.
ABNF for the attribute is defined in Section 20.3. ABNF for the attribute is defined in Section 20.3.
Example: Example:
a=control:rtsp://example.com/foo
a=control:rtsp://example.com/foo
This attribute MAY contain either relative or absolute URIs, This attribute MAY contain either relative or absolute URIs,
following the rules and conventions set out in RFC 3986 [RFC3986]. following the rules and conventions set out in RFC 3986 [RFC3986].
Implementations MUST look for a base URI in the following order: Implementations MUST look for a base URI in the following order:
1. the RTSP Content-Base field; 1. the RTSP Content-Base field;
2. the RTSP Content-Location field; 2. the RTSP Content-Location field;
3. the RTSP Request-URI. 3. the RTSP Request-URI.
skipping to change at page 262, line 7 skipping to change at page 275, line 36
The URI handling for SDPs from container files need special The URI handling for SDPs from container files need special
consideration. For example let's assume that a container file has consideration. For example let's assume that a container file has
the URI: "rtsp://example.com/container.mp4". Let's further assume the URI: "rtsp://example.com/container.mp4". Let's further assume
this URI is the base URI, and that there is an absolute media level this URI is the base URI, and that there is an absolute media level
URI: "rtsp://example.com/container.mp4/trackID=2". A relative media URI: "rtsp://example.com/container.mp4/trackID=2". A relative media
level URI that resolves in accordance with RFC 3986 [RFC3986] to the level URI that resolves in accordance with RFC 3986 [RFC3986] to the
above given media URI is: "container.mp4/trackID=2". It is usually above given media URI is: "container.mp4/trackID=2". It is usually
not desirable to need to include in or modify the SDP stored within not desirable to need to include in or modify the SDP stored within
the container file with the server local name of the container file. the container file with the server local name of the container file.
To avoid this, one can modify the base URI used to include a trailing To avoid this, one can modify the base URI used to include a trailing
slash, e.g. "rtsp://example.com/container.mp4/". In this case the slash, e.g. "rtsp://example.com/container.mp4/". In this case the
relative URI for the media will only need to be: "trackID=2". relative URI for the media will only need to be: "trackID=2".
However, this will also mean that using "*" in the SDP will result in However, this will also mean that using "*" in the SDP will result in
control URI including the trailing slash, i.e. "rtsp://example.com/ control URI including the trailing slash, i.e.
container.mp4/". "rtsp://example.com/container.mp4/".
Note: The usage of TrackID in the above is not a standardized Note: The usage of TrackID in the above is not a standardized
form, but one example out of several similar strings such as form, but one example out of several similar strings such as
TrackID, Track_ID, StreamID that is used by different server TrackID, Track_ID, StreamID that is used by different server
vendors to indicate a particular piece of media inside a container vendors to indicate a particular piece of media inside a container
file. file.
D.1.2. Media Streams D.1.2. Media Streams
The "m=" field is used to enumerate the streams. It is expected that The "m=" field is used to enumerate the streams. It is expected that
skipping to change at page 262, line 41 skipping to change at page 276, line 21
preference, it SHOULD set the port number value to zero. preference, it SHOULD set the port number value to zero.
The "m=" lines contain information about which transport protocol, The "m=" lines contain information about which transport protocol,
profile, and possibly lower-layer is to be used for the media stream. profile, and possibly lower-layer is to be used for the media stream.
The combination of transport, profile and lower layer, like RTP/AVP/ The combination of transport, profile and lower layer, like RTP/AVP/
UDP needs to be defined for how to be used with RTSP. The currently UDP needs to be defined for how to be used with RTSP. The currently
defined combinations are defined in Appendix C, further combinations defined combinations are defined in Appendix C, further combinations
MAY be specified. MAY be specified.
Example: Example:
m=audio 0 RTP/AVP 31
m=audio 0 RTP/AVP 31
D.1.3. Payload Type(s) D.1.3. Payload Type(s)
The payload type(s) are specified in the "m=" line. In case the The payload type(s) are specified in the "m=" line. In case the
payload type is a static payload type from RFC 3551 [RFC3551], no payload type is a static payload type from RFC 3551 [RFC3551], no
other information may be required. In case it is a dynamic payload other information may be required. In case it is a dynamic payload
type, the media attribute "rtpmap" is used to specify what the media type, the media attribute "rtpmap" is used to specify what the media
is. The "encoding name" within the "rtpmap" attribute may be one of is. The "encoding name" within the "rtpmap" attribute may be one of
those specified in [RFC4856], or a media type registered with IANA those specified in [RFC4856], or a media type registered with IANA
according to [RFC4855], or an experimental encoding as specified in according to [RFC4855], or an experimental encoding as specified in
skipping to change at page 264, line 34 skipping to change at page 278, line 11
Range", in case the client uses PLAY requests with a Range header. Range", in case the client uses PLAY requests with a Range header.
In case the content is dynamic in length and it is infeasible to In case the content is dynamic in length and it is infeasible to
provide a correct value in the SDP the server is recommended to provide a correct value in the SDP the server is recommended to
describe this as non-seekable content (see below). The server MAY describe this as non-seekable content (see below). The server MAY
override that property in the response to a PLAY request using the override that property in the response to a PLAY request using the
correct values in the Range header. correct values in the Range header.
The unit is specified first, followed by the value range. The units The unit is specified first, followed by the value range. The units
and their values are as defined in Section 4.4, Section 4.5 and and their values are as defined in Section 4.4, Section 4.5 and
Section 4.6 and MAY be extended with further formats. Any open ended Section 4.6 and MAY be extended with further formats. Any open ended
range (start-), i.e. without stop range, is of unspecified duration range (start-), i.e. without stop range, is of unspecified duration
and MUST be considered as non-seekable content unless this property and MUST be considered as non-seekable content unless this property
is overridden. Multiple instances carrying different clock formats is overridden. Multiple instances carrying different clock formats
MAY be included at either session or media level. MAY be included at either session or media level.
ABNF for the attribute is defined in Section 20.3. ABNF for the attribute is defined in Section 20.3.
Examples: Examples:
a=range:npt=0-34.4368
a=range:npt=0-34.4368 a=range:clock=19971113T211503Z-19971113T220300Z
a=range:clock=19971113T211503Z-19971113T220300Z Non seekable stream of unknown duration:
Non seekable stream of unknown duration: a=range:npt=0-
a=range:npt=0-
D.1.7. Time of Availability D.1.7. Time of Availability
The "t=" field defines when the SDP is valid. For on-demand content The "t=" field defines when the SDP is valid. For on-demand content
the server SHOULD indicate a stop time value for which it guarantees the server SHOULD indicate a stop time value for which it guarantees
the description to be valid, and a start time that is equal to or the description to be valid, and a start time that is equal to or
before the time at which the DESCRIBE request was received. It MAY before the time at which the DESCRIBE request was received. It MAY
also indicate start and stop times of 0, meaning that the session is also indicate start and stop times of 0, meaning that the session is
always available. always available.
For sessions that are of live type, i.e. specific start time, For sessions that are of live type, i.e. specific start time, unknown
unknown stop time, likely unseekable, the "t=" and "r=" field SHOULD stop time, likely unseekable, the "t=" and "r=" field SHOULD be used
be used to indicate the start time of the event. The stop time to indicate the start time of the event. The stop time SHOULD be
SHOULD be given so that the live event will have ended at that time, given so that the live event will have ended at that time, while
while still not be unnecessary long into the future. still not be unnecessary long into the future.
D.1.8. Connection Information D.1.8. Connection Information
In SDP used with RTSP, the "c=" field contains the destination In SDP used with RTSP, the "c=" field contains the destination
address for the media stream. If a multicast address is specified address for the media stream. If a multicast address is specified
the client SHOULD use this address in any SETUP request as the client SHOULD use this address in any SETUP request as
destination address, including any additional parameters, such as destination address, including any additional parameters, such as
TTL. For on-demand unicast streams and some multicast streams, the TTL. For on-demand unicast streams and some multicast streams, the
destination address MAY be specified by the client via the SETUP destination address MAY be specified by the client via the SETUP
request, thus overriding any specified address. To identify streams request, thus overriding any specified address. To identify streams
without a fixed destination address, where the client is required to without a fixed destination address, where the client is required to
specify a destination address, the "c=" field SHOULD be set to a null specify a destination address, the "c=" field SHOULD be set to a null
value. For addresses of type "IP4", this value MUST be "0.0.0.0", value. For addresses of type "IP4", this value MUST be "0.0.0.0",
and for type "IP6", this value MUST be "0:0:0:0:0:0:0:0" (can also be and for type "IP6", this value MUST be "0:0:0:0:0:0:0:0" (can also be
written as "::"), i.e. the unspecified address according to RFC 4291 written as "::"), i.e. the unspecified address according to RFC 4291
[RFC4291]. [RFC4291].
D.1.9. Message Body Tag D.1.9. Message Body Tag
The optional "a=mtag" attribute identifies a version of the session The optional "a=mtag" attribute identifies a version of the session
description. It is opaque to the client. SETUP requests may include description. It is opaque to the client. SETUP requests may include
this identifier in the If-Match field (see Section 18.23) to only this identifier in the If-Match field (see Section 18.23) to only
allow session establishment if this attribute value still corresponds allow session establishment if this attribute value still corresponds
to that of the current description. The attribute value is opaque to that of the current description. The attribute value is opaque
and may contain any character allowed within SDP attribute values. and may contain any character allowed within SDP attribute values.
ABNF for the attribute is defined in Section 20.3. ABNF for the attribute is defined in Section 20.3.
Example: Example:
a=mtag:"158bb3e7c7fd62ce67f12b533f06b83a"
a=mtag:"158bb3e7c7fd62ce67f12b533f06b83a"
One could argue that the "o=" field provides identical One could argue that the "o=" field provides identical
functionality. However, it does so in a manner that would put functionality. However, it does so in a manner that would put
constraints on servers that need to support multiple session constraints on servers that need to support multiple session
description types other than SDP for the same piece of media description types other than SDP for the same piece of media
content. content.
D.2. Aggregate Control Not Available D.2. Aggregate Control Not Available
If a presentation does not support aggregate control no session level If a presentation does not support aggregate control no session level
skipping to change at page 267, line 25 skipping to change at page 280, line 45
e=adm@example.com e=adm@example.com
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
a=control:* a=control:*
t=0 0 t=0 0
m=video 8002 RTP/AVP 31 m=video 8002 RTP/AVP 31
a=control:trackID=1 a=control:trackID=1
m=audio 8004 RTP/AVP 3 m=audio 8004 RTP/AVP 3
a=control:trackID=2 a=control:trackID=2
In this example, the client is recommended to establish a single RTSP In this example, the client is recommended to establish a single RTSP
session to the server, and uses the URIs rtsp://example.com/movie/ session to the server, and uses the URIs
trackID=1 and rtsp://example.com/movie/trackID=2 to set up the video rtsp://example.com/movie/trackID=1 and
and audio streams, respectively. The URI rtsp://example.com/movie/, rtsp://example.com/movie/trackID=2 to set up the video and audio
which is resolved from the "*", controls the whole presentation streams, respectively. The URI rtsp://example.com/movie/, which is
(movie). resolved from the "*", controls the whole presentation (movie).
A client is not required to issue SETUP requests for all streams A client is not required to issue SETUP requests for all streams
within an aggregate object. Servers should allow the client to ask within an aggregate object. Servers should allow the client to ask
for only a subset of the streams. for only a subset of the streams.
D.4. Grouping of Media Lines in SDP D.4. Grouping of Media Lines in SDP
For some types of media it is desirable to express a relationship For some types of media it is desirable to express a relationship
between various media components, for instance, for lip between various media components, for instance, for lip
synchronization or Scalable Video Codec (SVC) [RFC5583]. This synchronization or Scalable Video Codec (SVC) [RFC5583]. This
skipping to change at page 268, line 15 skipping to change at page 281, line 34
D.5. RTSP external SDP delivery D.5. RTSP external SDP delivery
There are some considerations that need to be made when the session There are some considerations that need to be made when the session
description is delivered to the client outside of RTSP, for example description is delivered to the client outside of RTSP, for example
via HTTP or email. via HTTP or email.
First of all, the SDP needs to contain absolute URIs, since relative First of all, the SDP needs to contain absolute URIs, since relative
will in most cases not work as the delivery will not correctly will in most cases not work as the delivery will not correctly
forward the base URI. forward the base URI.
The writing of the SDP session availability information, i.e. "t=" The writing of the SDP session availability information, i.e. "t="
and "r=", needs to be carefully considered. When the SDP is fetched and "r=", needs to be carefully considered. When the SDP is fetched
by the DESCRIBE method, the probability that it is valid is very by the DESCRIBE method, the probability that it is valid is very
high. However, the same is much less certain for SDPs distributed high. However, the same is much less certain for SDPs distributed
using other methods. Therefore the publisher of the SDP should take using other methods. Therefore the publisher of the SDP should take
care to follow the recommendations about availability in the SDP care to follow the recommendations about availability in the SDP
specification [RFC4566] in Section 4.2. specification [RFC4566] in Section 4.2.
Appendix E. RTSP Use Cases Appendix E. RTSP Use Cases
This Appendix describes the most important and considered use cases This Appendix describes the most important and considered use cases
for RTSP. They are listed in descending order of importance in for RTSP. They are listed in descending order of importance in
regards to ensuring that all necessary functionality is present. regards to ensuring that all necessary functionality is present.
This specification only fully supports usage of the two first. Also This specification only fully supports usage of the two first. Also
in these first two cases, there are special cases or exceptions that in these first two cases, there are special cases or exceptions that
are not supported without extensions, e.g. the redirection of media are not supported without extensions, e.g. the redirection of media
delivery to another address than the controlling agent's (client's). delivery to another address than the controlling agent's (client's).
E.1. On-demand Playback of Stored Content E.1. On-demand Playback of Stored Content
An RTSP capable server stores content suitable for being streamed to An RTSP capable server stores content suitable for being streamed to
a client. A client desiring playback of any of the stored content a client. A client desiring playback of any of the stored content
uses RTSP to set up the media transport required to deliver the uses RTSP to set up the media transport required to deliver the
desired content. RTSP is then used to initiate, halt and manipulate desired content. RTSP is then used to initiate, halt and manipulate
the actual transmission (playout) of the content. RTSP is also the actual transmission (playout) of the content. RTSP is also
required to provide necessary description and synchronization required to provide necessary description and synchronization
skipping to change at page 271, line 44 skipping to change at page 285, line 18
There are several issues with this use case that are not solved by There are several issues with this use case that are not solved by
this core specification for RTSP: this core specification for RTSP:
Denial of service: To avoid an RTSP server from being an unknowing Denial of service: To avoid an RTSP server from being an unknowing
participant in a denial of service attack the server needs to participant in a denial of service attack the server needs to
be able to verify the destination's acceptance of the media. be able to verify the destination's acceptance of the media.
Such a mechanism to verify the approval of received media does Such a mechanism to verify the approval of received media does
not yet exist; instead, only policies can be used, which can be not yet exist; instead, only policies can be used, which can be
made to work in controlled environments. made to work in controlled environments.
Distributing the presentation description to all participants in the group: Distributing the presentation description to all participants in the
To enable a media receiver to correctly decode the content group: To enable a media receiver to correctly decode the content
the media configuration information needs to be distributed the media configuration information needs to be distributed
reliably to all participants. This will most likely require reliably to all participants. This will most likely require
support from an external protocol. support from an external protocol.
Passing control of the session: If it is desired to pass control Passing control of the session: If it is desired to pass control of
of the RTSP session between the participants, some support the RTSP session between the participants, some support will be
will be required by an external protocol to exchange state required by an external protocol to exchange state information
information and possibly floor control of who is controlling and possibly floor control of who is controlling the RTSP
the RTSP session. session.
E.5. Live Content using Multicast E.5. Live Content using Multicast
This use case in its simplest form does not require any use of RTSP This use case in its simplest form does not require any use of RTSP
at all; this is what multicast conferences being announced with SAP at all; this is what multicast conferences being announced with SAP
[RFC2974] and SDP are intended to handle. However, in use cases [RFC2974] and SDP are intended to handle. However, in use cases
where more advanced features like access control to the multicast where more advanced features like access control to the multicast
session are desired, RTSP could be used for session establishment. session are desired, RTSP could be used for session establishment.
A client desiring to join a live multicasted media session with A client desiring to join a live multicasted media session with
skipping to change at page 275, line 4 skipping to change at page 290, line 9
maintained: maintained:
o CSeq: See Section 18.19 o CSeq: See Section 18.19
o Timestamp: See Section 18.51 o Timestamp: See Section 18.51
Appendix H. Backwards Compatibility Considerations Appendix H. Backwards Compatibility Considerations
This section contains notes on issues about backwards compatibility This section contains notes on issues about backwards compatibility
with clients or servers being implemented according to RFC 2326 with clients or servers being implemented according to RFC 2326
[RFC2326]. Note that there exists no requirement to implement RTSP [RFC2326]. Note that there exists no requirement to implement RTSP
1.0; in fact we recommend against it as it is difficult to do in an 1.0; in fact we recommend against it as it is difficult to do in an
interoperable way. interoperable way.
A server implementing RTSP/2.0 MUST include an RTSP-Version of RTSP/ A server implementing RTSP/2.0 MUST include an RTSP-Version of
2.0 in all responses to requests containing RTSP-Version RTSP/2.0. RTSP/2.0 in all responses to requests containing RTSP-Version
If a server receives an RTSP/1.0 request, it MAY respond with an RTSP RTSP/2.0. If a server receives an RTSP/1.0 request, it MAY respond
/1.0 response if it chooses to support RFC 2326. If the server with an RTSP/1.0 response if it chooses to support RFC 2326. If the
chooses not to support RFC 2326, it MUST respond with a 505 (RTSP server chooses not to support RFC 2326, it MUST respond with a 505
Version not supported) status code. A server MUST NOT respond to an (RTSP Version not supported) status code. A server MUST NOT respond
RTSP-Version RTSP/1.0 request with an RTSP-Version RTSP/2.0 response. to an RTSP-Version RTSP/1.0 request with an RTSP-Version RTSP/2.0
response.
Clients implementing RTSP/2.0 MAY use an OPTIONS request with a RTSP- Clients implementing RTSP/2.0 MAY use an OPTIONS request with a RTSP-
Version of 2.0 to determine whether a server supports RTSP/2.0. If Version of 2.0 to determine whether a server supports RTSP/2.0. If
the server responds with either an RTSP-Version of 1.0 or a status the server responds with either an RTSP-Version of 1.0 or a status
code of 505 (RTSP Version not supported), the client will have to use code of 505 (RTSP Version not supported), the client will have to use
RTSP/1.0 requests if it chooses to support RFC 2326. RTSP/1.0 requests if it chooses to support RFC 2326.
H.1. Play Request in Play State H.1. Play Request in Play State
The behavior in the server when a Play is received in Play state has The behavior in the server when a Play is received in Play state has
skipping to change at page 283, line 32 skipping to change at page 299, line 24
This document has benefited greatly from the comments of all those This document has benefited greatly from the comments of all those
participating in the MMUSIC-WG. In addition to those already participating in the MMUSIC-WG. In addition to those already
mentioned, the following individuals have contributed to this mentioned, the following individuals have contributed to this
specification: specification:
Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning, Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning,
Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari, Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari,
Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V. Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V.
Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt, Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt,
John K. Ho, Go Hori, Philipp Hoschka, Anne Jones, Ingemar Johansson, John K. Ho, Go Hori, Philipp Hoschka, Anne Jones, Ingemar Johansson,
Anders Klemets, Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo Anders Klemets, Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo
F. Llach, Thomas Marshall, Rob McCool, David Oran, Joerg Ott, Maria F. Llach, Thomas Marshall, Rob McCool, David Oran, Joerg Ott, Maria
Papadopouli, Sujal Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Papadopouli, Sujal Patel, Ema Patki, Alagu Periyannan, Colin Perkins,
Igor Plotnikov, Jonathan Sergent, Pinaki Shah, David Singer, Lior Igor Plotnikov, Jonathan Sergent, Pinaki Shah, David Singer, Lior
Sion, Jeff Smith, Alexander Sokolsky, Dale Stammen, John Francis Sion, Jeff Smith, Alexander Sokolsky, Dale Stammen, John Francis
Stracke, Maureen Chesire, David Walker, Geetha Srikantan, Stephan Stracke, Maureen Chesire, David Walker, Geetha Srikantan, Stephan
Wenger, Pekka Pessi, Jae-Hwan Kim, Holger Schmidt, Stephen Farrell, Wenger, Pekka Pessi, Jae-Hwan Kim, Holger Schmidt, Stephen Farrell,
Xavier Marjou, Joe Pallas, Martti Mela, Byungjo Yoon and Patrick Xavier Marjou, Joe Pallas, Martti Mela, Byungjo Yoon and Patrick
Hoffman, Jinhang Choi, Ross Finlayson, Dale R. Worley, and Hoffman, Jinhang Choi, Ross Finlayson, Dale R. Worley, and especially
especially to Flemming Andreasen. to Flemming Andreasen.
J.1. Contributors J.1. Contributors
The following people have made written contributions that were The following people have made written contributions that were
included in the specification: included in the specification:
o Tom Marshall contributed text on the usage of 3rr status codes. o Tom Marshall contributed text on the usage of 3rr status codes.
o Thomas Zheng contributed text on the usage of the Range in PLAY o Thomas Zheng contributed text on the usage of the Range in PLAY
responses and proposed an earlier version of the PLAY_NOTIFY responses and proposed an earlier version of the PLAY_NOTIFY
skipping to change at page 285, line 4 skipping to change at page 302, line 20
New York, NY 10027 New York, NY 10027
USA USA
Email: schulzrinne@cs.columbia.edu Email: schulzrinne@cs.columbia.edu
Anup Rao Anup Rao
Cisco Cisco
USA USA
Email: anrao@cisco.com Email: anrao@cisco.com
Rob Lanphier Rob Lanphier
Seattle, WA Seattle, WA
USA USA
Email: robla@robla.net Email: robla@robla.net
Magnus Westerlund Magnus Westerlund
Ericsson AB Ericsson AB
Faeroegatan 6 Faeroegatan 6
STOCKHOLM SE-164 80 STOCKHOLM, SE-164 80
SWEDEN SWEDEN
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
Martin Stiemerling Martin Stiemerling
NEC Laboratories Europe, NEC Europe Ltd. NEC Laboratories Europe, NEC Europe Ltd.
Kurfuersten-Anlage 36 Kurfuersten-Anlage 36
Heidelberg 69115 Heidelberg 69115
Germany Germany
 End of changes. 156 change blocks. 
1034 lines changed or deleted 1020 lines changed or added

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