draft-ietf-mmusic-rfc2326bis-37.txt   draft-ietf-mmusic-rfc2326bis-38.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: March 28, 2014 R. Lanphier Expires: April 13, 2014 R. Lanphier
M. Westerlund M. Westerlund
Ericsson AB Ericsson AB
M. Stiemerling (Ed.) M. Stiemerling (Ed.)
NEC NEC
September 24, 2013 October 10, 2013
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-37 draft-ietf-mmusic-rfc2326bis-38
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
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 28, 2014. This Internet-Draft will expire on April 13, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 27 skipping to change at page 3, line 27
3. Document Conventions . . . . . . . . . . . . . . . . . . . . 23 3. Document Conventions . . . . . . . . . . . . . . . . . . . . 23
3.1. Notational Conventions . . . . . . . . . . . . . . . . . 23 3.1. Notational Conventions . . . . . . . . . . . . . . . . . 23
3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 23 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 23
4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 27 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 27
4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 27 4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 27
4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 27 4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 27
4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 30 4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 30
4.4. Media Time Formats . . . . . . . . . . . . . . . . . . . 30 4.4. Media Time Formats . . . . . . . . . . . . . . . . . . . 30
4.4.1. SMPTE Relative Timestamps . . . . . . . . . . . . . 30 4.4.1. SMPTE Relative Timestamps . . . . . . . . . . . . . 30
4.4.2. Normal Play Time . . . . . . . . . . . . . . . . . . 31 4.4.2. Normal Play Time . . . . . . . . . . . . . . . . . . 31
4.4.3. Absolute Time . . . . . . . . . . . . . . . . . . . 31 4.4.3. Absolute Time . . . . . . . . . . . . . . . . . . . 32
4.5. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 32 4.5. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 33
4.6. Message Body Tags . . . . . . . . . . . . . . . . . . . 32 4.6. Message Body Tags . . . . . . . . . . . . . . . . . . . 33
4.7. Media Properties . . . . . . . . . . . . . . . . . . . . 33 4.7. Media Properties . . . . . . . . . . . . . . . . . . . . 34
4.7.1. Random Access and Seeking . . . . . . . . . . . . . 34 4.7.1. Random Access and Seeking . . . . . . . . . . . . . 34
4.7.2. Retention . . . . . . . . . . . . . . . . . . . . . 34 4.7.2. Retention . . . . . . . . . . . . . . . . . . . . . 35
4.7.3. Content Modifications . . . . . . . . . . . . . . . 34 4.7.3. Content Modifications . . . . . . . . . . . . . . . 35
4.7.4. Supported Scale Factors . . . . . . . . . . . . . . 35 4.7.4. Supported Scale Factors . . . . . . . . . . . . . . 36
4.7.5. Mapping to the Attributes . . . . . . . . . . . . . 35 4.7.5. Mapping to the Attributes . . . . . . . . . . . . . 36
5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 36 5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 36 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 37
5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 37 5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 38
5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 37 5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 38
5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 38 5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 39
6. General Header Fields . . . . . . . . . . . . . . . . . . . . 39 6. General Header Fields . . . . . . . . . . . . . . . . . . . . 40
7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 41 7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 42
7.2. Request Header Fields . . . . . . . . . . . . . . . . . 43 7.2. Request Header Fields . . . . . . . . . . . . . . . . . 44
8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 45 8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 45 8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 46
8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 45 8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 46
8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 49 8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 50
9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 50 9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 51
9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 50 9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 51
9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 51 9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 52
9.3. Message Body Format Negotiation . . . . . . . . . . . . 52 9.3. Message Body Format Negotiation . . . . . . . . . . . . 53
10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 53 10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 54
10.1. Reliability and Acknowledgements . . . . . . . . . . . . 53 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 54
10.2. Using Connections . . . . . . . . . . . . . . . . . . . 54 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 55
10.3. Closing Connections . . . . . . . . . . . . . . . . . . 57 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 58
10.4. Timing Out Connections and RTSP Messages . . . . . . . . 58 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 59
10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 59 10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 60
10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 60 10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 61
10.7. Overload Control . . . . . . . . . . . . . . . . . . . . 61 10.7. Overload Control . . . . . . . . . . . . . . . . . . . . 62
11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 63 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 64
11.1. Feature Tag: play.basic . . . . . . . . . . . . . . . . 64 11.1. Feature Tag: play.basic . . . . . . . . . . . . . . . . 65
12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 66 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 67
13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 67 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 68
13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 68 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 69
13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 69 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 70
13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 71 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 72
13.3.1. Changing Transport Parameters . . . . . . . . . . . 74 13.3.1. Changing Transport Parameters . . . . . . . . . . . 75
13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 75 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 76
13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 75 13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 76
13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 80 13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 81
13.4.3. Updating current PLAY Requests . . . . . . . . . . . 81 13.4.3. Updating current PLAY Requests . . . . . . . . . . . 82
13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 83 13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 84
13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 84 13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 85
13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 84 13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 85
13.4.7. Playing Live with Recording . . . . . . . . . . . . 85 13.4.7. Playing Live with Recording . . . . . . . . . . . . 86
13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 85 13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 86
13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 86 13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 87
13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 87 13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 88
13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 89 13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 90
13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 90 13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 91
13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 91 13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 92
13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 94 13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 95
13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 94 13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 95
13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 95 13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 96
13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 96 13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 97
13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 98 13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 99
13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 100 13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 101
14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 103 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 104
15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
15.1. Proxies and Protocol Extensions . . . . . . . . . . . . 106 15.1. Proxies and Protocol Extensions . . . . . . . . . . . . 107
15.2. Multiplexing and Demultiplexing of Messages . . . . . . 107 15.2. Multiplexing and Demultiplexing of Messages . . . . . . 108
16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
16.1. Validation Model . . . . . . . . . . . . . . . . . . . . 108 16.1. Validation Model . . . . . . . . . . . . . . . . . . . . 109
16.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 110 16.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 111
16.1.2. Message Body Tag Cache Validators . . . . . . . . . 110 16.1.2. Message Body Tag Cache Validators . . . . . . . . . 111
16.1.3. Weak and Strong Validators . . . . . . . . . . . . . 110 16.1.3. Weak and Strong Validators . . . . . . . . . . . . . 111
16.1.4. Rules for When to Use Message Body Tags and 16.1.4. Rules for When to Use Message Body Tags and
Last-Modified Dates . . . . . . . . . . . . . . . . 112 Last-Modified Dates . . . . . . . . . . . . . . . . 113
16.1.5. Non-validating Conditionals . . . . . . . . . . . . 114 16.1.5. Non-validating Conditionals . . . . . . . . . . . . 115
16.2. Invalidation After Updates or Deletions . . . . . . . . 114 16.2. Invalidation After Updates or Deletions . . . . . . . . 115
17. Status Code Definitions . . . . . . . . . . . . . . . . . . . 116 17. Status Code Definitions . . . . . . . . . . . . . . . . . . . 117
17.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 116 17.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 117
17.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 116 17.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 117
17.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 116 17.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 117
17.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 116 17.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 117
17.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 116 17.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 117
17.3.1. 300 . . . . . . . . . . . . . . . . . . . . . . . . 117 17.3.1. 300 . . . . . . . . . . . . . . . . . . . . . . . . 118
17.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 117 17.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 118
17.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 117 17.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 118
17.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 118 17.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 119
17.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 118 17.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 119
17.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 118 17.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 119
17.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 118 17.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 119
17.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 118 17.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 119
17.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 119 17.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 120
17.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 119 17.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 120
17.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 119 17.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 120
17.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 119 17.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 120
17.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 119 17.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 120
17.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 120 17.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 121
17.4.8. 407 Proxy Authentication Required . . . . . . . . . 120 17.4.8. 407 Proxy Authentication Required . . . . . . . . . 121
17.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 120 17.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 121
17.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 120 17.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 121
17.4.11. 412 Precondition Failed . . . . . . . . . . . . . . 121 17.4.11. 411 Length Required . . . . . . . . . . . . . . . . 122
17.4.12. 413 Request Message Body Too Large . . . . . . . . . 121 17.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 122
17.4.13. 414 Request-URI Too Long . . . . . . . . . . . . . . 121 17.4.13. 413 Request Message Body Too Large . . . . . . . . . 122
17.4.14. 415 Unsupported Media Type . . . . . . . . . . . . . 121 17.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 122
17.4.15. 451 Parameter Not Understood . . . . . . . . . . . . 121 17.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 122
17.4.16. 452 reserved . . . . . . . . . . . . . . . . . . . . 122 17.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 123
17.4.17. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 122 17.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 123
17.4.18. 454 Session Not Found . . . . . . . . . . . . . . . 122 17.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 123
17.4.19. 455 Method Not Valid in This State . . . . . . . . . 122 17.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 123
17.4.20. 456 Header Field Not Valid for Resource . . . . . . 122 17.4.20. 455 Method Not Valid in This State . . . . . . . . . 123
17.4.21. 457 Invalid Range . . . . . . . . . . . . . . . . . 122 17.4.21. 456 Header Field Not Valid for Resource . . . . . . 123
17.4.22. 458 Parameter Is Read-Only . . . . . . . . . . . . . 122 17.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 123
17.4.23. 459 Aggregate Operation Not Allowed . . . . . . . . 123 17.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 124
17.4.24. 460 Only Aggregate Operation Allowed . . . . . . . . 123 17.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 124
17.4.25. 461 Unsupported Transport . . . . . . . . . . . . . 123 17.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 124
17.4.26. 462 Destination Unreachable . . . . . . . . . . . . 123 17.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 124
17.4.27. 463 Destination Prohibited . . . . . . . . . . . . . 123 17.4.27. 462 Destination Unreachable . . . . . . . . . . . . 124
17.4.28. 464 Data Transport Not Ready Yet . . . . . . . . . . 123 17.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 124
17.4.29. 465 Notification Reason Unknown . . . . . . . . . . 124 17.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 124
17.4.30. 466 Key Management Error . . . . . . . . . . . . . . 124 17.4.30. 465 Notification Reason Unknown . . . . . . . . . . 125
17.4.31. 470 Connection Authorization Required . . . . . . . 124 17.4.31. 466 Key Management Error . . . . . . . . . . . . . . 125
17.4.32. 471 Connection Credentials not accepted . . . . . . 124 17.4.32. 470 Connection Authorization Required . . . . . . . 125
17.4.33. 472 Failure to establish secure connection . . . . . 124 17.4.33. 471 Connection Credentials not accepted . . . . . . 125
17.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 124 17.4.34. 472 Failure to establish secure connection . . . . . 125
17.5.1. 500 Internal Server Error . . . . . . . . . . . . . 124
17.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 125
17.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 125
17.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 125
17.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 125
17.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 125
17.5.7. 551 Option not supported . . . . . . . . . . . . . . 126
17.5.8. 553 Proxy Unavailable . . . . . . . . . . . . . . . 126
18. Header Field Definitions . . . . . . . . . . . . . . . . . . 127
18.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 137
18.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 138
18.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 138
18.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 139
18.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 140
18.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 141
18.7. Authentication-Info . . . . . . . . . . . . . . . . . . 141
18.8. Authorization . . . . . . . . . . . . . . . . . . . . . 141
18.9. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 142
18.10. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 143
18.11. Cache-Control . . . . . . . . . . . . . . . . . . . . . 143
18.12. Connection . . . . . . . . . . . . . . . . . . . . . . . 146
18.13. Connection-Credentials . . . . . . . . . . . . . . . . . 146
18.14. Content-Base . . . . . . . . . . . . . . . . . . . . . . 147
18.15. Content-Encoding . . . . . . . . . . . . . . . . . . . . 148
18.16. Content-Language . . . . . . . . . . . . . . . . . . . . 148
18.17. Content-Length . . . . . . . . . . . . . . . . . . . . . 149
18.18. Content-Location . . . . . . . . . . . . . . . . . . . . 149
18.19. Content-Type . . . . . . . . . . . . . . . . . . . . . . 150
18.20. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 151
18.21. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 152
18.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 153
18.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 154
18.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 155
18.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 155
18.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 155
18.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 156
18.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 157
18.29. Media-Properties . . . . . . . . . . . . . . . . . . . . 157
18.30. Media-Range . . . . . . . . . . . . . . . . . . . . . . 159
18.31. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 160
18.32. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 160
18.33. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 160
18.34. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 161
18.35. Proxy-Authentication-Info . . . . . . . . . . . . . . . 162
18.36. Proxy-Authorization . . . . . . . . . . . . . . . . . . 162
18.37. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 162
18.38. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 162
18.39. Public . . . . . . . . . . . . . . . . . . . . . . . . . 163
18.40. Range . . . . . . . . . . . . . . . . . . . . . . . . . 164
18.41. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 166
18.42. Request-Status . . . . . . . . . . . . . . . . . . . . . 166
18.43. Require . . . . . . . . . . . . . . . . . . . . . . . . 167
18.44. Retry-After . . . . . . . . . . . . . . . . . . . . . . 168
18.45. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 168
18.46. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 170
18.47. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 171
18.48. Server . . . . . . . . . . . . . . . . . . . . . . . . . 173
18.49. Session . . . . . . . . . . . . . . . . . . . . . . . . 173
18.50. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 175
18.51. Supported . . . . . . . . . . . . . . . . . . . . . . . 176
18.52. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 176
18.53. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 177
18.54. Transport . . . . . . . . . . . . . . . . . . . . . . . 177
18.55. Unsupported . . . . . . . . . . . . . . . . . . . . . . 184
18.56. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 185
18.57. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 185
18.58. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 186
19. Security Framework . . . . . . . . . . . . . . . . . . . . . 187
19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 187
19.1.1. Digest Authentication . . . . . . . . . . . . . . . 188
19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 188
19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 189
19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 191
19.3.2. User approved TLS procedure . . . . . . . . . . . . 192
20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 194
20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 196
20.2.1. Generic Protocol elements . . . . . . . . . . . . . 196
20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 199
20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 203
20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 212
21. Security Considerations . . . . . . . . . . . . . . . . . . . 213
21.1. Signaling Protocol Threats . . . . . . . . . . . . . . . 213
21.2. Media Stream Delivery Threats . . . . . . . . . . . . . 216
21.2.1. Remote Denial of Service Attack . . . . . . . . . . 217
21.2.2. RTP Security analysis . . . . . . . . . . . . . . . 218
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 220
22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 221
22.1.1. Description . . . . . . . . . . . . . . . . . . . . 221
22.1.2. Registering New Feature-tags with IANA . . . . . . . 221
22.1.3. Registered entries . . . . . . . . . . . . . . . . . 221
22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 222
22.2.1. Description . . . . . . . . . . . . . . . . . . . . 222
22.2.2. Registering New Methods with IANA . . . . . . . . . 222
22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 222
22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 223
22.3.1. Description . . . . . . . . . . . . . . . . . . . . 223
22.3.2. Registering New Status Codes with IANA . . . . . . . 223
22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 223
22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 223
22.4.1. Description . . . . . . . . . . . . . . . . . . . . 224
22.4.2. Registering New Headers with IANA . . . . . . . . . 224
22.4.3. Registered entries . . . . . . . . . . . . . . . . . 224
22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 226
22.5.1. Accept-Credentials policies . . . . . . . . . . . . 226
22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 226
22.6. Cache-Control Cache Directive Extensions . . . . . . . . 227
22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 227
22.7.1. Description . . . . . . . . . . . . . . . . . . . . 228
22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 228
22.7.3. Registered Values . . . . . . . . . . . . . . . . . 228
22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 228
22.8.1. Description . . . . . . . . . . . . . . . . . . . . 228
22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 229
22.8.3. Registered Values . . . . . . . . . . . . . . . . . 229
22.9. Range Header Formats . . . . . . . . . . . . . . . . . . 229
22.9.1. Description . . . . . . . . . . . . . . . . . . . . 229
22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 230
22.9.3. Registered Values . . . . . . . . . . . . . . . . . 230
22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 230
22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 230
22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 231
22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 231
22.11.1. Description . . . . . . . . . . . . . . . . . . . . 231
22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 231
22.11.3. Registered Values . . . . . . . . . . . . . . . . . 232
22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 232
22.12.1. Description . . . . . . . . . . . . . . . . . . . . 232
22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 232
22.12.3. Registered Values . . . . . . . . . . . . . . . . . 232
22.13. Transport Header Registries . . . . . . . . . . . . . . 233
22.13.1. Transport Protocol Identifier . . . . . . . . . . . 233
22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 235
22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 235
22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 236
22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 236
22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 237
22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 239
22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 239
22.16. Media Type Registration for text/parameters . . . . . . 240
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 242
23.1. Normative References . . . . . . . . . . . . . . . . . . 242
23.2. Informative References . . . . . . . . . . . . . . . . . 245
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 247
A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 247
A.2. Media on Demand using Pipelining . . . . . . . . . . . . 251
A.3. Secured Media Session for on Demand Content . . . . . . 253
A.4. Media on Demand (Unicast) . . . . . . . . . . . . . . . 256
A.5. Single Stream Container Files . . . . . . . . . . . . . 260
A.6. Live Media Presentation Using Multicast . . . . . . . . 262
A.7. Capability Negotiation . . . . . . . . . . . . . . . . . 263
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 265
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 265
B.2. State variables . . . . . . . . . . . . . . . . . . . . 265
B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 266
B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 266
Appendix C. Media Transport Alternatives . . . . . . . . . . . . 273
C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 273
C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 273
C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 273
C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 275
C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 275
C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 278
C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 278
C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 280
C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 280
C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 280
C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 284
C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 288
C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 290
C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 290
C.7. Maintaining NPT synchronization with RTP timestamps . . 290
C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 290
C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 290
C.10. Usage of SSRCs and the RTCP BYE Message During an
RTSP Session . . . . . . . . . . . . . . . . . . . . . . 290
C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 291
Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 292
D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 292
D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 292
D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 293
D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 294
D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 294
D.1.5. Directionality of media stream . . . . . . . . . . . 294
D.1.6. Range of Presentation . . . . . . . . . . . . . . . 295
D.1.7. Time of Availability . . . . . . . . . . . . . . . . 296
D.1.8. Connection Information . . . . . . . . . . . . . . . 296
D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 297
D.2. Aggregate Control Not Available . . . . . . . . . . . . 297
D.3. Aggregate Control Available . . . . . . . . . . . . . . 298
D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 299
D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 299
Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 300 17.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 125
E.1. On-demand Playback of Stored Content . . . . . . . . . . 300 17.5.1. 500 Internal Server Error . . . . . . . . . . . . . 126
E.2. Unicast Distribution of Live Content . . . . . . . . . . 301 17.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 126
E.3. On-demand Playback using Multicast . . . . . . . . . . . 302 17.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 126
E.4. Inviting an RTSP server into a conference . . . . . . . 302 17.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 126
E.5. Live Content using Multicast . . . . . . . . . . . . . . 303 17.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 126
Appendix F. Text format for Parameters . . . . . . . . . . . . . 305 17.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 127
Appendix G. Requirements for Unreliable Transport of RTSP . . . 306 17.5.7. 551 Option not supported . . . . . . . . . . . . . . 127
Appendix H. Backwards Compatibility Considerations . . . . . . . 308 17.5.8. 553 Proxy Unavailable . . . . . . . . . . . . . . . 127
H.1. Play Request in Play State . . . . . . . . . . . . . . . 308 18. Header Field Definitions . . . . . . . . . . . . . . . . . . 128
H.2. Using Persistent Connections . . . . . . . . . . . . . . 308 18.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 138
Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 309 18.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 139
I.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 309 18.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 140
I.2. Detailed List of Changes . . . . . . . . . . . . . . . . 310 18.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 140
Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 317 18.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 141
J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 317 18.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 142
Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 319 18.7. Authentication-Info . . . . . . . . . . . . . . . . . . 142
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 320 18.8. Authorization . . . . . . . . . . . . . . . . . . . . . 142
18.9. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 143
18.10. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 144
18.11. Cache-Control . . . . . . . . . . . . . . . . . . . . . 144
18.12. Connection . . . . . . . . . . . . . . . . . . . . . . . 147
18.13. Connection-Credentials . . . . . . . . . . . . . . . . . 147
18.14. Content-Base . . . . . . . . . . . . . . . . . . . . . . 148
18.15. Content-Encoding . . . . . . . . . . . . . . . . . . . . 149
18.16. Content-Language . . . . . . . . . . . . . . . . . . . . 149
18.17. Content-Length . . . . . . . . . . . . . . . . . . . . . 150
18.18. Content-Location . . . . . . . . . . . . . . . . . . . . 150
18.19. Content-Type . . . . . . . . . . . . . . . . . . . . . . 151
18.20. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 152
18.21. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 153
18.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 154
18.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 155
18.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 156
18.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 156
18.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 156
18.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 157
18.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 158
18.29. Media-Properties . . . . . . . . . . . . . . . . . . . . 158
18.30. Media-Range . . . . . . . . . . . . . . . . . . . . . . 160
18.31. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 161
18.32. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 161
18.33. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 161
18.34. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 162
18.35. Proxy-Authentication-Info . . . . . . . . . . . . . . . 163
18.36. Proxy-Authorization . . . . . . . . . . . . . . . . . . 163
18.37. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 163
18.38. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 164
18.39. Public . . . . . . . . . . . . . . . . . . . . . . . . . 164
18.40. Range . . . . . . . . . . . . . . . . . . . . . . . . . 165
18.41. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 167
18.42. Request-Status . . . . . . . . . . . . . . . . . . . . . 168
18.43. Require . . . . . . . . . . . . . . . . . . . . . . . . 168
18.44. Retry-After . . . . . . . . . . . . . . . . . . . . . . 169
18.45. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 169
18.46. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 171
18.47. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 172
18.48. Server . . . . . . . . . . . . . . . . . . . . . . . . . 174
18.49. Session . . . . . . . . . . . . . . . . . . . . . . . . 174
18.50. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 176
18.51. Supported . . . . . . . . . . . . . . . . . . . . . . . 177
18.52. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 177
18.53. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 178
18.54. Transport . . . . . . . . . . . . . . . . . . . . . . . 178
18.55. Unsupported . . . . . . . . . . . . . . . . . . . . . . 186
18.56. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 186
18.57. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 186
18.58. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 187
19. Security Framework . . . . . . . . . . . . . . . . . . . . . 188
19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 188
19.1.1. Digest Authentication . . . . . . . . . . . . . . . 189
19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 189
19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 190
19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 192
19.3.2. User approved TLS procedure . . . . . . . . . . . . 193
20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 195
20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 197
20.2.1. Generic Protocol elements . . . . . . . . . . . . . 197
20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 200
20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 204
20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 213
21. Security Considerations . . . . . . . . . . . . . . . . . . . 214
21.1. Signaling Protocol Threats . . . . . . . . . . . . . . . 214
21.2. Media Stream Delivery Threats . . . . . . . . . . . . . 217
21.2.1. Remote Denial of Service Attack . . . . . . . . . . 218
21.2.2. RTP Security analysis . . . . . . . . . . . . . . . 219
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 221
22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 222
22.1.1. Description . . . . . . . . . . . . . . . . . . . . 222
22.1.2. Registering New Feature-tags with IANA . . . . . . . 222
22.1.3. Registered entries . . . . . . . . . . . . . . . . . 222
22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 223
22.2.1. Description . . . . . . . . . . . . . . . . . . . . 223
22.2.2. Registering New Methods with IANA . . . . . . . . . 223
22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 223
22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 224
22.3.1. Description . . . . . . . . . . . . . . . . . . . . 224
22.3.2. Registering New Status Codes with IANA . . . . . . . 224
22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 224
22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 224
22.4.1. Description . . . . . . . . . . . . . . . . . . . . 225
22.4.2. Registering New Headers with IANA . . . . . . . . . 225
22.4.3. Registered entries . . . . . . . . . . . . . . . . . 225
22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 227
22.5.1. Accept-Credentials policies . . . . . . . . . . . . 227
22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 227
22.6. Cache-Control Cache Directive Extensions . . . . . . . . 228
22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 228
22.7.1. Description . . . . . . . . . . . . . . . . . . . . 229
22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 229
22.7.3. Registered Values . . . . . . . . . . . . . . . . . 229
22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 229
22.8.1. Description . . . . . . . . . . . . . . . . . . . . 229
22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 230
22.8.3. Registered Values . . . . . . . . . . . . . . . . . 230
22.9. Range Header Formats . . . . . . . . . . . . . . . . . . 230
22.9.1. Description . . . . . . . . . . . . . . . . . . . . 230
22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 231
22.9.3. Registered Values . . . . . . . . . . . . . . . . . 231
22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 231
22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 231
22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 232
22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 232
22.11.1. Description . . . . . . . . . . . . . . . . . . . . 232
22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 232
22.11.3. Registered Values . . . . . . . . . . . . . . . . . 233
22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 233
22.12.1. Description . . . . . . . . . . . . . . . . . . . . 233
22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 233
22.12.3. Registered Values . . . . . . . . . . . . . . . . . 233
22.13. Transport Header Registries . . . . . . . . . . . . . . 234
22.13.1. Transport Protocol Identifier . . . . . . . . . . . 234
22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 236
22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 236
22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 237
22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 237
22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 238
22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 240
22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 240
22.16. Media Type Registration for text/parameters . . . . . . 241
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 243
23.1. Normative References . . . . . . . . . . . . . . . . . . 243
23.2. Informative References . . . . . . . . . . . . . . . . . 246
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 249
A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 249
A.2. Media on Demand using Pipelining . . . . . . . . . . . . 253
A.3. Secured Media Session for on Demand Content . . . . . . 255
A.4. Media on Demand (Unicast) . . . . . . . . . . . . . . . 258
A.5. Single Stream Container Files . . . . . . . . . . . . . 262
A.6. Live Media Presentation Using Multicast . . . . . . . . 264
A.7. Capability Negotiation . . . . . . . . . . . . . . . . . 265
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 267
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 267
B.2. State variables . . . . . . . . . . . . . . . . . . . . 267
B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 268
B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 268
Appendix C. Media Transport Alternatives . . . . . . . . . . . . 275
C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 275
C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 275
C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 275
C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 277
C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 277
C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 280
C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 280
C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 282
C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 282
C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 282
C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 286
C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 290
C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 292
C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 292
C.7. Maintaining NPT synchronization with RTP timestamps . . 292
C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 292
C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 292
C.10. Usage of SSRCs and the RTCP BYE Message During an
RTSP Session . . . . . . . . . . . . . . . . . . . . . . 292
C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 293
Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 294
D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 294
D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 294
D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 295
D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 296
D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 296
D.1.5. Directionality of media stream . . . . . . . . . . . 296
D.1.6. Range of Presentation . . . . . . . . . . . . . . . 297
D.1.7. Time of Availability . . . . . . . . . . . . . . . . 298
D.1.8. Connection Information . . . . . . . . . . . . . . . 298
D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 299
D.2. Aggregate Control Not Available . . . . . . . . . . . . 299
D.3. Aggregate Control Available . . . . . . . . . . . . . . 300
D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 301
D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 301
Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 302
E.1. On-demand Playback of Stored Content . . . . . . . . . . 302
E.2. Unicast Distribution of Live Content . . . . . . . . . . 303
E.3. On-demand Playback using Multicast . . . . . . . . . . . 304
E.4. Inviting an RTSP server into a conference . . . . . . . 304
E.5. Live Content using Multicast . . . . . . . . . . . . . . 305
Appendix F. Text format for Parameters . . . . . . . . . . . . . 307
Appendix G. Requirements for Unreliable Transport of RTSP . . . 308
Appendix H. Backwards Compatibility Considerations . . . . . . . 310
H.1. Play Request in Play State . . . . . . . . . . . . . . . 310
H.2. Using Persistent Connections . . . . . . . . . . . . . . 310
Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 311
I.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 311
I.2. Detailed List of Changes . . . . . . . . . . . . . . . . 312
Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 319
J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 319
Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 321
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 322
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 13, line 26 skipping to change at page 13, line 26
then controls the delivery of these content resources from the then controls the delivery of these content resources from the
provider to the consumer. RTSP has three fundamental parts: Session provider to the consumer. RTSP has three fundamental parts: Session
Establishment, Media Delivery Control, and an extensibility model Establishment, Media Delivery Control, and an extensibility model
described below. The protocol is based on some assumptions about described below. The protocol is based on some assumptions about
existing functionality to provide a complete solution for client existing functionality to provide a complete solution for client
controlled real-time media delivery. controlled real-time media delivery.
RTSP uses text-based messages, requests and responses, that may RTSP uses text-based messages, requests and responses, that may
contain a binary message body. An RTSP request starts with a method contain a binary message body. An RTSP request starts with a method
line that identifies the method, the protocol and version and the line that identifies the method, the protocol and version and the
resource to act on. The resource is identified by an URI and the resource to act on. The resource is identified by a URI and the
hostname part of the URI is used by RTSP client to resolve the IPv4 hostname part of the URI is used by RTSP client to resolve the IPv4
or IPv6 address of the RTSP server. Following the method line are a or IPv6 address of the RTSP server. Following the method line are a
number of RTSP headers. This part is ended by two consecutive number of RTSP headers. This part is ended by two consecutive
carriage return line feed (CRLF) character pairs. The message body carriage return line feed (CRLF) character pairs. The message body
if present follows the two CRLF and the body's length is described by if present follows the two CRLF and the body's length is described by
a message header. RTSP responses are similar, but start with a a message header. RTSP responses are similar, but start with a
response line with the protocol and version, followed by a status response line with the protocol and version, followed by a status
code and a reason phrase. RTSP messages are sent over a reliable code and a reason phrase. RTSP messages are sent over a reliable
transport protocol between the client and server. RTSP 2.0 requires transport protocol between the client and server. RTSP 2.0 requires
clients and servers to implement TCP, and TLS over TCP, as mandatory clients and servers to implement TCP, and TLS over TCP, as mandatory
skipping to change at page 17, line 43 skipping to change at page 17, line 43
either the client or the server: GET_PARAMETER (Section 13.8) and either the client or the server: GET_PARAMETER (Section 13.8) and
SET_PARAMETER (Section 13.9). These methods carry the parameters in SET_PARAMETER (Section 13.9). These methods carry the parameters in
a message body of the appropriate format. One can also use headers a message body of the appropriate format. One can also use headers
to query state with the GET_PARAMETER method. As an example, clients to query state with the GET_PARAMETER method. As an example, clients
needing to know the current media-range for a time-progressing needing to know the current media-range for a time-progressing
session can use the GET_PARAMETER method and include the media-range. session can use the GET_PARAMETER method and include the media-range.
Furthermore, synchronization information can be requested by using a Furthermore, synchronization information can be requested by using a
combination of RTP-Info (Section 18.45) and Range (Section 18.40). combination of RTP-Info (Section 18.45) and Range (Section 18.40).
RTSP 2.0 does not have a strong mechanism for providing negotiation RTSP 2.0 does not have a strong mechanism for providing negotiation
of the headers, or parameters and their formats, which can be used. of the headers, or parameters and their formats, that can be used.
However, responses will indicate request headers or parameters that However, responses will indicate request-headers or parameters that
are not supported. A priori determination of what features are are not supported. A priori determination of what features are
available needs to be done through out-of-band mechanisms, like the available needs to be done through out-of-band mechanisms, like the
session description, or through the usage of feature tags session description, or through the usage of feature tags
(Section 4.5). (Section 4.5).
2.5. Media Delivery 2.5. Media Delivery
The delivery of media to the RTSP client is done with a protocol The delivery of media to the RTSP client is done with a protocol
outside of RTSP and this protocol is determined during the session outside of RTSP and this protocol is determined during the session
establishment. This document specifies how media is delivered with establishment. This document specifies how media is delivered with
skipping to change at page 22, line 32 skipping to change at page 22, line 32
recipient. If the client needs negative acknowledgment when a recipient. If the client needs negative acknowledgment when a
method extension is not supported, a tag corresponding to the method extension is not supported, a tag corresponding to the
extension may be added in the field of the Require or Proxy- extension may be added in the field of the Require or Proxy-
Require headers. Require headers.
o New methods can be added. If the recipient of the message does o New methods can be added. If the recipient of the message does
not understand the request, it must respond with error code 501 not understand the request, it must respond with error code 501
(Not Implemented) so that the sender can avoid using this method (Not Implemented) so that the sender can avoid using this method
again. A client may also use the OPTIONS method to inquire about again. A client may also use the OPTIONS method to inquire about
methods supported by the server. The server must list the methods methods supported by the server. The server must list the methods
it supports using the Public response header. it supports using the Public response-header.
o A new version of the protocol can be defined, allowing almost all o A new version of the protocol can be defined, allowing almost all
aspects (except the position of the protocol version number) to aspects (except the position of the protocol version number) to
change. A new version of the protocol must be registered through change. A new version of the protocol must be registered through
an IETF standards track document. an IETF standards track document.
The basic capability discovery mechanism can be used to both discover The basic capability discovery mechanism can be used to both discover
support for a certain feature and to ensure that a feature is support for a certain feature and to ensure that a feature is
available when performing a request. For a detailed explanation of available when performing a request. For a detailed explanation of
this see Section 11. this see Section 11.
skipping to change at page 24, line 22 skipping to change at page 24, line 22
source and sink; that is, the sink needs to reproduce the timing source and sink; that is, the sink needs to reproduce the timing
relationship that existed at the source. The most common examples relationship that existed at the source. The most common examples
of continuous media are audio and motion video. Continuous media of continuous media are audio and motion video. Continuous media
can be real-time (interactive or conversational), where there is a can be real-time (interactive or conversational), where there is a
"tight" timing relationship between source and sink, or streaming "tight" timing relationship between source and sink, or streaming
where the relationship is less strict. where the relationship is less strict.
Feature-tag: A tag representing a certain set of functionality, Feature-tag: A tag representing a certain set of functionality,
i.e., a feature. i.e., a feature.
IRI: Internationalized Resource Identifier, is the same as an URI, IRI: Internationalized Resource Identifier, is the same as a URI,
with the exception that it allows characters from the whole with the exception that it allows characters from the whole
Universal Character Set (Unicode/ISO 10646), rather than the US- Universal Character Set (Unicode/ISO 10646), rather than the US-
ASCII only. See [RFC3987] for more information. ASCII only. See [RFC3987] for more information.
Live: Normally used to describe a presentation or session with media Live: Normally used to describe a presentation or session with media
coming from an ongoing event. This generally results in the coming from an ongoing event. This generally results in the
session having an unbound or only loosely defined duration, and session having an unbound or only loosely defined duration, and
sometimes no seek operations are possible. sometimes no seek operations are possible.
Media initialization: Datatype/codec specific initialization. This Media initialization: Datatype/codec specific initialization. This
skipping to change at page 26, line 24 skipping to change at page 26, line 24
Transport initialization: The negotiation of transport information Transport initialization: The negotiation of transport information
(e.g., port numbers, transport protocols) between the client and (e.g., port numbers, transport protocols) between the client and
the server. the server.
URI: Universal Resource Identifier, see [RFC3986]. The URIs used in URI: Universal Resource Identifier, see [RFC3986]. The URIs used in
RTSP are generally URLs as they give a location for the resource. RTSP are generally URLs as they give a location for the resource.
As URLs are a subset of URIs, they will be referred to as URIs to As URLs are a subset of URIs, they will be referred to as URIs to
cover also the cases when an RTSP URI would not be an URL. cover also the cases when an RTSP URI would not be an URL.
URL: Universal Resource Locator, is an URI which identifies the URL: Universal Resource Locator, is a URI which identifies the
resource through its primary access mechanism, rather than resource through its primary access mechanism, rather than
identifying the resource by name or by some other attribute(s) of identifying the resource by name or by some other attribute(s) of
that resource. that resource.
4. Protocol Parameters 4. Protocol Parameters
4.1. RTSP Version 4.1. RTSP Version
This specification defines version 2.0 of RTSP. This specification defines version 2.0 of RTSP.
skipping to change at page 27, line 29 skipping to change at page 27, line 29
The <minor> number is incremented when the changes made to the The <minor> number is incremented when the changes made to the
protocol add features which do not change the general message parsing protocol add features which do not change the general message parsing
algorithm, but which may add to the message semantics and imply algorithm, but which may add to the message semantics and imply
additional capabilities of the sender. The <major> number is additional capabilities of the sender. The <major> number is
incremented when the format of a message within the protocol is incremented when the format of a message within the protocol is
changed. The version of an RTSP message is indicated by an RTSP- changed. The version of an RTSP message is indicated by an RTSP-
Version field in the first line of the message. Note that the major Version field in the first line of the message. Note that the major
and minor numbers MUST be treated as separate integers and that each and minor numbers MUST be treated as separate integers and that each
MAY be incremented higher than a single digit. Thus, RTSP/2.4 is a MAY be incremented higher than a single digit. Thus, RTSP/2.4 is a
lower version than RTSP/2.13, which in turn is lower than RTSP/12.3. lower version than RTSP/2.13, which in turn is lower than RTSP/12.3.
Leading zeros MUST be ignored by recipients and MUST NOT be sent. Leading zeros SHALL NOT be sent and MUST be ignored by recipients.
4.2. RTSP IRI and URI 4.2. RTSP IRI and URI
RTSP 2.0 defines and registers or updates three URI schemes "rtsp", RTSP 2.0 defines and registers or updates three URI schemes "rtsp",
"rtsps" and "rtspu". The usage of the last, "rtspu", is unspecified "rtsps" and "rtspu". The usage of the last, "rtspu", is unspecified
in RTSP 2.0, and is defined here to register the URI scheme that was in RTSP 2.0, and is defined here to register the URI scheme that was
defined in RTSP 1.0. The "rtspu" scheme indicates unspecified defined in RTSP 1.0. The "rtspu" scheme indicates unspecified
transport of the RTSP messages over unreliable transport (UDP in RTSP transport of the RTSP messages over unreliable transport (UDP in RTSP
1.0). An RTSP server MUST respond with an error code indicating the 1.0). An RTSP server MUST respond with an error code indicating the
"rtspu" scheme is not implemented (501) to a request that carries a "rtspu" scheme is not implemented (501) to a request that carries a
skipping to change at page 28, line 13 skipping to change at page 28, line 13
one is required to use IPv6 literals to reach an RTSP server, then one is required to use IPv6 literals to reach an RTSP server, then
that RTSP server must be IPv6 capable, and RTSP 1.0 is not a fully that RTSP server must be IPv6 capable, and RTSP 1.0 is not a fully
IPv6 capable protocol. If an RTSP 1.0 client attempts to process the IPv6 capable protocol. If an RTSP 1.0 client attempts to process the
URI it will not match the allowed syntax and be considered invalid URI it will not match the allowed syntax and be considered invalid
and processing will be stopped. This is clearly a failure to reach and processing will be stopped. This is clearly a failure to reach
the resource, however it is not a signification issue as RTSP 2.0 the resource, however it is not a signification issue as RTSP 2.0
support was needed anyway in both server and client. Thus failure support was needed anyway in both server and client. Thus failure
will only occur in a later step when there is a RTSP version mismatch will only occur in a later step when there is a RTSP version mismatch
between client and server. The second change will only occur inside between client and server. The second change will only occur inside
RTSP message headers, as the request URI must be an absolute URI. RTSP message headers, as the request URI must be an absolute URI.
Thus such usages are occurring after agents has accepted processing Thus such usages will only occur after an agent has accepted and
RTSP 2.0 messages, and an RTSP 1.0 only agent will not be required to started processing RTSP 2.0 messages, and an RTSP 1.0 only agent will
parse such types of relative URIs. not be required to parse such types of relative URIs.
This specification also defines the format of the RTSP IRI [RFC3987] This specification also defines the format of the RTSP IRI [RFC3987]
that can be used as RTSP resource identifiers and locators, in web that can be used as RTSP resource identifiers and locators, in web
pages, user interfaces, on paper, etc. However, the RTSP request pages, user interfaces, on paper, etc. However, the RTSP request
message format only allows usage of the absolute URI format. The message format only allows usage of the absolute URI format. The
RTSP IRI format MUST use the rules and transformation for IRIs to RTSP IRI format MUST use the rules and transformation for IRIs to
URIs, as defined in [RFC3987]. This allows a URI that matches the URIs, as defined in [RFC3987]. This allows a URI that matches the
RTSP 2.0 specification, and so is suitable for use in a request, to RTSP 2.0 specification, and so is suitable for use in a request, to
be created from an RTSP IRI. be created from an RTSP IRI.
skipping to change at page 30, line 25 skipping to change at page 30, line 25
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. Media Time Formats 4.4. Media Time Formats
RTSP currently supports three different media time formats defined RTSP currently supports three different media time formats defined
below. Additional time formats may be specified in the future. below. Additional time formats may be specified in the future.
These time formats can be used with the Range header (Section 18.40) These time formats can be used with the Range header (Section 18.40)
to request playback and specify at which media position protocol to request playback and specify at which media position protocol
requests actually will or has taken place. They are also used in requests actually will or have taken place. They are also used in
description of the media's properties using the Media-Range header description of the media's properties using the Media-Range header
(Section 18.30). The format identifier only are used in Accept- (Section 18.30). The unqualified format identifier is used on its
Ranges header (Section 18.5) to declare supported time formats and own in Accept-Ranges header (Section 18.5) to declare supported time
also in the Range header (Section 18.40) to request the time format formats and also in the Range header (Section 18.40) to request the
used in the response. time format used in the response.
4.4.1. SMPTE Relative Timestamps 4.4.1. SMPTE Relative Timestamps
A Society of Motion Picture and Television Engineers (SMPTE) relative A Society of Motion Picture and Television Engineers (SMPTE) relative
timestamp expresses time relative to the start of the clip. Relative timestamp expresses time relative to the start of the clip. Relative
timestamps are expressed as SMPTE time codes [SMPTE_TC] for frame- timestamps are expressed as SMPTE time codes [SMPTE_TC] for frame-
level access accuracy. The time code has the format level access accuracy. The time code has the format
hours:minutes:seconds:frames.subframes, hours:minutes:seconds:frames.subframes,
skipping to change at page 31, line 13 skipping to change at page 31, line 13
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.4.2. Normal Play Time 4.4.2. 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. 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.
The beginning of a presentation corresponds to 0.0 seconds. Negative The beginning of a presentation corresponds to 0.0 seconds. Negative
values are not defined. values are not defined.
The special constant "now" is defined as the current instant of a The special constant "now" is defined as the current instant of a
live event. It MAY only be used for live events, and MUST NOT be live event. It MAY only be used for live events, and MUST NOT be
skipping to change at page 31, line 41 skipping to change at page 31, line 40
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 is based on ISO 8601 [ISO.8601.2000]. Two different
notation is optimized for automatic generation, the npt-hhmmss notations are allowed. The npt-hhmmss notation are using a ISO 8601
notation for consumption by human readers. The "now" constant extended complete representation of the time of the day format
allows clients to request to receive the live feed rather than the (Section 5.3.1.1 of [ISO.8601.2000]) using colon (":") as separators
stored or time-delayed version. This is needed since neither between hours, minutes and seconds (hh:mm:ss). With the exception
absolute time nor zero time are appropriate for this case. that it expresses duration since presentation start rather than time
since midnight and the hour counter is not limited to 0-24 hours,
instead up to nineteen (19) digits of hours are allowed. ISO 8601
time format requires all digits to be used for each format, and all
format required needs to be included, e.g. if one use a hh:mm:ss
format, then that requires two digits for hours, two digits for
minutes and two digits for second, a time value such as 7 minutes and
0 seconds, is expressed as 00:07:00. The npt-sec notation is
expressing the duration since presentation start in seconds, using
one to nineteen (19) digits. Both notations allows decimal fractions
of seconds as specified in Section 5.3.1.3 of [ISO.8601.2000] with
the limitation of at maximum of 9 digits and only allowing "." (full
stop) as separator. Due to RTSP 1.0 and the fact that the highest
values are expanded beyond two digits, all implementations MUST allow
the highest value to be single digit and SHALL NOT send leading zeros
for hours in the npt-hhmmss notation and leading zeros for seconds in
the npt-sec notation. The hours and the seconds in the npt-hhmmss
notation SHALL be sent using leading zeros, but receivers SHALL
accept values without leading zeros.
The npt-sec notation is optimized for automatic generation, the npt-
hhmmss notation for consumption by human readers. The "now" constant
allows clients to request to receive the live feed rather than the
stored or time-delayed version. This is needed since neither
absolute time nor zero time are appropriate for this case.
4.4.3. Absolute Time 4.4.3. Absolute Time
Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps, Absolute time is expressed following a specific types of ISO 8601
using UTC (GMT). Fractions of a second may be indicated. [ISO.8601.2000] based timestamps. The date is complete
representation calendar date in basic format (YYYYMMDD) without
separators (per Section 5.2.1.1 of [ISO.8601.2000]). The time of day
is provided in the complete representation basic format (hhmmss) as
specified in Section 5.3.1.1 of [ISO.8601.2000], allowing decimal
fractions of seconds following Section 5.3.1.3 requiring "." (full
stop) as decimal separator and limiting the number of digits to no
more than nine (9). The time expressed MUST be using UTC (GMT), i.e.
no timezone offsets allowed. The full date and time specification is
the eight digit date followed by a "T" followed by the six digits
time value, optionally followed by a full stop followed by one to
nine fractions of a second and ended by "Z", e.g.
YYYYMMDDThhmmss.ssZ.
The reason for this time format rather than using "Date and Time
on the Internet: Timestamps" [RFC3339] are historic and using the
format specified in RTSP 1.0. The motivations raised in RFC 3339
applies to why a selection from ISO 8601 was done, but a different
and even more restrictive selection was applied in this case.
Example for clock format range request for a starting time of Example for clock format range request for a starting time of
November 8, 1996 at 14h 37 min and 20 and a quarter seconds UTC November 8, 1996 at 14h 37 min and 20 and a quarter seconds UTC
playing for 10 min and 5 seconds, a Media-Properties header's "Time- playing for 10 min and 5 seconds, a Media-Properties header's "Time-
Limited UTC property for 24th of December 2014 at 15 hours and 00 Limited UTC property for 24th of December 2014 at 15 hours and 00
mins, and a Terminate-Readon headers "time" property for 18th of June mins, and a Terminate-Readon headers "time" property for 18th of June
2013 at 16 hours, 12 minutes and 56 seconds: 2013 at 16 hours, 12 minutes and 56 seconds:
clock=19961108T143720.25Z-19961108T144725.25Z clock=19961108T143720.25Z-19961108T144725.25Z
Time-Limited=20141224T1500Z Time-Limited=20141224T1500Z
skipping to change at page 33, line 23 skipping to change at page 34, line 17
When an RTSP server handles media, it is important to consider the When an RTSP server handles media, it is important to consider the
different properties a media instance for delivery and playback can different properties a media instance for delivery and playback can
have. This specification considers the media properties listed below have. This specification considers the media properties listed below
in its protocol operations. They are derived from the differences in its protocol operations. They are derived from the differences
between a number of supported usages. between a number of supported usages.
On-demand: Media that has a fixed (given) duration that doesn't On-demand: Media that has a fixed (given) duration that doesn't
change during the 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
skipping to change at page 34, line 24 skipping to change at page 35, line 17
particular point may not be reachable, but seeking to a point particular point may not be reachable, but seeking to a point
close by is enabled. A floating point number of seconds may be close by is enabled. A floating point number of seconds may be
provided to express the worst case distance between random access provided to express the worst case distance between random access
points. points.
Beginning-Only: Seeking is only possible to the beginning of the Beginning-Only: Seeking is only possible to the beginning of the
content. content.
No-seeking: Seeking is not possible at all. No-seeking: Seeking is not possible at all.
If random access is possible, as indicated by Media-Properties If random access is possible, as indicated by the Media-Properties
header, the actual behavior policy when seeking can be controlled header, the actual behavior policy when seeking can be controlled
using the Seek-Style header (Section 18.47). using the Seek-Style header (Section 18.47).
4.7.2. Retention 4.7.2. Retention
Media may have different retention policies in place that affect the Media may have different retention policies in place that affect the
operation on media. The following different media retention policies operation on media. The following different media retention policies
are envisioned and taken into consideration where applicable: are envisioned and taken into consideration where applicable:
Unlimited: The media will not be removed as long as the RTSP session Unlimited: The media will not be removed as long as the RTSP session
skipping to change at page 36, line 40 skipping to change at page 37, line 40
and Response (Section 8) messages use a format based on the generic and Response (Section 8) messages use a format based on the generic
message format of RFC 5322 [RFC5322] for transferring bodies (the message format of RFC 5322 [RFC5322] for transferring bodies (the
payload of the message). Both types of messages consist of a start- payload of the message). Both types of messages consist of a start-
line, zero or more header fields (also known as "headers"), an empty line, zero or more header fields (also known as "headers"), an empty
line (i.e., a line with nothing preceding the CRLF) indicating the line (i.e., a line with nothing preceding the CRLF) indicating the
end of the headers, and possibly the data of the message body. The end of the headers, and possibly the data of the message body. The
below ABNF [RFC5234] is for information and the formal message below ABNF [RFC5234] is for information and the formal message
specification is present in Section 20.2.2. specification is present in Section 20.2.2.
generic-message = start-line generic-message = start-line
*(message-header CRLF) *(rtsp-header CRLF)
CRLF CRLF
[ message-body-data ] [ message-body-data ]
start-line = Request-Line | Status-Line start-line = Request-Line | Status-Line
In the interest of robustness, agents MUST ignore any empty line(s) In the interest of robustness, agents MUST ignore any empty line(s)
received where a Request-Line or Response-Line is expected. In other received where a Request-Line or Response-Line is expected. In other
words, if the agent is reading the protocol stream at the beginning words, if the agent is reading the protocol stream at the beginning
of a message and receives a CRLF first, it MUST ignore the CRLF. of a message and receives a CRLF first, it MUST ignore the CRLF.
5.2. Message Headers 5.2. Message Headers
RTSP header fields (see Section 18) include general-header, request- RTSP header fields (see Section 18) include general-header, request-
header, response-header, and message-body header fields. header, response-header, and message-body header fields.
The order in which header fields with differing field names are The order in which header fields with differing field names are
received is not significant. However, it is "good practice" to send received is not significant. However, it is "good practice" to send
general-header fields first, followed by request-header or response- general-header fields first, followed by request-header or response-
header fields, and ending with the Message-body header fields. header fields, and ending with the Message-body header fields.
Multiple message-header fields with the same field-name MAY be Multiple header fields with the same field-name MAY be present in a
present in a message if and only if the entire field-value for that message if and only if the entire field-value for that header field
header field is defined as a comma-separated list. It MUST be is defined as a comma-separated list. It MUST be possible to combine
possible to combine the multiple header fields into one "field-name: the multiple header fields into one "field-name: field-value" pair,
field-value" pair, without changing the semantics of the message, by without changing the semantics of the message, by appending each
appending each subsequent field-value to the first, each separated by subsequent field-value to the first, each separated by a comma. The
a comma. The order in which header fields with the same field-name order in which header fields with the same field-name are received is
are received is therefore significant to the interpretation of the therefore significant to the interpretation of the combined field
combined field value, and thus a proxy MUST NOT change the order of value, and thus a proxy MUST NOT change the order of these field
these field values when a message is forwarded. values when a message is forwarded.
Unknown message headers MUST be ignored (skipping over the header to Unknown message headers MUST be ignored (skipping over the header to
the next protocol element, and not causing an error) by a RTSP server the next protocol element, and not causing an error) by a RTSP server
or client. An RTSP Proxy MUST forward unknown message headers. or client. An RTSP Proxy MUST forward unknown message headers.
Message headers defined outside of this specification that are Message headers defined outside of this specification that are
required to be interpreted by the RTSP agent will need to use feature required to be interpreted by the RTSP agent will need to use feature
tags (Section 4.5) and include them in the appropriate Require tags (Section 4.5) and include them in the appropriate Require
(Section 18.43) or Proxy-Require (Section 18.37) header. (Section 18.43) or Proxy-Require (Section 18.37) header.
5.3. Message Body 5.3. Message Body
skipping to change at page 37, line 49 skipping to change at page 38, line 49
Protocol (SDP) message. Protocol (SDP) message.
The presence of a message body in either a request or a response MUST The presence of a message body in either a request or a response MUST
be signaled by the inclusion of a Content-Length header (see be signaled by the inclusion of a Content-Length header (see
Section 18.17) and Content-Type (see Section 18.19). A message body Section 18.17) and Content-Type (see Section 18.19). A message body
MUST NOT be included in a request or response if the specification of MUST NOT be included in a request or response if the specification of
the particular method (see Method Definitions (Section 13)) does not the particular method (see Method Definitions (Section 13)) does not
allow sending a message body. In case a message body is received in allow sending a message body. In case a message body is received in
a message when not expected the message body data SHOULD be a message when not expected the message body data SHOULD be
discarded. This is to allow future extensions to define optional use discarded. This is to allow future extensions to define optional use
of message body. of a message body.
5.4. Message Length 5.4. Message Length
An RTSP Message that does not contain any message body is terminated An RTSP Message that does not contain any message body is terminated
by the first empty line after the header fields (Note: An empty line by the first empty line after the header fields (Note: An empty line
is a line with nothing preceding the CRLF.). In RTSP messages that is a line with nothing preceding the CRLF.). In RTSP messages that
contain message bodies the empty line is followed by the message contain message bodies the empty line is followed by the message
body. The length of that body is determined by the value of the body. The length of that body is determined by the value of the
Content-Length header (Section 18.17). The value in the header Content-Length header (Section 18.17). The value in the header
represents the length of the message-body in octets. If this header represents the length of the message-body in octets. If this header
skipping to change at page 39, line 8 skipping to change at page 40, line 8
transfer coding (see [H3.6.1]). transfer coding (see [H3.6.1]).
Given the moderate length of presentation descriptions returned, Given the moderate length of presentation descriptions returned,
the server should always be able to determine its length, even if the server should always be able to determine its length, even if
it is generated dynamically, making the chunked transfer encoding it is generated dynamically, making the chunked transfer encoding
unnecessary. unnecessary.
6. General Header Fields 6. General Header Fields
General headers are headers that may be used in both requests and General headers are headers that may be used in both requests and
responses. The general headers are listed in Table 1: responses. The general-headers are listed in Table 1:
+--------------------+--------------------+ +--------------------+--------------------+
| Header Name | Defined in Section | | Header Name | Defined in Section |
+--------------------+--------------------+ +--------------------+--------------------+
| Accept-Ranges | Section 18.5 | | Accept-Ranges | Section 18.5 |
| | | | | |
| Cache-Control | Section 18.11 | | Cache-Control | Section 18.11 |
| | | | | |
| Connection | Section 18.12 | | Connection | Section 18.12 |
| | | | | |
skipping to change at page 41, line 14 skipping to change at page 42, line 14
7. Request 7. Request
A request message uses the format outlined below regardless of the A request message uses the format outlined below regardless of the
direction of a request, client to server or server to client: direction of a request, client to server or server to client:
o Request line, containing the method to be applied to the resource, o Request line, containing the method to be applied to the resource,
the identifier of the resource, and the protocol version in use; the identifier of the resource, and the protocol version in use;
o Zero or more Header lines, that can be of the following types: o Zero or more Header lines, that can be of the following types:
general headers (Section 6), request headers (Section 7.2), or general-headers (Section 6), request-headers (Section 7.2), or
message body headers (Section 9.1); message body headers (Section 9.1);
o One empty line (CRLF) to indicate the end of the header section; o One empty line (CRLF) to indicate the end of the header section;
o Optionally a message-body, consisting of one or more lines. The o Optionally a message-body, consisting of one or more lines. The
length of the message body in octets is indicated by the Content- length of the message body in octets is indicated by the Content-
Length message header. Length message header.
7.1. Request Line 7.1. Request Line
skipping to change at page 42, line 44 skipping to change at page 43, line 44
Note: This syntax cannot be freely changed in future versions of Note: This syntax cannot be freely changed in future versions of
RTSP. This line needs to remain parsable by older RTSP RTSP. This line needs to remain parsable by older RTSP
implementations since it indicates the RTSP version of the message. implementations since it indicates the RTSP version of the message.
In contrast to HTTP/1.1 [RFC2616], RTSP requests identify the In contrast to HTTP/1.1 [RFC2616], RTSP requests identify the
resource through an absolute RTSP URI (including scheme, host, and resource through an absolute RTSP URI (including scheme, host, and
port) (see Section 4.2) rather than just the absolute path. port) (see Section 4.2) rather than just the absolute path.
HTTP/1.1 requires servers to understand the absolute URI, but HTTP/1.1 requires servers to understand the absolute URI, but
clients are supposed to use the Host request header. This is clients are supposed to use the Host request-header. This is
purely needed for backward-compatibility with HTTP/1.0 servers, a purely needed for backward-compatibility with HTTP/1.0 servers, a
consideration that does not apply to RTSP. consideration that does not apply to RTSP.
An asterisk "*" can be used instead of an absolute URI in the An asterisk "*" can be used instead of an absolute URI in the
Request-URI part to indicate that the request does not apply to a Request-URI part to indicate that the request does not apply to a
particular resource, but to the server or proxy itself, and is only particular resource, but to the server or proxy itself, and is only
allowed when the request method does not necessarily apply to a allowed when the request method does not necessarily apply to a
resource. resource.
For example: For example:
skipping to change at page 43, line 21 skipping to change at page 44, line 21
the specific server needs to be determined, without regard to the the specific server needs to be determined, without regard to the
capability of an intervening proxy, the server should be addressed capability of an intervening proxy, the server should be addressed
explicitly with an absolute URI that contains the server's address. explicitly with an absolute URI that contains the server's address.
For example: For example:
OPTIONS rtsp://example.com RTSP/2.0 OPTIONS rtsp://example.com RTSP/2.0
7.2. Request Header Fields 7.2. Request Header Fields
The RTSP headers in Table 3 can be included in a request, as request The RTSP headers in Table 3 can be included in a request, as request-
headers, to modify the specifics of the request. headers, to modify the specifics of the request.
+---------------------+--------------------+ +---------------------+--------------------+
| Header | Defined in Section | | Header | Defined in Section |
+---------------------+--------------------+ +---------------------+--------------------+
| Accept | Section 18.1 | | Accept | Section 18.1 |
| | | | | |
| Accept-Credentials | Section 18.2 | | Accept-Credentials | Section 18.2 |
| | | | | |
| Accept-Encoding | Section 18.3 | | Accept-Encoding | Section 18.3 |
skipping to change at page 44, line 49 skipping to change at page 45, line 49
| | | | | |
| Require | Section 18.43 | | Require | Section 18.43 |
| | | | | |
| Terminate-Reason | Section 18.52 | | Terminate-Reason | Section 18.52 |
+---------------------+--------------------+ +---------------------+--------------------+
Table 3: The RTSP request headers Table 3: The RTSP request headers
Detailed header definitions are provided in Section 18. Detailed header definitions are provided in Section 18.
New request headers may be defined. If the receiver of the request New request-headers may be defined. If the receiver of the request
is required to understand the request header, the request MUST is required to understand the request-header, the request MUST
include a corresponding feature tag in a Require or Proxy-Require include a corresponding feature tag in a Require or Proxy-Require
header to ensure the processing of the header. header to ensure the processing of the header.
8. Response 8. Response
After receiving and interpreting a request message, the recipient After receiving and interpreting a request message, the recipient
responds with an RTSP response message. Normally, there is only one, responds with an RTSP response message. Normally, there is only one,
final, response. Only responses using the response code class 1xx, final, response. Only responses using the response code class 1xx,
are allowed to send one or more 1xx response messages prior to the are allowed to send one or more 1xx response messages prior to the
final response message. final response message.
skipping to change at page 46, line 26 skipping to change at page 47, line 26
RTSP has its own registry separate from HTTP for status codes. RTSP has its own registry separate from HTTP for status codes.
RTSP status codes are extensible. RTSP applications are not required RTSP status codes are extensible. RTSP applications are not required
to understand the meaning of all registered status codes, though such to understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST understanding is obviously desirable. However, applications MUST
understand the class of any status code, as indicated by the first understand the class of any status code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the digit, and treat any unrecognized response as being equivalent to the
x00 status code of that class, with an exception for unknown 3xx x00 status code of that class, with an exception for unknown 3xx
codes, which MUST be treated as a 302 (Found). The reason being that codes, which MUST be treated as a 302 (Found). The reason being that
no 300 (Multiple Choices in HTTP) is defined for RTSP. An response no 300 (Multiple Choices in HTTP) is defined for RTSP. An response
with unrecognized status code MUST NOT be cached. For example, if an with an unrecognized status code MUST NOT be cached. For example, if
unrecognized status code of 431 is received by the client, it can an 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 |
+------+---------------------------------+--------------------------+ +------+---------------------------------+--------------------------+
skipping to change at page 49, line 11 skipping to change at page 50, line 11
+------+---------------------------------+--------------------------+ +------+---------------------------------+--------------------------+
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 headers currently classified as response-headers are listed in
Table 5. Table 5.
+------------------------+--------------------+ +------------------------+--------------------+
| Header | Defined in Section | | Header | Defined in Section |
+------------------------+--------------------+ +------------------------+--------------------+
| Authentication-Info | Section 18.7 | | Authentication-Info | Section 18.7 |
| | | | | |
| Connection-Credentials | Section 18.13 | | Connection-Credentials | Section 18.13 |
| | | | | |
| Location | Section 18.28 | | Location | Section 18.28 |
skipping to change at page 49, line 44 skipping to change at page 50, line 44
+------------------------+--------------------+ +------------------------+--------------------+
Table 5: The RTSP response headers Table 5: The RTSP response headers
Response-header names can be extended reliably only in combination Response-header names can be extended reliably only in combination
with a change in the protocol version. However, the usage of with a change in the protocol version. However, the usage of
feature-tags in the request allows the responding party to learn the feature-tags in the request allows the responding party to learn the
capability of the receiver of the response. A new or experimental capability of the receiver of the response. A new or experimental
header MAY be given the semantics of response-header if all parties header MAY be given the semantics of response-header if all parties
in the communication recognize them to be a response-header. in the communication recognize them to be a response-header.
Unrecognized headers in responses are treated as message-headers and Unrecognized headers in responses are treated as message-body headers
hence MUST be ignored. and hence MUST be ignored.
9. Message Body 9. Message Body
Request and Response messages MAY transfer a message body, if not Request and Response messages MAY transfer a message body, if not
otherwise restricted by the request method or response status code. otherwise restricted by the request method or response status code.
The message body consists of the content data itself (see also The message body consists of the content data itself (see also
Section 5.3). Section 5.3).
The SET_PARAMETER and GET_PARAMETER requests and responses, and the The SET_PARAMETER and GET_PARAMETER requests and responses, and the
DESCRIBE response as defined by this specification MAY have a message DESCRIBE response as defined by this specification MAY have a message
skipping to change at page 52, line 11 skipping to change at page 53, line 11
The Content-Length of a message is the length of the content, The Content-Length of a message is the length of the content,
measured in octets. measured in octets.
9.3. Message Body Format Negotiation 9.3. Message Body Format Negotiation
The content format of the message body is provided using the Content- The content format of the message body is provided using the Content-
Type header (Section 18.19). To enable the responder of a request to Type header (Section 18.19). To enable the responder of a request to
determine which media type it should use, the requestor may include determine which media type it should use, the requestor may include
the Accept header (Section 18.1) in a request to identify supported the Accept header (Section 18.1) in a request to identify supported
media types or media type ranges suitable to the response. In cases media types or media type ranges suitable to the response. In case
the responder is not supporting any of the specified formats, then the responder is not supporting any of the specified formats, then
the request response will be a 406 (Not Acceptable) error code. the request response will be a 406 (Not Acceptable) error code.
The media types that may be used on requests with message bodies The media types that may be used on requests with message bodies need
needs to be determined through the use of feature-tags, specification to be determined through the use of feature-tags, specification
requirement or trial and error. Trial and error works in the regards requirement or trial and error. Trial and error works because when
that in case the responder is not supporting the media type of the the responder does not support the media type of the message body it
message body it will respond with a 415 (Unsupported Media Type). will respond with a 415 (Unsupported Media Type).
The formats supported and their negotiation is done individually on a The formats supported and their negotiation is done individually on a
per method and direction (request or response body) direction. per method and direction (request or response body) direction.
Requirements on supporting particular media types for use as message Requirements on supporting particular media types for use as message
bodies in requests and response SHALL also be specified on per method bodies in requests and response SHALL also be specified on per method
and direction basis. and direction basis.
10. Connections 10. Connections
RTSP Messages are transferred between RTSP agents and proxies using a RTSP Messages are transferred between RTSP agents and proxies using a
skipping to change at page 55, line 17 skipping to change at page 56, line 17
exchanges in a session and then close the connection. Later, when exchanges in a session and then close the connection. Later, when
the client wishes to send a new request, such as a PAUSE for the the client wishes to send a new request, such as a PAUSE for the
session, a new connection would be opened. This connection may session, a new connection would be opened. This connection may
either be transient or persistent. either be transient or persistent.
An RTSP agent MAY use one connection to handle multiple RTSP sessions An RTSP agent MAY use one connection to handle multiple RTSP sessions
on the same server. The RTSP agent SHALL NOT use more than one on the same server. The RTSP agent SHALL NOT use more than one
connection per RTSP session at any given point. connection per RTSP session at any given point.
Using a single connection for multiple RTSP session saves Using a single connection for multiple RTSP session saves
complexity by enabling the server to maintain less state about its
connection resources on the server. Not using more than one connection resources on the server. Not using more than one
connection at a time for a particular RTSP session avoids wasting connection at a time for a particular RTSP session avoids wasting
connection resources and allows the server to track only for the connection resources and allows the server to track only the most
latest in client to server used connection for each RTSP session recently used client to server connection for each RTSP session as
as being the currently valid server to client connection. being the currently valid server to client connection.
RTSP allows a server to send requests to a client. However, this can RTSP allows a server to send requests to a client. However, this can
be supported only if a client establishes a persistent connection be supported only if a client establishes a persistent connection
with the server. In cases where a persistent connection does not with the server. In cases where a persistent connection does not
exist between a server and its client, due to the lack of a signaling exist between a server and its client, due to the lack of a signaling
channel the server may be forced to silently discard RTSP messages, channel the server may be forced to silently discard RTSP messages,
and may even drop an RTSP session without notifying the client. An and may even drop an RTSP session without notifying the client. An
example of such a case is when the server desires to send a REDIRECT example of such a case is when the server desires to send a REDIRECT
request for an RTSP session to the client but is not able to do so request for an RTSP session to the client but is not able to do so
because it cannot reach the client. A server that attempts to send a because it cannot reach the client. A server that attempts to send a
request to a client that has no connection currently to the server request to a client that has no connection currently to the server
SHALL discard the request directly. SHALL discard the request directly.
Without a persistent connection between the client and the server, Without a persistent connection between the client and the server,
the media server has no reliable way of reaching the client. the media server has no reliable way of reaching the client.
Because the likely failure of server to client established Because the likely failure of server to client established
connections the server will not even attempt establishing any connections the server will not even attempt establishing any
connection. connection.
Queuing of server to client requests has been considered. However Queuing of server to client requests has been considered. However
a security issue exist in how one authorizes a client establishing a security issue exists as to how it might be possible to
a new connection as being a legit receiver of request related to a authorize a client establishing a new connection as being a
particular RTSP session without the client first issuing requests legitimate receiver of a request related to a particular RTSP
related to the request. Thus, likely making any such requests session without the client first issuing requests related to the
even more delayed and less useful. request. Thus, it would be likely to make any such requests even
more delayed and less useful.
The sending of client and server requests can be asynchronous events. The sending of client and server requests can be asynchronous events.
To avoid deadlock situations both client and server MUST be able to To avoid deadlock situations both client and server MUST be able to
send and receive requests simultaneously. As an RTSP response may be send and receive requests simultaneously. As an RTSP response may be
queued up for transmission, reception or processing behind the peer queued up for transmission, reception or processing behind the peer
RTSP agent's own requests, all RTSP agents are required to have a RTSP agent's own requests, all RTSP agents are required to have a
certain capability of handling outstanding messages. A potential certain capability of handling outstanding messages. A potential
issue is that outstanding requests may timeout despite them being issue is that outstanding requests may timeout despite them being
processed by the peer due to the response being caught in the queue processed by the peer due to the response being caught in the queue
behind a number of requests that the RTSP agent is processing but behind a number of requests that the RTSP agent is processing but
skipping to change at page 57, line 5 skipping to change at page 58, line 7
RTSP Agents can send requests to multiple different destinations, RTSP Agents can send requests to multiple different destinations,
either servers or client contexts over the same connection to a either servers or client contexts over the same connection to a
proxy. Then the proxy forks the message to the different proxy. Then the proxy forks the message to the different
destinations over proxy to agent connections. In these cases when destinations over proxy to agent connections. In these cases when
multiple requests are outstanding the requesting agent MUST be ready multiple requests are outstanding the requesting agent MUST be ready
to receive the responses out of order compared to the order they to receive the responses out of order compared to the order they
where sent on the connection. The order between multiple messages where sent on the connection. The order between multiple messages
for each destination will be maintained, however, the order between for each destination will be maintained, however, the order between
response from different destinations can be different. response from different destinations can be different.
The reason for this is to avoid a head of line blocking. In a The reason for this is to avoid a head-of-line blocking
sequence of request an early outstanding request may take time to sitauation. In a sequence of requests an early outstanding
be processed at one destination. Simultaneously a responses from request may take time to be processed at one destination.
any other destinations, that was later in the sequence of requests Simultaneously, a response from any other destination that was
may have arrived at the proxy. Thus allowing out-of-order later in the sequence of requests, may have arrived at the proxy.
responses avoid forcing the proxy to buffer this response and Thus allowing out-of-order responses avoids forcing the proxy to
instead deliver it as soon as possible. Note, this will not buffer this response and instead deliver it as soon as possible.
affect the order they where processed at request destination. Note, this will not affect the order in which the messages sent to
each separate destination were processed at request destination.
This scenario can occur in two cases involving proxies. The first is This scenario can occur in two cases involving proxies. The first is
a client issuing requests for sessions on different servers using a a client issuing requests for sessions on different servers using a
common client to proxy connection. The second is for server to common client to proxy connection. The second is for server to
client requests, like REDIRECT being sent by the server over a common client requests, like REDIRECT being sent by the server over a common
transport connection the proxy created for its different connecting transport connection the proxy created for its different connecting
clients. clients.
10.3. Closing Connections 10.3. Closing Connections
skipping to change at page 57, line 45 skipping to change at page 58, line 48
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.24) are used for negotiating capabilities Allowed" (Section 17.4.25) are used for negotiating capabilities
of a server with respect to content or other factors. In such of a server with respect to content or other factors. In such
cases, it is inefficient for the server to close a connection on cases, it is inefficient for the server to close a connection on
an error response. Also, such behavior would prevent an error response. Also, such behavior would prevent
implementation of advanced/special types of requests or result in implementation of advanced/special types of requests or result in
extra overhead for the client when testing for new features. On extra overhead for the client when testing for new features. On
the other hand, keeping connections open after sending an error the other hand, keeping connections open after sending an error
response poses a Denial of Service security risk (Section 21). response poses a Denial of Service security risk (Section 21).
The server MAY close a connection if it receives an incomplete The server MAY close a connection if it receives an incomplete
message and if the message is not completed within a reasonable message and if the message is not completed within a reasonable
skipping to change at page 58, line 48 skipping to change at page 60, line 5
final response indicating the success or failure of the request. final response indicating the success or failure of the request.
A requester SHOULD wait at least 10 seconds for a response before A requester SHOULD wait at least 10 seconds for a response before
concluding that the responder will not be responding to its request. concluding that the responder will not be responding to its request.
After receiving a 100 response, the requester SHOULD continue waiting After receiving a 100 response, the requester SHOULD continue waiting
for further responses. If more than 10 seconds elapses without for further responses. If more than 10 seconds elapses without
receiving any response, the requester MAY assume that the responder receiving any response, the requester MAY assume that the responder
is unresponsive and abort the connection by closing the TCP is unresponsive and abort the connection by closing the TCP
connection. connection.
Note: In cases multiple RTSP sessions share the same transport In cases multiple RTSP sessions share the same transport connection,
connection, abandoning a request closing the connection may have abandoning a request and closing the connection may have significant
significant impact on those other sessions. First of all, other impact on those other sessions. First of all, other RTSP requests
RTSP requests may have become queued up due to the request taking may have become queued up due to the request taking long time.
long time. Secondly also those sessions loose the possibility to Secondly also those sessions loose the possibility to receive server
receive server to client requests. To mitigate that situation the to client requests. To mitigate that situation the RTSP agent SHOULD
RTSP agent should establish a new connection and send any queued establish a new connection and send any queued up and non-responded
up and non-responded requests on this new connection. Secondly, requests on this new connection. Secondly, to ensure that the RTSP
to ensure that the RTSP server knows which connection that is server knows which connection that is valid for a particular RTSP
valid for a particular RTSP session, the RTSP agent should send a session, the RTSP agent SHOULD send a keep-alive request, if no other
keep-alive request, if no other request will be sent immediately request will be sent immediately for that RTSP session, for each RTSP
for that RTSP session, for each RTSP session on the old session on the old connection. The keep-alive request will normally
connection. The keep-alive request will normally be a be a GET_PARAMETER with a session header to inform the server that
GET_PARAMETER with a session header to inform the server that this this agent cares about this RTSP session.
agent cares about this RTSP session.
A requester SHOULD wait longer than 10 seconds for a response if it A requester SHOULD wait longer than 10 seconds for a response if it
is experiencing significant transport delays on its connection to the is experiencing significant transport delays on its connection to the
responder. The requester is capable of determining the round trip responder. The requester is capable of determining the round trip
time (RTT) of the request/response cycle using the Timestamp header time (RTT) of the request/response cycle using the Timestamp header
(Section 18.53) in any RTSP request. (Section 18.53) in any RTSP request.
10 seconds was chosen for the following reasons. It gives TCP 10 seconds was chosen for the following reasons. It gives TCP
time to perform a couple of retransmissions, even if operating on time to perform a couple of retransmissions, even if operating on
default values. It is short enough that users may not abandon the default values. It is short enough that users may not abandon the
skipping to change at page 60, line 21 skipping to change at page 61, line 25
mechanisms below. mechanisms below.
SET_PARAMETER: When using SET_PARAMETER for keep-alive, a body SET_PARAMETER: When using SET_PARAMETER for keep-alive, a body
SHOULD NOT be included. This method is the RECOMMENDED RTSP SHOULD NOT be included. This method is the RECOMMENDED RTSP
method to use for a request intended only to perform keep- method to use for a request intended only to perform keep-
alive. Support of SET_PARAMETER is mandatory for RTSP Servers alive. Support of SET_PARAMETER is mandatory for RTSP Servers
to ensure clients can use this method. to ensure clients can use this method.
GET_PARAMETER: When using GET_PARAMETER for keep-alive, no body GET_PARAMETER: When using GET_PARAMETER for keep-alive, no body
SHOULD be included. Dependent on implementation support in SHOULD be included. Dependent on implementation support in
server. server. Use OPTIONS method to determine if there are method
support or simply try.
OPTIONS: This method is also usable, but it causes the server to OPTIONS: This method is also usable, but it causes the server to
perform more unnecessary processing and results in bigger perform more unnecessary processing and results in bigger
responses than necessary for the task. The reason is that the responses than necessary for the task. The reason is that the
server needs to determine the capabilities associated with the server needs to determine the capabilities associated with the
media resource to correctly populate the Public and Allow media resource to correctly populate the Public and Allow
headers. headers.
The timeout parameter of the Session header (Section 18.49) MAY be The timeout parameter of the Session header (Section 18.49) MAY be
included in a SETUP response, and MUST NOT be included in requests. included in a SETUP response, and MUST NOT be included in requests.
skipping to change at page 61, line 15 skipping to change at page 62, line 17
10.7. Overload Control 10.7. Overload Control
Overload in RTSP can occur when servers and proxies have insufficient Overload in RTSP can occur when servers and proxies have insufficient
resources to complete the processing of a request. An improper resources to complete the processing of a request. An improper
handling of such an overload situation at proxies and servers can handling of such an overload situation at proxies and servers can
impact the operation of the RTSP deployment, and probably worsen the impact the operation of the RTSP deployment, and probably worsen the
situation. RTSP defines the 503 (Service Unavailable) response situation. RTSP defines the 503 (Service Unavailable) response
(Section 17.5.4) to let servers and proxies notify requesting proxies (Section 17.5.4) to let servers and proxies notify requesting proxies
and RTSP clients about an overload situation. In conjunction with and RTSP clients about an overload situation. In conjunction with
the Retry-After header (Section 18.44) the server or proxy can the Retry-After header (Section 18.44) the server or proxy can
indicate the time after the requesting entity can send another indicate the time after which the requesting entity can send another
request to the proxy or server. request to the proxy or server.
There are two scopes of such 503 answers, one for established RTSP There are two scopes of such 503 answers, one for established RTSP
sessions, where the request resulting in the 503 response as well as sessions, where the request resulting in the 503 response as well as
the response carries a Session header identifying the session which the response carries a Session header identifying the session which
is suffering overload. This response only applies to this particular is suffering overload. This response only applies to this particular
session. The other scope is the general RTSP server as identified by session. The other scope is the general RTSP server as identified by
the host in the request URL. Such a 503 answer with any Retyr-After the host in the request URL. Such a 503 answer with any Retry-After
header applies to all non-session specific requests to that server, header applies to all non-session specific requests to that server,
including SETUP request intended to create a new RTSP session. including SETUP request intended to create a new RTSP session.
Another scope for overload situation exists, which is the RTSP proxy. Another scope for overload situation exists, which is the RTSP proxy.
To enable an RTSP proxy to signal that it is overloaded, or otherwise To enable an RTSP proxy to signal that it is overloaded, or otherwise
unavailable and can't handle the request, a 553 response code has unavailable and can't handle the request, a 553 response code has
been defined with the meaning "Proxy Unavailable". Also for proxies been defined with the meaning "Proxy Unavailable". As with servers,
there is a separation in response scopes between requests associated there is a separation in response scopes between requests associated
with existing RTSP sessions, and requests to create new sessions or with existing RTSP sessions, and requests to create new sessions or
general proxy requests. general proxy requests.
Simply implementing and using the 503 (Service Unavailable) and 553 Simply implementing and using the 503 (Service Unavailable) and 553
(Proxy Unavailable) is not sufficient for properly handling overload (Proxy Unavailable) is not sufficient for properly handling overload
situations. For instance, a simplistic approach would be to send the situations. For instance, a simplistic approach would be to send the
503 response with a Retry-After header set to a fixed value. 503 response with a Retry-After header set to a fixed value.
However, this can cause the situation where multiple RTSP clients However, this can cause the situation where multiple RTSP clients
again send requests to a proxy or server at roughly the same time again send requests to a proxy or server at roughly the same time
skipping to change at page 63, line 44 skipping to change at page 64, line 44
"play.basic" feature-tag (Section 11.1) which represents the minimal "play.basic" feature-tag (Section 11.1) which represents the minimal
media delivery for playback implementation. media delivery for playback implementation.
Feature-tags are used to determine whether the client, server or Feature-tags are used to determine whether the client, server or
proxy supports the functionality that is necessary to achieve the proxy supports the functionality that is necessary to achieve the
desired service. To determine support of a feature-tag, several desired service. To determine support of a feature-tag, several
different headers can be used, each explained below: different headers can be used, each explained below:
Supported: This header is used to determine the complete set of Supported: This header is used to determine the complete set of
functionality that both client and server have in general and functionality that both client and server have in general and
is not dependent on specific resource. The intended usage is is not dependent on a specific resource. The intended usage is
to determine before one needs to use a functionality that it is to determine before one needs to use a functionality that it is
supported. It can be used in any method, but OPTIONS is the supported. It can be used in any method, but OPTIONS is the
most suitable one as it at the same time determines all methods most suitable one as it at the same time determines all methods
that are implemented. When sending a request the requester that are implemented. When sending a request the requester
declares all its capabilities by including all supported declares all its capabilities by including all supported
feature-tags. This results in the receiver is learning the feature-tags. This results in the receiver learning the
requester's feature support. The receiver then includes its requester's feature support. The receiver then includes its
set of features in the response. set of features in the response.
Proxy-Supported: This header is used similarly to the Supported Proxy-Supported: This header is used 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 the common functionality supported in responder a view of the common functionality supported in
general by all members of the proxy chain between the two general by all members of the proxy chain between the two
supports and not dependent on the resource. Proxies are supports and not dependent on the resource. Proxies are
required to add this header whenever the Supported header is required to add this header whenever the Supported header is
skipping to change at page 64, line 44 skipping to change at page 65, line 44
Unsupported: This header is used in a 551 error response, to Unsupported: This header is used in a 551 error response, to
indicate which features were not supported. Such a response is indicate which features were not supported. Such a response is
only the result of the usage of the Require and/or Proxy- only the result of the usage of the Require and/or Proxy-
Require header where one or more features where not supported. Require header where one or more features where not supported.
This information allows the requester to make the best of This information allows the requester to make the best of
situations as it knows which features are not supported. situations as it knows which features are not supported.
11.1. Feature Tag: play.basic 11.1. Feature Tag: play.basic
The play.basic feature tag represents an RTSP implementation The play.basic feature tag represents an RTSP implementation offering
according to all normative RTSP protocol features specified in this all the normative RTSP protocol features specified in this
specification. This specification is both a RTSP core specification specification. This specification is both a RTSP core specification
as well intended to enable setup and control of playback of media. as well providing mechanisms for the setup and control of playback of
Thus following all normative parts in the main sections (the ones media. Thus following all normative parts in the main sections (the
with numbers), not the appendices (starting with letters), unless ones with numbers), but omitting the appendices (starting with
explicitly specified in a main section for being a required appendix. letters), unless explicitly specified in a main section as being a
required appendix.
Note: This feature tag does not mandate any media delivery Note: This feature tag does not mandate any media delivery
protocol, such as RTP. protocol, such as RTP.
In RTSP 1.0 there was a minimal implementation section. However, In RTSP 1.0 there was a minimal implementation section. However,
that was not consistent with the rest of the specification. So that was not consistent with the rest of the specification. So
rather than making an attempt to explicitly enumerate the features rather than making an attempt to explicitly enumerate the features
for play.basic this specification have to be read in completeness for play.basic this specification has to be taken as a whole and
and the necessary features normatively defined as being required the necessary features normatively defined as being required are
are included. included.
12. Pipelining Support 12. Pipelining Support
Pipelining is a general method to improve performance of request Pipelining is a general method to improve performance of request
response protocols by allowing the requesting agent to have more than response protocols by allowing the requesting agent to have more than
one request outstanding and send them over the same persistent one request outstanding and send them over the same persistent
connection. For RTSP, where the relative order of requests will connection. For RTSP, where the relative order of requests will
matter, it is important to maintain the order of the requests. matter, it is important to maintain the order of the requests.
Because of this, the responding agent MUST process the incoming Because of this, the responding agent MUST process the incoming
requests in their sending order. The sending order can be determined requests in their sending order. The sending order can be determined
skipping to change at page 68, line 7 skipping to change at page 69, line 7
| | S -> C | P | required | required | | | S -> C | P | required | required |
+---------------+-----------+--------+-------------+-------------+ +---------------+-----------+--------+-------------+-------------+
Table 7: Overview of RTSP methods, their direction, and what objects Table 7: Overview of RTSP methods, their direction, and what objects
(P: presentation, S: stream) they operate on. Further it indicates if (P: presentation, S: stream) they operate on. Further it indicates if
a server or a client implementation are required (mandatory), a server or a client implementation are required (mandatory),
recommended or if it is optional to implement the method. recommended or if it is optional to implement the method.
Note on Table 7: GET_PARAMETER is optional. For example, a fully Note on Table 7: GET_PARAMETER is optional. For example, a fully
functional server can be built to deliver media without any functional server can be built to deliver media without any
parameters. However, SET_PARAMETER is required, i.e. mandatory to parameters. However, SET_PARAMETER is required, i.e., mandatory
implement for the server, this is due to its usage for keep-alive. to implement for the server, this is due to its usage for keep-
PAUSE is required because it is the only way of leaving the Play alive. PAUSE is required because it is the only way of leaving
state without terminating the whole session. the Play state without terminating the whole session.
If an RTSP agent does not support a particular method, it MUST return If an RTSP agent does not support a particular method, it MUST return
501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD 501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD
NOT try this method again for the given agent / resource combination. NOT try this method again for the given agent / resource combination.
An RTSP proxy whose main function is to log or audit and not modify An RTSP proxy whose main function is to log or audit and not modify
transport or media handling in any way MAY forward RTSP messages with transport or media handling in any way MAY forward RTSP messages with
unknown methods. Note that the proxy still needs to perform the unknown methods. Note that the proxy still needs to perform the
minimal required processing, like adding the Via header. minimal required processing, like adding the Via header.
13.1. OPTIONS 13.1. OPTIONS
skipping to change at page 71, line 16 skipping to change at page 72, line 16
session establishment conditional on being valid. session establishment conditional on being valid.
It is RECOMMENDED that minimal servers support the DESCRIBE method, It is RECOMMENDED that minimal servers support the DESCRIBE method,
and highly recommended that minimal clients support the ability to and highly recommended that minimal clients support the ability to
act as "helper applications" that accept a media initialization file act as "helper applications" that accept a media initialization file
from a user interface, and/or other means that are appropriate to the from a user interface, and/or other means that are appropriate to the
operating environment of the clients. operating environment of the clients.
13.3. SETUP 13.3. SETUP
The below description uses the following states in a protocol state The description below uses the following states in a protocol state
machine that are related to a specific session when that session has machine that is related to a specific session when that session has
been created. The state transitions are driven by protocol been created. The state transitions are driven by protocol
interactions. For additional information about the state machine see interactions. For additional information about the state machine see
Appendix B. Appendix B.
Init: Initial state: no session exists. Init: Initial state: no session exists.
Ready: Session is ready to start playing. Ready: Session is ready to start playing.
Play: Session is playing, i.e., sending media stream data in the Play: Session is playing, i.e., sending media stream data in the
direction S->C. direction S->C.
The SETUP request for an URI specifies the transport mechanism to be The SETUP request for a URI specifies the transport mechanism to be
used for the streamed media. The SETUP method may be used in two used for the streamed media. The SETUP method may be used in two
different cases; Create an RTSP session and change the transport different cases; Create an RTSP session and change the transport
parameters of already set up media stream(s). SETUP can be used in parameters of already set up media stream(s). SETUP can be used in
all three states; Init, and Ready, for both purposes and in PLAY to all three states; Init, and Ready, for both purposes and in PLAY to
change the transport parameters. There is also a third possible change the transport parameters. There is also a third possible
usage for the SETUP method which is not specified in this memo: usage for the SETUP method which is not specified in this memo:
adding a media to a session. Using SETUP to add media to an existing adding a media to a session. Using SETUP to add media to an existing
session, when the session is in Play state, is unspecified. session, when the session is in Play state, is unspecified.
The Transport header, see Section 18.54, specifies the media The Transport header, see Section 18.54, specifies the media
skipping to change at page 73, line 41 skipping to change at page 74, line 41
AVP/UDP transport and adds the address and ports it will send and AVP/UDP transport and adds the address and ports it will send and
receive RTP and RTCP from, and the RTP SSRC that will be used by the receive RTP and RTCP from, and the RTP SSRC that will be used by the
server. server.
The server MUST generate a session identifier in response to a The server MUST generate a session identifier in response to a
successful SETUP request, unless a SETUP request to a server includes successful SETUP request, unless a SETUP request to a server includes
a session identifier or a Pipelined-Requests header referencing an a session identifier or a Pipelined-Requests header referencing an
existing session context, in which case the server MUST bundle this existing session context, in which case the server MUST bundle this
SETUP request into the existing session (aggregated session) or SETUP request into the existing session (aggregated session) or
return error 459 (Aggregate Operation Not Allowed) (see return error 459 (Aggregate Operation Not Allowed) (see
Section 17.4.23). An Aggregate control URI MUST be used to control Section 17.4.24). An Aggregate control URI MUST be used to control
an aggregated session. This URI MUST be different from the stream an aggregated session. This URI MUST be different from the stream
control URIs of the individual media streams included in the control URIs of the individual media streams included in the
aggregate (see Section 13.4.2 for aggregated sessions and for the aggregate (see Section 13.4.2 for aggregated sessions and for the
particular URIs see Appendix D.1.1). The Aggregate control URI is to particular URIs see Appendix D.1.1). The Aggregate control URI is to
be specified by the session description if the server supports be specified by the session description if the server supports
aggregated control and aggregated control is desired for the session. aggregated control and aggregated control is desired for the session.
However, even if aggregated control is offered the client MAY chose However, even if aggregated control is offered the client MAY chose
to not set up the session in aggregated control. If an Aggregate to not set up the session in aggregated control. If an Aggregate
control URI is not specified in the session description, it is control URI is not specified in the session description, it is
normally an indication that non-aggregated control should be used. normally an indication that non-aggregated control should be used.
skipping to change at page 86, line 41 skipping to change at page 87, line 41
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 use both aggregate control URI and PLAY_NOTIFY requests MAY use both aggregate control URI and
individual media resource URIs depending on scope of the individual media resource URIs depending on the scope of the
notification. This scope may have important distinctions for notification. This scope may have important distinctions for
aggregated sessions, and each reason for a PLAY_NOTIFY request needs aggregated sessions, and each reason for a PLAY_NOTIFY request needs
to specify the interpretation and if aggregated control URIs or to specify the interpretation and if aggregated control URIs or
individual URIs may be used in requests. individual URIs may be used in requests.
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
skipping to change at page 87, line 15 skipping to change at page 88, line 15
the client can understand the received message body. This is related the client can understand the received message body. This is related
to DESCRIBE (see Section 13.2 ), but in this particular case the to DESCRIBE (see Section 13.2 ), but in this particular case the
client can state its acceptable message bodies by using the Accept client can state its acceptable message bodies by using the Accept
header. In the case of PLAY_NOTIFY, the server does not know which header. In the case of PLAY_NOTIFY, the server does not know which
message bodies are understood by the client. message bodies are understood by the client.
The Notify-Reason header (see Section 18.32) specifies the reason why The Notify-Reason header (see Section 18.32) specifies the reason why
the server sends the PLAY_NOTIFY request. This is extensible and new the server sends the PLAY_NOTIFY request. This is extensible and new
reasons MAY be added in the future (see Section 22.8). In case the reasons MAY be added in the future (see Section 22.8). In case the
client does not understand the reason for the notification it MUST client does not understand the reason for the notification it MUST
respond with a 465 (Notification Reason Unknown) (Section 17.4.29) respond with a 465 (Notification Reason Unknown) (Section 17.4.30)
error code. Servers can send PLAY_NOTIFY with these types: error code. Servers can send PLAY_NOTIFY with these types:
o end-of-stream (see Section 13.5.1); o end-of-stream (see Section 13.5.1);
o media-properties-update (see Section 13.5.2); o media-properties-update (see Section 13.5.2);
o scale-change (see Section 13.5.3). o scale-change (see Section 13.5.3).
13.5.1. End-of-Stream 13.5.1. End-of-Stream
skipping to change at page 88, line 17 skipping to change at page 89, line 17
e.g., "npt=-15", if npt is currently at 14.2 seconds. The Scale e.g., "npt=-15", if npt is currently at 14.2 seconds. The Scale
header is to be included so that it is evident if the media time header is to be included so that it is evident if the media time
scale is moving backwards and/or have a non-default pace. The end- scale is moving backwards and/or have a non-default pace. The end-
of-stream notification does not prevent the client from sending a new of-stream notification does not prevent the client from sending a new
PLAY request. PLAY request.
If RTP is used as media transport, a RTP-Info header MUST be If RTP is used as media transport, a RTP-Info header MUST be
included, and the RTP-Info header MUST indicate the last sequence included, and the RTP-Info header MUST indicate the last sequence
number in the seq parameter. number in the seq parameter.
For RTSP Session where media resources under aggregated control the For an RTSP Session where media resources are under aggregated
media resources will normally end at approximately the same time, control the media resources will normally end at approximately the
although some small differences may exist, on the scale of a few same time, although some small differences may exist, on the scale of
hundred of milliseconds. In those cases a RTSP session under a few hundred of milliseconds. In those cases a RTSP session under
aggregated control SHOULD send only a single PLAY_NOTIFY request. By aggregated control SHOULD send only a single PLAY_NOTIFY request. By
using the aggregate control URI in the PLAY_NOTIFY request the RTSP using the aggregate control URI in the PLAY_NOTIFY request the RTSP
server indicates that this applies to all media resources within the server indicates that this applies to all media resources within the
session. In cases RTP is used for media delivery corresponding RTP- session. In cases RTP is used for media delivery corresponding RTP-
Info needs to be included for all media resources. In cases where Info needs to be included for all media resources. In cases where
one or more media resource has significantly shorter duration than one or more media resource has significantly shorter duration than
some other resources in the aggregated session the server MAY send some other resources in the aggregated session the server MAY send
end-of-stream notifications using individual media resource URIs to end-of-stream notifications using individual media resource URIs to
indicate to agents that there will be no more media for this indicate to agents that there will be no more media for this
particular media resource related to the current active PLAY request. particular media resource related to the current active PLAY request.
In such cases when the remaining media resources comes to end-of- In such cases when the remaining media resources comes to end-of-
stream they MUST send a PLAY_NOTIFY request using the aggregate stream they MUST send a PLAY_NOTIFY request using the aggregate
control URI to indicate that no more resources remains. control URI to indicate that no more resources remain.
A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream
MUST NOT carry a message body. MUST NOT carry a message body.
This example request notifies the client about a future end-of-stream This example request notifies the client about a future end-of-stream
event: event:
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 854 CSeq: 854
Notify-Reason: end-of-stream Notify-Reason: end-of-stream
skipping to change at page 89, line 43 skipping to change at page 90, line 43
MUST be using the aggregated control URI. MUST be using the aggregated control URI.
This notification MUST be sent for media that are Time-Progressing This notification MUST be sent for media that are Time-Progressing
every time an event happens that changes the basis for making every time an event happens that changes the basis for making
estimates on how the available for play-back media range will estimates on how the available for play-back media range will
progress with wall clock time. In addition it is RECOMMENDED that progress with wall clock time. In addition it is RECOMMENDED that
the server sends these notifications approximately every 5 minutes the server sends these notifications approximately every 5 minutes
for time-progressing content to ensure the long-term stability of the for time-progressing content to ensure the long-term stability of the
client estimation and allowing for clock skew detection by the client estimation and allowing for clock skew detection by the
client. The time between notifications should be greater than 1 client. The time between notifications should be greater than 1
minute and less than 2 hours. Requests for the just mentioned minute and less than 2 hours. For the reasons just explained,
reasons MUST include Media-Range header to provide current Media requests MUST include a Media-Range header to provide current Media
duration and the Range header to indicate the current playing point duration and a Range header to indicate the current playing point and
and any remaining parts of the requested range. any remaining parts of the requested range.
The recommendation for sending updates every 5 minutes is due to The recommendation for sending updates every 5 minutes is due to
any clock skew issues. In 5 minutes the clock skew should not any clock skew issues. In 5 minutes the clock skew should not
become too significant as this is not used for media playback and become too significant as this is not used for media playback and
synchronization, only for determining which content is available synchronization, only for determining which content is available
to the user. to the user.
A PLAY_NOTIFY request with Notify-Reason header set to media- A PLAY_NOTIFY request with Notify-Reason header set to media-
properties-update MUST NOT carry a message body. properties-update MUST NOT carry a message body.
skipping to change at page 91, line 21 skipping to change at page 92, line 21
change was due to the content changing what scale values that is change was due to the content changing what scale values that is
supported. supported.
For media streams being delivered using RTP also a RTP-Info header For media streams being delivered using RTP also a RTP-Info header
MUST be included. It MUST contain the rtptime parameter with a value MUST be included. It MUST contain the rtptime parameter with a value
corresponding to the point of change in that media and optionally corresponding to the point of change in that media and optionally
also the sequence number. also the sequence number.
PLAY_NOTIFY requests for aggregated sessions MUST use the aggregated PLAY_NOTIFY requests for aggregated sessions MUST use the aggregated
control URI in the request. The scale change for any aggregated control URI in the request. The scale change for any aggregated
session do apply to all media streams part of the aggregate. session applies to all media streams part of the aggregate.
A PLAY_NOTIFY request with Notify-Reason header set to "Scale-Change" A PLAY_NOTIFY request with Notify-Reason header set to "Scale-Change"
MUST NOT carry a message body. MUST NOT carry a message body.
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
Date: Tue, 14 Apr 2008 15:48:06 GMT Date: Tue, 14 Apr 2008 15:48:06 GMT
CSeq: 854 CSeq: 854
Notify-Reason: scale-change Notify-Reason: scale-change
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
Media-Properties: Time-Progressing, Media-Properties: Time-Progressing,
skipping to change at page 95, line 5 skipping to change at page 96, line 5
Session header in the response. Session header in the response.
A TEARDOWN using a media URI in an aggregated session MAY only be A TEARDOWN using a media URI in an aggregated session MAY only be
done in Ready state. Such a request only removes the indicated media done in Ready state. Such a request only removes the indicated media
stream and associated resources from the session. This may result in stream and associated resources from the session. This may result in
a session returning to non-aggregated control, because it only a session returning to non-aggregated control, because it only
contains a single media after the request's completion. A session contains a single media after the request's completion. A session
that will exist after the processing of the TEARDOWN request MUST in that will exist after the processing of the TEARDOWN request MUST in
the response to that TEARDOWN request contain a Session header. Thus the response to that TEARDOWN request contain a Session header. Thus
the presence of the Session header indicates to the receiver of the the presence of the Session header indicates to the receiver of the
response if the session is still existing or has been removed. response if the session is still extant or has been removed.
Example: Example:
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 892 CSeq: 892
Session: 12345678 Session: 12345678
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 892 CSeq: 892
skipping to change at page 95, line 35 skipping to change at page 96, line 35
in the Terminate-Reason header (Section 18.52). in the Terminate-Reason header (Section 18.52).
When a RTSP client has maintained a RTSP session that otherwise is When a RTSP client has maintained a RTSP session that otherwise is
inactive for an extended period of time the server may reclaim the inactive for an extended period of time the server may reclaim the
resources. That is done by issuing a TEARDOWN request with the resources. That is done by issuing a TEARDOWN request with the
Terminate-Reason set to "Session-Timeout". This MAY be done when the Terminate-Reason set to "Session-Timeout". This MAY be done when the
client has been inactive in the RTSP session for more than one client has been inactive in the RTSP session for more than one
Session Timeout period (Section 18.49). However, the server is Session Timeout period (Section 18.49). However, the server is
RECOMMENDED to not perform this operation until an extended period of RECOMMENDED to not perform this operation until an extended period of
inactivity of 10 times the Session Timeout period has passed. It is inactivity of 10 times the Session Timeout period has passed. It is
to the operator of the RTSP server to actually configure how long up to the operator of the RTSP server to actually configure how long
this extended period of inactivity is. An operator should take into this extended period of inactivity is. An operator should take into
account when doing this configuration what the served content is and account when doing this configuration what the served content is and
what this means for the extended period of inactivity. what this means for the extended period of inactivity.
In case the server needs to stop providing service to the established In case the server needs to stop providing service to the established
sessions and there is no server to point at in a REDIRECT request, sessions and there is no server to point at in a REDIRECT request,
then TEARDOWN SHALL be used to terminate the session. This method then TEARDOWN SHALL be used to terminate the session. This method
can also be used when non-recoverable internal errors have happened can also be used when non-recoverable internal errors have happened
and the server has no other option then to terminate the sessions. and the server has no other option then to terminate the sessions.
skipping to change at page 96, line 40 skipping to change at page 97, line 40
URI. If the Session header is present in a request, the value of a URI. If the Session header is present in a request, the value of a
parameter MUST be retrieved in the specified session context. There parameter MUST be retrieved in the specified session context. There
are two ways of specifying the parameters to be retrieved. are two ways of specifying the parameters to be retrieved.
The first is by including headers which have been defined such that The first is by including headers which have been defined such that
you can use them for this purpose. Headers for this purpose should you can use them for this purpose. Headers for this purpose should
allow empty, or stripped value parts to avoid having to specify bogus allow empty, or stripped value parts to avoid having to specify bogus
data when indicating the desire to retrieve a value. The successful data when indicating the desire to retrieve a value. The successful
completion of the request should also be evident from any filled out completion of the request should also be evident from any filled out
values in the response. The headers in this specification that MAY values in the response. The headers in this specification that MAY
be used for retrieving their current value using GET_PARAMETER below. be used for retrieving their current value using GET_PARAMETER are
Additional headers MAY be specified in the future: listed below; additional headers MAY be specified in the future:
o Accept-Ranges o Accept-Ranges
o Media-Range o Media-Range
o Media-Properties o Media-Properties
o Range o Range
o RTP-Info o RTP-Info
The other way is to specify a message body that lists the The other way is to specify a message body that lists the
parameter(s) that are desired to be retrieved. The Content-Type parameter(s) that are desired to be retrieved. The Content-Type
header (Section 18.19) is used to specify which format the message header (Section 18.19) is used to specify which format the message
body has. If the receiver of the request is not supporting the media body has. If the receiver of the request does not support the media
type used for the message body, it SHALL respond using the error code type used for the message body, it SHALL respond using the error code
415 (Unsupported Media Type). The responder to a GET_PARAMETER 415 (Unsupported Media Type). The responder to a GET_PARAMETER
request MUST use the media type of the request for the response. For request MUST use the media type of the request for the response. For
additional considerations regarding message body negotiation see additional considerations regarding message body negotiation see
Section 9.3. Section 9.3.
RTSP Agents implementing support for responding to GET_PARAMETER RTSP Agents implementing support for responding to GET_PARAMETER
requests SHALL implement the text/parameters format (Appendix F). requests SHALL implement the text/parameters format (Appendix F).
This to ensure that at least one known format for parameter are This to ensure that at least one known format for parameters is
implemented and thus prevent parameter format negotiation failure. implemented and thus prevent parameter format negotiation failure.
Parameters specified within the body of the message must all be Parameters specified within the body of the message must all be
understood by the request receiving agent. If one or more parameters understood by the request receiving agent. If one or more parameters
are not understood a 451 (Parameter Not Understood) MUST be sent are not understood a 451 (Parameter Not Understood) MUST be sent
including a body listing these parameters that weren't understood. including a body listing these parameters that weren't understood.
If all parameters are understood their values are filled in and If all parameters are understood their values are filled in and
returned in the response message body. returned in the response message body.
The method MAY also be used without a message body or any header that The method MAY also be used without a message body or any header that
skipping to change at page 98, line 51 skipping to change at page 99, line 51
When using a message body to list the parameter(s) that are desired When using a message body to list the parameter(s) that are desired
to be set the Content-Type header (Section 18.19) is used to specify to be set the Content-Type header (Section 18.19) is used to specify
which format the message body has. If the receiver of the request is which format the message body has. If the receiver of the request is
not supporting the media type used for the message body, it SHALL not supporting the media type used for the message body, it SHALL
respond using the error code 415 (Unsupported Media Type). For respond using the error code 415 (Unsupported Media Type). For
additional considerations regarding message body negotiation see additional considerations regarding message body negotiation see
Section 9.3. Section 9.3.
RTSP Agents implementing support for responding to SET_PARAMETER RTSP Agents implementing support for responding to SET_PARAMETER
requests SHALL implement the text/parameters format (Appendix F). requests SHALL implement the text/parameters format (Appendix F).
This to ensure that at least one known format for parameters are This to ensure that at least one known format for parameters is
implemented and thus prevent parameter format negotiation failure. implemented and thus prevent parameter format negotiation failure.
A request is RECOMMENDED to only contain a single parameter to allow A request is RECOMMENDED to only contain a single parameter to allow
the client to determine why a particular request failed. If the the client to determine why a particular request failed. If the
request contains several parameters, the server MUST only act on the request contains several parameters, the server MUST only act on the
request if all of the parameters can be set successfully. A server request if all of the parameters can be set successfully. A server
MUST allow a parameter to be set repeatedly to the same value, but it MUST allow a parameter to be set repeatedly to the same value, but it
MAY disallow changing parameter values. If the receiver of the MAY disallow changing parameter values. If the receiver of the
request does not understand or cannot locate a parameter, error 451 request does not understand or cannot locate a parameter, error 451
(Parameter Not Understood) MUST be used. When a parameter is not (Parameter Not Understood) MUST be used. When a parameter is not
skipping to change at page 103, line 12 skipping to change at page 104, line 12
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 conjunction with network address translators that block RTP in conjunction with network address translators that block RTP
traffic over UDP, it may be necessary to interleave RTSP messages and traffic over UDP, it may be necessary to interleave RTSP messages and
media stream data. This interleaving should generally be avoided media stream data. This interleaving should generally be avoided
unless necessary since it complicates client and server operation and unless 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-octet channel identifier, sign (36 decimal), followed by a one-octet 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-octet unsigned integer in network byte order. The stream data two-octet unsigned integer in network octet order (Appendix B of
follows immediately afterwards, without a CRLF, but including the [RFC0791]). The stream data follows immediately afterwards, without
upper-layer protocol headers. Each $ block MUST contain exactly one a CRLF, but including the upper-layer protocol headers. Each $ block
upper-layer protocol data unit, e.g., one RTP packet. MUST contain exactly one upper-layer protocol data unit, e.g., one
RTP packet.
Note that this mechanism does not support larger PDUs than 65535 Note that this mechanism does not support PDUs larger than 65535
bytes, which is the same that regular IPv4 and IPv6 is capable. octets, which matches the maximum payload size of regular, non-
If the media delivery protocol intended to be used has larger PDUs jumbo IPv4 and IPv6 packets. If the media delivery protocol
than that, the definition of such mechanisms usage of this intended to be used has larger PDUs than that, definition of a PDU
mechanism will require the definition of a PDU fragmentation fragmentation mechanism will be required to support embedded
mechanism. binary data.
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 octets | | "$" = 36 | Channel ID | Length in octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Binary data (Length according to Length field) : : Binary data (Length according to Length field) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Embedded Interleaved Binary Data Format Figure 1: Embedded Interleaved Binary Data Format
skipping to change at page 105, line 12 skipping to change at page 106, line 12
S->C: $005{2 octet length}{"length" octets data, w/RTP header} S->C: $005{2 octet length}{"length" octets data, w/RTP header}
S->C: $006{2 octet length}{"length" octets RTCP packet} S->C: $006{2 octet length}{"length" octets RTCP packet}
15. Proxies 15. Proxies
RTSP Proxies are RTSP agents that are located in between a client and RTSP Proxies are RTSP agents that are located in between a client and
a server. A proxy can take on both the role as a client and as a server. A proxy can take on both the role as a client and as
server depending on what it tries to accomplish. RTSP proxies use server depending on what it tries to accomplish. RTSP proxies use
two transport layer connections, one from the RTSP client to the RTSP two transport layer connections, one from the RTSP client to the RTSP
proxy and a second from the RTSP proxy to the RTSP server. Proxies proxy and a second from the RTSP proxy to the RTSP server. Proxies
are introduced for several different reasons and the below listed are are introduced for several different reasons and those listed below
often combined. are often combined.
There are these types of RTSP proxies:
Caching Proxy: This type of proxy is used to reduce the workload on Caching Proxy: This type of proxy is used to reduce the workload on
servers and connections. By caching the description and media servers and connections. By caching the description and media
streams, i.e., the presentation, the proxy can serve a client streams, i.e., the presentation, the proxy can serve a client
with content, but without requesting it from the server once it with content, but without requesting it from the server once it
has been cached and has not become stale. See the caching has been cached and has not become stale. See the caching
Section 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.
skipping to change at page 106, line 16 skipping to change at page 107, line 14
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 also be used 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
skipping to change at page 117, line 16 skipping to change at page 118, line 16
an established session, the client SHOULD send a TEARDOWN request for an established session, the client SHOULD send a TEARDOWN request for
the session, and MAY reestablish the session using the resource the session, and MAY reestablish the session using the resource
indicated by the Location. indicated by the Location.
If the Location header is used in a response it MUST contain an If the Location header is used in a response it MUST contain an
absolute URI pointing out the media resource the client is redirected absolute URI pointing out the media resource the client is redirected
to, the URI MUST NOT only contain the host name. to, the URI MUST NOT only contain the host name.
17.3.1. 300 17.3.1. 300
This response code is not used in RTSP 2.0. For behavior to use with This response code is not used in RTSP 2.0. In the event that an
unknown 3rr status codes, one follows the 302 (Section 17.3.3). unknown 3rr status code is received, the agent SHOULD behave as if a
302 response code had been received (Section 17.3.3).
17.3.2. 301 Moved Permanently 17.3.2. 301 Moved Permanently
The requested resource is moved permanently and resides now at the The requested resource is moved permanently and resides now at the
URI given by the Location header. The user client SHOULD redirect URI given by the Location header. The user client SHOULD redirect
automatically to the given URI. This response MUST NOT contain a automatically to the given URI. This response MUST NOT contain a
message-body. The Location header MUST be included in the response. message-body. The Location header MUST be included in the response.
17.3.3. 302 Found 17.3.3. 302 Found
skipping to change at page 121, line 8 skipping to change at page 122, line 8
The 410 response is primarily intended to assist the task of The 410 response is primarily intended to assist the task of
repository maintenance by notifying the recipient that the resource repository maintenance by notifying the recipient that the resource
is intentionally unavailable and that the server owners desire that is intentionally unavailable and that the server owners desire that
remote links to that resource be removed. Such an event is common remote links to that resource be removed. Such an event is common
for limited-time, promotional services and for resources belonging to for limited-time, promotional services and for resources belonging to
individuals no longer working at the server's site. It is not individuals no longer working at the server's site. It is not
necessary to mark all permanently unavailable resources as "gone" or necessary to mark all permanently unavailable resources as "gone" or
to keep the mark for any length of time -- that is left to the to keep the mark for any length of time -- that is left to the
discretion of the owner of the server. discretion of the owner of the server.
17.4.11. 412 Precondition Failed 17.4.11. 411 Length Required
This error code is not defined for RTSP. This as the use of Content-
Length (Section 18.17) is always required when message bodies are
included in RTSP messages.
17.4.12. 412 Precondition Failed
The precondition given in one or more of the 'if-' request-header The precondition given in one or more of the 'if-' request-header
fields evaluated to false when it was tested on the server. See fields evaluated to false when it was tested on the server. See
these sections for the 'if-' headers: If-Match Section 18.24, If- these sections for the 'if-' headers: If-Match Section 18.24, If-
Modified-Since Section 18.25, and If-None-Match Section 18.26. This Modified-Since Section 18.25, and If-None-Match Section 18.26. This
response code allows the client to place preconditions on the current response code allows the client to place preconditions on the current
resource meta information (header field data) and thus prevent the resource meta information (header field data) and thus prevent the
requested method from being applied to a resource other than the one requested method from being applied to a resource other than the one
intended. intended.
17.4.12. 413 Request Message Body Too Large 17.4.13. 413 Request Message Body Too Large
The server is refusing to process a request because the request The server is refusing to process a request because the request
message body is larger than the server is willing or able to process. message body is larger than the server is willing or able to process.
The server MAY close the connection to prevent the client from The server MAY close the connection to prevent the client from
continuing the request. continuing the request.
If the condition is temporary, the server SHOULD include a Retry- If the condition is temporary, the server SHOULD include a Retry-
After header field to indicate that it is temporary and after what After header field to indicate that it is temporary and after what
time the client MAY try again. time the client MAY try again.
17.4.13. 414 Request-URI Too Long 17.4.14. 414 Request-URI Too Long
The server is refusing to service the request because the Request-URI The server is refusing to service the request because the Request-URI
is longer than the server is willing to interpret. This rare is longer than the server is willing to interpret. This rare
condition is only likely to occur when a client has used a request condition is only likely to occur when a client has used a request
with long query information, when the client has descended into a URI with long query information, when the client has descended into a URI
"black hole" of redirection (e.g., a redirected URI prefix that "black hole" of redirection (e.g., a redirected URI prefix that
points to a suffix of itself), or when the server is under attack by points to a suffix of itself), or when the server is under attack by
a client attempting to exploit security holes present in some servers a client attempting to exploit security holes present in some servers
using fixed-length buffers for reading or manipulating the Request- using fixed-length buffers for reading or manipulating the Request-
URI. URI.
17.4.14. 415 Unsupported Media Type 17.4.15. 415 Unsupported Media Type
The server is refusing to service the request because the message The server is refusing to service the request because the message
body of the request is in a format not supported by the requested body of the request is in a format not supported by the requested
resource for the requested method. resource for the requested method.
17.4.15. 451 Parameter Not Understood 17.4.16. 451 Parameter Not Understood
The recipient of the request does not support one or more parameters The recipient of the request does not support one or more parameters
contained in the request. When returning this error message the contained in the request. When returning this error message the
sender SHOULD return a message body containing the offending sender SHOULD return a message body containing the offending
parameter(s). parameter(s).
17.4.16. 452 reserved 17.4.17. 452 reserved
This status code MUST NOT be used in RTSP 2.0. However, it was This status code MUST NOT be used in RTSP 2.0. However, it was
allowed in RTSP 1.0 [RFC2326]. allowed in RTSP 1.0 [RFC2326].
17.4.17. 453 Not Enough Bandwidth 17.4.18. 453 Not Enough Bandwidth
The request was refused because there was insufficient bandwidth. The request was refused because there was insufficient bandwidth.
This may, for example, be the result of a resource reservation This may, for example, be the result of a resource reservation
failure. failure.
17.4.18. 454 Session Not Found 17.4.19. 454 Session Not Found
The RTSP session identifier in the Session header is missing, The RTSP session identifier in the Session header is missing,
invalid, or has timed out. invalid, or has timed out.
17.4.19. 455 Method Not Valid in This State 17.4.20. 455 Method Not Valid in This State
The client or server cannot process this request in its current The client or server cannot process this request in its current
state. The response MUST contain an Allow header to make error state. The response MUST contain an Allow header to make error
recovery possible. recovery possible.
17.4.20. 456 Header Field Not Valid for Resource 17.4.21. 456 Header Field Not Valid for Resource
The server could not act on a required request header. For example, The server could not act on a required request-header. For example,
if PLAY contains the Range header field but the stream does not allow if PLAY contains the Range header field but the stream does not allow
seeking. This error message may also be used for specifying when the seeking. This error message may also be used for specifying when the
time format in Range is impossible for the resource. In that case time format in Range is impossible for the resource. In that case
the Accept-Ranges header MUST be returned to inform the client of the Accept-Ranges header MUST be returned to inform the client of
which format(s) that are allowed. which format(s) that are allowed.
17.4.21. 457 Invalid Range 17.4.22. 457 Invalid Range
The Range value given is out of bounds, e.g., beyond the end of the The Range value given is out of bounds, e.g., beyond the end of the
presentation. presentation.
17.4.22. 458 Parameter Is Read-Only 17.4.23. 458 Parameter Is Read-Only
The parameter to be set by SET_PARAMETER can be read but not The parameter to be set by SET_PARAMETER can be read but not
modified. When returning this error message the sender SHOULD return modified. When returning this error message the sender SHOULD return
a message body containing the offending parameter(s). a message body containing the offending parameter(s).
17.4.23. 459 Aggregate Operation Not Allowed 17.4.24. 459 Aggregate Operation Not Allowed
The requested method may not be applied on the URI in question since The requested method may not be applied on the URI in question since
it is an aggregate (presentation) URI. The method may be applied on it is an aggregate (presentation) URI. The method may be applied on
a media URI. a media URI.
17.4.24. 460 Only Aggregate Operation Allowed 17.4.25. 460 Only Aggregate Operation Allowed
The requested method may not be applied on the URI in question since The requested method may not be applied on the URI in question since
it is not an aggregate control (presentation) URI. The method may be it is not an aggregate control (presentation) URI. The method may be
applied on the aggregate control URI. applied on the aggregate control URI.
17.4.25. 461 Unsupported Transport 17.4.26. 461 Unsupported Transport
The Transport field did not contain a supported transport The Transport field did not contain a supported transport
specification. specification.
17.4.26. 462 Destination Unreachable 17.4.27. 462 Destination Unreachable
The data transmission channel could not be established because the The data transmission channel could not be established because the
client address could not be reached. This error will most likely be client address could not be reached. This error will most likely be
the result of a client attempt to place an invalid dest_addr the result of a client attempt to place an invalid dest_addr
parameter in the Transport field. parameter in the Transport field.
17.4.27. 463 Destination Prohibited 17.4.28. 463 Destination Prohibited
The data transmission channel was not established because the server The data transmission channel was not established because the server
prohibited access to the client address. This error is most likely prohibited access to the client address. This error is most likely
the result of a client attempt to redirect media traffic to another the result of a client attempt to redirect media traffic to another
destination with a dest_addr parameter in the Transport header. destination with a dest_addr parameter in the Transport header.
17.4.28. 464 Data Transport Not Ready Yet 17.4.29. 464 Data Transport Not Ready Yet
The data transmission channel to the media destination is not yet The data transmission channel to the media destination is not yet
ready for carrying data. However, the responding agent still expects ready for carrying data. However, the responding agent still expects
that the data transmission channel will be established at some point that the data transmission channel will be established at some point
in time. Note, however, that this may result in a permanent failure in time. Note, however, that this may result in a permanent failure
like 462 "Destination Unreachable". like 462 "Destination Unreachable".
An example when this error may occur is in the case a client sends a An example when this error may occur is in the case a client sends a
PLAY request to a server prior to ensuring that the TCP connections PLAY request to a server prior to ensuring that the TCP connections
negotiated for carrying media data was successfully established (In negotiated for carrying media data was successfully established (In
violation of this specification). The server would use this error violation of this specification). The server would use this error
code to indicate that the requested action could not be performed due code to indicate that the requested action could not be performed due
to the failure of completing the connection establishment. to the failure of completing the connection establishment.
17.4.29. 465 Notification Reason Unknown 17.4.30. 465 Notification Reason Unknown
This indicates that the client has received a PLAY_NOTIFY This indicates that the client has received a PLAY_NOTIFY
(Section 13.5) with a Notify-Reason header (Section 18.32) unknown to (Section 13.5) with a Notify-Reason header (Section 18.32) unknown to
the client. the client.
17.4.30. 466 Key Management Error 17.4.31. 466 Key Management Error
This indicates that there has been an error in a Key Management This indicates that there has been an error in a Key Management
function used in conjunction with a request. For example usage of function used in conjunction with a request. For example usage of
MIKEY [RFC3830] according to Appendix C.1.4.1 may result in this MIKEY [RFC3830] according to Appendix C.1.4.1 may result in this
error. error.
17.4.31. 470 Connection Authorization Required 17.4.32. 470 Connection Authorization Required
The secured connection attempt needs user or client authorization The secured connection attempt needs user or client authorization
before proceeding. The next hop's certificate is included in this before proceeding. The next hop's certificate is included in this
response in the Accept-Credentials header. response in the Accept-Credentials header.
17.4.32. 471 Connection Credentials not accepted 17.4.33. 471 Connection Credentials not accepted
When performing a secure connection over multiple connections, an When performing a secure connection over multiple connections, an
intermediary has refused to connect to the next hop and carry out the intermediary has refused to connect to the next hop and carry out the
request due to unacceptable credentials for the used policy. request due to unacceptable credentials for the used policy.
17.4.33. 472 Failure to establish secure connection 17.4.34. 472 Failure to establish secure connection
A proxy fails to establish a secure connection to the next hop RTSP A proxy fails to establish a secure connection to the next hop RTSP
agent. This is primarily caused by a fatal failure at the TLS agent. This is primarily caused by a fatal failure at the TLS
handshake, for example due to server not accepting any cipher suites. handshake, for example due to server not accepting any cipher suites.
17.5. Server Error 5xx 17.5. Server Error 5xx
Response status codes beginning with the digit "5" indicate cases in Response status codes beginning with the digit "5" indicate cases in
which the server is aware that it has erred or is incapable of which the server is aware that it has erred or is incapable of
performing the request The server SHOULD include a message body performing the request The server SHOULD include a message body
skipping to change at page 128, line 14 skipping to change at page 129, line 14
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;
c: header field is copied from the request to the response. c: header field is copied from the request to the response.
An empty entry in the "where" column indicates that the header field G: header field is a general-header and may be present in both
may be present in both requests and responses. requests and responses.
Note: General headers does not always use the "G" value in the where
column. This is due to differencies when the header may be applied
in requests compared to responses. When such differencies exist they
are expressed using two differet rows, one with where being "R" and
one with it being "r".
The "proxy" column describes the operations a proxy may perform on a The "proxy" column describes the operations a proxy may perform on a
header field. An empty proxy column indicates that the proxy MUST header field. An empty proxy column indicates that the proxy MUST
NOT do any changes to that header, all allowed operations are NOT do any changes to that header, all allowed operations are
explicitly stated: explicitly stated:
a: A proxy can add or concatenate the header field if not present. a: A proxy can add or concatenate the header field if not present.
m: A proxy can modify an existing header field value. m: A proxy can modify an existing header field value.
skipping to change at page 129, line 9 skipping to change at page 130, line 19
-: The header field is not applicable. -: The header field is not applicable.
"Optional" means that a Client/Server MAY include the header field in "Optional" means that a Client/Server MAY include the header field in
a request or response. The Client/Server behavior when receiving a request or response. The Client/Server behavior when receiving
such headers varies, for some it may ignore the header field, in such headers varies, for some it may ignore the header field, in
other cases it is a request to process the header. This is regulated other cases it is a request to process the header. This is regulated
by the method and header descriptions. Example of headers that by the method and header descriptions. Example of headers that
require processing are the Require and Proxy-Require header fields require processing are the Require and Proxy-Require header fields
discussed in Section 18.43 and Section 18.37. A "mandatory" header discussed in Section 18.43 and Section 18.37. A "mandatory" header
field MUST be present in a request, and MUST be understood by the field MUST be present in a request, and MUST be understood by the
Client/Server receiving the request. A mandatory response header Client/Server receiving the request. A mandatory response-header
field MUST be present in the response, and the header field MUST be field MUST be present in the response, and the header field MUST be
understood by the Client/Server processing the response. "Not understood by the Client/Server processing the response. "Not
applicable" means that the header field MUST NOT be present in a applicable" means that the header field MUST NOT be present in a
request. If one is placed in a request by mistake, it MUST be request. If one is placed in a request by mistake, it MUST be
ignored by the Client/Server receiving the request. Similarly, a ignored by the Client/Server receiving the request. Similarly, a
header field labeled "not applicable" for a response means that the header field labeled "not applicable" for a response means that the
Client/Server MUST NOT place the header field in the response, and Client/Server MUST NOT place the header field in the response, and
the Client/Server MUST ignore the header field in the response. the Client/Server MUST ignore the header field in the response.
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 a 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 | DE | OPT | STP | PLY | PSE | TRD | | Header | Where | Pro | DE | OPT | STP | PLY | PSE | TRD |
| | | xy | S | | | | | | | | | xy | S | | | | | |
+------------------+-------+-----+----+-----+-----+-----+-----+-----+ +------------------+-------+-----+----+-----+-----+-----+-----+-----+
| Accept | R | | o | - | - | - | - | - | | Accept | R | | o | - | - | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Accept-Credentia | R | rm | o | o | o | o | o | o | | Accept-Credentia | R | rm | o | o | o | o | o | o |
| ls | | | | | | | | | | ls | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| 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 | G | 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 |
| | | | | | | | | | | | | | | | | | | |
| Authentication-I | r | | o | o | o | o | o | o/- | | Authentication-I | r | | o | o | o | o | o | o/- |
| nfo | | | | | | | | | | nfo | | | | | | | | |
| | | | | | | | | |
| 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 | G | r | o | - | o | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Connection | | ad | o | o | o | o | o | o | | Connection | G | ad | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Connection-Crede | 470,4 | ar | o | o | o | o | o | o | | Connection-Crede | 470,4 | ar | o | o | o | o | o | o |
| ntials | 07 | | | | | | | | | ntials | 07 | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Content-Base | r | | o | - | - | - | - | - | | Content-Base | r | | o | - | - | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Content-Base | 4xx,5 | | o | o | o | o | o | o | | Content-Base | 4xx,5 | | o | o | o | o | o | o |
| | xx | | | | | | | | | | xx | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Content-Encoding | R | r | - | - | - | - | - | - | | Content-Encoding | R | r | - | - | - | - | - | - |
skipping to change at page 130, line 45 skipping to change at page 132, line 4
| | | | | | | | | | | | | | | | | | | |
| Content-Length | r | r | * | - | - | - | - | - | | Content-Length | r | r | * | - | - | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Content-Length | 4xx,5 | r | * | * | * | * | * | * | | Content-Length | 4xx,5 | r | * | * | * | * | * | * |
| | xx | | | | | | | | | | xx | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Content-Location | r | r | o | - | - | - | - | - | | Content-Location | r | r | o | - | - | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Content-Location | 4xx,5 | r | o | o | o | o | o | o | | Content-Location | 4xx,5 | r | o | o | o | o | o | o |
| | xx | | | | | | | | | | xx | | | | | | | |
| | | | | | | | | |
| Content-Type | r | r | * | - | - | - | - | - | | Content-Type | r | r | * | - | - | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Content-Type | 4xx,5 | ar | * | * | * | * | * | * | | Content-Type | 4xx,5 | ar | * | * | * | * | * | * |
| | xx | | | | | | | | | | xx | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| CSeq | Rc | rm | m | m | m | m | m | m | | CSeq | Gc | rm | m | m | m | m | m | m |
| Date | | am | o/ | o/* | o/* | o/* | o/* | o/* | | | | | | | | | | |
| Date | G | 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-Sinc | R | r | o | - | o | - | - | - | | If-Modified-Sinc | R | r | o | - | o | - | - | - |
| e | | | | | | | | | | e | | | | | | | | |
skipping to change at page 131, line 30 skipping to change at page 132, line 37
| Location | 3rr | | o | o | o | o | o | o | | Location | 3rr | | o | o | o | o | o | o |
+------------------+-------+-----+----+-----+-----+-----+-----+-----+ +------------------+-------+-----+----+-----+-----+-----+-----+-----+
Table 9: Overview of RTSP header fields (A-L) related to methods Table 9: Overview of RTSP header fields (A-L) related to methods
DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.
+------------------+---------+-----+----+----+----+-----+-----+-----+ +------------------+---------+-----+----+----+----+-----+-----+-----+
| Header | Where | Pro | DE | OP | ST | PLY | PSE | TRD | | Header | Where | Pro | DE | OP | ST | PLY | PSE | TRD |
| | | xy | S | T | P | | | | | | | xy | S | T | P | | | |
+------------------+---------+-----+----+----+----+-----+-----+-----+ +------------------+---------+-----+----+----+----+-----+-----+-----+
| Media- | | | - | - | m | m | m | - | | Media- | G | | - | - | m | m | m | - |
| Properties | | | | | | | | | | Properties | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Media-Range | | | - | - | m | m | m | - | | Media-Range | G | | - | - | m | m | m | - |
| | | | | | | | | | | | | | | | | | | |
| MTag | r | r | o | - | o | - | - | - | | MTag | r | r | o | - | o | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Pipelined-Reques | | amd | - | o | o | o | o | o | | Pipelined-Reques | G | amd | - | o | o | o | o | o |
| ts | | r | | | | | | | | ts | | r | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Proxy- | 407 | amr | m | m | m | m | m | m | | Proxy- | 407 | amr | m | m | m | m | m | m |
| Authenticate | | | | | | | | | | Authenticate | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Proxy-Authentica | r | amd | o | o | o | o | o | o/- | | Proxy-Authentica | r | amd | o | o | o | o | o | o/- |
| tion-Info | | r | | | | | | | | tion-Info | | r | | | | | | |
| | | | | | | | | |
| 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- Supported | R | amr | c | c | c | c | c | c |
| | | | | | | | | | | | | | | | | | | |
| Proxy- Supported | r | | c | c | c | c | c | c | | Proxy- Supported | r | | c | c | c | c | c | c |
| | | | | | | | | | | | | | | | | | | |
| 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 | - | - |
| | | | | | | | | | | | | | | | | | | |
skipping to change at page 133, line 4 skipping to change at page 134, line 11
| | | | | | | | | | | | | | | | | | | |
| Session | r | r | - | c | m | m | m | o | | Session | r | r | - | c | m | m | m | o |
| | | | | | | | | | | | | | | | | | | |
| Speed | R | adm | - | - | - | o | - | - | | Speed | R | adm | - | - | - | o | - | - |
| | | r | | | | | | | | | | r | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Speed | r | adm | - | - | - | c | - | - | | Speed | r | adm | - | - | - | c | - | - |
| | | r | | | | | | | | | | r | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Supported | R | amr | o | o | o | o | o | o | | Supported | R | amr | o | o | o | o | o | o |
| | | | | | | | | |
| Supported | r | amr | c | c | c | c | c | c | | Supported | r | amr | c | c | c | c | c | c |
| | | | | | | | | | | | | | | | | | | |
| Terminate-Reason | R | r | - | - | - | - | - | - | | Terminate-Reason | R | r | - | - | - | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Timestamp | R | adm | o | o | o | o | o | o | | Timestamp | R | adm | o | o | o | o | o | o |
| | | r | | | | | | | | | | r | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Timestamp | c | adm | m | m | m | m | m | m | | Timestamp | c | adm | m | m | m | m | m | m |
| | | r | | | | | | | | | | r | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Transport | | mr | - | - | m | - | - | - | | Transport | G | mr | - | - | m | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Unsupported | r | | c | c | c | c | c | c | | Unsupported | r | | c | c | c | c | c | c |
| | | | | | | | | | | | | | | | | | | |
| User-Agent | R | | m* | m* | m* | m* | m* | m* | | User-Agent | R | | m* | m* | m* | m* | m* | m* |
| | | | | | | | | | | | | | | | | | | |
| Via | R | amr | o | o | o | o | o | o | | Via | R | amr | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Via | c | dr | m | m | m | m | m | m | | Via | c | dr | m | m | m | m | m | m |
| | | | | | | | | | | | | | | | | | | |
| WWW- | 401 | | m | m | m | m | m | m | | WWW- | 401 | | m | m | m | m | m | m |
skipping to change at page 133, line 42 skipping to change at page 134, line 50
| Header | Where | Proxy | GPR | SPR | RDR | PNY | | Header | Where | Proxy | GPR | SPR | RDR | PNY |
+-------------------------+---------+-------+-----+-----+-----+-----+ +-------------------------+---------+-------+-----+-----+-----+-----+
| Accept | R | arm | o | o | - | - | | Accept | R | arm | o | o | - | - |
| | | | | | | | | | | | | | | |
| Accept-Credentials | R | rm | o | o | o | - | | Accept-Credentials | R | rm | o | o | o | - |
| | | | | | | | | | | | | | | |
| Accept-Encoding | R | r | o | o | o | - | | Accept-Encoding | R | r | o | o | o | - |
| | | | | | | | | | | | | | | |
| Accept-Language | R | r | o | o | o | - | | Accept-Language | R | r | o | o | o | - |
| | | | | | | | | | | | | | | |
| Accept-Ranges | | rm | o | - | - | - | | Accept-Ranges | G | rm | o | - | - | - |
| | | | | | | | | | | | | | | |
| Allow | 405 | amr | m | m | m | - | | Allow | 405 | amr | m | m | m | - |
| | | | | | | | | | | | | | | |
| Authentication-Info | r | | o/- | o/- | - | - | | Authentication-Info | r | | o/- | o/- | - | - |
| | | | | | | | | | | | | | | |
| Authorization | R | | o | o | o | - | | Authorization | R | | o | o | o | - |
| | | | | | | | | | | | | | | |
| Bandwidth | R | | - | o | - | - | | Bandwidth | R | | - | o | - | - |
| | | | | | | | | | | | | | | |
| Blocksize | R | | - | o | - | - | | Blocksize | R | | - | o | - | - |
| | | | | | | | | | | | | | | |
| Cache-Control | | r | o | o | - | - | | Cache-Control | G | r | o | o | - | - |
| | | | | | | | | | | | | | | |
| Connection | | | o | o | o | o | | Connection | G | | 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 135, line 44 skipping to change at page 137, line 4
| Notify-Reason | R | | - | - | - | m | | Notify-Reason | R | | - | - | - | m |
| | | | | | | | | | | | | | | |
| Pipelined-Requests | R | amdr | o | o | - | - | | Pipelined-Requests | R | amdr | o | o | - | - |
| | | | | | | | | | | | | | | |
| Proxy-Authenticate | 407 | amdr | m | m | m | - | | Proxy-Authenticate | 407 | amdr | m | m | m | - |
| | | | | | | | | | | | | | | |
| Proxy-Authentication-In | r | amdr | o/- | o/- | - | - | | Proxy-Authentication-In | r | amdr | o/- | o/- | - | - |
| fo | | | | | | | | fo | | | | | | |
| | | | | | | | | | | | | | | |
| Proxy-Authorization | R | amdr | o | o | o | - | | Proxy-Authorization | R | amdr | o | o | o | - |
| | | | | | | |
| Proxy-Require | R | ar | o | o | o | - | | Proxy-Require | R | ar | o | o | o | - |
| | | | | | | | | | | | | | | |
| Proxy-Supported | R | amr | c | c | c | - | | Proxy-Supported | R | amr | c | c | c | - |
| | | | | | | | | | | | | | | |
| Proxy-Supported | r | | c | c | c | - | | Proxy-Supported | r | | c | c | c | - |
| | | | | | | | | | | | | | | |
| Public | 501 | admr | m | m | m | - | | Public | 501 | admr | m | m | m | - |
+-------------------------+---------+-------+-----+-----+-----+-----+ +-------------------------+---------+-------+-----+-----+-----+-----+
Table 11: Overview of RTSP header fields (A-P) related to methods Table 11: Overview of RTSP header fields (A-P) related to methods
skipping to change at page 136, line 29 skipping to change at page 137, line 35
| Require | R | r | o | o | o | - | | Require | R | r | o | o | o | - |
| | | | | | | | | | | | | | | |
| Retry-After | 3rr,503 | | o | o | - | - | | Retry-After | 3rr,503 | | o | o | - | - |
| | | | | | | | | | | | | | | |
| Retry-After | 413 | | o | o | - | - | | Retry-After | 413 | | o | o | - | - |
| | | | | | | | | | | | | | | |
| RTP-Info | R | r | o | - | - | C | | RTP-Info | R | r | o | - | - | C |
| | | | | | | | | | | | | | | |
| RTP-Info | r | r | c | - | - | - | | RTP-Info | r | r | c | - | - | - |
| | | | | | | | | | | | | | | |
| Scale | | | - | - | - | c | | Scale | G | | - | - | - | c |
| | | | | | | | | | | | | | | |
| Seek-Style | | | - | - | - | - | | Seek-Style | G | | - | - | - | - |
| | | | | | | | | | | | | | | |
| Server | R | r | o | o | o | o | | Server | R | r | o | o | o | o |
| | | | | | | | | | | | | | | |
| Server | r | r | o | o | - | - | | Server | r | r | o | o | - | - |
| | | | | | | | | | | | | | | |
| Session | R | r | o | o | o | m | | Session | R | r | o | o | o | m |
| | | | | | | | | | | | | | | |
| Session | r | r | c | c | o | m | | Session | r | r | c | c | o | m |
| | | | | | | | | | | | | | | |
| Speed | | | - | - | - | - | | Speed | G | | - | - | - | - |
| | | | | | | | | | | | | | | |
| Supported | R | adrm | o | o | o | - | | Supported | R | adrm | o | o | o | - |
| | | | | | | | | | | | | | | |
| Supported | r | adrm | c | c | c | - | | Supported | r | adrm | c | c | c | - |
| | | | | | | |
| Terminate-Reason | R | r | - | - | m | - | | Terminate-Reason | R | r | - | - | m | - |
| | | | | | | | | | | | | | | |
| Timestamp | R | adrm | o | o | o | - | | Timestamp | R | adrm | o | o | o | - |
| | | | | | | | | | | | | | | |
| Timestamp | c | adrm | m | m | m | - | | Timestamp | c | adrm | m | m | m | - |
| Transport | | mr | - | - | - | - | | | | | | | | |
| Transport | G | 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 | - |
skipping to change at page 138, line 13 skipping to change at page 139, line 19
application/example media type with a 0.7 quality rating. application/example media type with a 0.7 quality rating.
If no Accept header field is present, then it is assumed that the If no Accept header field is present, then it is assumed that the
client accepts all media types. If an Accept header field is client accepts all media types. If an Accept header field is
present, and if the server cannot send a response which is acceptable present, and if the server cannot send a response which is acceptable
according to the combined Accept field value, then the server SHOULD according to the combined Accept field value, then the server SHOULD
send a 406 (not acceptable) response. send a 406 (not acceptable) response.
18.2. Accept-Credentials 18.2. Accept-Credentials
The Accept-Credentials header is a request header used to indicate to The Accept-Credentials header is a request-header used to indicate to
any trusted intermediary how to handle further secured connections to any trusted intermediary how to handle further secured connections to
proxies or servers. See Section 19 for the usage of this header. It proxies or servers. See Section 19 for the usage of this header. It
MUST NOT be included in server to client requests. MUST NOT be included in server to client requests.
In a request the header MUST contain the method (User, Proxy, or Any) In a request the header MUST contain the method (User, Proxy, or Any)
for approving credentials selected by the requester. The method MUST for approving credentials selected by the requester. The method MUST
NOT be changed by any proxy, unless it is "Proxy" when a proxy MAY NOT be changed by any proxy, unless it is "Proxy" when a proxy MAY
change it to "user" to take the role of user approving each further change it to "user" to take the role of user approving each further
hop. If the method is "User" the header contains zero or more of hop. If the method is "User" the header contains zero or more of
credentials that the client accepts. The header may contain zero credentials that the client accepts. The header may contain zero
credentials in the first RTSP request to a RTSP server when using the credentials in the first RTSP request to a RTSP server when using the
"User" method. This is because the client has not yet received any "User" method. This is because the client has not yet received any
credentials to accept. Each credential MUST consist of one URI credentials to accept. Each credential MUST consist of one URI
identifying the proxy or server, the hash algorithm identifier, and identifying the proxy or server, the hash algorithm identifier, and
the hash over that agent's ASN.1 distinguished encoding rules (DER) the hash over that agent's ASN.1 distinguished encoding rules (DER)
encoded certificate [RFC5280] in Base64 [RFC4648]. All RTSP clients encoded certificate [RFC5280] in BASE64, according to Section 4 of
and proxies MUST implement the SHA-256[FIPS-pub-180-2] algorithm for [RFC4648] and where the padding bits are set to zero. All RTSP
computation of the hash of the DER encoded certificate. The SHA-256 clients and proxies MUST implement the SHA-256[FIPS-pub-180-2]
algorithm is identified by the token "sha-256". algorithm for computation of the hash of the DER encoded certificate.
The SHA-256 algorithm is identified by the 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
exists. exists.
Example: Example:
skipping to change at page 141, line 11 skipping to change at page 142, line 17
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, clock Accept-Ranges: npt, smpte, clock
The syntax is defined in Section 20.2.3. The syntax is defined in Section 20.2.3.
18.6. Allow 18.6. Allow
The Allow message-header field lists the methods supported by the The Allow message-body header field lists the methods supported by
resource identified by the Request-URI. The purpose of this field is the resource identified by the Request-URI. The purpose of this
to inform the recipient of the complete set of valid methods field is to inform the recipient of the complete set of valid methods
associated with the resource. An Allow header field MUST be present associated with the resource. An Allow header field MUST be present
in a 405 (Method Not Allowed) response. The Allow header MUST also in a 405 (Method Not Allowed) response. The Allow header MUST also
be present in all OPTIONS responses where the content of the header be present in all OPTIONS responses where the content of the header
will not include exactly the same methods as listed in the Public will not include exactly the same methods as listed in the Public
header. header.
The Allow message-header MUST also be included in SETUP and DESCRIBE The Allow message-body header MUST also be included in SETUP and
responses, if the methods allowed for the resource is different from DESCRIBE responses, if the methods allowed for the resource are
the complete set of methods defined in this memo. different from the complete set of methods defined in this memo.
Example of use: Example of use:
Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE
18.7. Authentication-Info 18.7. Authentication-Info
The Authentication-Info header is used by the server to communicate The Authentication-Info response-header is used by the server to
some information regarding the successful authentication in the communicate some information regarding the successful authentication
response message. This usage of this header is specified in in the response message. This usage of this header is specified in
[RFC2617] with some RTSP clarification in Section 19.1. This header [RFC2617] with some RTSP clarification in Section 19.1. This header
MUST only be used in response messages related to client to server MUST only be used in response messages related to client to server
requests. requests.
18.8. Authorization 18.8. Authorization
An RTSP client that wishes to authenticate itself with a server using An RTSP client that wishes to authenticate itself with a server using
authentication mechanism from HTTP [RFC2617] , usually, but not authentication mechanism from HTTP [RFC2617] , usually, but not
necessarily, after receiving a 401 response, does so by including an necessarily, after receiving a 401 response, does so by including an
Authorization request-header field with the request. The Authorization request-header field with the request. The
skipping to change at page 142, line 38 skipping to change at page 143, line 45
18.9. Bandwidth 18.9. Bandwidth
The Bandwidth request-header field describes the estimated bandwidth The Bandwidth request-header field describes the estimated bandwidth
available to the client, expressed as a positive integer and measured available to the client, expressed as a positive integer and measured
in kilobits per second. The bandwidth available to the client may in kilobits per second. The bandwidth available to the client may
change during an RTSP session, e.g., due to mobility, congestion, change during an RTSP session, e.g., due to mobility, congestion,
etc. etc.
Clients may not be able to accurately determine the available Clients may not be able to accurately determine the available
bandwidth, for example because first hop is not a bottleneck. For bandwidth, for example because the first hop is not a bottleneck.
example most local area networks (LAN) will not be a bottleneck if For example most local area networks (LAN) will not be a bottleneck
the server is not in the same LAN. Thus link speeds of WLAN or if the server is not in the same LAN. Thus link speeds of WLAN or
Ethernet networks are normally not a basis for estimating the Ethernet networks are normally not a basis for estimating the
available bandwidth. Cellular devices or other devices directly available bandwidth. Cellular devices or other devices directly
connected to a modem or connection enabling device may more connected to a modem or connection enabling device may more
accurately estimate the bottleneck bandwidth and what is a reasonable accurately estimate the bottleneck bandwidth and what is a reasonable
share of it for RTSP controlled media. The client will also need to share of it for RTSP controlled media. The client will also need to
take into account other traffic sharing the bottleneck. For example take into account other traffic sharing the bottleneck. For example
by only assigning a certain fraction to RTSP and its media streams. by only assigning a certain fraction to RTSP and its media streams.
It is RECOMMENDED that only clients that 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.
skipping to change at page 146, line 26 skipping to change at page 147, line 27
corresponding additional header field(s), since the additional header corresponding additional header field(s), since the additional header
field may not be sent if there are no parameters associated with that field may not be sent if there are no parameters associated with that
connection option. connection option.
Message headers listed in the Connection header MUST NOT include end- Message headers listed in the Connection header MUST NOT include end-
to-end headers, such as Cache-Control. to-end headers, such as Cache-Control.
RTSP 2.0 defines the "close" connection option for the sender to RTSP 2.0 defines the "close" connection option for the sender to
signal that the connection will be closed after completion of the signal that the connection will be closed after completion of the
response. For example, Connection: close in either the request or response. For example, Connection: close in either the request or
the response header fields indicates that the connection SHOULD NOT the response-header fields indicates that the connection SHOULD NOT
be considered `persistent' (Section 10.2) after the current request/ be considered `persistent' (Section 10.2) after the current request/
response is complete. response is complete.
The use of the connection option "close" in RTSP messages SHOULD be The use of the connection option "close" in RTSP messages SHOULD be
limited to error messages when the server is unable to recover and limited to error messages when the server is unable to recover and
therefore sees it necessary to close the connection. The reason is therefore sees it necessary to close the connection. The reason is
that the client has the choice of continuing using a connection that the client has the choice of continuing using a connection
indefinitely, as long as it sends valid messages. indefinitely, as long as it sends valid messages.
18.13. Connection-Credentials 18.13. Connection-Credentials
The Connection-Credentials response header is used to carry the chain The Connection-Credentials response-header is used to carry the chain
of credentials for any next hop that needs to be approved by the of credentials for any next hop that needs to be approved by the
requester. It MUST only be used in server to client responses. requester. It MUST only be used in server to client responses.
The Connection-Credentials header in an RTSP response MUST, if The Connection-Credentials header in an RTSP response MUST, if
included, contain the credential information (in form of a list of included, contain the credential information (in form of a list of
certificates providing the chain of certification) of the next hop certificates providing the chain of certification) of the next hop
that an intermediary needs to securely connect to. The header MUST that an intermediary needs to securely connect to. The header MUST
include the URI of the next hop (proxy or server) and a base64 include the URI of the next hop (proxy or server) and a BASE64
[RFC4648] encoded binary structure containing a sequence of DER (according to Section 4 of [RFC4648] and where the padding bits are
encoded X.509v3 certificates[RFC5280] . set to zero) encoded binary structure containing a sequence of DER
encoded X.509v3 certificates [RFC5280].
The binary structure starts with the number of certificates The binary structure starts with the number of certificates
(NR_CERTS) included as a 16 bit unsigned integer. This is followed (NR_CERTS) included as a 16 bit unsigned integer. This is followed
by NR_CERTS number of 16 bit unsigned integers providing the size in by NR_CERTS number of 16 bit unsigned integers providing the size in
octets of each DER encoded certificate. This is followed by NR_CERTS octets of each DER encoded certificate. This is followed by NR_CERTS
number of DER encoded X.509v3 certificates in a sequence (chain). number of DER encoded X.509v3 certificates in a sequence (chain).
This format is exemplified in Figure 2. The proxy or server's This format is exemplified in Figure 2. The proxy or server's
certificate must come first in the structure. Each following certificate must come first in the structure. Each following
certificate must directly certify the one preceding it. Because certificate must directly certify the one preceding it. Because
certificate validation requires that root keys be distributed certificate validation requires that root keys be distributed
skipping to change at page 147, line 39 skipping to change at page 148, line 43
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DER Encoding of Certificate #2 : : DER Encoding of Certificate #2 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DER Encoding of Certificate #3 : : DER Encoding of Certificate #3 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Connection-Credentials header's Certificate Format Example Figure 2: Connection-Credentials header's Certificate Format Example
18.14. Content-Base 18.14. Content-Base
The Content-Base message-header field may be used to specify the base The Content-Base message-body header field may be used to specify the
URI for resolving relative URIs within the message body. base URI for resolving relative URIs within the message body.
Content-Base: rtsp://media.example.com/movie/twister/ Content-Base: rtsp://media.example.com/movie/twister/
If no Content-Base field is present, the base URI of an message body If no Content-Base field is present, the base URI of an message body
is defined either by its Content-Location (if that Content-Location is defined either by its Content-Location (if that Content-Location
URI is an absolute URI) or the URI used to initiate the request, in URI is an absolute URI) or the URI used to initiate the request, in
that order of precedence. Note, however, that the base URI of the that order of precedence. Note, however, that the base URI of the
contents within the message-body may be redefined within that contents within the message-body may be redefined within that
message-body. message-body.
18.15. Content-Encoding 18.15. Content-Encoding
The Content-Encoding message-header field is used as a modifier to The Content-Encoding message-body header field is used as a modifier
the media-type. When present, its value indicates what additional to the media-type. When present, its value indicates what additional
content codings have been applied to the message body, and thus what content codings have been applied to the message body, and thus what
decoding mechanisms must be applied in order to obtain the media-type decoding mechanisms must be applied in order to obtain the media-type
referenced by the Content-Type header field. Content-Encoding is referenced by the Content-Type header field. Content-Encoding is
primarily used to allow a document to be compressed without losing primarily used to allow a document to be compressed without losing
the identity of its underlying media type. the identity of its underlying media type.
The content-coding is a characteristic of the message body identified The content-coding is a characteristic of the message body identified
by the Request-URI. Typically, the message body is stored with this by the Request-URI. Typically, the message body is stored with this
encoding and is only decoded before rendering or analogous usage. encoding and is only decoded before rendering or analogous usage.
However, an RTSP proxy MAY modify the content-coding if the new However, an RTSP proxy MAY modify the content-coding if the new
skipping to change at page 148, line 38 skipping to change at page 149, line 40
status code of 415 (Unsupported Media Type). status code of 415 (Unsupported Media Type).
If multiple encodings have been applied to a message body, the If multiple encodings have been applied to a message body, the
content codings MUST be listed in the order in which they were content codings MUST be listed in the order in which they were
applied, first to last from left to right. Additional information applied, first to last from left to right. Additional information
about the encoding parameters MAY be provided by other header fields about the encoding parameters MAY be provided by other header fields
not defined by this specification. not defined by this specification.
18.16. Content-Language 18.16. Content-Language
The Content-Language message-header field describes the natural The Content-Language message-body header field describes the natural
language(s) of the intended audience for the enclosed message body. language(s) of the intended audience for the enclosed message body.
Note that this might not be equivalent to all the languages used Note that this might not be equivalent to all the languages used
within the message body. within the message body.
Language tags are mentioned in Section 18.4. The primary purpose of Language tags are mentioned in Section 18.4. The primary purpose of
Content-Language is to allow a user to identify and differentiate Content-Language is to allow a user to identify and differentiate
entities according to the user's own preferred language. Thus, if entities according to the user's own preferred language. Thus, if
the body content is intended only for a Danish-literate audience, the the body content is intended only for a Danish-literate audience, the
appropriate field is appropriate field is
Content-Language: da Content-Language: da
skipping to change at page 149, line 30 skipping to change at page 150, line 30
audiences. An example would be a beginner's language primer, such as audiences. An example would be a beginner's language primer, such as
"A First Lesson in Latin," which is clearly intended to be used by an "A First Lesson in Latin," which is clearly intended to be used by an
English-literate audience. In this case, the Content-Language would English-literate audience. In this case, the Content-Language would
properly only include "en". properly only include "en".
Content-Language MAY be applied to any media type -- it is not Content-Language MAY be applied to any media type -- it is not
limited to textual documents. limited to textual documents.
18.17. Content-Length 18.17. Content-Length
The Content-Length message-header field contains the length of the The Content-Length message-body header field contains the length of
message body of the RTSP message (i.e., after the double CRLF the message body of the RTSP message (i.e., after the double CRLF
following the last header). Unlike HTTP, it MUST be included in all following the last header). 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.18. Content-Location 18.18. Content-Location
The Content-Location message-header field MAY be used to supply the The Content-Location message-body header field MAY be used to supply
resource location for the message body enclosed in the message when the resource location for the message body enclosed in the message
that body is accessible from a location separate from the requested when that body is accessible from a location separate from the
resource's URI. A server SHOULD provide a Content-Location for the requested resource's URI. A server SHOULD provide a Content-Location
variant corresponding to the response message body; especially in the for the variant corresponding to the response message body;
case where a resource has multiple variants associated with it, and especially in the case where a resource has multiple variants
those entities actually have separate locations by which they might associated with it, and those entities actually have separate
be individually accessed, the server SHOULD provide a Content- locations by which they might be individually accessed, the server
Location for the particular variant which is returned. SHOULD provide a Content-Location 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 the resource identifier
("rtsp://a.example.com/movie/Plan9FromOuterSpace/FullHD.sdp") is ("rtsp://a.example.com/movie/Plan9FromOuterSpace/FullHD.sdp") is
provided in Content-Location, while the description is still a valid provided in Content-Location, while the description is still a valid
skipping to change at page 150, line 49 skipping to change at page 151, line 50
have still been provided under the same request URI. have still been provided under the same request URI.
Note also, as in most cases the URI used in the DESCRIBE and the Note also, as in most cases the URI used in the DESCRIBE and the
SETUP requests are different, the URI provided in a DESCRIBE Content- SETUP requests are different, the URI provided in a DESCRIBE Content-
Location response can't directly be used in a SETUP request. Instead Location response can't directly be used in a SETUP request. Instead
the extra step of resolving URIs combined with the media descriptions the extra step of resolving URIs combined with the media descriptions
indication, like with SDP's a=control attribute. indication, like with SDP's a=control attribute.
18.19. Content-Type 18.19. Content-Type
The Content-Type message-header indicates the media type of the The Content-Type message-body header indicates the media type of the
message body sent to the recipient. Note that the content types message body sent to the recipient. Note that the content types
suitable for RTSP are likely to be restricted in practice to suitable for RTSP are likely to be restricted in practice to
presentation descriptions and parameter-value types. presentation descriptions and parameter-value types.
18.20. CSeq 18.20. CSeq
The CSeq general-header field specifies the sequence number for an The CSeq general-header field specifies the sequence number (integer)
RTSP request-response pair. This field MUST be present in all for an RTSP request-response pair. This field MUST be present in all
requests and responses. For every RTSP request containing the given requests and responses. RTSP agents maintain a sequence number
sequence number, the corresponding response will have the same series for each responder to which they have an open message
number. For each new RTSP request an agent creates the CSeq value transport channel. For each new RTSP request an agent originates on
MUST be incremented by one. This primarily allows for associating a particular RTSP message transport the CSeq value MUST be
requests with responses. It also enables detecting loss of a request incremented by one. The initial sequence number MAY be any number,
and await a retransmission prior to processing a sub-sequent request however, it is RECOMMENDED to start at 0. Each sequence number
when using unreliable transport. Any retransmitted request MUST series is unique between each requester and responder, i.e., the
contain the same sequence number as the original, i.e., the sequence client has one series for its requests to a server and the server has
number is not incremented for retransmissions of the same request. another when sending requests to the client. Each requester and
Agents receiving a request over a reliable transport with an in-order responder is identified by its socket address (IP address and port
delivery MUST ignore how the sequence value increments, i.e. it can number), i.e., per direction of a TCP connection. Any retransmitted
increment with other values than 1. The initial sequence number MAY request MUST contain the same sequence number as the original, i.e.,
be any number, however, it is RECOMMENDED to start at 0. Each the sequence number is not incremented for retransmissions of the
sequence number series is unique between each requester and same request. The RTSP agent receiving requests MUST process the
responder, i.e., the client has one series for its request to a requests arriving on a particular transport in the order of the
server and the server has another when sending request to the client. sequence numbers. Responses are sent in the order that they are
Each requester and responder is identified with its socket address generated. The RTSP response MUST have the same sequence number as
(IP address and port number), i.e., per direction of a TCP was present in the corresponding request. A RTSP Agent receiving a
connection. response MAY receive the responses out of order compared to the order
of the requests it sent. Thus, the agent MUST use the sequence
The above rules may appear unnecessary loose. However, they are number in the response to pair it with the corresponding request.
allowing for a behavior which is not uncommon. When using multiple
connections in sequence it may still be easiest to use a single
sequence number series for a client connecting with a particular
server. Thus, the initial sequence number may be arbitrary depending
on the number of previous requests.
Proxies that aggregate several client sessions on the same transport The main purpose of the sequence number is to map responses to
will have to ensure that the requests sent towards a particular requests.
server have a joint sequence number space. A proxy having one client
with concurrent sessions with two different servers using the same
client proxy connection can avoid rewriting on the proxy to server
connection. The latest equally applies to server to client requests,
where one server may have multiple clients over the same proxy. The
proxy can use only one joint sequence number space for a given
transport connection to a particular server for sending request, as
the identification of the RTSP agents, i.e., the proxy and the server
is based on the IP address and port number. This requires that the
proxy renumbers the CSeq header field in both requests and responses
to fulfill the rules for the header.
An RTSP proxy MUST renumber the RTSP request from RTSP agents that The requirement to use a sequence number increment of one for each
are sent to a particular RTSP agent in order to preserve the joint new request is to support any future specification of RTSP message
sequence number space on the connection between the proxy and the transport over a protocol that does not provide in order delivery
agent. The RTSP proxy MUST increase the CSeq for each request it or is unreliable.
transmits over a particular transport connection or transport flow,
without regard of different sessions.
An RTSP proxy MUST renumber RTSP responses back to the sequence The above rules relating to the initial sequence number may appear
number that the corresponding request had when originally received by unnecessarily loose. The reason is to cater for some common
the proxy before forwarding it to the RTSP agent. behavior of existing implementations: When using multiple reliable
connections in sequence it may still be easiest to use a single
sequence number series for a client connecting with a particular
server. Thus, the initial sequence number may be arbitrary
depending on the number of previous requests. For any unreliable
transport a stricter definition or other solution will be required
to enable detection of any loss of the first request.
A proxy that forwards responses from multiple RTSP agents towards a When using multiple sequential transport connections, there is no
specific agent MUST maintain the order between request/responses on a protocol mechanism to ensure in order processing as the sequence
per incoming connection basis. This means that different RTSP number is scoped on the individual transport connection and its
sessions are handled over the same same transport connection between five tuple. Thus, there are potential issues with opening a new
proxy and the specific agent. transport connection to the same host for which there already
exists a transport connection with outstanding requests and
previously despatched requests related to the same RTSP session.
Given that the RTSP proxy and the agents are using reliable transport RTSP Proxies also need to follow the above rules. This implies that
connections, the proxy MAY forward received responses without proxies that aggregate requests from multiple clients onto a single
considering the response's relation to responses from other transport towards a server or a next hop proxy need to renumber these
connections which will share the same outgoing transport connection requests to form a unified sequence on that transport, fulfilling the
from the proxy. above rules. A proxy capable of fulfilling some agent's request
without emitting its own request (e.g., a caching proxy that fulfils
a request from its cache), also causes a need to renumber as the
number of received requests with a particular target, may not be the
same as the number of emitted requests towards that target agent. A
proxy that needs to renumber, needs to perform the corresponding
renumbering back to the original sequence number for any received
response before forwarding it back to the originator of the request.
Note: This exception is to avoid responses being blocked by A client connected to a proxy, and using that transport to send
other agents being slow to respond. This can result in out-of- requests to multiple servers creates a situation where it is quite
order delivery of responses arriving at the RTSP client in likely to receive the responses out of order. This is because the
relation to the transport connection, but that delivery is in- proxy will establish separate transports from the proxy to the
order with respect to the RTSP agent and any session. servers on which to forward the client's requests. When the
responses arrive from the different servers they will be forwarded
to the client in the order they arrive at the proxy and can be
processed, not the order of the client's original sequence
numbers. This is intentional to avoid some session's requests
being blocked by another server's slow processing of requests.
18.21. Date 18.21. Date
The Date general-header field represents the date and time at which The Date general-header field represents the date and time at which
the message was originated. The inclusion of the Date header in RTSP the message was originated. The inclusion of the Date header in RTSP
message follows these rules: message follows these rules:
o An RTSP message, sent either by the client or the server, o An RTSP message, sent either by the client or the server,
containing a body MUST include a Date header, if the sending host containing a body MUST include a Date header, if the sending host
has a clock; has a clock;
skipping to change at page 153, line 13 skipping to change at page 154, line 18
were associated with the resource by a system or user with a were associated with the resource by a system or user with a
reliable clock. It MAY assign an Expires value that is known, at reliable clock. It MAY assign an Expires value that is known, at
or before server configuration time, to be in the past (this or before server configuration time, to be in the past (this
allows "pre-expiration" of responses without storing separate allows "pre-expiration" of responses without storing separate
Expires values for each resource). Expires values for each resource).
A received message that does not have a Date header field MUST be A received message that does not have a Date header field MUST be
assigned one by the recipient if the message will be cached by that assigned one by the recipient if the message will be cached by that
recipient. An RTSP implementation without a clock MUST NOT cache recipient. An RTSP implementation without a clock MUST NOT cache
responses without revalidating them on every use. An RTSP cache, responses without revalidating them on every use. An RTSP cache,
especially a shared cache, SHOULD use a mechanism, such as NTP, to especially a shared cache, SHOULD use a mechanism, such as Network
synchronize its clock with a reliable external standard. Time Protocol (NTP) [RFC5905], to synchronize its clock with a
reliable external standard.
The RTSP-date, a full date as specified by Section 3.3 of [RFC5322], The RTSP-date, a full date as specified by Section 3.3 of [RFC5322],
sent in a Date header SHOULD NOT represent a date and time subsequent sent in a Date header SHOULD NOT represent a date and time subsequent
to the generation of the message. It SHOULD represent the best to the generation of the message. It SHOULD represent the best
available approximation of the date and time of message generation, available approximation of the date and time of message generation,
unless the implementation has no means of generating a reasonably unless the implementation has no means of generating a reasonably
accurate date and time. In theory, the date ought to represent the accurate date and time. In theory, the date ought to represent the
moment just before the message body is generated. In practice, the moment just before the message body is generated. In practice, the
date can be generated at any time during the message origination date can be generated at any time during the message origination
without affecting its semantic value. without affecting its semantic value.
Note: The RTSP 2.0 date is defined as RFC 5322 format date. This Note: The RTSP 2.0 date format is defined to be the RFC 5322 full
format is more allowing than the RTSP 1.0 and earlier draft date format. This format is more flexible than the RFC 1123 date
versions using RFC 1123 date format. Thus implementations should format used by RTSP 1.0. Thus implementations should use single
use single spaces as recommended as separators and support spaces as recommended by RFC 5322 as separators and support
receiving the obsoleted identifiers. receiving the obsolete format.
[[RFC Editor please remove this note: Prior to version 37 of the
draft, rfc2326bis envisaged sticking with the RFC 1123 format.]]
18.22. Expires 18.22. Expires
The Expires message-header field gives a date and time after which The Expires message-body header field gives a date and time after
the description or media-stream should be considered stale. The which the description or media-stream should be considered stale.
interpretation depends on the method: The interpretation depends on the method:
DESCRIBE response: The Expires header indicates a date and time DESCRIBE response: The Expires header indicates a date and time
after which the presentation description (body) SHOULD be after which the presentation description (body) SHOULD be
considered stale. considered stale.
SETUP response: The Expires header indicate a date and time after SETUP response: The Expires header indicate a date and time after
which the media stream SHOULD be considered stale. which the media stream SHOULD be considered stale.
A stale cache entry may not normally be returned by a cache (either a A stale cache entry may not normally be returned by a cache (either a
proxy cache or an user agent cache) unless it is first validated with proxy cache or an user agent cache) unless it is first validated with
skipping to change at page 155, line 39 skipping to change at page 156, line 46
description will not be returned from the server (DESCRIBE) or a description will not be returned from the server (DESCRIBE) or a
stream will not be set up (SETUP). Instead, a 304 (Not Modified) stream will not be set up (SETUP). Instead, a 304 (Not Modified)
response MUST be returned without any message-body. response MUST be returned without any message-body.
An example of the field is: An example of the field is:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
18.26. If-None-Match 18.26. If-None-Match
This request header can be used with one or several message body tags This request-header can be used with one or several message body tags
to make DESCRIBE requests conditional. A client that has one or more to make DESCRIBE requests conditional. A client that has one or more
message bodies previously obtained from the resource, can verify that message bodies previously obtained from the resource, can verify that
none of those entities is current by including a list of their none of those entities is current by including a list of their
associated message body tags in the If-None-Match header field. The associated message body tags in the If-None-Match header field. The
purpose of this feature is to allow efficient updates of cached purpose of this feature is to allow efficient updates of cached
information with a minimum amount of transaction overhead. As a information with a minimum amount of transaction overhead. As a
special case, the value "*" matches any current entity of the special case, the value "*" matches any current entity of the
resource. resource.
If any of the message body tags match the message body tag of the If any of the message body tags match the message body tag of the
skipping to change at page 156, line 34 skipping to change at page 157, line 42
header MUST be ignored. (See Section 16.1.4 for a discussion of header MUST be ignored. (See Section 16.1.4 for a discussion of
server behavior when both If-Modified-Since and If-None-Match appear server behavior when both If-Modified-Since and If-None-Match appear
in the same request.) in the same request.)
The result of a request having both an If-None-Match header field and The result of a request having both an If-None-Match header field and
an If-Match header field is unspecified and MUST be considered an an If-Match header field is unspecified and MUST be considered an
illegal request. illegal request.
18.27. Last-Modified 18.27. Last-Modified
The Last-Modified message-header field indicates the date and time at The Last-Modified message-body header field indicates the date and
which the origin server believes the presentation description or time at which the origin server believes the presentation description
media stream was last modified. For the method DESCRIBE, the header or media stream was last modified. For the method DESCRIBE, the
field indicates the last modification date and time of the header field indicates the last modification date and time of the
description, for SETUP that of the media stream. description, for SETUP that of the media stream.
An origin server MUST NOT send a Last-Modified date which is later An origin server MUST NOT send a Last-Modified date which is later
than the server's time of message origination. In such cases, where than the server's time of message origination. In such cases, where
the resource's last modification would indicate some time in the the resource's last modification would indicate some time in the
future, the server MUST replace that date with the message future, the server MUST replace that date with the message
origination date. origination date.
An origin server SHOULD obtain the Last-Modified value of the message An origin server SHOULD obtain the Last-Modified value of the message
body as close as possible to the time that it generates the Date body as close as possible to the time that it generates the Date
skipping to change at page 157, line 25 skipping to change at page 158, line 32
Note: The Content-Location header field (Section 18.18) differs from Note: The Content-Location header field (Section 18.18) differs from
Location in that the Content-Location identifies the original Location in that the Content-Location identifies the original
location of the message body enclosed in the request. It is location of the message body enclosed in the request. It is
therefore possible for a response to contain header fields for both therefore possible for a response to contain header fields for both
Location and Content-Location. Also, see Section 16.2 for cache Location and Content-Location. Also, see Section 16.2 for cache
requirements of some methods. requirements of some methods.
18.29. Media-Properties 18.29. Media-Properties
This general header is used in SETUP response or PLAY_NOTIFY requests This general-header is used in SETUP response or PLAY_NOTIFY requests
to indicate the media's properties that currently are applicable to to indicate the media's properties that currently are applicable to
the RTSP session. PLAY_NOTIFY MAY be used to modify these properties the RTSP session. PLAY_NOTIFY MAY be used to modify these properties
at any point. However, the client SHOULD have received the update at any point. However, the client SHOULD have received the update
prior to any action related to the new media properties taking prior to any action related to the new media properties taking
effect. For aggregated sessions, the Media-Properties header will be effect. For aggregated sessions, the Media-Properties header will be
returned in each SETUP response. The header received in the latest returned in each SETUP response. The header received in the latest
response is the one that applies on the whole session from this point response is the one that applies on the whole session from this point
until any future update. The header MAY be included without value in until any future update. The header MAY be included without value in
GET_PARAMETER requests to the server with a Session header included GET_PARAMETER requests to the server with a Session header included
to query the current Media-Properties for the session. The responder to query the current Media-Properties for the session. The responder
skipping to change at page 159, line 23 skipping to change at page 160, line 32
On-demand: On-demand:
Media-Properties: Random-Access=2.5, Unlimited, Immutable, Media-Properties: Random-Access=2.5, 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
18.30. Media-Range 18.30. Media-Range
The Media-Range general header is used to give the range of the media The Media-Range general-header is used to give the range of the media
at the time of sending the RTSP message. This header MUST be at the time of sending the RTSP message. This header MUST be
included in SETUP response, and PLAY and PAUSE response for media included in SETUP response, and PLAY and PAUSE response for media
that are Time-Progressing, and PLAY and PAUSE response after any that are Time-Progressing, and PLAY and PAUSE response after any
change for media that are Dynamic, and in PLAY_NOTIFY request that change for media that are Dynamic, and in PLAY_NOTIFY request that
are sent due to Media-Property-Update. Media-Range header without are sent due to Media-Property-Update. Media-Range header without
any range specifications MAY be included in GET_PARAMETER requests to any range specifications MAY be included in GET_PARAMETER requests to
the server to request the current range. The server MUST in this the server to request the current range. The server MUST in this
case include the current range at the time of sending the response. case include the current range at the time of sending the response.
The header MUST include range specifications for all time formats The header MUST include range specifications for all time formats
supported for the media, as indicated in Accept-Ranges header supported for the media, as indicated in Accept-Ranges header
(Section 18.5) when setting up the media. The server MAY include (Section 18.5) when setting up the media. The server MAY include
more than one range specification of any given time format to more than one range specification of any given time format to
indicate media that has non-continuous range. The range indicate media that has non-continuous range. The range
specifications shall be ordered with the range with the lowest value specifications SHALL be ordered with the range with the lowest value
or earliest start time first, followed by ranges with increasingly or earliest start time first, followed by ranges with increasingly
higher values or later start time. higher values or later start time.
For media that has the Time-Progressing property, the Media-Range For media that has the Time-Progressing property, the Media-Range
values will only be valid for the particular point in time when it values will only be valid for the particular point in time when it
was issued. As wallclock progresses so will also the media range. was issued. As wallclock progresses so will also the media range.
However, it shall be assumed that media time progresses in direct However, it shall be assumed that media time progresses in direct
relationship to wallclock time (with the exception of clock skew) so relationship to wallclock time (with the exception of clock skew) so
that a reasonably accurate estimation of the media range can be that a reasonably accurate estimation of the media range can be
calculated. calculated.
18.31. MTag 18.31. MTag
The MTag response header MAY be included in DESCRIBE, GET_PARAMETER The MTag response-header MAY be included in DESCRIBE, GET_PARAMETER
or SETUP responses. The message body tags (Section 4.6) returned in or SETUP responses. The message body tags (Section 4.6) returned in
a DESCRIBE response, and the one in SETUP 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 "a=mtag" attribute in SDP, and in the response message, then both the "a=mtag" attribute in SDP, and in the response message, then both
skipping to change at page 160, line 31 skipping to change at page 161, line 37
descriptions that are distributed outside of RTSP, for example using descriptions that are distributed outside of RTSP, for example using
HTTP, etc. it will be necessary to include the message body tag in HTTP, etc. it will be necessary to include the message body tag in
the session description as specified in Appendix D.1.9. the session description as specified in Appendix D.1.9.
SETUP and DESCRIBE requests can be made conditional upon the MTag SETUP and DESCRIBE requests can be made conditional upon the MTag
using the headers If-Match (Section 18.24) and If-None-Match ( using the headers If-Match (Section 18.24) and If-None-Match (
Section 18.26). Section 18.26).
18.32. Notify-Reason 18.32. Notify-Reason
The Notify Reason header is solely used in the PLAY_NOTIFY method. The Notify-Reason response-header is solely used in the PLAY_NOTIFY
It indicates the reason why the server has sent the asynchronous method. It indicates the reason why the server has sent the
PLAY_NOTIFY request (see Section 13.5). asynchronous PLAY_NOTIFY request (see Section 13.5).
18.33. Pipelined-Requests 18.33. Pipelined-Requests
The Pipelined-Requests general header is used to indicate that a The Pipelined-Requests general-header is used to indicate that a
request is to be executed in the context created by a previous request is to be executed in the context created by a previous
request(s). The primary usage of this header is to allow pipelining request(s). The primary usage of this header is to allow pipelining
of SETUP requests so that any additional SETUP request after the of SETUP requests so that any additional SETUP request after the
first one does not need to wait for the session ID to be sent back to first one does not need to wait for the session ID to be sent back to
the requesting agent. The header contains a unique identifier that the requesting agent. The header contains a unique identifier that
is scoped by the persistent connection used to send the requests. is scoped by the persistent connection used to send the requests.
Upon receiving a request with the Pipelined-Requests the responding Upon receiving a request with the Pipelined-Requests the responding
agent MUST look up if there exists a binding between this Pipelined- agent MUST look up if there exists a binding between this Pipelined-
Requests identifier for the current persistent connection and an RTSP Requests identifier for the current persistent connection and an RTSP
skipping to change at page 161, line 45 skipping to change at page 163, line 4
requests onto a persistent connection. requests onto a persistent connection.
18.34. Proxy-Authenticate 18.34. Proxy-Authenticate
The Proxy-Authenticate response-header field MUST be included as part The Proxy-Authenticate response-header field MUST be included as part
of a 407 (Proxy Authentication Required) response. The field value of a 407 (Proxy Authentication Required) response. The field value
consists of a challenge that indicates the authentication scheme and consists of a challenge that indicates the authentication scheme and
parameters applicable to the proxy for this Request-URI. parameters applicable to the proxy for this Request-URI.
The HTTP access authentication process is described in [RFC2617]. The HTTP access authentication process is described in [RFC2617].
Unlike WWW-Authenticate, the Proxy-Authenticate header field applies Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
only to the current connection and SHOULD NOT be passed on to only to the current connection and SHOULD NOT be passed on to
downstream agents. This header MUST only be used in response downstream agents. This header MUST only be used in response
messages related to client to server requests. messages related to client to server requests.
18.35. Proxy-Authentication-Info 18.35. Proxy-Authentication-Info
The Proxy-Authentication-Info header is used by the proxy to The Proxy-Authentication-Info response-header is used by the proxy to
communicate some information regarding the successful authentication communicate some information regarding the successful authentication
to the proxy in the message response. The content and usage of this to the proxy in the message response. The content and usage of this
header is described in the HTTP access authentication [RFC2617] that header is described in the HTTP access authentication [RFC2617] that
is also used by RTSP and clarified in Section 19.1. This header MUST is also used by RTSP and clarified in Section 19.1. This header MUST
only be used in response messages related to client to server only be used in response messages related to client to server
requests. This header has hop by hop scope. requests. This header has hop by hop scope.
18.36. Proxy-Authorization 18.36. Proxy-Authorization
The Proxy-Authorization request-header field allows the client to The Proxy-Authorization request-header field allows the client to
skipping to change at page 163, line 45 skipping to change at page 164, line 50
Via: 2.0 pro.example.com, 2.0 prox2.example.com Via: 2.0 pro.example.com, 2.0 prox2.example.com
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
Supported: foo, bar, baz Supported: foo, bar, baz
Proxy-Supported: proxy-foo, proxy-blech Proxy-Supported: proxy-foo, proxy-blech
Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
Via: 2.0 pro.example.com, 2.0 prox2.example.com Via: 2.0 pro.example.com, 2.0 prox2.example.com
18.39. Public 18.39. Public
The Public response header field lists the set of methods supported The Public response-header field lists the set of methods supported
by the response sender. This header applies to the general by the response sender. This header applies to the general
capabilities of the sender and its only purpose is to indicate the capabilities of the sender and its only purpose is to indicate the
sender's capabilities to the recipient. The methods listed may or sender's capabilities to the recipient. The methods listed may or
may not be applicable to the Request-URI; the Allow header field may not be applicable to the Request-URI; the Allow header field
(Section 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
skipping to change at page 164, line 19 skipping to change at page 165, line 23
In the event that there are proxies between the sender and the In the event that there are proxies between the sender and the
recipient of a response, each intervening proxy MUST modify the recipient of a response, each intervening proxy MUST modify the
Public header field to remove any methods that are not supported via Public header field to remove any methods that are not supported via
that proxy. The resulting Public header field will contain an that proxy. The resulting Public header field will contain an
intersection of the sender's methods and the methods allowed through intersection of the sender's methods and the methods allowed through
by the intervening proxies. by the intervening proxies.
In general, proxies should allow all methods to transparently pass In general, proxies should allow all methods to transparently pass
through from the sending RTSP agent to the receiving RTSP agent, through from the sending RTSP agent to the receiving RTSP agent,
but there may be cases where this is not desirable for a given but there may be cases where this is not desirable for a given
proxy. Modification of the Public response header field by the proxy. Modification of the Public response-header field by the
intervening proxies ensures that the request sender gets an intervening proxies ensures that the request sender gets an
accurate response indicating the methods that can be used on the accurate response indicating the methods that can be used on the
target agent via the proxy chain. target agent via the proxy chain.
18.40. Range 18.40. Range
The Range general-header specifies a time range in PLAY The Range general-header specifies a time range in PLAY
(Section 13.4), PAUSE (Section 13.6), SETUP (Section 13.3), REDIRECT (Section 13.4), PAUSE (Section 13.6), SETUP (Section 13.3), REDIRECT
(Section 13.10), and PLAY_NOTIFY (Section 13.5) requests and (Section 13.10), and PLAY_NOTIFY (Section 13.5) requests and
responses. It MAY be included in GET_PARAMETER requests from the responses. It MAY be included in GET_PARAMETER requests from the
skipping to change at page 164, line 43 skipping to change at page 165, line 47
range format, respond with the current playing point or pause point range format, respond with the current playing point or pause point
as the start of the range. If an explicit stop point was used in the as the start of the range. If an explicit stop point was used in the
previous PLAY request, then that value shall be included as stop previous PLAY request, then that value shall be included as stop
point. Note that if the server is currently under any type of media point. Note that if the server is currently under any type of media
playback manipulation affecting the interpretation of Range, like playback manipulation affecting the interpretation of Range, like
Scale, that is also required to be included in any GET_PARAMETER Scale, that is also required to be included in any GET_PARAMETER
response to provide complete information. response to provide complete information.
The range can be specified in a number of units. This specification The range can be specified in a number of units. This specification
defines smpte (Section 4.4.1), npt (Section 4.4.2), and clock defines smpte (Section 4.4.1), npt (Section 4.4.2), and clock
(Section 4.4.3) range units. While byte ranges [H14.35.1] and other (Section 4.4.3) range units. While octet ranges (Byte Ranges)
extended units MAY be used, their behavior is unspecified since they [H14.35.1] and other extended units MAY be used, their behavior is
are not normally meaningful in RTSP. Servers supporting the Range unspecified since they are not normally meaningful in RTSP. Servers
header MUST understand the NPT range format and SHOULD understand the supporting the Range header MUST understand the NPT range format and
SMPTE range format. If the Range header is sent in a time format SHOULD understand the SMPTE range format. If the Range header is
that is not understood, the recipient SHOULD return 456 (Header Field sent in a time format that is not understood, the recipient SHOULD
Not Valid for Resource) and include an Accept-Ranges header return 456 (Header Field Not Valid for Resource) and include an
indicating the supported time formats for the given resource. Accept-Ranges header 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
skipping to change at page 166, line 50 skipping to change at page 168, line 9
Referrer field is sent. For example, a streaming client could have a Referrer field is sent. For example, a streaming client could have a
toggle switch for openly/anonymously, which would respectively toggle switch for openly/anonymously, which would respectively
enable/disable the sending of Referrer and From information. enable/disable the sending of Referrer and From information.
Clients SHOULD NOT include a Referrer header field in a (non-secure) Clients SHOULD NOT include a Referrer header field in a (non-secure)
RTSP request if the referring page was transferred with a secure RTSP request if the referring page was transferred with a secure
protocol. protocol.
18.42. Request-Status 18.42. Request-Status
This request header is used to indicate the end result for requests This request-header is used to indicate the end result for requests
that take time to complete, such as PLAY (Section 13.4). It is sent that take time to complete, such as PLAY (Section 13.4). It is sent
in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report
how the PLAY request concluded, either in success or in failure. The how the PLAY request concluded, either in success or in failure. The
header carries a reference to the request it reports on using the header carries a reference to the request it reports on using the
CSeq number for the session indicated by the Session header in the CSeq number for the session indicated by the Session header in the
request. It provides both a numerical status code (according to request. It provides both a numerical status code (according to
Section 8.1.1) and a human readable reason phrase. Section 8.1.1) and a human readable reason phrase.
Example: Example:
Request-Status: cseq=63 status=500 reason="Media data unavailable" Request-Status: cseq=63 status=500 reason="Media data unavailable"
18.43. Require 18.43. Require
The Require request-header field is used by agents to ensure that the The Require request-header field is used by agents to ensure that the
other end-point supports features that are required in respect to other end-point supports features that are required in respect to
this request. It can also be used to query if the other end-point this request. It can also be used to query if the other end-point
supports certain features, however, the use of the Supported message- supports certain features, however, the use of the Supported general-
header (Section 18.51) is much more effective in this purpose. In header (Section 18.51) is much more effective in this purpose. In
case any of the feature-tags listed by the Require header are not case any of the feature-tags listed by the Require header are not
supported by the server or client receiving the request, it MUST supported by the server or client receiving the request, it MUST
respond to the request using the error code 551 (Option Not respond to the request using the error code 551 (Option Not
Supported) and include the Unsupported header listing those feature- Supported) and include the Unsupported header listing those feature-
tags which are NOT supported. This header does not apply to proxies, tags which are NOT supported. This header does not apply to proxies,
for the same functionality in respect to proxies see Proxy-Require for the same functionality in respect to proxies see Proxy-Require
header (Section 18.37) with the exception of media modifying proxies. header (Section 18.37) with the exception of media modifying proxies.
Media modifying proxies, due to their nature of handling media in a Media modifying proxies, due to their nature of handling media in a
way that is very similar to a server, do need to understand also the way that is very similar to a server, do need to understand also the
skipping to change at page 168, line 39 skipping to change at page 169, line 48
Example: Example:
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120 Retry-After: 120
In the latter example, the delay is 2 minutes. In the latter example, the delay is 2 minutes.
18.45. RTP-Info 18.45. RTP-Info
The RTP-Info general header field is used to set RTP-specific The RTP-Info general-header field is used to set RTP-specific
parameters in the PLAY and GET_PARAMETER responses or a PLAY_NOTIFY parameters in the PLAY and GET_PARAMETER responses or a PLAY_NOTIFY
and GET_PARAMETER requests. For streams using RTP as transport and GET_PARAMETER requests. For streams using RTP as transport
protocol the RTP-Info header SHOULD be part of a 200 response to protocol the RTP-Info header SHOULD be part of a 200 response to
PLAY. PLAY.
The exclusion of the RTP-Info in a PLAY response for RTP The exclusion of the RTP-Info in a PLAY response for RTP
transported media will result in a client needing to synchronize transported media will result in a client needing to synchronize
the media streams using RTCP. This may have negative impact as the media streams using RTCP. This may have negative impact as
the RTCP can be lost, and does not need to be particularly timely the RTCP can be lost, and does not need to be particularly timely
in its arrival. Also functionality that informs the client from in its arrival. Also functionality that informs the client from
skipping to change at page 169, line 41 skipping to change at page 170, line 50
that is direct result of the request. This allows clients to that is direct result of the request. This allows clients to
gracefully deal with packets when seeking. The client uses gracefully deal with packets when seeking. The client uses
this value to differentiate packets that originated before the this value to differentiate packets that originated before the
seek from packets that originated after the seek. Note that a seek from packets that originated after the seek. Note that a
client may not receive the packet with the expressed sequence client may not receive the packet with the expressed sequence
number, and instead packets with a higher sequence number, due number, and instead packets with a higher sequence number, due
to packet loss or reordering. This parameter is RECOMMENDED to to packet loss or reordering. This parameter is RECOMMENDED to
be present. be present.
rtptime: MUST indicate the RTP timestamp value corresponding to the rtptime: MUST indicate the RTP timestamp value corresponding to the
start time value in the Range response header, or if not start time value in the Range response-header, or if not
explicitly given the implied start point. The client uses this explicitly given the implied start point. The client uses this
value to calculate the mapping of RTP time to NPT or other value to calculate the mapping of RTP time to NPT or other
media timescale. This parameter SHOULD be present to ensure media timescale. This parameter SHOULD be present to ensure
inter-media synchronization is achieved. There exists no inter-media synchronization is achieved. There exists no
requirement that any received RTP packet will have the same RTP requirement that any received RTP packet will have the same RTP
timestamp value as the one in the parameter used to establish timestamp value as the one in the parameter used to establish
synchronization. synchronization.
A mapping from RTP timestamps to Network Time Protocol (NTP) A mapping from RTP timestamps to Network Time Protocol (NTP)
format timestamps (wallclock) is available via RTCP. However, format timestamps (wallclock) is available via RTCP. However,
skipping to change at page 171, line 48 skipping to change at page 173, line 6
Range: npt=15-10 Range: npt=15-10
18.47. Seek-Style 18.47. 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 general-header is defined.
Seek-Style is a general header that MAY be included in any PLAY Seek-Style is a general-header that MAY be included in any PLAY
request to indicate the client's preference for any media stream that request to indicate the client's preference for any media stream that
has random access properties. The server MUST always include the has random access properties. The server MUST always include the
header in any PLAY response for media with random access properties header in any PLAY response for media with random access properties
to indicate what policy was applied. A server that receives an to indicate what policy was applied. A server that receives an
unknown Seek-Style policy MUST ignore it and select the server unknown Seek-Style policy MUST ignore it and select the server
default policy. A client receiving an unknown policy MUST ignore it default policy. A client receiving an unknown policy MUST ignore it
and use the Range header and any media synchronization information as and use the Range header and any media synchronization information as
basis to determine what the server did. basis to determine what the server did.
This specification defines the following seek policies that may be This specification defines the following seek policies that may be
skipping to change at page 176, line 7 skipping to change at page 177, line 7
cases are buffer operations or local scale operations. Implementors cases are buffer operations or local scale operations. Implementors
should keep in mind that bandwidth for the session may be negotiated should keep in mind that bandwidth for the session may be negotiated
beforehand (by means other than RTSP), and therefore re-negotiation beforehand (by means other than RTSP), and therefore re-negotiation
may be necessary. To perform Speed operations the server needs to may be necessary. To perform Speed operations the server needs to
ensure that the network path can support the resulting bit-rate. ensure that the network path can support the resulting bit-rate.
Thus the media transport needs to support feedback so that the server Thus the media transport needs to support feedback so that the server
can react and adapt to the available bitrate. can react and adapt to the available bitrate.
18.51. Supported 18.51. Supported
The Supported general header enumerates all the extensions supported The Supported general-header enumerates all the extensions supported
by the client or server using feature tags. The header carries the by the client or server using feature tags. The header carries the
extensions supported by the message sending client or server. The extensions supported by the message sending client or server. The
Supported header MAY be included in any request. When present in a Supported header MAY be included in any request. When present in a
request, the receiver MUST respond with its corresponding Supported request, the receiver MUST respond with its corresponding Supported
header. Note that the Supported header is also included in 4xx and header. Note that the Supported header is also included in 4xx and
5xx responses. 5xx responses.
The Supported header contains a list of feature-tags, described in The Supported header contains a list of feature-tags, described in
Section 4.5, that are understood by the client or server. These Section 4.5, that are understood by the client or server. These
feature tags are the ones the server or client support in general, feature tags are the ones the server or client support in general,
skipping to change at page 176, line 31 skipping to change at page 177, line 31
C->S: OPTIONS rtsp://example.com/ RTSP/2.0 C->S: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech Supported: foo, bar, blech
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
Supported: bar, blech, baz Supported: bar, blech, baz
18.52. Terminate-Reason 18.52. Terminate-Reason
The Terminate-Reason request header allows the server when sending a The Terminate-Reason request-header allows the server when sending a
REDIRECT or TEARDOWN request to provide a reason for the session REDIRECT or TEARDOWN request to provide a reason for the session
termination and any additional information. This specification termination and any additional information. This specification
identifies three reasons for Redirections and may be extended in the identifies three reasons for Redirections and may be extended in the
future: future:
Server-Admin: The server needs to be shutdown for some Server-Admin: The server needs to be shutdown for some
administrative reason. administrative reason.
Session-Timeout: A client's session has been kept alive for extended Session-Timeout: A client's session has been kept alive for extended
periods of time and the server has determined that it needs to periods of time and the server has determined that it needs to
skipping to change at page 177, line 37 skipping to change at page 178, line 37
unreliable transport. unreliable transport.
18.54. Transport 18.54. Transport
The Transport general-header indicates which transport protocol is to The Transport general-header indicates which transport protocol is to
be used and configures its parameters such as destination address, be used and configures its parameters such as destination address,
compression, multicast time-to-live and destination port for a single compression, multicast time-to-live and destination port for a single
stream. It sets those values not already determined by a stream. It sets those values not already determined by a
presentation description. presentation description.
A Transport request header MAY contain a list of transport options A Transport request-header MAY contain a list of transport options
acceptable to the client, in the form of multiple transport acceptable to the client, in the form of multiple transport
specification entries. Transport specifications are comma separated, specification entries. Transport specifications are comma separated,
listed in decreasing order of preference. Each transport listed in decreasing order of preference. Each transport
specification consist of a transport protocol identifier, followed by specification consists of a transport protocol identifier, followed
any number of parameters, each parameter separated by a semicolon. A by any number of parameters, each parameter separated by a semicolon.
Transport request header MAY contain multiple transport A Transport request-header MAY contain multiple transport
specifications using the same transport protocol Identifier. The specifications using the same transport protocol Identifier. The
server MUST return a Transport response-header in the response to server MUST return a Transport response-header in the response to
indicate the values actually chosen if any. If no transport indicate the values actually chosen if any. If no transport
specification is supported, no transport header is returned and the specification is supported, no transport header is returned and the
request MUST be responded using the status code 461 (Unsupported response MUST use the status code 461 (Unsupported Transport)
Transport) (Section 17.4.25). In case more than one transport (Section 17.4.26). In case more than one transport specification was
specification was present in the request, the server MUST return the present in the request, the server MUST return the single transport
single transport specification (transport-spec) which was actually specification (transport-spec) which was actually chosen, if any.
chosen, if any. The number of transport-spec entries is expected to The number of transport-spec entries is expected to be limited as the
be limited as the client will get guidance on what configurations client will receive guidance on what configurations that are possible
that are possible from the presentation description. from the presentation description.
The Transport header MAY also be used in subsequent SETUP requests to The Transport header MAY also be used in subsequent SETUP requests to
change transport parameters. A server MAY refuse to change change transport parameters. A server MAY refuse to change
parameters of an existing stream. parameters of an existing stream.
The transport protocol identifier defines for each transport The transport protocol identifier defines for each transport
specification which transport protocol to use and any related rules. specification which transport protocol to use and any related rules.
Each transport protocol identifier defines the parameters that are Each transport protocol identifier defines the parameters that are
required to occur, additional optional parameters MAY occur. This as required to occur; additional optional parameters MAY occur. This
parameters may be different and provide different options to the RTSP flexibility is provided as parameters may be different and provide
Agent. A transport specification may only contain one of any given different options to the RTSP Agent. A transport specification may
parameter within it. A parameter consists of a name and optionally a only contain one of any given parameter within it. A parameter
value string. Parameters MAY be given in any order. Additionally, consists of a name and optionally a value string. Parameters MAY be
transport specification may only contain either of the unicast or the given in any order. Additionally, a transport specification may only
multicast transport type parameter. The transport protocol contain either of the unicast or the multicast transport type
identifier and all parameters need to be understood in a transport parameter. The transport protocol identifier and all parameters need
specification, if not, the transport specification MUST be ignored. to be understood in a transport specification; if not, the transport
An RTSP proxy of any type that uses or modifies the transport specification MUST be ignored. An RTSP proxy of any type that uses
specification, e.g., access proxy or security proxy, MUST remove or modifies the transport specification, e.g., access proxy or
specifications with unknown parameters before forwarding the RTSP security proxy, MUST remove specifications with unknown parameters
message. If that results in no remaining transport specification the before forwarding the RTSP message. If that results in no remaining
proxy SHALL send a 461 (Unsupported Transport) (Section 17.4.25) transport specification the proxy SHALL send a 461 (Unsupported
response without any Transport header. Transport) (Section 17.4.26) response without any Transport header.
The Transport header is restricted to describing a single media The Transport header is restricted to describing a single media
stream. (RTSP can also control multiple streams as a single stream. (RTSP can also control multiple streams as a single
entity.) Making it part of RTSP rather than relying on a entity.) Making it part of RTSP rather than relying on a
multitude of session description formats greatly simplifies multitude of session description formats greatly simplifies
designs of firewalls. designs of firewalls.
The general syntax for the transport protocol identifier is a list of The general syntax for the transport protocol identifier is a list of
slash separated tokens: slash separated tokens:
skipping to change at page 182, line 11 skipping to change at page 183, line 11
This allows RTP/RTCP to be handled similarly to the way This allows RTP/RTCP to be handled similarly to the way
that it is done with UDP, i.e., one channel for RTP and that it is done with UDP, i.e., one channel for RTP and
the other for RTCP. the other for RTCP.
MIKEY: This parameter is used in conjunction with transport MIKEY: This parameter is used in conjunction with transport
specifications that can utilize MIKEY [RFC3830] for security specifications that can utilize MIKEY [RFC3830] for security
context establishment. So far only the SRTP based RTP profiles context establishment. So far only the SRTP based RTP profiles
SAVP and SAVPF can utilize MIKEY and this is defined in SAVP and SAVPF can utilize MIKEY and this is defined in
Appendix C.1.4.1. This parameter can be included both in Appendix C.1.4.1. This parameter can be included both in
request and response messages. The binary MIKEY message SHALL request and response messages. The binary MIKEY message SHALL
be Base64 [RFC4648] encoded before being included in the value be BASE64 [RFC4648] encoded before being included in the value
part of the parameter. part of the parameter, where the encoding adheres to the
definition in Section 4 of RFC 4648 and where the padding bits
are set to zero.
Multicast-specific: Multicast-specific:
ttl: multicast time-to-live for IPv4. When included in requests the ttl: multicast time-to-live for IPv4. When included in requests the
value indicate the TTL value that the client requests the value indicate the TTL value that the client requests the
server to use. In a response, the value actually being used by server to use. In a response, the value actually being used by
the server is returned. A server will need to consider what the server is returned. A server will need to consider what
values that are reasonable and also the authority of the user values that are reasonable and also the authority of the user
to set this value. Corresponding functions are not needed for to set this value. Corresponding functions are not needed for
IPv6 as the scoping is part of the IPv6 multicast address IPv6 as the scoping is part of the IPv6 multicast address
skipping to change at page 186, line 16 skipping to change at page 187, line 21
18.58. WWW-Authenticate 18.58. WWW-Authenticate
The WWW-Authenticate response-header field MUST be included in 401 The WWW-Authenticate response-header field MUST be included in 401
(Unauthorized) response messages. The field value consists of at (Unauthorized) response messages. The field value consists of at
least one challenge that indicates the authentication scheme(s) and least one challenge that indicates the authentication scheme(s) and
parameters applicable to the Request-URI. This header MUST only be parameters applicable to the Request-URI. This header MUST only be
used in response messages related to client to server requests. used in response messages related to client to server requests.
The HTTP access authentication process is described in [RFC2617] with The HTTP access authentication process is described in [RFC2617] with
some clarification in Section 19.1. User agents are advised to take some clarification in Section 19.1. User agents are advised to take
special care in parsing the WWW- Authenticate field value as it might special care in parsing the WWW-Authenticate field value as it might
contain more than one challenge, or if more than one WWW-Authenticate contain more than one challenge, or if more than one WWW-Authenticate
header field is provided, the contents of a challenge itself can header field is provided, the contents of a challenge itself can
contain a comma-separated list of authentication parameters. contain a comma-separated list of authentication parameters.
19. Security Framework 19. Security Framework
The RTSP security framework consists of two high level components: The RTSP security framework consists of two high level components:
the pure authentication mechanisms based on HTTP authentication, and the pure authentication mechanisms based on HTTP authentication, and
the message transport protection based on TLS, which is independent the message transport protection based on TLS, which is independent
of RTSP. Because of the similarity in syntax and usage between RTSP of RTSP. Because of the similarity in syntax and usage between RTSP
servers and HTTP servers, the security for HTTP is re-used to a large servers and HTTP servers, the security for HTTP is re-used to a large
extent. extent.
19.1. RTSP and HTTP Authentication 19.1. RTSP and HTTP Authentication
RTSP and HTTP share common authentication schemes, and thus follow RTSP and HTTP share common authentication schemes, and thus follow
the same usage guidelines as specified in [RFC2617] with the the same usage guidelines as specified in [RFC2617] with the
additions for digest specified below in Section 19.1.1. Servers additions for digest authentication specified below in
SHOULD implement both basic and digest [RFC2617] authentication. Section 19.1.1. Servers SHOULD implement both basic and digest
Clients MUST implement both basic and digest authentication [RFC2617] [RFC2617] authentication. Clients MUST implement both basic and
so that a server that requires the client to authenticate can trust digest authentication [RFC2617] so that a server that requires the
that the capability is present. client to authenticate can trust that the capability is present.
It should be stressed that using the HTTP authentication alone does It should be stressed that using the HTTP authentication alone does
not provide full control message security. Therefore, in not provide full control message security. Therefore, in
environments requiring tighter security for the control messages, TLS environments requiring tighter security for the control messages, TLS
SHOULD be used, see Section 19.2. Any RTSP message containing an SHOULD be used, see Section 19.2. Any RTSP message containing an
Authorization header using basic authorization MUST be using a TLS Authorization header using basic authorization MUST be using a TLS
connection with confidentiality protection enabled, i.e. no NULL connection with confidentiality protection enabled, i.e., no NULL
encryption. encryption.
In cases where there is a chain of proxies between the client and the In cases where there is a chain of proxies between the client and the
server, each proxy may individually request the client or previous server, each proxy may individually request the client or previous
proxy to authenticate itself. This is done using the Proxy- proxy to authenticate itself. This is done using the Proxy-
Authenticate (Section 18.34), the Proxy-Authorization (Section 18.36) Authenticate (Section 18.34), the Proxy-Authorization (Section 18.36)
and the Proxy-Authentication-Info (Section 18.35) headers. These and the Proxy-Authentication-Info (Section 18.35) headers. These
headers are hop-by-hop headers and have only scope for the current headers are hop-by-hop headers and are only scoped to the current
connection. Thus if a chain exist, the proxy connecting to another connection and hop. Thus if a proxy chain exists, a proxy connecting
proxy will have to act as a client to authorize itself towards the to another proxy will have to act as a client to authorize itself
next proxy. The WWW-Authenticate (Section 18.58), Authorization towards the next proxy. The WWW-Authenticate (Section 18.58),
(Section 18.8) and Authentication-Info (Section 18.7) headers are Authorization (Section 18.8) and Authentication-Info (Section 18.7)
end-to-end and must not be modified by proxies. headers are end-to-end and must not be modified by proxies.
This authentication mechanism works only for client to server This authentication mechanism works only for client to server
requests as currently defined. This leaves server to client request requests as currently defined. This leaves server to client request
outside of the context of TLS based communication more vulnerable to outside of the context of TLS based communication more vulnerable to
message injection attacks on the client. Based on the server to message injection attacks on the client. Based on the server to
client methods that exist, the potential risks are various; hijacking client methods that exist, the potential risks are various; hijacking
(REDIRECT), denial of service (TEARDOWN and PLAY_NOTIFY) or attacks (REDIRECT), denial of service (TEARDOWN and PLAY_NOTIFY) or attacks
with uncertain results (SET_PARAMETER). with uncertain results (SET_PARAMETER).
19.1.1. Digest Authentication 19.1.1. Digest Authentication
skipping to change at page 188, line 18 skipping to change at page 189, line 18
to apply the HTTP Digest authentication scheme to RTSP. The RTSP to apply the HTTP Digest authentication scheme to RTSP. The RTSP
scheme usage is almost completely identical to that for HTTP scheme usage is almost completely identical to that for HTTP
[RFC2617]. These are based on the procedures defined for SIP 2.0 [RFC2617]. These are based on the procedures defined for SIP 2.0
[RFC3261]. [RFC3261].
The rules for Digest authentication follow those defined in The rules for Digest authentication follow those defined in
[RFC2617], with "HTTP/1.1" replaced by "RTSP/2.0" in addition to the [RFC2617], with "HTTP/1.1" replaced by "RTSP/2.0" in addition to the
following differences: following differences:
1. Use the ABNF specified in this document, rather than the one in 1. Use the ABNF specified in this document, rather than the one in
[RFC2617]. That way the following is assured: [RFC2617]. Consequently the following is assured:
* Using the right RTSP URIs allowed in the challenge as well as * Using the right RTSP URIs allowed in the challenge as well as
in the digest. in the digest.
* Resolved the error in the "uri" parameter of the Authorization * Resolved the error in the "uri" parameter of the Authorization
header in [RFC2617]. header in [RFC2617].
2. If MTags are used then the example procedure for choosing a nonce 2. If MTags are used then the example procedure for choosing a nonce
based on Etag can work based on replacing ETag with the MTag. based on Etag can work based on replacing ETag with the MTag.
skipping to change at page 189, line 34 skipping to change at page 190, line 34
RTSP includes the possibility to keep a TCP session up between the RTSP includes the possibility to keep a TCP session up between the
client and server, throughout the RTSP session lifetime. It may be client and server, throughout the RTSP session lifetime. It may be
convenient to keep the TCP session, not only to save the extra setup convenient to keep the TCP session, not only to save the extra setup
time for TCP, but also the extra setup time for TLS (even if TLS uses time for TCP, but also the extra setup time for TLS (even if TLS uses
the resume function, there will be almost two extra round trips). the resume function, there will be almost two extra round trips).
Still, when TLS is used, such behavior introduces extra active state Still, when TLS is used, such behavior introduces extra active state
in the server, not only for TCP and RTSP, but also for TLS. This may in the server, not only for TCP and RTSP, but also for TLS. This may
increase the vulnerability to DoS attacks. increase the vulnerability to DoS attacks.
There exist a potential security vulnerability when reusing TCP and There exists a potential security vulnerability when reusing TCP and
TLS state for different resources (URIs). If two different host TLS state for different resources (URIs). If two different host
names points at the same IP address it can be desirable to re-use the names point at the same IP address it can be desirable to re-use the
TCP/TLS connection to that server. In that case the RTSP agent TCP/TLS connection to that server. In that case the RTSP agent
having the TCP/TLS connection MUST verify that the server certificate having the TCP/TLS connection MUST verify that the server certificate
associated with the connection has a SubjectAltName matching the host associated with the connection has a SubjectAltName matching the host
name present in the URI for the resource an RTSP request is to be name present in the URI for the resource an RTSP request is to be
issued for. issued for.
In addition to these recommendations, Section 19.3 gives further In addition to these recommendations, Section 19.3 gives further
recommendations of TLS usage with proxies. recommendations of TLS usage with proxies.
19.3. Security and Proxies 19.3. Security and Proxies
skipping to change at page 190, line 21 skipping to change at page 191, line 21
There are in general two categories of proxies, the transparent There are in general two categories of proxies, the transparent
proxies (of which the client is not aware) and the non-transparent proxies (of which the client is not aware) and the non-transparent
proxies (of which the client is aware). This memo specifies only proxies (of which the client is aware). This memo specifies only
non-transparent RTSP proxies, i.e., proxies visible to the RTSP non-transparent RTSP proxies, i.e., proxies visible to the RTSP
client and RTSP server. An infrastructure based on proxies requires client and RTSP server. An infrastructure based on proxies requires
that the trust model is such that both client and servers can trust that the trust model is such that both client and servers can trust
the proxies to handle the RTSP messages correctly. To be able to the proxies to handle the RTSP messages correctly. To be able to
trust a proxy, the client and server also need to be aware of the trust a proxy, the client and server also need to be aware of the
proxy. Hence, transparent proxies cannot generally be seen as proxy. Hence, transparent proxies cannot generally be seen as
trusted and will not work well with security (unless they work only trusted and will not work well with security (unless they work only
at transport layer). In the rest of this section any reference to at the transport layer). In the rest of this section any reference
proxy will be to a non-transparent proxy, which inspects or to proxy will be to a non-transparent proxy, which inspects or
manipulates the RTSP messages. manipulates the RTSP messages.
HTTP Authentication is built on the assumption of proxies and can HTTP Authentication is built on the assumption of proxies and can
provide user-proxy authentication and proxy-proxy/server provide user-proxy authentication and proxy-proxy/server
authentication in addition to the client-server authentication. authentication in addition to the client-server authentication.
When TLS is applied and a proxy is used, the client will connect to When TLS is applied and a proxy is used, the client will connect to
the proxy's address when connecting to any RTSP server. This implies the proxy's address when connecting to any RTSP server. This implies
that for TLS, the client will authenticate the proxy server and not that for TLS, the client will authenticate the proxy server and not
the end server. Note that when the client checks the server the end server. Note that when the client checks the server
skipping to change at page 191, line 26 skipping to change at page 192, line 26
(Failure to establish secure connection). (Failure to establish secure connection).
19.3.1. Accept-Credentials 19.3.1. Accept-Credentials
The Accept-Credentials header can be used by the client to distribute The Accept-Credentials header can be used by the client to distribute
simple authorization policies to intermediate proxies. The client simple authorization policies to intermediate proxies. The client
includes the Accept-Credentials header to dictate how the proxy includes the Accept-Credentials header to dictate how the proxy
treats the server/next proxy certificate. There are currently three treats the server/next proxy certificate. There are currently three
methods defined: methods defined:
Any, which means that the proxy (or proxies) MUST accept whatever Any: which means that the proxy (or proxies) MUST accept whatever
certificate is presented. This is of course not a recommended certificate is presented. This is of course not a recommended
option to use, but may be useful in certain circumstances (such option to use, but may be useful in certain circumstances (such
as testing). as testing).
Proxy: which means that the proxy (or proxies) MUST use its own Proxy: which means that the proxy (or proxies) MUST use its own
policies to validate the certificate and decide whether to policies to validate the certificate and decide whether to
accept it or not. This is convenient in cases where the user accept it or not. This is convenient in cases where the user
has a strong trust relation with the proxy. Reasons why a has a strong trust relation with the proxy. Reasons why a
strong trust relation may exist are: personal/company proxy, strong trust relation may exist are: personal/company proxy,
proxy has a out-of-band policy configuration mechanism. proxy has a out-of-band policy configuration mechanism.
User, which means that the proxy (or proxies) MUST send credential User: which means that the proxy (or proxies) MUST send credential
information about the next hop to the client for authorization. information about the next hop to the client for authorization.
The client can then decide whether the proxy should accept the The client can then decide whether the proxy should accept the
certificate or not. See Section 19.3.2 for further details. certificate or not. See Section 19.3.2 for further details.
If the Accept-Credentials header is not included in the RTSP request If the Accept-Credentials header is not included in the RTSP request
from the client, then the "Proxy" method MUST be used as default. If from the client, then the "Proxy" method MUST be used as default. If
another method than the "Proxy" is to be used, then the Accept- another method than the "Proxy" is to be used, then the Accept-
Credentials header MUST be included in all of the RTSP requests from Credentials header MUST be included in all of the RTSP requests from
the client. This is because it cannot be assumed that the proxy the client. This is because it cannot be assumed that the proxy
always keeps the TLS state or the user's previous preference between always keeps the TLS state or the user's previous preference between
skipping to change at page 200, line 9 skipping to change at page 201, line 9
extension-header = header-name HCOLON header-value extension-header = header-name HCOLON header-value
header-name = token header-name = token
header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) header-value = *(TEXT-UTF8char / UTF8-CONT / LWS)
20.2.2. Message Syntax 20.2.2. Message Syntax
RTSP-message = Request / Response ; RTSP/2.0 messages RTSP-message = Request / Response ; RTSP/2.0 messages
Request = Request-Line Request = Request-Line
*((general-header *((general-header
/ request-header / request-header
/ message-header) CRLF) / message-body-header) CRLF)
CRLF CRLF
[ message-body-data ] [ message-body-data ]
Response = Status-Line Response = Status-Line
*((general-header *((general-header
/ response-header / response-header
/ message-header) CRLF) / message-body-header) CRLF)
CRLF CRLF
[ message-body-data ] [ message-body-data ]
Request-Line = Method SP Request-URI SP RTSP-Version CRLF Request-Line = Method SP Request-URI SP RTSP-Version CRLF
Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF
Method = "DESCRIBE" Method = "DESCRIBE"
/ "GET_PARAMETER" / "GET_PARAMETER"
/ "OPTIONS" / "OPTIONS"
/ "PAUSE" / "PAUSE"
skipping to change at page 202, line 4 skipping to change at page 203, line 4
/ "502" ; Bad Gateway / "502" ; Bad Gateway
/ "503" ; Service Unavailable / "503" ; Service Unavailable
/ "504" ; Gateway Time-out / "504" ; Gateway Time-out
/ "505" ; RTSP Version not supported / "505" ; RTSP Version not supported
/ "551" ; Option not supported / "551" ; Option not supported
/ extension-code / extension-code
extension-code = 3DIGIT extension-code = 3DIGIT
Reason-Phrase = 1*(TEXT-UTF8char / HT / SP) Reason-Phrase = 1*(TEXT-UTF8char / HT / SP)
rtsp-header = general-header
/ request-header
/ response-header
/ message-body-header
general-header = Accept-Ranges general-header = Accept-Ranges
/ Cache-Control / Cache-Control
/ Connection / Connection
/ CSeq / CSeq
/ Date / Date
/ Media-Properties / Media-Properties
/ Media-Range / Media-Range
/ Pipelined-Requests / Pipelined-Requests
/ Proxy-Supported / Proxy-Supported
/ Range / Range
skipping to change at page 203, line 17 skipping to change at page 204, line 17
/ Location / Location
/ MTag / MTag
/ Proxy-Authenticate / Proxy-Authenticate
/ Proxy-Authentication-Info / Proxy-Authentication-Info
/ Public / Public
/ Retry-After / Retry-After
/ Unsupported / Unsupported
/ WWW-Authenticate / WWW-Authenticate
/ extension-header / extension-header
message-header = Allow message-body-header = Allow
/ Content-Base / Content-Base
/ Content-Encoding / Content-Encoding
/ Content-Language / Content-Language
/ Content-Length / Content-Length
/ Content-Location / Content-Location
/ Content-Type / Content-Type
/ Expires / Expires
/ Last-Modified / Last-Modified
/ extension-header / extension-header
skipping to change at page 216, line 8 skipping to change at page 217, line 8
The above threats and considerations have resulted in a set of The above threats and considerations have resulted in a set of
security functions and mechanisms built into or used by the protocol. security functions and mechanisms built into or used by the protocol.
The signaling protocol relies on two security features defined in the The signaling protocol relies on two security features defined in the
Security Framework (Section 19) namely client authentication using Security Framework (Section 19) namely client authentication using
HTTP authentication and TLS based transport protection of the HTTP authentication and TLS based transport protection of the
signaling messages. Both of these mechanisms are required to be signaling messages. Both of these mechanisms are required to be
implemented by any RTSP agent. implemented by any RTSP agent.
A number of different security mitigations have been designed into A number of different security mitigations have been designed into
the protocol and will be instantiated if the specification is the protocol and will be instantiated if the specification is
implemented written, for example by ensuring sufficient amount of implemented as written, for example by ensuring sufficient amount of
entropy in the randomly generated session identifiers when not using entropy in the randomly generated session identifiers when not using
client authentication to minimize the risk of session hijacking. client authentication to minimize the risk of session hijacking.
When client authentication is used the protection against hijacking When client authentication is used the protection against hijacking
will be greatly improved by scoping the accessible sessions to the will be greatly improved by scoping the accessible sessions to the
one this client identity has created. Some of the above threats are one this client identity has created. Some of the above threats are
such that the implementation of the RTSP functionality itself needs such that the implementation of the RTSP functionality itself needs
to consider which policy and strategy it uses to mitigate them. to consider which policy and strategy it uses to mitigate them.
21.2. Media Stream Delivery Threats 21.2. Media Stream Delivery Threats
The fact that RTSP establishes and controls a media stream delivery The fact that RTSP establishes and controls a media stream delivery
results in a set of security issues related to the media streams. results in a set of security issues related to the media streams.
This section will attempt to analyze general threats, however the This section will attempt to analyze general threats, however the
choice of media stream transport protocol, such as RTP will result in choice of media stream transport protocol, such as RTP will result in
some differences in threats and what mechanisms that exist to some differences in threats and what mechanisms exist to mitigate
mitigate them. Thus it becomes important that each specification of them. Thus it becomes important that each specification of a new
a new media stream transport and delivery protocol usable by RTSP media stream transport and delivery protocol usable by RTSP requires
requires its own security analysis. This section includes one for its own security analysis. This section includes one for RTP.
RTP.
The set of general threats from or by the media stream delivery The set of general threats from or by the media stream delivery
itself are: itself are:
Concentrated denial-of-service attack: The protocol offers the Concentrated denial-of-service attack: The protocol offers the
opportunity for a remote-controlled denial-of-service (DoS) opportunity for a remote-controlled denial-of-service (DoS)
attack, where the media stream is the hammer in that DoS attack. attack, where the media stream is the hammer in that DoS attack.
See Section 21.2.1. See Section 21.2.1.
Media Confidentiality: The media delivery may contain content of any Media Confidentiality: The media delivery may contain content of any
skipping to change at page 219, line 32 skipping to change at page 220, line 32
Taking into account the above general discussion in Section 21.2 and Taking into account the above general discussion in Section 21.2 and
the RTP specific discussion in this section it is clear that it is the RTP specific discussion in this section it is clear that it is
necessary that a strong security mechanism is supported to protect necessary that a strong security mechanism is supported to protect
RTP. Therefore this specification has the following requirements on RTP. Therefore this specification has the following requirements on
RTP security functions for all RTSP agents that handles media streams RTP security functions for all RTSP agents that handles media streams
and where the media stream transport is done using RTP. and where the media stream transport is done using RTP.
RTSP agents supporting RTP MUST implement Secure RTP (SRTP) [RFC3711] RTSP agents supporting RTP MUST implement Secure RTP (SRTP) [RFC3711]
and thus the SAVP profile. In addition the secure AVP profile and thus the SAVP profile. In addition the secure AVP profile
(SAVPF) [RFC5124] MUST also be supported if the AVPF profile is (SAVPF) [RFC5124] MUST also be supported if the AVPF profile is
implemented. This specification requires no additional crypto implemented. This specification requires no additional cryptographic
transforms or configuration values beyond those > mandatory to transforms or configuration values beyond those specified as
implement in RFC3711, i.e., AES-CM and HMAC-SHA1. The default key- mandatory to implement in RFC3711, i.e., AES-CM and HMAC-SHA1. The
management mechanism which MUST be implemented is the one defined in default key-management mechanism which MUST be implemented is the one
the MIKEY Key Establishment (Appendix C.1.4.1). The MIKEY defined in the MIKEY Key Establishment (Appendix C.1.4.1). The MIKEY
implementation MUST implement the necessary functions for MIKEY-RSA-R implementation MUST implement the necessary functions for MIKEY-RSA-R
mode [RFC4738] and in addition the SRTP parameter negotiation mode [RFC4738] and in addition the SRTP parameter negotiation
necessary to negotiate the supported SRTP transforms and parameters. necessary to negotiate the supported SRTP transforms and parameters.
22. IANA Considerations 22. IANA Considerations
This section sets up a number of registries for RTSP 2.0 that should This section sets up a number of registries for RTSP 2.0 that should
be maintained by IANA. These registries are separate from any be maintained by IANA. These registries are separate from any
registries existing for RTSP 1.0. For each registry there is a registries existing for RTSP 1.0. For each registry there is a
description of what it is required to contain, what specification is description of what it is required to contain, what specification is
skipping to change at page 224, line 46 skipping to change at page 225, line 46
All headers specified in Section 18 in RFCXXXX are to be registered. All headers specified in Section 18 in RFCXXXX are to be registered.
The Registry is to include header name and reference. The Registry is to include header name and reference.
Furthermore the following legacy RTSP headers defined in other Furthermore the following legacy RTSP headers defined in other
specifications are registered with header name, reference and specifications are registered with header name, reference and
description according to below list. Note: These references may not description according to below list. Note: These references may not
fulfill all of the above rules for registrations due to their legacy fulfill all of the above rules for registrations due to their legacy
status. status.
o x-wap-profile defined in [TS-26234]. The x-wap-profile request o x-wap-profile defined in [TS-26234]. The x-wap-profile request-
header contains one or more absolute URLs to the requesting header contains one or more absolute URLs to the requesting
agent's device capability profile. agent's device capability profile.
o x-wap-profile-diff defined in [TS-26234]. The x-wap-profile-diff o x-wap-profile-diff defined in [TS-26234]. The x-wap-profile-diff
request header contains a subset of a device capability profile. request-header contains a subset of a device capability profile.
o x-wap-profile-warning defined in [TS-26234]. The x-wap-profile- o x-wap-profile-warning defined in [TS-26234]. The x-wap-profile-
warning is a response header that contains error codes explaining warning is a response-header that contains error codes explaining
to what extent the server has been able to match the terminal to what extent the server has been able to match the terminal
request in regards to device capability profile as described using request in regards to device capability profile as described using
x-wap-profile and x-wap-profile-diff headers. x-wap-profile and x-wap-profile-diff headers.
o x-predecbufsize defined in [TS-26234]. This response header o x-predecbufsize defined in [TS-26234]. This response-header
provides an RTSP agent with the TS 26.234 Annex G hypothetical provides an RTSP agent with the TS 26.234 Annex G hypothetical
pre-decoder buffer size. pre-decoder buffer size.
o x-initpredecbufperiod defined in [TS-26234]. This response header o x-initpredecbufperiod defined in [TS-26234]. This response-header
provides an RTSP agent with the TS 26.234 Annex G hypothetical provides an RTSP agent with the TS 26.234 Annex G hypothetical
pre-decoder buffering period. pre-decoder buffering period.
o x-initpostdecbufperiod defined in [TS-26234]. This response o x-initpostdecbufperiod defined in [TS-26234]. This response-
header provides an RTSP agent with the TS 26.234 Annex G post- header provides an RTSP agent with the TS 26.234 Annex G post-
decoder buffering period. decoder buffering period.
o 3gpp-videopostdecbufsize defined in [TS-26234]. This response o 3gpp-videopostdecbufsize defined in [TS-26234]. This response-
header provides an RTSP agent with the TS 26.234 defined post- header provides an RTSP agent with the TS 26.234 defined post-
decoder buffer size usable for H.264 (AVC) video streams. decoder buffer size usable for H.264 (AVC) video streams.
o 3GPP-Link-Char defined in [TS-26234]. This request header o 3GPP-Link-Char defined in [TS-26234]. This request-header
provides the RTSP server with the RTSP client's link provides the RTSP server with the RTSP client's link
characteristics as determined from the radio interface. The characteristics as determined from the radio interface. The
information that can be provided are guaranteed bit-rate, maximum information that can be provided are guaranteed bit-rate, maximum
bit-rate and maximum transfer delay. bit-rate and maximum transfer delay.
o 3GPP-Adaptation defined in [TS-26234]. This general header is o 3GPP-Adaptation defined in [TS-26234]. This general-header is
part of the bit-rate adaptation solution specified for PSS. It part of the bit-rate adaptation solution specified for PSS. It
provides the RTSP client's buffer sizes and target buffer levels provides the RTSP client's buffer sizes and target buffer levels
to the server and responses are used to acknowledge the support to the server and responses are used to acknowledge the support
and values. and values.
o 3GPP-QoE-Metrics defined in [TS-26234]. This general header is o 3GPP-QoE-Metrics defined in [TS-26234]. This general-header is
used by PSS RTSP agents to negotiate the quality of experience used by PSS RTSP agents to negotiate the quality of experience
metrics that a client should gather and report to the server. metrics that a client should gather and report to the server.
o 3GPP-QoE-Feedback defined in [TS-26234]. This request header is o 3GPP-QoE-Feedback defined in [TS-26234]. This request-header is
used by RTSP clients supporting PSS to report the actual values of used by RTSP clients supporting PSS to report the actual values of
the metrics gathered in its quality of experience metering. the metrics gathered in its quality of experience metering.
The use of "x-" is NOT RECOMMENDED but the above headers in the The use of "x-" is NOT RECOMMENDED but the above headers in the
register list were defined prior to the clarification. register list were defined prior to the clarification.
22.5. Accept-Credentials 22.5. Accept-Credentials
The security framework's TLS connection mechanism has two The security framework's TLS connection mechanism has two
registerable entities. registerable entities.
skipping to change at page 233, line 35 skipping to change at page 234, line 35
A registry for the parameter transport protocol identifier MUST be A registry for the parameter transport protocol identifier MUST be
defined with the following rules: defined with the following rules:
o Registering uses the policy of Specification Required. o Registering uses the policy of Specification Required.
o A contact person or organization with address and email. o A contact person or organization with address and email.
o A value definition that are following the ABNF syntax definition o A value definition that are following the ABNF syntax definition
of "transport-id" Section 20.2.3. of "transport-id" Section 20.2.3.
o A describing text that explains how the registered value are used o A descriptive text that explains how the registered value are used
in RTSP, which underlying transport protocols that are used, and in RTSP, which underlying transport protocols that are used, and
any required Transport header parameters. any required Transport header parameters.
The registry should be represented as: The protocol ID string, The registry should be represented as: The protocol ID string,
contact person and reference. contact person and reference.
This specification registers the following values: This specification registers the following values:
RTP/AVP: Use of the RTP [RFC3550] protocol for media transport in RTP/AVP: Use of the RTP [RFC3550] protocol for media transport in
combination with the "RTP profile for audio and video combination with the "RTP profile for audio and video
skipping to change at page 236, line 41 skipping to change at page 237, line 41
The registry should be represented as: The transport parameter name, The registry should be represented as: The transport parameter name,
contact person and reference. contact person and reference.
22.14. URI Schemes 22.14. URI Schemes
This specification updates two URI schemes, one previously registered This specification updates two URI schemes, one previously registered
"rtsp", and one missing in the registry "rtspu", previously only "rtsp", and one missing in the registry "rtspu", previously only
defined in the RTSP 1.0 [RFC2326], one new URI scheme "rtsps" is also defined in the RTSP 1.0 [RFC2326], one new URI scheme "rtsps" is also
registered. These URI schemes are registered in an existing registry registered. These URI schemes are registered in an existing registry
(Uniform Resource Identifier (URI) Schemes) which are not created by (Uniform Resource Identifier (URI) Schemes) which is not created by
this memo. Registrations are following RFC 4395[RFC4395]. this memo. Registrations are following RFC 4395[RFC4395].
22.14.1. The rtsp URI Scheme 22.14.1. The rtsp URI Scheme
URI scheme name: rtsp URI scheme name: rtsp
Status: Permanent Status: Permanent
URI scheme syntax: See Section 20.2.1 of RFC XXXX. URI scheme syntax: See Section 20.2.1 of RFC XXXX.
URI scheme semantics: The rtsp scheme is used to indicate resources URI scheme semantics: The rtsp scheme is used to indicate resources
skipping to change at page 245, line 27 skipping to change at page 246, line 27
pictures and associated audio information - part 6: pictures and associated audio information - part 6:
Extension for digital storage media and control", Extension for digital storage media and control",
ISO 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.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[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.
skipping to change at page 246, line 5 skipping to change at page 247, line 7
[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, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 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.
[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.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
skipping to change at page 253, line 27 skipping to change at page 255, line 27
ssrc=4F312DD8:seq=54321;rtptime=2876889 ssrc=4F312DD8:seq=54321;rtptime=2876889
Pipelined-Requests: 7654 Pipelined-Requests: 7654
A.3. Secured Media Session for on Demand Content A.3. Secured Media Session for on Demand Content
This example is basically the above example (Appendix A.2), but now This example is basically the above example (Appendix A.2), but now
including establishment of SRTP crypto contexts to get a secured including establishment of SRTP crypto contexts to get a secured
media delivery. First of all, the client attempts to fetch this media delivery. First of all, the client attempts to fetch this
insecurely, but the server redirects to a URI indicating a insecurely, but the server redirects to a URI indicating a
requirement on using a secure connection for the RTSP messages. The requirement on using a secure connection for the RTSP messages. The
client establish a TCP/TLS connections and the session description is client establishes a TCP/TLS connections and the session description
retrieved to determine what media resources need to be setup. In the is retrieved to determine what media resources need to be setup. In
this session description secure media (SRTP) is indicated. In the the this session description secure media (SRTP) is indicated. In
next step, the client sends the necessary SETUP requests including the next step, the client sends the necessary SETUP requests
MIKEY messages. This is pipeline with a PLAY request to initiate including MIKEY messages. This is pipeline with a PLAY request to
media delivery. initiate media delivery.
Client C requests a presentation from media server M. The movie is Client C requests a presentation from media server M. The movie is
stored in a container file. The client has obtained an RTSP URI to stored in a container file. The client has obtained an RTSP URI to
the container file. the container file.
Note: The below MIKEY messages are not valid MIKEY message and are Note: The MIKEY messages below are not valid MIKEY message and are
BASE64 encoded random data to represent where the MIKEY messages BASE64 encoded random data to represent where the MIKEY messages
would go. would go.
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 301 Moved Permanently M->C: RTSP/2.0 301 Moved Permanently
CSeq: 1 CSeq: 1
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
skipping to change at page 265, line 9 skipping to change at page 267, line 9
dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; dest_addr="192.0.2.53:3056"/"192.0.2.53:3057";
src_addr="198.51.100.5:5000"/"198.51.100.5:5001" src_addr="198.51.100.5:5000"/"198.51.100.5:5001"
Server: PhonyServer/2.0 Server: PhonyServer/2.0
Accept-Ranges: npt, smpte Accept-Ranges: npt, smpte
Media-Properties: Random-Access=0.8, Immutable, Unlimited Media-Properties: Random-Access=0.8, Immutable, Unlimited
Appendix B. RTSP Protocol State Machine Appendix B. RTSP Protocol State Machine
The RTSP session state machine describes the behavior of the protocol The RTSP session state machine describes the behavior of the protocol
from RTSP session initialization through RTSP session termination. from RTSP session initialization through RTSP session termination.
It is likely easiest to think of this as the server's state and then It is probably easiest to think of this as the server's state and
the client need to track what it believe the server's state will be then view the the client as needing to track what it believes the
based on sent or received RTSP messages. Thus most cases the below server's state will be based on sent or received RTSP messages. Thus
state tables can be read as: If the client do X, assuming it fulfills in most cases the state tables below can be read as: If the client
any pre-requisite the state will move to the new state and the does X, and assuming it fulfills any pre-requisite(s), the (server)
indicated response will come back. However, there are also server to state will move to the new state and the indicated response will
client notifications or requests, where the action describes what returned. However, there are also server to client notifications or
notification or request that happens, its requisites and what new requests, where the action describes what notification or request
state will occur after the server has received the response, and will occur, its requisites and what new state will result after the
describing the clients response to the action. server has received the response, as well as describing the client's
response to the action.
The State machine is defined on a per session basis which is uniquely The State machine is defined on a per session basis which is uniquely
identified by the RTSP session identifier. The session may contain identified by the RTSP session identifier. The session may contain
one or more media streams depending on state. If a single media one or more media streams depending on state. If a single media
stream is part of the session it is in non-aggregated control. If stream is part of the session it is in non-aggregated control. If
two or more is part of the session it is in aggregated control. two or more is part of the session it is in aggregated control.
The below state machine is an informative description of the The below state machine is an informative description of the
protocols behavior. In case of ambiguity with the earlier parts of protocols behavior. In case of ambiguity with the earlier parts of
this specification, the description in the earlier parts take this specification, the description in the earlier parts take
skipping to change at page 282, line 19 skipping to change at page 284, line 19
of successful connect to the server by actively connecting outwards. of successful connect to the server by actively connecting outwards.
Therefore the clients are RECOMMENDED to take the active role. Therefore the clients are RECOMMENDED to take the active role.
After sending (receiving) a 2xx reply for a SETUP method for a non- After sending (receiving) a 2xx reply for a SETUP method for a non-
interleaved RTP/AVP/TCP media stream, the active party SHOULD interleaved RTP/AVP/TCP media stream, the active party SHOULD
initiate the TCP connection as soon as possible. The client MUST NOT initiate the TCP connection as soon as possible. The client MUST NOT
send a PLAY request prior to the establishment of all the TCP send a PLAY request prior to the establishment of all the TCP
connections negotiated using SETUP for the session. In case the connections negotiated using SETUP for the session. In case the
server receives a PLAY request in a session that has not yet server receives a PLAY request in a session that has not yet
established all the TCP connections, it MUST respond using the 464 established all the TCP connections, it MUST respond using the 464
"Data Transport Not Ready Yet" (Section 17.4.28) error code. "Data Transport Not Ready Yet" (Section 17.4.29) error code.
Once the PLAY request for a media resource transported over non- Once the PLAY request for a media resource transported over non-
interleaved RTP/AVP/TCP occurs, media begins to flow from server to interleaved RTP/AVP/TCP occurs, media begins to flow from server to
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
skipping to change at page 292, line 9 skipping to change at page 294, line 9
o Discuss congestion control for media, especially if transport o Discuss congestion control for media, especially if transport
without built in congestion control is used. without built in congestion control is used.
See the IANA section (Section 22) for information how to register new See the IANA section (Section 22) for information how to register new
attributes. attributes.
Appendix D. Use of SDP for RTSP Session Descriptions Appendix D. Use of SDP for RTSP Session Descriptions
The Session Description Protocol (SDP, [RFC4566]) may be used to The Session Description Protocol (SDP, [RFC4566]) may be used to
describe streams or presentations in RTSP. This description is describe streams or presentations in RTSP. This description is
typically returned in reply to a DESCRIBE request on an URI from a typically returned in reply to a DESCRIBE request on a URI from a
server to a client, or received via HTTP from a server to a client. server to a client, or received via HTTP from a server to a client.
This appendix describes how an SDP file determines the operation of This appendix describes how an SDP file determines the operation of
an RTSP session. Thus, it is worth pointing out that the an RTSP session. Thus, it is worth pointing out that the
interpretation of the SDP is done in the context of the SDP receiver, interpretation of the SDP is done in the context of the SDP receiver,
which is the one being configured. This is the same as in SAP which is the one being configured. This is the same as in SAP
[RFC2974]; this differs from SDP Offer/Answer [RFC3264] where each [RFC2974]; this differs from SDP Offer/Answer [RFC3264] where each
SDP is interpreted in the context of the agent providing it. SDP is interpreted in the context of the agent providing it.
SDP as is provides no mechanism by which a client can distinguish, SDP as is provides no mechanism by which a client can distinguish,
skipping to change at page 306, line 18 skipping to change at page 308, line 18
messages over unreliable transports as has been defined in RTSP 1.0 messages over unreliable transports as has been defined in RTSP 1.0
[RFC2326]. RFC 2326 defined the "rtspu" URI scheme and provided some [RFC2326]. RFC 2326 defined the "rtspu" URI scheme and provided some
basic information for the transport of RTSP messages over UDP. The basic information for the transport of RTSP messages over UDP. The
information is being provided here as there has been at at least one information is being provided here as there has been at at least one
commercial implementation and compatibility with that should be commercial implementation and compatibility with that should be
maintained. maintained.
The following points should be considered for an interoperable The following points should be considered for an interoperable
implementation: implementation:
o Request shall be acknowledged by the receiver. If there is no o Requests shall be acknowledged by the receiver. If there is no
acknowledgement, the sender may resend the same message after a acknowledgement, the sender may resend the same message after a
timeout of one round-trip time (RTT). Any retransmissions due to timeout of one round-trip time (RTT). Any retransmissions due to
lack of acknowledgement must carry the same sequence number as the lack of acknowledgement must carry the same sequence number as the
original request. original request.
o The round-trip time can be estimated as in TCP (RFC 6298) o The round-trip time can be estimated as in TCP (RFC 6298)
[RFC6298], with an initial round-trip value of 500 ms. An [RFC6298], with an initial round-trip value of 500 ms. An
implementation may cache the last RTT measurement as the initial implementation may cache the last RTT measurement as the initial
value for future connections. value for future connections.
skipping to change at page 312, line 44 skipping to change at page 314, line 44
* There is now a requirement on the servers to handle non- * There is now a requirement on the servers to handle non-
persistent connections as this provides fault tolerance. persistent connections as this provides fault tolerance.
* Added wording on the usage of Connection:Close for RTSP. * Added wording on the usage of Connection:Close for RTSP.
* Specified usage of TLS for RTSP messages, including a scheme to * Specified usage of TLS for RTSP messages, including a scheme to
approve a proxy's TLS connection to the next hop. approve a proxy's TLS connection to the next hop.
o The following header related changes have been made: o The following header related changes have been made:
* Accept-Ranges response header is added. This header clarifies * Accept-Ranges response-header is added. This header clarifies
which range formats that can be used for a resource. which range formats that can be used for a resource.
* Fixed the missing definitions for the Cache-Control header. * Fixed the missing definitions for the Cache-Control header.
Also added to the syntax definition the missing delta-seconds Also added to the syntax definition the missing delta-seconds
for max-stale and min-fresh parameters. for max-stale and min-fresh parameters.
* Put requirement on CSeq header that the value is increased by * Put requirement on CSeq header that the value is increased by
one for each new RTSP request. A Recommendation to start at 0 one for each new RTSP request. A Recommendation to start at 0
has also been added. has also been added.
skipping to change at page 316, line 34 skipping to change at page 318, line 34
actual text to the specification. actual text to the specification.
o Added a section Use Cases that describes the major use cases for o Added a section Use Cases that describes the major use cases for
RTSP. RTSP.
o Clarified the usage of a=range and how to indicate live content o Clarified the usage of a=range and how to indicate live content
that are not seekable with this header. that are not seekable with this header.
o Text specifying the special behavior of PLAY for live content. o Text specifying the special behavior of PLAY for live content.
o Security features of RTSP has been clarified: o Security features of RTSP have been clarified:
* HTTP based authorization has been clarified requring both Basic * HTTP based authorization has been clarified requring both Basic
and DIGEST support and DIGEST support
* TLS support mandated * TLS support mandated
* IF one implements RTP then SRTP and defined MIKEY based key- * IF one implements RTP then SRTP and defined MIKEY based key-
exchange must be supported exchange must be supported
* Various minor mitigations discussed or resulted in protocol * Various minor mitigations discussed or resulted in protocol
skipping to change at page 317, line 15 skipping to change at page 319, line 15
Appendix J. Acknowledgements Appendix J. Acknowledgements
This memorandum defines RTSP version 2.0 which is a revision of the This memorandum defines RTSP version 2.0 which is a revision of the
Proposed Standard RTSP version 1.0 which is defined in [RFC2326]. Proposed Standard RTSP version 1.0 which is defined in [RFC2326].
The authors of RFC 2326 are Henning Schulzrinne, Anup Rao, and Robert The authors of RFC 2326 are Henning Schulzrinne, Anup Rao, and Robert
Lanphier. Lanphier.
Both RTSP version 1.0 and RTSP version 2.0 borrow format and Both RTSP version 1.0 and RTSP version 2.0 borrow format and
descriptions from HTTP/1.1. descriptions from HTTP/1.1.
Robert Sparks and especially Elwyn Davies provided very valuable and
detailed reviews in the IETF last call that greately improved the
document and resolved many issues, especially regarding consistency.
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, Claudio Allocchio, Jeff Ayars, Milko Boic, Torsten
Bruce Butterfield, Steve Casner, Maureen Chesire, Jinhang Choi, Braun, Brent Browning, Bruce Butterfield, Steve Casner, Maureen
Francisco Cortes, Elwyn Davies, Kelly Djahandari, Martin Dunsmuir, Chesire, Jinhang Choi, Francisco Cortes, Elwyn Davies, Kelly
Stephen Farrell, Ross Finlayson, Eric Fleischman, Jay Geagan, Andy Djahandari, Martin Dunsmuir, Stephen Farrell, Ross Finlayson, Eric
Grignon, Christian Groves, V. Guruprasad, Peter Haight, Mark Handley, Fleischman, Jay Geagan, Andy Grignon, Christian Groves, V.
Brad Hefta-Gaub, Volker Hilt, John K. Ho, Patrick Hoffman, Go Hori, Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt,
Philipp Hoschka, Anne Jones, Ingemar Johansson, Jae-Hwan Kim, Anders John K. Ho, Patrick Hoffman, Go Hori, Philipp Hoschka, Anne Jones,
Klemets, Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Ingemar Johansson, Jae-Hwan Kim, Anders Klemets, Ruth Lang, Stephanie
Llach, Chris Lonvick, Xavier Marjou, Thomas Marshall, Rob McCool, Leif, Jonathan Lennox, Eduardo F. Llach, Chris Lonvick, Xavier
Martti Mela, David Oran, Joerg Ott, Joe Pallas, Maria Papadopouli, Marjou, Thomas Marshall, Rob McCool, Martti Mela, David Oran, Joerg
Sujal Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Pekka Pessi, Ott, Joe Pallas, Maria Papadopouli, Sujal Patel, Ema Patki, Alagu
Igor Plotnikov, Holger Schmidt, Jonathan Sergent, Pinaki Shah, David Periyannan, Colin Perkins, Pekka Pessi, Igor Plotnikov, Peter Saint-
Singer, Lior Sion, Jeff Smith, Alexander Sokolsky, Dale Stammen, John Andre, Holger Schmidt, Jonathan Sergent, Pinaki Shah, David Singer,
Francis Stracke, Geetha Srikantan, Scott Taylor, David Walker, Lior Sion, Jeff Smith, Alexander Sokolsky, Dale Stammen, John Francis
Stephan Wenger, Dale R. Worley, and Byungjo Yoon , and especially to Stracke, Geetha Srikantan, Scott Taylor, David Walker, Stephan
Flemming Andreasen. Wenger, Dale R. Worley, and Byungjo Yoon , and especially 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
 End of changes. 217 change blocks. 
792 lines changed or deleted 879 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/