draft-ietf-mmusic-rfc2326bis-15.txt   draft-ietf-mmusic-rfc2326bis-16.txt 
MMUSIC Working Group H. Schulzrinne MMUSIC Working Group H. Schulzrinne
Internet-Draft Columbia University Internet-Draft Columbia University
Intended status: Standards Track A. Rao Intended status: Standards Track A. Rao
Expires: December 27, 2007 Cisco Expires: May 22, 2008 Cisco
R. Lanphier R. Lanphier
Real Networks Real Networks
M. Westerlund M. Westerlund
Ericsson AB Ericsson AB
A. Narasimhan
Overture Computing Corp.
M. Stiemerling (Ed.) M. Stiemerling (Ed.)
NEC NEC
June 25, 2007 November 19, 2007
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-15.txt draft-ietf-mmusic-rfc2326bis-16.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 43 skipping to change at page 1, line 41
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 27, 2007. This Internet-Draft will expire on May 22, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
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 RFC 2326. Proposed Standard RTSP version 1.0 which is defined in RFC 2326.
skipping to change at page 2, line 23 skipping to change at page 2, line 23
controlled, on-demand delivery of real-time data, such as audio and controlled, on-demand delivery of real-time data, such as audio and
video. Sources of data can include both live data feeds and stored video. Sources of data can include both live data feeds and stored
clips. This protocol is intended to control multiple data delivery clips. This protocol is intended to control multiple data delivery
sessions, provide a means for choosing delivery channels such as UDP, sessions, provide a means for choosing delivery channels such as UDP,
multicast UDP and TCP, and provide a means for choosing delivery multicast UDP and TCP, and provide a means for choosing delivery
mechanisms based upon RTP (RFC 3550). mechanisms based upon RTP (RFC 3550).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1. RTSP Specification Update . . . . . . . . . . . . . . . 8 1.1. Scope and Background . . . . . . . . . . . . . . . . . . 8
1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2. RTSP Specificication Update . . . . . . . . . . . . . . 9
1.3. Notational Conventions . . . . . . . . . . . . . . . . . 10 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 10
1.3.1. RFC Editor Consideration . . . . . . . . . . . . . . 10
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . 10 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . 10
1.5. Protocol Properties . . . . . . . . . . . . . . . . . . 14 2. RTSP Introduction . . . . . . . . . . . . . . . . . . . . . . 15
1.6. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 15 2.1. Protocol Properties . . . . . . . . . . . . . . . . . . 15
1.7. Overall Operation . . . . . . . . . . . . . . . . . . . 16 2.2. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 16
1.8. RTSP States . . . . . . . . . . . . . . . . . . . . . . 17 2.3. Overall Operation . . . . . . . . . . . . . . . . . . . 17
1.9. Relationship with Other Protocols . . . . . . . . . . . 18 2.4. RTSP States . . . . . . . . . . . . . . . . . . . . . . 18
2. RTSP Use Cases . . . . . . . . . . . . . . . . . . . . . . . 19 2.5. Relationship with Other Protocols . . . . . . . . . . . 19
2.1. On-demand Playback of Stored Content . . . . . . . . . . 19 3. RTSP Use Cases . . . . . . . . . . . . . . . . . . . . . . . 20
2.2. Unicast distribution of Live Content . . . . . . . . . . 20 3.1. On-demand Playback of Stored Content . . . . . . . . . . 20
2.3. On-demand Playback using Multicast . . . . . . . . . . . 21 3.2. Unicast distribution of Live Content . . . . . . . . . . 21
2.4. Inviting an RTSP server into a conference . . . . . . . 21 3.3. On-demand Playback using Multicast . . . . . . . . . . . 22
2.5. Live Content using Multicast . . . . . . . . . . . . . . 22 3.4. Inviting an RTSP server into a conference . . . . . . . 22
3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 24 3.5. Live Content using Multicast . . . . . . . . . . . . . . 23
3.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 24 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 25
3.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 24 4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 25
3.3. Session Identifiers . . . . . . . . . . . . . . . . . . 26 4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 25
3.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . 26 4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 27
3.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 26 4.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . 27
3.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . 27 4.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 27
3.7. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 27 4.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . 28
3.8. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 28 4.7. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 28
4. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 29 4.8. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 29
4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 29 5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 29 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 30
4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 29 5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 30
4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 29 5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 30
5. General Header Fields . . . . . . . . . . . . . . . . . . . . 31 5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 30
6. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 6. General Header Fields . . . . . . . . . . . . . . . . . . . . 32
6.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 32 7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2. Request Header Fields . . . . . . . . . . . . . . . . . 34 7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 33
7. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7.2. Request Header Fields . . . . . . . . . . . . . . . . . 35
7.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 36 8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.1.1. Status Code and Reason Phrase . . . . . . . . . . . 36 8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 37
7.2. Response Header Fields . . . . . . . . . . . . . . . . . 39 8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 37
8. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 8.2. Response Header Fields . . . . . . . . . . . . . . . . . 40
8.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 42 9. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 43 9.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 43
9. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 44 9.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 44
9.1. Reliability and Acknowledgements . . . . . . . . . . . . 44 10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.2. Using Connections . . . . . . . . . . . . . . . . . . . 45 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 45
9.3. Closing Connections . . . . . . . . . . . . . . . . . . 46 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 46
9.4. Timing Out Connections and RTSP Messages . . . . . . . . 47 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 47
9.5. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 47 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 48
10. Capability Handling . . . . . . . . . . . . . . . . . . . . . 48 10.5. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 48
11. Method Definitions . . . . . . . . . . . . . . . . . . . . . 50 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 49
11.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 51 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 51
11.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 52 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 52
11.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 54 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 53
11.3.1. Changing Transport Parameters . . . . . . . . . . . 56 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 54
11.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 57 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 56
11.5. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 62 13.3.1. Changing Transport Parameters . . . . . . . . . . . 58
11.6. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 65 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 59
11.7. GETPARAMETER . . . . . . . . . . . . . . . . . . . . . . 66 13.5. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 64
11.8. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 67 13.6. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 66
11.9. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 68 13.7. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 67
12. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 71 13.8. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 68
13. Status Code Definitions . . . . . . . . . . . . . . . . . . . 73 13.9. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 69
13.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 73 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 73
13.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 73 15. Status Code Definitions . . . . . . . . . . . . . . . . . . . 75
13.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 73 15.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 75
13.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 73 15.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 75
13.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 74 15.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 75
13.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 74 15.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 75
13.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 74 15.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 76
13.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 74 15.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 76
13.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 74 15.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 76
13.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 75 15.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 76
13.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 75 15.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 76
13.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 75 15.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 77
13.4.2. 405 Method Not Allowed . . . . . . . . . . . . . . . 75 15.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 77
13.4.3. 451 Parameter Not Understood . . . . . . . . . . . . 75 15.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 77
13.4.4. 452 reserved . . . . . . . . . . . . . . . . . . . . 75 15.4.2. 405 Method Not Allowed . . . . . . . . . . . . . . . 77
13.4.5. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 76 15.4.3. 451 Parameter Not Understood . . . . . . . . . . . . 77
13.4.6. 454 Session Not Found . . . . . . . . . . . . . . . 76 15.4.4. 452 reserved . . . . . . . . . . . . . . . . . . . . 77
13.4.7. 455 Method Not Valid in This State . . . . . . . . . 76 15.4.5. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 78
13.4.8. 456 Header Field Not Valid for Resource . . . . . . 76 15.4.6. 454 Session Not Found . . . . . . . . . . . . . . . 78
13.4.9. 457 Invalid Range . . . . . . . . . . . . . . . . . 76 15.4.7. 455 Method Not Valid in This State . . . . . . . . . 78
13.4.10. 458 Parameter Is Read-Only . . . . . . . . . . . . . 76 15.4.8. 456 Header Field Not Valid for Resource . . . . . . 78
13.4.11. 459 Aggregate Operation Not Allowed . . . . . . . . 76 15.4.9. 457 Invalid Range . . . . . . . . . . . . . . . . . 78
13.4.12. 460 Only Aggregate Operation Allowed . . . . . . . . 76 15.4.10. 458 Parameter Is Read-Only . . . . . . . . . . . . . 78
13.4.13. 461 Unsupported Transport . . . . . . . . . . . . . 77 15.4.11. 459 Aggregate Operation Not Allowed . . . . . . . . 78
13.4.14. 462 Destination Unreachable . . . . . . . . . . . . 77 15.4.12. 460 Only Aggregate Operation Allowed . . . . . . . . 78
13.4.15. 463 Destination Prohibited . . . . . . . . . . . . . 77 15.4.13. 461 Unsupported Transport . . . . . . . . . . . . . 79
13.4.16. 464 Data Transport Not Ready Yet . . . . . . . . . . 77 15.4.14. 462 Destination Unreachable . . . . . . . . . . . . 79
13.4.17. 470 Connection Authorization Required . . . . . . . 77 15.4.15. 463 Destination Prohibited . . . . . . . . . . . . . 79
13.4.18. 471 Connection Credentials not accepted . . . . . . 77 15.4.16. 464 Data Transport Not Ready Yet . . . . . . . . . . 79
13.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 78 15.4.17. 470 Connection Authorization Required . . . . . . . 79
13.5.1. 551 Option not supported . . . . . . . . . . . . . . 78 15.4.18. 471 Connection Credentials not accepted . . . . . . 79
14. Header Field Definitions . . . . . . . . . . . . . . . . . . 79 15.4.19. 472 Failure to establish secure connection . . . . . 80
14.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 88 15.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 80
14.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 88 15.5.1. 551 Option not supported . . . . . . . . . . . . . . 80
14.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 89 16. Header Field Definitions . . . . . . . . . . . . . . . . . . 81
14.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 89 16.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 90
14.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 89 16.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 90
14.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 89 16.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 91
14.7. Authorization . . . . . . . . . . . . . . . . . . . . . 90 16.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 91
14.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 90 16.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 91
14.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 90 16.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 91
14.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 90 16.7. Authorization . . . . . . . . . . . . . . . . . . . . . 92
14.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 93 16.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 92
14.12. Connection-Credentials . . . . . . . . . . . . . . . . . 93 16.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 92
14.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 93 16.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 92
14.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 93 16.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 95
14.15. Content-Language . . . . . . . . . . . . . . . . . . . . 93 16.12. Connection-Credentials . . . . . . . . . . . . . . . . . 95
14.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 94 16.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 96
14.17. Content-Location . . . . . . . . . . . . . . . . . . . . 94 16.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 96
14.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 94 16.15. Content-Language . . . . . . . . . . . . . . . . . . . . 96
14.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 94 16.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 96
14.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 94 16.17. Content-Location . . . . . . . . . . . . . . . . . . . . 97
14.21. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 95 16.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 97
14.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 95 16.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 97
14.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 96 16.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 97
14.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 96 16.21. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 97
14.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 97 16.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 98
14.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 97 16.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 99
14.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 97 16.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 99
14.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 97 16.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 99
14.29. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 97 16.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 100
14.30. Proxy-Authorization . . . . . . . . . . . . . . . . . . 97 16.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 100
14.31. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 97 16.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 100
14.32. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 98 16.29. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 100
14.33. Public . . . . . . . . . . . . . . . . . . . . . . . . . 99 16.30. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 101
14.34. Range . . . . . . . . . . . . . . . . . . . . . . . . . 100 16.31. Proxy-Authorization . . . . . . . . . . . . . . . . . . 101
14.35. Referer . . . . . . . . . . . . . . . . . . . . . . . . 101 16.32. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 101
14.36. Retry-After . . . . . . . . . . . . . . . . . . . . . . 101 16.33. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 102
14.37. Require . . . . . . . . . . . . . . . . . . . . . . . . 101 16.34. Public . . . . . . . . . . . . . . . . . . . . . . . . . 103
14.38. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 102 16.35. Range . . . . . . . . . . . . . . . . . . . . . . . . . 103
14.39. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 104 16.36. Referer . . . . . . . . . . . . . . . . . . . . . . . . 105
14.40. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 105 16.37. Retry-After . . . . . . . . . . . . . . . . . . . . . . 105
14.41. Server . . . . . . . . . . . . . . . . . . . . . . . . . 106 16.38. Require . . . . . . . . . . . . . . . . . . . . . . . . 105
14.42. Session . . . . . . . . . . . . . . . . . . . . . . . . 106 16.39. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 106
14.43. Supported . . . . . . . . . . . . . . . . . . . . . . . 107 16.40. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 108
14.44. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 108 16.41. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 109
14.45. Transport . . . . . . . . . . . . . . . . . . . . . . . 108 16.42. Server . . . . . . . . . . . . . . . . . . . . . . . . . 110
14.46. Unsupported . . . . . . . . . . . . . . . . . . . . . . 114 16.43. Session . . . . . . . . . . . . . . . . . . . . . . . . 110
14.47. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 114 16.44. Supported . . . . . . . . . . . . . . . . . . . . . . . 111
14.48. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 114 16.45. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 112
14.49. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 114 16.46. Transport . . . . . . . . . . . . . . . . . . . . . . . 112
14.50. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 114 16.47. Unsupported . . . . . . . . . . . . . . . . . . . . . . 118
15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 16.48. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 118
16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 16.49. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 118
17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 118 16.50. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 118
17.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 118 16.51. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 119
17.2. Media on Demand (Unicast) . . . . . . . . . . . . . . . 121 17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
17.3. Single Stream Container Files . . . . . . . . . . . . . 123 18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
17.4. Live Media Presentation Using Multicast . . . . . . . . 125 19. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 123
17.5. Capability Negotiation . . . . . . . . . . . . . . . . . 126 19.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 123
18. Security Framework . . . . . . . . . . . . . . . . . . . . . 128 19.2. Media on Demand using Pipelining . . . . . . . . . . . . 126
18.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 128 19.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 128
18.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 128 19.4. Single Stream Container Files . . . . . . . . . . . . . 131
18.3. Security and Proxies . . . . . . . . . . . . . . . . . . 129 19.5. Live Media Presentation Using Multicast . . . . . . . . 133
18.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 130 19.6. Capability Negotiation . . . . . . . . . . . . . . . . . 135
18.3.2. User approved TLS procedure . . . . . . . . . . . . 131 20. Security Framework . . . . . . . . . . . . . . . . . . . . . 137
19. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 20.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 137
19.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 133 20.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 137
19.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 135 20.3. Security and Proxies . . . . . . . . . . . . . . . . . . 138
19.2.1. Generic Protocol elements . . . . . . . . . . . . . 135 20.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 139
19.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 138 20.3.2. User approved TLS procedure . . . . . . . . . . . . 140
19.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 142 21. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
19.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 149 21.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 143
20. Security Considerations . . . . . . . . . . . . . . . . . . . 150 21.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 145
20.1. Remote denial of Service Attack . . . . . . . . . . . . 152 21.2.1. Generic Protocol elements . . . . . . . . . . . . . 145
21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 154 21.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 148
21.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 154 21.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 152
21.1.1. Description . . . . . . . . . . . . . . . . . . . . 154 21.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 159
21.1.2. Registering New Feature-tags with IANA . . . . . . . 155 22. Security Considerations . . . . . . . . . . . . . . . . . . . 160
21.1.3. Registered entries . . . . . . . . . . . . . . . . . 155 22.1. Remote denial of Service Attack . . . . . . . . . . . . 162
21.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 155 23. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 164
21.2.1. Description . . . . . . . . . . . . . . . . . . . . 155 23.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 164
21.2.2. Registering New Methods with IANA . . . . . . . . . 155 23.1.1. Description . . . . . . . . . . . . . . . . . . . . 164
21.2.3. Registered Entries . . . . . . . . . . . . . . . . . 156 23.1.2. Registering New Feature-tags with IANA . . . . . . . 165
21.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 156 23.1.3. Registered entries . . . . . . . . . . . . . . . . . 165
21.3.1. Description . . . . . . . . . . . . . . . . . . . . 156 23.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 165
21.3.2. Registering New Status Codes with IANA . . . . . . . 156 23.2.1. Description . . . . . . . . . . . . . . . . . . . . 165
21.3.3. Registered Entries . . . . . . . . . . . . . . . . . 156 23.2.2. Registering New Methods with IANA . . . . . . . . . 165
21.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 156 23.2.3. Registered Entries . . . . . . . . . . . . . . . . . 166
21.4.1. Description . . . . . . . . . . . . . . . . . . . . 156 23.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 166
21.4.2. Registering New Headers with IANA . . . . . . . . . 157 23.3.1. Description . . . . . . . . . . . . . . . . . . . . 166
21.4.3. Registered entries . . . . . . . . . . . . . . . . . 157 23.3.2. Registering New Status Codes with IANA . . . . . . . 166
21.5. Transport Header Registries . . . . . . . . . . . . . . 158 23.3.3. Registered Entries . . . . . . . . . . . . . . . . . 166
21.5.1. Transport Protocol Specification . . . . . . . . . . 158 23.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 166
21.5.2. Transport modes . . . . . . . . . . . . . . . . . . 159 23.4.1. Description . . . . . . . . . . . . . . . . . . . . 166
21.5.3. Transport Parameters . . . . . . . . . . . . . . . . 160 23.4.2. Registering New Headers with IANA . . . . . . . . . 167
21.6. Cache Directive Extensions . . . . . . . . . . . . . . . 160 23.4.3. Registered entries . . . . . . . . . . . . . . . . . 167
21.7. Accept-Credentials . . . . . . . . . . . . . . . . . . . 161 23.5. Transport Header Registries . . . . . . . . . . . . . . 168
21.7.1. Accept-Credentials policies . . . . . . . . . . . . 161 23.5.1. Transport Protocol Specification . . . . . . . . . . 168
21.7.2. Accept-Credentials hash algorithms . . . . . . . . . 161 23.5.2. Transport modes . . . . . . . . . . . . . . . . . . 169
21.8. Range header formats . . . . . . . . . . . . . . . . . . 162 23.5.3. Transport Parameters . . . . . . . . . . . . . . . . 170
21.9. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 162 23.6. Cache Directive Extensions . . . . . . . . . . . . . . . 170
21.9.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 162 23.7. Accept-Credentials . . . . . . . . . . . . . . . . . . . 171
21.9.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 163 23.7.1. Accept-Credentials policies . . . . . . . . . . . . 171
21.9.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 164 23.7.2. Accept-Credentials hash algorithms . . . . . . . . . 171
21.10. SDP attributes . . . . . . . . . . . . . . . . . . . . . 165 23.8. Range header formats . . . . . . . . . . . . . . . . . . 172
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 166 23.9. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 172
22.1. Normative References . . . . . . . . . . . . . . . . . . 166 23.9.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 172
22.2. Informative References . . . . . . . . . . . . . . . . . 168 23.9.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 173
Appendix A. RTSP Protocol State Machine . . . . . . . . . . . . 170 23.9.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 174
A.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 170 23.10. SDP attributes . . . . . . . . . . . . . . . . . . . . . 175
A.2. State variables . . . . . . . . . . . . . . . . . . . . 170 24. References . . . . . . . . . . . . . . . . . . . . . . . . . 176
A.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 170 24.1. Normative References . . . . . . . . . . . . . . . . . . 176
A.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 171 24.2. Informative References . . . . . . . . . . . . . . . . . 178
Appendix B. Media Transport Alternatives . . . . . . . . . . . . 176 Appendix A. RTSP Protocol State Machine . . . . . . . . . . . . 181
B.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 176 A.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 181
B.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 176 A.2. State variables . . . . . . . . . . . . . . . . . . . . 181
B.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 176 A.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 181
B.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 177 A.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 182
B.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 178 Appendix B. Media Transport Alternatives . . . . . . . . . . . . 187
B.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 178 B.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 187
B.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 178 B.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 187
B.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 178 B.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 187
B.2.2. RTP over independent TCP . . . . . . . . . . . . . . 179 B.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 188
B.2.3. Handling NPT Jumps in the RTP Media Layer . . . . . 182 B.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 189
B.2.4. Handling RTP Timestamps after PAUSE . . . . . . . . 184 B.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 189
B.2.5. RTSP / RTP Integration . . . . . . . . . . . . . . . 186 B.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 189
B.2.6. Scaling with RTP . . . . . . . . . . . . . . . . . . 186 B.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 190
B.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 190
B.2.2. RTP over independent TCP . . . . . . . . . . . . . . 190
B.2.3. Handling NPT Jumps in the RTP Media Layer . . . . . 194
B.2.4. Handling RTP Timestamps after PAUSE . . . . . . . . 197
B.2.5. RTSP / RTP Integration . . . . . . . . . . . . . . . 199
B.2.6. Scaling with RTP . . . . . . . . . . . . . . . . . . 199
B.2.7. Maintaining NPT synchronization with RTP B.2.7. Maintaining NPT synchronization with RTP
timestamps . . . . . . . . . . . . . . . . . . . . . 187 timestamps . . . . . . . . . . . . . . . . . . . . . 199
B.2.8. Continuous Audio . . . . . . . . . . . . . . . . . . 187 B.2.8. Continuous Audio . . . . . . . . . . . . . . . . . . 199
B.2.9. Multiple Sources in an RTP Session . . . . . . . . . 187 B.2.9. Multiple Sources in an RTP Session . . . . . . . . . 199
B.2.10. Usage of SSRCs and the RTCP BYE Message During an B.2.10. Usage of SSRCs and the RTCP BYE Message During an
RTSP Session . . . . . . . . . . . . . . . . . . . . 187 RTSP Session . . . . . . . . . . . . . . . . . . . . 199
B.3. Future Additions . . . . . . . . . . . . . . . . . . . . 187 B.3. Future Additions . . . . . . . . . . . . . . . . . . . . 200
Appendix C. Use of SDP for RTSP Session Descriptions . . . . . . 189 Appendix C. Use of SDP for RTSP Session Descriptions . . . . . . 201
C.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 189 C.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 201
C.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 189 C.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 201
C.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 190 C.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 202
C.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 191 C.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 203
C.1.4. Format-Specific Parameters . . . . . . . . . . . . . 191 C.1.4. Format-Specific Parameters . . . . . . . . . . . . . 203
C.1.5. Directionality of media stream . . . . . . . . . . . 191 C.1.5. Directionality of media stream . . . . . . . . . . . 203
C.1.6. Range of Presentation . . . . . . . . . . . . . . . 192 C.1.6. Range of Presentation . . . . . . . . . . . . . . . 204
C.1.7. Time of Availability . . . . . . . . . . . . . . . . 193 C.1.7. Time of Availability . . . . . . . . . . . . . . . . 205
C.1.8. Connection Information . . . . . . . . . . . . . . . 193 C.1.8. Connection Information . . . . . . . . . . . . . . . 205
C.1.9. Entity Tag . . . . . . . . . . . . . . . . . . . . . 193 C.1.9. Entity Tag . . . . . . . . . . . . . . . . . . . . . 205
C.2. Aggregate Control Not Available . . . . . . . . . . . . 194 C.2. Aggregate Control Not Available . . . . . . . . . . . . 206
C.3. Aggregate Control Available . . . . . . . . . . . . . . 195 C.3. Aggregate Control Available . . . . . . . . . . . . . . 206
C.4. RTSP external SDP delivery . . . . . . . . . . . . . . . 196 C.4. RTSP external SDP delivery . . . . . . . . . . . . . . . 207
Appendix D. Minimal RTSP Implementation . . . . . . . . . . . . 197 Appendix D. Minimal RTSP Implementation . . . . . . . . . . . . 209
D.1. Minimal Core Implementation . . . . . . . . . . . . . . 197 D.1. Minimal Core Implementation . . . . . . . . . . . . . . 209
D.2. Recommended Core Implementation . . . . . . . . . . . . 197 D.2. Recommended Core Implementation . . . . . . . . . . . . 209
D.3. The Basic Playback Feature Support . . . . . . . . . . . 198 D.3. The Basic Playback Feature Support . . . . . . . . . . . 210
D.3.1. Client . . . . . . . . . . . . . . . . . . . . . . . 198 D.3.1. Client . . . . . . . . . . . . . . . . . . . . . . . 210
D.3.2. Server . . . . . . . . . . . . . . . . . . . . . . . 198 D.3.2. Server . . . . . . . . . . . . . . . . . . . . . . . 210
D.3.3. Proxy . . . . . . . . . . . . . . . . . . . . . . . 199 D.3.3. Proxy . . . . . . . . . . . . . . . . . . . . . . . 211
D.4. Secure Transport . . . . . . . . . . . . . . . . . . . . 199 D.4. Secure Transport . . . . . . . . . . . . . . . . . . . . 211
Appendix E. Requirements for Unreliable Transport of RTSP . . . 200 Appendix E. Requirements for Unreliable Transport of RTSP . . . 212
Appendix F. Backwards Compatibility Considerations . . . . . . . 202 Appendix F. Backwards Compatibility Considerations . . . . . . . 214
F.1. Play Request in Play mode . . . . . . . . . . . . . . . 202 F.1. Play Request in Play mode . . . . . . . . . . . . . . . 214
F.2. Using Persistent Connections . . . . . . . . . . . . . . 202 F.2. Using Persistent Connections . . . . . . . . . . . . . . 214
Appendix G. Open Issues . . . . . . . . . . . . . . . . . . . . 203 Appendix G. Open Issues . . . . . . . . . . . . . . . . . . . . 215
Appendix H. Changes . . . . . . . . . . . . . . . . . . . . . . 205 Appendix H. Changes . . . . . . . . . . . . . . . . . . . . . . 217
H.1. Changes needing to be updated . . . . . . . . . . . . . 210 H.1. Changes needing to be updated . . . . . . . . . . . . . 222
Appendix I. Contributors . . . . . . . . . . . . . . . . . . . . 211 Appendix I. Acknowledgements . . . . . . . . . . . . . . . . . . 224
Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 212 I.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 224
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 213 Appendix J. RFC Editor Consideration . . . . . . . . . . . . . . 226
Intellectual Property and Copyright Statements . . . . . . . . . 215 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 227
Intellectual Property and Copyright Statements . . . . . . . . . 228
1. Introduction 1. Introduction
1.1. RTSP Specification Update 1.1. Scope and Background
This memorandum specifies RTSP 2.0 which is an update of RTSP 1.0, a
proposed standard defined in [RFC2326]. The goal of this version is
to correct the many flaws that have been identified in RTSP 1.0 since
its publication. The corrections are such that backwards
compatibility was impossible. Thus a new version was deemed the most
appropriate solution to get a more functional protocol. There are no
plans to revise RTSP 1.0. Appendix H catalogs the changes of this
version in relation to RTSP 1.0.
RTSP 2.0 has reduced functionality compared to RTSP 1.0 and aims at
specifying the RTSP core, functionality and rules for extensions, and
basic interaction with the media delivery protocol RTP [RFC3550].
Any other functionality would be need to be published as extension This memo defines version 2.0 of the Real Time Streaming Protocol
documents. This specification provides rules for such extensions and (RTSP 2.0) which is an application-level protocol for control over
defines registries to avoid naming collisions. the delivery of data with real-time properties, typically streaming
media. Streaming media is, for instance, video on demand or audio
life streaming. Put simply, RTSP acts as a "network remote control"
for multimedia servers, as you know it from your TV set.
1.2. Purpose The protocol operates between RTSP 2.0 clients and servers, but also
supports the usage of RTSP 2.0 proxies between clients and servers.
Basically, clients can request information about streaming media from
servers, by asking for a description of the media or use media
description provided externally. Based on the media description
clients can request to play out the media, pause it, or stop it
completely, as known from a regular TV remote control. The requested
media can consist of multiple audio and video streams that are
delivered as a time- synchronized stream from servers to clients.
The Real-Time Streaming Protocol (RTSP) establishes and controls one This memorandum describes the use of RTSP over a reliable connection
or several time-synchronized streams of continuous media such as based transport level protocol, such as TCP. For security, TLS over
audio and video. Put simply, RTSP acts as a "network remote control" a connection oriented transport is supported.
for multimedia servers.
There is no notion of an RTSP connection in the protocol. Instead, There is no notion of an RTSP connection in the protocol. Instead,
an RTSP server maintains a session labeled by an identifier to an RTSP server maintains a session labeled by an identifier to
associate groups of media streams and their states. An RTSP session associate groups of media streams and their states. An RTSP session
is not tied to a transport-level connection such as a TCP connection. is not tied to a transport-level connection such as a TCP connection.
During a session, a client may open and close multiple reliable During a session, a client may open and close multiple reliable
transport connections to the server to issue RTSP requests for that transport connections to the server to issue RTSP requests for that
session. session.
This memorandum describes the use of RTSP over a reliable connection
based transport level protocol such as TCP. RTSP may be implemented
over an unreliable connectionless transport protocol such as UDP.
While nothing in RTSP precludes this, additional definition of this
problem area needs to be handled as an extension to the core
specification.
The mechanisms of RTSP's operation over UDP were left out of this
spec. because they were poorly defined in [RFC2326] and the
tradeoff in size and complexity of this memorandum for a small
gain in a limited problem space was not deemed justifiable.
The set of streams to be controlled in an RTSP session is defined by The set of streams to be controlled in an RTSP session is defined by
a presentation description. This memorandum does not define a format a presentation description. This memorandum does not define a format
for the presentation description. However appendix C describes how for the presentation description. However Appendix C describes how
SDP [RFC4566] is used for this purpose. The streams controlled by SDP [RFC4566] is used for this purpose. The streams controlled by
RTSP may use RTP [RFC3550] for their data transport, but the RTSP may use RTP [RFC3550] for their data transport, but the
operation of RTSP does not depend on the transport mechanism used to operation of RTSP does not depend on the transport mechanism used to
carry continuous media. RTSP is intentionally similar in syntax and carry continuous media. RTSP is intentionally similar in syntax and
operation to HTTP/1.1 [RFC2616] so that extension mechanisms to HTTP operation to HTTP/1.1 [RFC2616] so that extension mechanisms to HTTP
can in most cases also be applied to RTSP. However, RTSP differs in can in most cases also be applied to RTSP. However, RTSP differs in
a number of important aspects from HTTP: a number of important aspects from HTTP:
* RTSP introduces a number of new methods and has a different * RTSP introduces a number of new methods and has a different
protocol identifier. protocol identifier.
* RTSP has the notion of a session built into the protocol. * RTSP has the notion of a session built into the protocol.
* An RTSP server needs to maintain state in almost all cases, as * An RTSP server needs to maintain state in almost all cases, as
opposed to the stateless nature of HTTP. opposed to the stateless nature of HTTP.
* Both an RTSP server and client can issue requests. * Both an RTSP server and client can issue requests.
* Data is usually carried out-of-band by a different protocol. * Data is usually carried out-of-band by a different protocol.
Session descriptions returned in a DESCRIBE response (see Session descriptions returned in a DESCRIBE response (see
Section 11.2) and interleaving of RTP with RTSP over TCP are Section 13.2) and interleaving of RTP with RTSP over TCP are
exceptions to this rule (see Section 12). exceptions to this rule (see Section 14).
* RTSP is defined to use ISO 10646 (UTF-8) rather than ISO * RTSP is defined to use ISO 10646 (UTF-8) rather than ISO
8859-1, consistent with HTML internationalization efforts 8859-1, consistent with HTML internationalization efforts
[RFC2070]. [RFC2070].
* The Request-URI always contains the absolute URI. Because of * The Request-URI always contains the absolute URI. Because of
backward compatibility with a historical blunder, HTTP/1.1 backward compatibility with a historical blunder, HTTP/1.1
[RFC2616] carries only the absolute path in the request and [RFC2616] carries only the absolute path in the request and
puts the host name in a separate header field. puts the host name in a separate header field.
This makes "virtual hosting" easier, where a single host with This makes "virtual hosting" easier, where a single host with
skipping to change at page 10, line 16 skipping to change at page 9, line 49
"invited" to join an existing conference to play back media "invited" to join an existing conference to play back media
into the presentation. This mode is useful, for example, in into the presentation. This mode is useful, for example, in
distributed teaching applications. Several parties in the distributed teaching applications. Several parties in the
conference may take turns "pushing the remote control buttons". conference may take turns "pushing the remote control buttons".
Note: This functionality will require RTSP external application Note: This functionality will require RTSP external application
level functionality. level functionality.
RTSP requests may be handled by proxies, tunnels and caches as in RTSP requests may be handled by proxies, tunnels and caches as in
HTTP/1.1 [RFC2616]. HTTP/1.1 [RFC2616].
1.2. RTSP Specificication Update
This memorandum specifies RTSP 2.0 which is an update of RTSP 1.0, a
proposed standard defined in [RFC2326]. The goal of this version is
to correct the many flaws that have been identified in RTSP 1.0 since
its publication. The corrections are such that backwards
compatibility was impossible. Thus a new version was deemed the most
appropriate solution to get a more functional protocol. There are no
plans to revise RTSP 1.0. Appendix H catalogs the changes of this
version in relation to RTSP 1.0.
RTSP 2.0 has reduced functionality compared to RTSP 1.0 and aims at
specifying the RTSP core, functionality and rules for extensions, and
basic interaction with the media delivery protocol RTP [RFC3550].
Any other functionality would need to be published as extension
documents. This specification provides rules for such extensions and
defines registries to avoid naming collisions.
1.3. Notational Conventions 1.3. Notational Conventions
Since many of the definitions and syntax are identical to HTTP/1.1, Since many of the definitions and syntax are identical to HTTP/1.1,
this specification only points to the section where they are defined this specification only points to the section where they are defined
rather than copying it. For brevity, [HX.Y] is to be taken to refer rather than copying it. For brevity, [HX.Y] is to be taken to refer
to Section X.Y of the current HTTP/1.1 specification ([RFC2616]). to Section X.Y of the current HTTP/1.1 specification ([RFC2616]).
All the mechanisms specified in this document are described in both All the mechanisms specified in this document are described in both
prose and the Augmented Backus-Naur form (ABNF) described in detail prose and the Augmented Backus-Naur form (ABNF) described in detail
in [RFC4234]. in [RFC4234].
skipping to change at page 10, line 41 skipping to change at page 10, line 44
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The word, "unspecified" is used to indicate functionality or features The word, "unspecified" is used to indicate functionality or features
that are not defined in this specification. Such functionality that are not defined in this specification. Such functionality
cannot be used in a standardized manner without further definition in cannot be used in a standardized manner without further definition in
an extension specification to RTSP. an extension specification to RTSP.
1.3.1. RFC Editor Consideration
Please replace RFC XXXX with the RFC number this specification
recieves.
Please replace RFC YYYY with the RFC number that SAVPF
[I-D.ietf-avt-profile-savpf] receives.
1.4. Terminology 1.4. Terminology
Some of the terminology has been adopted from HTTP/1.1 [RFC2616]. Some of the terminology has been adopted from HTTP/1.1 [RFC2616].
Terms not listed here are defined as in HTTP/1.1. Terms not listed here are defined as in HTTP/1.1.
Aggregate control: The concept of controlling multiple streams using Aggregate control: The concept of controlling multiple streams using
a single timeline, generally maintained by the server. A client, a single timeline, generally maintained by the server. A client,
for example, uses aggregate control when it issues a single play for example, uses aggregate control when it issues a single play
or pause message to simultaneously control both the audio and or pause message to simultaneously control both the audio and
video in a movie. A session which is under aggregate control is video in a movie. A session which is under aggregate control is
referred to as an aggregated session. referred to as an aggregated session.
Aggregate control URI: The URI used in an RTSP request to refer to Aggregate control URI: The URI used in an RTSP request to refer to
and control an aggregated session. It normally, but not always, and control an aggregated session. It normally, but not always,
corresponds to the presentation URI specified in the session corresponds to the presentation URI specified in the session
description. See Section 11.3 for more information. description. See Section 13.3 for more information.
Conference: A multiparty, multimedia presentation, where "multi" Conference: A multiparty, multimedia presentation, where "multi"
implies greater than or equal to one. implies greater than or equal to one.
Client: The client requests media service from the media server. Client: The client requests media service from the media server.
Connection: A transport layer virtual circuit established between Connection: A transport layer virtual circuit established between
two programs for the purpose of communication. two programs for the purpose of communication.
Container file: A file which may contain multiple media streams Container file: A file which may contain multiple media streams
skipping to change at page 11, line 42 skipping to change at page 11, line 42
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
(playback), where the relationship is less strict. (playback), where the relationship is less strict.
Entity: The information transferred as the payload of a request or Entity: The information transferred as the payload of a request or
response. An entity consists of meta-information in the form of response. An entity consists of meta-information in the form of
entity-header fields and content in the form of an entity-body, as entity-header fields and content in the form of an entity-body, as
described in Section 8. described in Section 9.
Feature-tag: A tag representing a certain set of functionality, i.e. Feature-tag: A tag representing a certain set of functionality, i.e.
a feature. a feature.
IRI: Internationalized Resource Identifier, is the same as an URI, IRI: Internationalized Resource Identifier, is the same as an 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
skipping to change at page 12, line 35 skipping to change at page 12, line 35
Media server indirection: Redirection of a media client to a Media server indirection: Redirection of a media client to a
different media server. different media server.
(Media) stream: A single media instance, e.g., an audio stream or a (Media) stream: A single media instance, e.g., an audio stream or a
video stream as well as a single whiteboard or shared application video stream as well as a single whiteboard or shared application
group. When using RTP, a stream consists of all RTP and RTCP group. When using RTP, a stream consists of all RTP and RTCP
packets created by a source within an RTP session. packets created by a source within an RTP session.
Message: The basic unit of RTSP communication, consisting of a Message: The basic unit of RTSP communication, consisting of a
structured sequence of octets matching the syntax defined in structured sequence of octets matching the syntax defined in
Section 19 and transmitted over a connection or a connectionless Section 21 and transmitted over a connection or a connectionless
transport. transport.
Non-Aggregated Control: Control of a single media stream. This is Non-Aggregated Control: Control of a single media stream. This is
only possible in RTSP sessions with a single media. only possible in RTSP sessions with a single media.
Participant: Member of a conference. A participant may be a Participant: Member of a conference. A participant may be a
machine, e.g., a playback server. machine, e.g., a playback server.
Presentation: A set of one or more streams presented to the client Presentation: A set of one or more streams presented to the client
as a complete media feed and described by a presentation as a complete media feed and described by a presentation
skipping to change at page 14, line 10 skipping to change at page 15, line 5
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 an 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.
1.5. Protocol Properties 2. RTSP Introduction
2.1. Protocol Properties
RTSP has the following properties: RTSP has the following properties:
Extendable: New methods and parameters can be easily added to RTSP. Extendable: New methods and parameters can be easily added to RTSP.
Easy to parse: RTSP can be parsed by standard HTTP or MIME parsers. Easy to parse: RTSP can be parsed by standard HTTP or MIME parsers.
Secure: RTSP re-uses web security mechanisms, either at the Secure: RTSP re-uses web security mechanisms, either at the
transport level (TLS, [RFC4346]) or within the protocol itself. transport level (TLS, [RFC4346]) or within the protocol itself.
All HTTP authentication mechanisms such as basic ([RFC2616]) and All HTTP authentication mechanisms such as basic ([RFC2616]) and
skipping to change at page 15, line 34 skipping to change at page 16, line 30
HTTP since controlling continuous media requires server state in HTTP since controlling continuous media requires server state in
most cases. most cases.
Appropriate server control: If a client can start a stream, it needs Appropriate server control: If a client can start a stream, it needs
to be able to stop a stream. Servers should not start streaming to be able to stop a stream. Servers should not start streaming
to clients in such a way that clients cannot stop the stream. to clients in such a way that clients cannot stop the stream.
Transport negotiation: The client can negotiate the transport method Transport negotiation: The client can negotiate the transport method
prior to actually needing to process a continuous media stream. prior to actually needing to process a continuous media stream.
1.6. Extending RTSP 2.2. Extending RTSP
Since not all media servers have the same functionality, media Since not all media servers have the same functionality, media
servers by necessity will support different sets of requests. For servers by necessity will support different sets of requests. For
example: example:
o A server may not be capable of seeking (absolute positioning) if o A server may not be capable of seeking (absolute positioning) if
it is to support live events only. it is to support live events only.
o Some servers may not support setting stream parameters and thus o Some servers may not support setting stream parameters and thus
not support GET_PARAMETER and SET_PARAMETER. not support GET_PARAMETER and SET_PARAMETER.
skipping to change at page 16, line 13 skipping to change at page 17, line 10
be supported across all servers. be supported across all servers.
RTSP can be extended in three ways, listed here in order of the RTSP can be extended in three ways, listed here in order of the
magnitude of changes supported: magnitude of changes supported:
o Existing methods can be extended with new parameters, e.g. o Existing methods can be extended with new parameters, e.g.
headers, as long as these parameters can be safely ignored by the headers, as long as these parameters can be safely ignored by the
recipient. If the client needs negative acknowledgement when a recipient. If the client needs negative acknowledgement when a
method extension is not supported, a tag corresponding to the method extension is not supported, a tag corresponding to the
extension may be added in the field of the Require or Proxy- extension may be added in the field of the Require or Proxy-
Require headers (see Section 14.31). Require headers (see Section 16.32).
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 standard track document. an IETF standard track document.
The basic capability discovery mechanism can be used to both discover The basic capability discovery mechanism can be used to both discover
support for a certain feature and to ensure that a feature is support for a certain feature and to ensure that a feature is
available when performing a request. For detailed explanation of available when performing a request. For detailed explanation of
this see Section 10. this see Section 11.
1.7. Overall Operation 2.3. Overall Operation
Each presentation and media stream is identified by an RTSP URI. The Each presentation and media stream is identified by an RTSP URI. The
overall presentation and the properties of the media the presentation overall presentation and the properties of the media the presentation
is composed of are defined by a presentation description file, the is composed of are defined by a presentation description file, the
format of which is outside the scope of this specification. The format of which is outside the scope of this specification. The
presentation description file may be obtained by the client using presentation description file may be obtained by the client using
HTTP or other means such as email and may not necessarily be stored HTTP or other means such as email and may not necessarily be stored
on the media server. on the media server.
For the purposes of this specification, a presentation description is For the purposes of this specification, a presentation description is
skipping to change at page 17, line 31 skipping to change at page 18, line 28
Multicast, server chooses address: The media server picks the Multicast, server chooses address: The media server picks the
multicast address and port. This is the typical case for a live multicast address and port. This is the typical case for a live
or near-media-on-demand transmission. or near-media-on-demand transmission.
Multicast, client chooses address: If the server is to participate Multicast, client chooses address: If the server is to participate
in an existing multicast conference, the multicast address, port in an existing multicast conference, the multicast address, port
and encryption key are given by the conference description, and encryption key are given by the conference description,
established by means outside the scope of this specification, for established by means outside the scope of this specification, for
example by a SIP created conference. example by a SIP created conference.
1.8. RTSP States 2.4. RTSP States
RTSP controls a stream which may be sent via a separate protocol, RTSP controls a stream which may be sent via a separate protocol,
independent of the control channel. For example, RTSP control may be independent of the control channel. For example, RTSP control may be
transported on a TCP connection while the media data is conveyed via transported on a TCP connection while the media data is conveyed via
UDP. Thus, data delivery continues even if no RTSP requests are UDP. Thus, data delivery continues even if no RTSP requests are
received by the media server. Also, during its lifetime a single received by the media server. Also, during its lifetime a single
media stream may be controlled by RTSP requests issued sequentially media stream may be controlled by RTSP requests issued sequentially
on different TCP connections. Therefore, the server needs to on different TCP connections. Therefore, the server needs to
maintain "session state" to be able to correlate RTSP requests with a maintain "session state" to be able to correlate RTSP requests with a
stream. The state transitions are described in Appendix A. stream. The state transitions are described in Appendix A.
skipping to change at page 18, line 16 skipping to change at page 19, line 14
PAUSE: Temporarily halts a stream without freeing server resources. PAUSE: Temporarily halts a stream without freeing server resources.
REDIRECT: Indicates that the session should be moved to a new server REDIRECT: Indicates that the session should be moved to a new server
or location or location
TEARDOWN: Frees resources associated with the stream. The RTSP TEARDOWN: Frees resources associated with the stream. The RTSP
session ceases to exist on the server. session ceases to exist on the server.
RTSP methods that contribute to state use the Session header field RTSP methods that contribute to state use the Session header field
(Section 14.43) to identify the RTSP session whose state is being (Section 16.44) to identify the RTSP session whose state is being
manipulated. The server generates session identifiers in response to manipulated. The server generates session identifiers in response to
SETUP requests (Section 11.3). SETUP requests (Section 13.3).
1.9. Relationship with Other Protocols 2.5. Relationship with Other Protocols
RTSP has some overlap in functionality with HTTP. It also may RTSP has some overlap in functionality with HTTP. It also may
interact with HTTP in that the initial contact with streaming content interact with HTTP in that the initial contact with streaming content
will often be made through a web page. The current protocol will often be made through a web page. The current protocol
specification aims to allow different hand-off points between a web specification aims to allow different hand-off points between a web
server and the media server implementing RTSP. For example, the server and the media server implementing RTSP. For example, the
presentation description can be retrieved using HTTP or RTSP, which presentation description can be retrieved using HTTP or RTSP, which
reduces round trips in web-browser-based scenarios, yet also allows reduces round trips in web-browser-based scenarios, yet also allows
for stand alone RTSP servers and clients which do not rely on HTTP at for stand alone RTSP servers and clients which do not rely on HTTP at
all. However, RTSP differs fundamentally from HTTP in that most data all. However, RTSP differs fundamentally from HTTP in that most data
skipping to change at page 19, line 5 skipping to change at page 20, line 5
authentication is valuable. authentication is valuable.
RTSP assumes the existence of a presentation description format that RTSP assumes the existence of a presentation description format that
can express both static and temporal properties of a presentation can express both static and temporal properties of a presentation
containing several media streams. Session Description Protocol (SDP) containing several media streams. Session Description Protocol (SDP)
[RFC4566] is generally the format of choice; however, RTSP is not [RFC4566] is generally the format of choice; however, RTSP is not
bound to it. For data delivery, most real-time media will use RTP as bound to it. For data delivery, most real-time media will use RTP as
a transport protocol. While RTSP works well with RTP, it is not tied a transport protocol. While RTSP works well with RTP, it is not tied
to RTP. to RTP.
2. RTSP Use Cases 3. RTSP Use Cases
This section describes the most important and considered use cases This section describes the most important and considered use cases
for RTSP. They are listed in descending order of importance in for RTSP. They are listed in descending order of importance in
regards to ensuring that all necessary functionality is present. regards to ensuring that all necessary functionality is present.
This specification only fully supports usage of the two first. Also This specification only fully supports usage of the two first. Also
in these first two cases, there are special cases or exceptions that in these first two cases, there are special cases or exceptions that
are not supported without extensions, e.g. the redirection of media are not supported without extensions, e.g. the redirection of media
to another address than the controlling entity. to another address than the controlling entity.
2.1. On-demand Playback of Stored Content 3.1. On-demand Playback of Stored Content
An RTSP capable server stores content suitable for being streamed to An RTSP capable server stores content suitable for being streamed to
a client. A client desiring playback of any of the stored content a client. A client desiring playback of any of the stored content
uses RTSP to set up the media transport required to deliver the uses RTSP to set up the media transport required to deliver the
desired content. RTSP is then used to initiate, halt and manipulate desired content. RTSP is then used to initiate, halt and manipulate
the actual transmission (playout) of the content. RTSP is also the actual transmission (playout) of the content. RTSP is also
required to provide necessary description and synchronization required to provide necessary description and synchronization
information for the content. information for the content.
The above high level description can be broken down into a number of The above high level description can be broken down into a number of
skipping to change at page 20, line 35 skipping to change at page 21, line 35
Unicast Transport: Content for each individual client is transmitted Unicast Transport: Content for each individual client is transmitted
to them using unicast traffic. to them using unicast traffic.
It is also possible to redirect the media traffic to a different It is also possible to redirect the media traffic to a different
destination than that of the entity controlling the traffic. destination than that of the entity controlling the traffic.
However, allowing this without appropriate mechanisms for checking However, allowing this without appropriate mechanisms for checking
that the destination approves of this allows for distributed denial that the destination approves of this allows for distributed denial
of service attacks (DDoS). of service attacks (DDoS).
2.2. Unicast distribution of Live Content 3.2. Unicast distribution of Live Content
This use cases is similar to the above on-demand content case (see This use cases is similar to the above on-demand content case (see
Section 2.1) the difference is the nature of the content itself. Section 3.1) the difference is the nature of the content itself.
Live content is continuously distributed as it becomes available from Live content is continuously distributed as it becomes available from
a source; i.e., the main difference from on-demand is that one starts a source; i.e., the main difference from on-demand is that one starts
distributing content before the end of it has become available to the distributing content before the end of it has become available to the
server. server.
In many cases the consumer of live content is only interested in In many cases the consumer of live content is only interested in
consuming what is actually happens "now"; i.e., very similar to consuming what is actually happens "now"; i.e., very similar to
broadcast TV. However in this case it is assumed that there exist no broadcast TV. However in this case it is assumed that there exist no
broadcast or multicast channel to the users, and instead the server broadcast or multicast channel to the users, and instead the server
functions as a distribution node, sending the same content to functions as a distribution node, sending the same content to
skipping to change at page 21, line 12 skipping to change at page 22, line 12
This unicast traffic and the transport parameters are individually This unicast traffic and the transport parameters are individually
negotiated for each receiving client. negotiated for each receiving client.
Another aspect of live content is that it often has a very limited Another aspect of live content is that it often has a very limited
time of availability, as it is only is available for the duration of time of availability, as it is only is available for the duration of
the event the content covers. An example of such a live content the event the content covers. An example of such a live content
could be a music concert which lasts 2 hour and starts at a could be a music concert which lasts 2 hour and starts at a
predetermined time. Thus there is need to announce when and for how predetermined time. Thus there is need to announce when and for how
long the live content is available. long the live content is available.
2.3. On-demand Playback using Multicast In some cases, the server providing live content may be saving some
or all of the content to allow clients to pause the stream and resume
it from the paused point, or to "rewind" and play continuously from a
point earlier than the live point. Hence, this use case does not
necessarily exclude playing from other than the live point of the
stream, playing with scales other than 1.0, etc.
3.3. On-demand Playback using Multicast
It is possible to use RTSP to request that media be delivered to a It is possible to use RTSP to request that media be delivered to a
multicast group. The entity setting up the session (the controller) multicast group. The entity setting up the session (the controller)
will then control when and what media is delivered to the group. will then control when and what media is delivered to the group.
This use case has some potential for denial of service attacks by This use case has some potential for denial of service attacks by
flooding a multicast group. Therefore, a mechanism is needed to flooding a multicast group. Therefore, a mechanism is needed to
indicate that the group actually accepts the traffic from the RTSP indicate that the group actually accepts the traffic from the RTSP
server. server.
An open issue in this use case is how one ensures that all receivers An open issue in this use case is how one ensures that all receivers
listening to the multicast or broadcast receives the session listening to the multicast or broadcast receives the session
presentation configuring the receivers. presentation configuring the receivers.
2.4. Inviting an RTSP server into a conference 3.4. Inviting an RTSP server into a conference
If one has an established conference or group session, it is possible If one has an established conference or group session, it is possible
to have an RTSP server distribute media to the whole group. to have an RTSP server distribute media to the whole group.
Transmission to the group is simplest when controlled by a single Transmission to the group is simplest when controlled by a single
participant or leader of the conference. Shared control might be participant or leader of the conference. Shared control might be
possible, but would require further investigation and possibly possible, but would require further investigation and possibly
extensions. extensions.
This use case assumes that there exists either multicast or a This use case assumes that there exists either multicast or a
conference focus that redistribute media to all participants. conference focus that redistribute media to all participants.
skipping to change at page 22, line 27 skipping to change at page 23, line 31
Passing control of the session: If it is desired to pass control of Passing control of the session: If it is desired to pass control of
the RTSP session between the participants, some support will be the RTSP session between the participants, some support will be
required by an external protocol to exchange state information required by an external protocol to exchange state information
and possibly floor control of who is controlling the RTSP and possibly floor control of who is controlling the RTSP
session. session.
If there interest in this use case, further work is required on the If there interest in this use case, further work is required on the
necessary extensions. necessary extensions.
2.5. Live Content using Multicast 3.5. Live Content using Multicast
This use case in its simplest form does not require any use of RTSP This use case in its simplest form does not require any use of RTSP
at all; this is what multicast conferences being announced with SAP at all; this is what multicast conferences being announced with SAP
and SDP are intended to handle. However in use cases where more and SDP are intended to handle. However in use cases where more
advanced features like access control to the multicast session are advanced features like access control to the multicast session are
desired, RTSP could be used for session establishment. desired, RTSP could be used for session establishment.
A client desiring to join a live multicasted media session with A client desiring to join a live multicasted media session with
cryptographic (encryption) access control could use RTSP in the cryptographic (encryption) access control could use RTSP in the
following way. The source of the session announces the session and following way. The source of the session announces the session and
skipping to change at page 22, line 52 skipping to change at page 24, line 8
example, for billing or access control. An RTSP link also allows for example, for billing or access control. An RTSP link also allows for
load balancing between multiple servers. load balancing between multiple servers.
If these were the only goals, they could be achieved by simply using If these were the only goals, they could be achieved by simply using
HTTP. However, for cases where the sender likes to keep track of HTTP. However, for cases where the sender likes to keep track of
each individual receiver of a session, and possibly use the session each individual receiver of a session, and possibly use the session
as a side channel for distributing key-updates or other information as a side channel for distributing key-updates or other information
on a per-receiver basis, and the full set of receivers is not know on a per-receiver basis, and the full set of receivers is not know
prior to the session start, the state establishment that RTSP prior to the session start, the state establishment that RTSP
provides can be beneficial. In this case a client would establish an provides can be beneficial. In this case a client would establish an
RTSP session to the multicast group. The RTSP server will not RTSP session for this multicast group with the RTSP server. The RTSP
transmit any media, but instead will point to the multicast group. server will not transmit any media, but instead will point to the
The client and server will be able to keep the session alive for as multicast group. The client and server will be able to keep the
long as the receiver participates in the session thus enabling, for session alive for as long as the receiver participates in the session
example, the server to push updates to the client. thus enabling, for example, the server to push updates to the client.
This use case will most likely not be able to be implemented without This use case will most likely not be able to be implemented without
some extensions to the server-to-client push mechanism. Here a some extensions to the server-to-client push mechanism. Here a
method like ANNOUNCE (see [RFC2326]) might be suitable; however, it method like ANNOUNCE (see [RFC2326]) might be suitable; however, it
will require a RTSP extension to revive the method. will require a RTSP extension to revive the method.
3. Protocol Parameters 4. Protocol Parameters
3.1. RTSP Version 4.1. RTSP Version
HTTP specification section [H3.1] applies, with "HTTP" replaced by HTTP specification section [H3.1] applies, with "HTTP" replaced by
"RTSP". This specification defines version 2.0 of RTSP. "RTSP". This specification defines version 2.0 of RTSP.
3.2. RTSP IRI and URI 4.2. RTSP IRI and URI
RTSP 2.0 defines and registers three URI schemas "rtsp", "rtsps" and RTSP 2.0 defines and registers three URI schemas "rtsp", "rtsps" and
"rtspu". The usage of the last, "rtspu", is unspecified in RTSP 2.0, "rtspu". The usage of the last, "rtspu", is unspecified in RTSP 2.0,
and is defined here to register and reserve the URI scheme that is and is defined here to register and reserve the URI scheme that is
defined in RTSP 1.0. The "rtspu" scheme indicates transport of the defined in RTSP 1.0. The "rtspu" scheme indicates undefined
RTSP messages over unreliable transport (UDP). The syntax of "rtsp" transport of the RTSP messages over unreliable transport (UDP). The
and "rtsps" URIs has been changed from RTSP 1.0. syntax of "rtsp" and "rtsps" URIs has been changed from RTSP 1.0.
This specification also defines the format of the RTSP IRI [RFC3987] This specification also defines the format of the RTSP IRI [RFC3987]
that can be used as RTSP resource identifiers and locators, in web that can be used as RTSP resource identifiers and locators, in web
pages, user interfaces, on paper, etc. However, the RTSP request pages, user interfaces, on paper, etc. However, the RTSP request
message format only allows usage of the absolute URI format. The message format only allows usage of the absolute URI format. The
RTSP IRI format SHALL use the rules and transformation for IRIs RTSP IRI format SHALL use the rules and transformation for IRIs
defined in [RFC3987]. This way RTSP 2.0 URIs for request can be defined in [RFC3987]. This way RTSP 2.0 URIs for request can be
produced from an RTSP IRI. produced from an RTSP IRI.
The RTSP IRI and URI are both syntax restricted compared to the The RTSP IRI and URI are both syntax restricted compared to the
skipping to change at page 25, line 8 skipping to change at page 26, line 8
request relates to; i.e., the media type indicated in Content-Type request relates to; i.e., the media type indicated in Content-Type
header in the response to DESCRIBE. header in the response to DESCRIBE.
The syntax of any URI query string is unspecified and responder The syntax of any URI query string is unspecified and responder
(usually the server) specific. The query is, from the requestor's (usually the server) specific. The query is, from the requestor's
perspective, an opaque string and needs to be handled as such. perspective, an opaque string and needs to be handled as such.
The URI scheme "rtsp" requires that commands are issued via a The URI scheme "rtsp" requires that commands are issued via a
reliable protocol (within the Internet, TCP), while the scheme reliable protocol (within the Internet, TCP), while the scheme
"rtsps" identifies a reliable transport using secure transport (TLS "rtsps" identifies a reliable transport using secure transport (TLS
[RFC4346], see Section (Section 18). [RFC4346], see (Section 20).
For the scheme "rtsp", if no port number is provided in the authority For the scheme "rtsp", if no port number is provided in the authority
part of the URI port number 554 SHALL be used. For the scheme part of the URI port number 554 SHALL be used. For the scheme
"rtsps", the TCP port 322 is registered and SHALL be assumed. "rtsps", the TCP port 322 is registered and SHALL be assumed.
A presentation or a stream is identified by a textual media A presentation or a stream is identified by a textual media
identifier, using the character set and escape conventions of URIs identifier, using the character set and escape conventions of URIs
(RFC 3986 [RFC3986]). URIs may refer to a stream or an aggregate of (RFC 3986 [RFC3986]). URIs may refer to a stream or an aggregate of
streams; i.e., a presentation. Accordingly, requests described in streams; i.e., a presentation. Accordingly, requests described in
Section (Section 11) can apply to either the whole presentation or an (Section 13) can apply to either the whole presentation or an
individual stream within the presentation. Note that some request individual stream within the presentation. Note that some request
methods can only be applied to streams, not presentations, and vice methods can only be applied to streams, not presentations, and vice
versa. versa.
For example, the RTSP URI: For example, the RTSP URI:
rtsp://media.example.com:554/twister/audiotrack rtsp://media.example.com:554/twister/audiotrack
may identify the audio stream within the presentation "twister", may identify the audio stream within the presentation "twister",
which can be controlled via RTSP requests issued over a TCP which can be controlled via RTSP requests issued over a TCP
skipping to change at page 26, line 5 skipping to change at page 27, line 5
streams. A presentation description may name a stream "a.mov" and streams. A presentation description may name a stream "a.mov" and
the whole presentation "b.mov". the whole presentation "b.mov".
The path components of the RTSP URI are opaque to the client and do The path components of the RTSP URI are opaque to the client and do
not imply any particular file system structure for the server. not imply any particular file system structure for the server.
This decoupling also allows presentation descriptions to be used This decoupling also allows presentation descriptions to be used
with non-RTSP media control protocols simply by replacing the with non-RTSP media control protocols simply by replacing the
scheme in the URI. scheme in the URI.
3.3. Session Identifiers 4.3. Session Identifiers
Session identifiers are strings of any arbitrary length. A session Session identifiers are strings of any arbitrary length. A session
identifier MUST be chosen randomly and MUST be at least eight identifier MUST be chosen cryptographically random (See [RFC4086] )
characters long to make guessing it more difficult. (See and MUST be at least eight characters (can contain a maximum of 48
Section 20.) bits of entropy) long to make guessing it more difficult. It is
RECOMMENDED that it contains 128 bits of entropy, i.e. approxamitely
22 characters from a high quality generator. (See Section 22.)
However, it needs to be noted that the session identifier does not
provide any security against session hijacking unless it is kept
confidential between client, server and trusted proxies.
3.4. SMPTE Relative Timestamps 4.4. SMPTE Relative Timestamps
A SMPTE relative timestamp expresses time relative to the start of A SMPTE relative timestamp expresses time relative to the start of
the clip. Relative timestamps are expressed as SMPTE time codes for the clip. Relative timestamps are expressed as SMPTE time codes for
frame-level access accuracy. The time code has the format frame-level access accuracy. The time code has the format
hours:minutes:seconds:frames.subframes, hours:minutes:seconds:frames.subframes,
with the origin at the start of the clip. The default smpte format with the origin at the start of the clip. The default smpte format
is "SMPTE 30 drop" format, with frame rate is 29.97 frames per is "SMPTE 30 drop" format, with frame rate is 29.97 frames per
second. Other SMPTE codes MAY be supported (such as "SMPTE 25") second. Other SMPTE codes MAY be supported (such as "SMPTE 25")
skipping to change at page 26, line 38 skipping to change at page 27, line 43
values are zero, they may be omitted. Subframes are measured in one- values are zero, they may be omitted. Subframes are measured in one-
hundredth of a frame. hundredth of a frame.
Examples: Examples:
smpte=10:12:33:20- smpte=10:12:33:20-
smpte=10:07:33- smpte=10:07:33-
smpte=10:07:00-10:07:33:05.01 smpte=10:07:00-10:07:33:05.01
smpte-25=10:07:00-10:07:33:05.01 smpte-25=10:07:00-10:07:33:05.01
3.5. Normal Play Time 4.5. Normal Play Time
Normal play time (NPT) indicates the stream absolute position Normal play time (NPT) indicates the stream absolute position
relative to the beginning of the presentation, not to be confused relative to the beginning of the presentation, not to be confused
with the Network Time Protocol (NTP) [RFC1305]. The timestamp with the Network Time Protocol (NTP) [RFC1305]. The timestamp
consists of a decimal fraction. The part left of the decimal may be consists of a decimal fraction. The part left of the decimal may be
expressed in either seconds or hours, minutes, and seconds. The part expressed in either seconds or hours, minutes, and seconds. The part
right of the decimal point measures fractions of a second. right of the decimal point measures 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. The special constant "now" is defined as the values are not defined. The special constant "now" is defined as the
skipping to change at page 27, line 24 skipping to change at page 28, line 29
npt=12:05:35.3- npt=12:05:35.3-
npt=now- npt=now-
The syntax conforms to ISO 8601 [ISO.8601.2000]. The npt-sec The syntax conforms to ISO 8601 [ISO.8601.2000]. The npt-sec
notation is optimized for automatic generation, the npt-hhmmss notation is optimized for automatic generation, the npt-hhmmss
notation for consumption by human readers. The "now" constant notation for consumption by human readers. The "now" constant
allows clients to request to receive the live feed rather than the allows clients to request to receive the live feed rather than the
stored or time-delayed version. This is needed since neither stored or time-delayed version. This is needed since neither
absolute time nor zero time are appropriate for this case. absolute time nor zero time are appropriate for this case.
3.6. Absolute Time 4.6. Absolute Time
Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps, Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps,
using UTC (GMT). Fractions of a second may be indicated. using UTC (GMT). Fractions of a second may be indicated.
Example for November 8, 1996 at 14h37 and 20 and a quarter seconds Example for November 8, 1996 at 14h37 and 20 and a quarter seconds
UTC: UTC:
19961108T143720.25Z 19961108T143720.25Z
3.7. Feature-tags 4.7. Feature-tags
Feature-tags are unique identifiers used to designate features in Feature-tags are unique identifiers used to designate features in
RTSP. These tags are used in Require ( (Section 14.37)), Proxy- RTSP. These tags are used in Require ( (Section 16.38)), Proxy-
Require (Section 14.31), Proxy-Supported ( (Section 14.32)), Require (Section 16.32), Proxy-Supported ( (Section 16.33)),
Unsupported ( (Section 14.46)), and header fields. Unsupported ( (Section 16.47)), and header fields.
A feature-tag definition MUST indicate which combination of clients, A feature-tag definition MUST indicate which combination of clients,
servers or proxies they applies too. servers or proxies they applies to.
The creator of a new RTSP feature-tag should either prefix the The creator of a new RTSP feature-tag should either prefix the
feature-tag with a reverse domain name (e.g., feature-tag with a reverse domain name (e.g.,
"com.example.mynewfeature" is an apt name for a feature whose "com.example.mynewfeature" is an apt name for a feature whose
inventor can be reached at "example.com"), or register the new inventor can be reached at "example.com"), or register the new
feature-tag with the Internet Assigned Numbers Authority (IANA) (see feature-tag with the Internet Assigned Numbers Authority (IANA) (see
IANA Section 21). IANA Section 23).
The usage of feature-tags is further described in Section 10 that The usage of feature-tags is further described in Section 11 that
deals with capability handling. deals with capability handling.
3.8. Entity Tags 4.8. Entity Tags
Entity tags are opaque strings that are used to compare two entities Entity tags are opaque strings that are used to compare two entities
from the same resource, for example in caches or to optimize setup from the same resource, for example in caches or to optimize setup
after a redirect. Further explanation is present in [H3.11]. For an after a redirect. Further explanation is present in [H3.11]. For an
explanation of how to compare entity tags see [H13.3]. Entity tags explanation of how to compare entity tags see [H13.3]. Entity tags
can be carried in the ETag header (see Section 14.21) or in SDP (see can be carried in the ETag header (see Section 16.21) or in SDP (see
Appendix C.1.9). Appendix C.1.9).
Entity tags are used in RTSP to make some methods conditional. The Entity tags are used in RTSP to make some methods conditional. The
methods are made conditional through the inclusion of headers, see methods are made conditional through the inclusion of headers, see
Section 14.24 and Section 14.26. Note that RTSP entity tags apply to Section 16.24 and Section 16.26. Note that RTSP entity tags apply to
the complete presentation; i.e., both the session description and the the complete presentation; i.e., both the session description and the
individual media streams. Thus entity tags can be used to verify at individual media streams. Thus entity tags can be used to verify at
setup time after a redirect that the same session description applies setup time after a redirect that the same session description applies
to the media at the new location using the If-Match header. to the media at the new location using the If-Match header.
4. RTSP Message 5. RTSP Message
RTSP is a text-based protocol and uses the ISO 10646 character set in RTSP is a text-based protocol and uses the ISO 10646 character set in
UTF-8 encoding (RFC 3629 [RFC3629]). Lines SHALL be terminated by UTF-8 encoding (RFC 3629 [RFC3629]). Lines SHALL be terminated by
CRLF. CRLF.
Text-based protocols make it easier to add optional parameters in Text-based protocols make it easier to add optional parameters in
a self-describing manner. Since the number of parameters and the a self-describing manner. Since the number of parameters and the
frequency of commands is low, processing efficiency is not a frequency of commands is low, processing efficiency is not a
concern. Text-based protocols, if done carefully, also allow easy concern. Text-based protocols, if done carefully, also allow easy
implementation of research prototypes in scripting languages such implementation of research prototypes in scripting languages such
skipping to change at page 29, line 30 skipping to change at page 30, line 30
used. This is also the encoding used for RTCP [RFC3550]. ISO 8859-1 used. This is also the encoding used for RTCP [RFC3550]. ISO 8859-1
translates directly into Unicode with a high-order octet of zero. translates directly into Unicode with a high-order octet of zero.
ISO 8859-1 characters with the most-significant bit set are ISO 8859-1 characters with the most-significant bit set are
represented as 1100001x 10xxxxxx. (See RFC 3629 [RFC3629]) represented as 1100001x 10xxxxxx. (See RFC 3629 [RFC3629])
Requests contain methods, the object the method is operating upon and Requests contain methods, the object the method is operating upon and
parameters to further describe the method. Methods are idempotent parameters to further describe the method. Methods are idempotent
unless otherwise noted. Methods are also designed to require little unless otherwise noted. Methods are also designed to require little
or no state maintenance at the media server. or no state maintenance at the media server.
4.1. Message Types 5.1. Message Types
See [H4.1]. See [H4.1].
4.2. Message Headers 5.2. Message Headers
See [H4.2]. See [H4.2].
4.3. Message Body 5.3. Message Body
See [H4.3]. See [H4.3].
Unlike HTTP, the presence of a message-body in either a request or a Unlike HTTP, the presence of a message-body in either a request or a
response MUST be signaled by the inclusion of a Content-Length header response MUST be signaled by the inclusion of a Content-Length header
field (see Section 14.16). field (see Section 16.16).
4.4. Message Length 5.4. Message Length
When a message body is included with a message, the length of that When a message body is included with a message, the length of that
body is determined by one of the following (in order of precedence): body is determined by one of the following (in order of precedence):
1. Any response message which MUST NOT include a message body (such 1. Any response message which MUST NOT include a message body (such
as the 1xx, 204, and 304 responses) is always terminated by the as the 1xx, 204, and 304 responses) is always terminated by the
first empty line after the header fields, regardless of the first empty line after the header fields, regardless of the
entity-header fields present in the message. (Note: An empty entity-header fields present in the message. (Note: An empty
line is a line with nothing preceding the CRLF.) line is a line with nothing preceding the CRLF.)
2. If a Content-Length header field (Section 14.16) is present, its 2. If a Content-Length header field (Section 16.16) is present, its
value in bytes represents the length of the message-body. If value in bytes represents the length of the message-body. If
this header field is not present, a value of zero is assumed. this header field is not present, a value of zero is assumed.
Unlike an HTTP message, an RTSP message MUST contain a Content-Length Unlike an HTTP message, an RTSP message MUST contain a Content-Length
header field whenever it contains a message body. Note that RTSP header field whenever it contains a message body. Note that RTSP
does not support the HTTP/1.1 "chunked" transfer coding (see does not support the HTTP/1.1 "chunked" transfer coding (see
[H3.6.1]). [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.
5. General Header Fields 6. General Header Fields
See [H4.5], except that the Pragma, Trailer, Transfer-Encoding, See [H4.5], except that the Pragma, Trailer, Transfer-Encoding,
Upgrade, and Warning headers are not defined. RTSP further defines Upgrade, and Warning headers are not defined. RTSP further defines
the CSeq, Proxy-Supported and Timestamp headers. The general headers the CSeq, Pipelined-Requests, Proxy-Supported and Timestamp headers.
are listed in Table 1: The general headers are listed in Table 1:
+-----------------+--------------------+ +--------------------+--------------------+
| Header Name | Defined in Section | | Header Name | Defined in Section |
+-----------------+--------------------+ +--------------------+--------------------+
| Cache-Control | Section 14.10 | | Cache-Control | Section 16.10 |
| | | | | |
| Connection | Section 14.11 | | Connection | Section 16.11 |
| | | | | |
| CSeq | Section 14.19 | | CSeq | Section 16.19 |
| | | | | |
| Date | Section 14.20 | | Date | Section 16.20 |
| | | | | |
| Proxy-Supported | Section 14.32 | | Pipelined-Requests | Section 16.29 |
| | | | | |
| Supported | Section 14.43 | | Proxy-Supported | Section 16.33 |
| | | | | |
| Timestamp | Section 14.44 | | Supported | Section 16.44 |
| | | | | |
| Via | Section 14.49 | | Timestamp | Section 16.45 |
+-----------------+--------------------+ | | |
| Via | Section 16.50 |
+--------------------+--------------------+
Table 1: The general headers used in RTSP Table 1: The general headers used in RTSP
6. Request 7. Request
A request message uses the format outlined below regardless of the A request message uses the format outlined below regardless of the
direction of a request, client to server or server to client: direction of a request, client to server or server to client:
o Request line, containing the method to be applied to the resource, o Request line, containing the method to be applied to the resource,
the identifier of the resource, and the protocol version in use; the identifier of the resource, and the protocol version in use;
o Zero or more Header lines, that can be of the following types: o Zero or more Header lines, that can be of the following types:
general (Section 5), request (Section 6.2), or entity general (Section 6), request (Section 7.2), or entity
(Section 8.1); (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 (entity), consisting of one or more o Optionally a message body (entity), consisting of one or more
lines. The length of the message body in bytes is indicated by lines. The length of the message body in bytes is indicated by
the Content-Length entity header. the Content-Length entity header.
6.1. Request Line 7.1. Request Line
The request line provides the key information about the request: what The request line provides the key information about the request: what
method, on what resources and using which RTSP version. The methods method, on what resources and using which RTSP version. The methods
that are defined by this specification are listed in Table 2. that are defined by this specification are listed in Table 2.
+---------------+--------------------+ +---------------+--------------------+
| Method | Defined in Section | | Method | Defined in Section |
+---------------+--------------------+ +---------------+--------------------+
| DESCRIBE | Section 11.2 | | DESCRIBE | Section 13.2 |
| | | | | |
| GET_PARAMETER | Section 11.7 | | GET_PARAMETER | Section 13.7 |
| | | | | |
| OPTIONS | Section 11.1 | | OPTIONS | Section 13.1 |
| | | | | |
| PAUSE | Section 11.5 | | PAUSE | Section 13.5 |
| | | | | |
| PLAY | Section 11.4 | | PLAY | Section 13.4 |
| | | | | |
| REDIRECT | Section 11.9 | | REDIRECT | Section 13.9 |
| | | | | |
| SETUP | Section 11.3 | | SETUP | Section 13.3 |
| | | | | |
| SET_PARAMETER | Section 11.8 | | SET_PARAMETER | Section 13.8 |
| | | | | |
| TEARDOWN | Section 11.6 | | TEARDOWN | Section 13.6 |
+---------------+--------------------+ +---------------+--------------------+
Table 2: The RTSP Methods Table 2: The RTSP Methods
The syntax of the RTSP request line is the following: The syntax of the RTSP request line is the following:
<Method> <Request-URI> <RTSP-Version> CRLF <Method> <Request-URI> <RTSP-Version> CRLF
Note: This syntax cannot be freely changed in future versions of Note: This syntax cannot be freely changed in future versions of
RTSP. This line needs to remain parsable by older RTSP RTSP. This line needs to remain parsable by older RTSP
implementations since it indicates the RTSP version of the message. implementations since it indicates the RTSP version of the message.
In contrast to HTTP/1.1 [RFC2616], RTSP requests identify the In contrast to HTTP/1.1 [RFC2616], RTSP requests identify the
resource through an absolute RTSP URI (scheme, host, and port) (see resource through an absolute RTSP URI (scheme, host, and port) (see
Section 3.2) rather than just the absolute path. 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
skipping to change at page 34, line 17 skipping to change at page 35, line 17
An OPTIONS in this form will determine the capabilities of the server An OPTIONS in this form will determine the capabilities of the server
or the proxy that first receives the request. If the capability of or the proxy that first receives the request. If the capability of
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
6.2. Request Header Fields 7.2. Request Header Fields
The RTSP headers in Table Table 3 can be included in a request, as The RTSP headers in Table 3 can be included in a request, as request
request headers, to modify the specifics of the request. Some of headers, to modify the specifics of the request. Some of these
these headers may also be used in the response to a request, as headers may also be used in the response to a request, as response
response headers, to modify the specifics of a response headers, to modify the specifics of a response (Section 8.2).
(Section 7.2).
+--------------------+--------------------+ +--------------------+--------------------+
| Header | Defined in Section | | Header | Defined in Section |
+--------------------+--------------------+ +--------------------+--------------------+
| Accept | Section 14.1 | | Accept | Section 16.1 |
| | | | | |
| Accept-Credentials | Section 14.2 | | Accept-Credentials | Section 16.2 |
| | | | | |
| Accept-Encoding | Section 14.3 | | Accept-Encoding | Section 16.3 |
| | | | | |
| Accept-Language | Section 14.4 | | Accept-Language | Section 16.4 |
| | | | | |
| Authorization | Section 14.7 | | Authorization | Section 16.7 |
| | | | | |
| Bandwidth | Section 14.8 | | Bandwidth | Section 16.8 |
| | | | | |
| Blocksize | Section 14.9 | | Blocksize | Section 16.9 |
| | | | | |
| From | Section 14.23 | | From | Section 16.23 |
| | | | | |
| If-Match | Section 14.24 | | If-Match | Section 16.24 |
| | | | | |
| If-Modified-Since | Section 14.25 | | If-Modified-Since | Section 16.25 |
| | | | | |
| If-None-Match | Section 14.26 | | If-None-Match | Section 16.26 |
| | | | | |
| Proxy-Require | Section 14.31 | | Proxy-Require | Section 16.32 |
| | | | | |
| Range | Section 14.34 | | Range | Section 16.35 |
| Referer | Section 14.35 |
| | | | | |
| Require | Section 14.37 | | Referer | Section 16.36 |
| | | | | |
| Scale | Section 14.39 | | Require | Section 16.38 |
| | | | | |
| Session | Section 14.42 | | Scale | Section 16.40 |
| | | | | |
| Speed | Section 14.40 | | Session | Section 16.43 |
| | | | | |
| Supported | Section 14.43 | | Speed | Section 16.41 |
| | | | | |
| Transport | Section 14.45 | | Supported | Section 16.44 |
| | | | | |
| User-Agent | Section 14.47 | | Transport | Section 16.46 |
| | |
| User-Agent | Section 16.48 |
+--------------------+--------------------+ +--------------------+--------------------+
Table 3: The RTSP request headers Table 3: The RTSP request headers
Detailed headers definition are provided in Section 14. Detailed headers definition are provided in Section 16.
New request headers may be defined. If the receiver of the request New request headers may be defined. If the receiver of the request
is required to understand the request header, the request MUST is required to understand the request header, the request MUST
include a corresponding feature tag in a Require or Proxy-Require include a corresponding feature tag in a Require or Proxy-Require
header to ensure the correct processing of the header. header to ensure the correct processing of the header.
7. Response 8. Response
[H6] applies except that HTTP-Version is replaced by RTSP-Version. [H6] applies except that HTTP-Version is replaced by RTSP-Version.
Also, RTSP defines additional status codes and does not define some Also, RTSP defines additional status codes and does not define some
of the HTTP codes. The valid response codes and the methods they can of the HTTP codes. The valid response codes and the methods they can
be used with are listed in Table 4. be used with are listed in Table 4.
After receiving and interpreting a request message, the recipient After receiving and interpreting a request message, the recipient
responds with an RTSP response message. responds with an RTSP response message.
7.1. Status-Line 8.1. Status-Line
The first line of a Response message is the Status-Line, consisting The first line of a Response message is the Status-Line, consisting
of the protocol version followed by a numeric status code and the of the protocol version followed by a numeric status code and the
textual phrase associated with the status code, with each element textual phrase associated with the status code, with each element
separated by SP characters. No CR or LF is allowed except in the separated by SP characters. No CR or LF is allowed except in the
final CRLF sequence. final CRLF sequence.
<RTSP-Version> SP <Status-Code> SP <Reason-Phrase> CRLF <RTSP-Version> SP <Status-Code> SP <Reason-Phrase> CRLF
7.1.1. Status Code and Reason Phrase 8.1.1. Status Code and Reason Phrase
The Status-Code element is a 3-digit integer result code of the The Status-Code element is a 3-digit integer result code of the
attempt to understand and satisfy the request. These codes are fully attempt to understand and satisfy the request. These codes are fully
defined in Section 13. The Reason-Phrase is intended to give a short defined in Section 15. The Reason-Phrase is intended to give a short
textual description of the Status-Code. The Status-Code is intended textual description of the Status-Code. The Status-Code is intended
for use by automata and the Reason-Phrase is intended for the human for use by automata and the Reason-Phrase is intended for the human
user. The client is not required to examine or display the Reason- user. The client is not required to examine or display the Reason-
Phrase. Phrase.
The first digit of the Status-Code defines the class of response. The first digit of the Status-Code defines the class of response.
The last two digits do not have any categorization role. There are 5 The last two digits do not have any categorization role. There are 5
values for the first digit: values for the first digit:
1xx: Informational - Request received, continuing process 1xx: Informational - Request received, continuing process
skipping to change at page 37, line 29 skipping to change at page 38, line 29
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 the exception that an x00 status code of that class, with the exception that an
unrecognized response MUST NOT be cached. For example, if an unrecognized response MUST NOT be cached. For example, if an
unrecognized status code of 431 is received by the client, it can unrecognized status code of 431 is received by the client, it can
safely assume that there was something wrong with its request and safely assume that there was something wrong with its request and
treat the response as if it had received a 400 status code. In such treat the response as if it had received a 400 status code. In such
cases, user agents SHOULD present to the user the entity returned cases, user agents SHOULD present to the user the entity returned
with the response, since that entity is likely to include human- with the response, since that entity is likely to include human-
readable information which will explain the unusual status. readable information which will explain the unusual status.
+------+-------------------------------------+-----------------+ +------+----------------------------------------+-----------------+
| Code | Reason | Method | | Code | Reason | Method |
+------+-------------------------------------+-----------------+ +------+----------------------------------------+-----------------+
| 100 | Continue | all | | 100 | Continue | all |
| | | | | | | |
| | | | | | | |
| 200 | OK | all | | 200 | OK | all |
| | | | | | | |
| | | | | | | |
| 300 | Multiple Choices | all | | 300 | Multiple Choices | all |
| | | | | | | |
| 301 | Multiple Choices | all | | 301 | Multiple Choices | all |
| | | | | | | |
skipping to change at page 39, line 16 skipping to change at page 40, line 16
| 462 | Destination Unreachable | all | | 462 | Destination Unreachable | all |
| | | | | | | |
| 463 | Destination Prohibited | SETUP | | 463 | Destination Prohibited | SETUP |
| | | | | | | |
| 464 | Data Transport Not Ready Yet | PLAY | | 464 | Data Transport Not Ready Yet | PLAY |
| | | | | | | |
| 470 | Connection Authorization Required | all | | 470 | Connection Authorization Required | all |
| | | | | | | |
| 471 | Connection Credentials not accepted | all | | 471 | Connection Credentials not accepted | all |
| | | | | | | |
| 472 | Failure to establish secure connection | all |
| | | |
| | | | | | | |
| 500 | Internal Server Error | all | | 500 | Internal Server Error | all |
| | | | | | | |
| 501 | Not Implemented | all | | 501 | Not Implemented | all |
| | | | | | | |
| 502 | Bad Gateway | all | | 502 | Bad Gateway | all |
| | | | | | | |
| 503 | Service Unavailable | all | | 503 | Service Unavailable | all |
| | | | | | | |
| 504 | Gateway Timeout | all | | 504 | Gateway Timeout | all |
| | | | | | | |
| 505 | RTSP Version Not Supported | all | | 505 | RTSP Version Not Supported | all |
| | | | | | | |
| 551 | Option not support | all | | 551 | Option not support | all |
+------+-------------------------------------+-----------------+ +------+----------------------------------------+-----------------+
Table 4: Status codes and their usage with RTSP methods Table 4: Status codes and their usage with RTSP methods
7.2. Response Header Fields 8.2. Response Header Fields
The response-header fields allow the request recipient to pass The response-header fields allow the request recipient to pass
additional information about the response which cannot be placed in additional information about the response which cannot be placed in
the Status-Line. These header fields give information about the the Status-Line. These header fields give information about the
server and about further access to the resource identified by the server and about further access to the resource identified by the
Request-URI. All headers currently classified as response headers Request-URI. All headers currently classified as response headers
are listed in Table 5. are listed in Table 5.
+------------------------+--------------------+ +------------------------+--------------------+
| Header | Defined in Section | | Header | Defined in Section |
+------------------------+--------------------+ +------------------------+--------------------+
| Accept-Credentials | Section 14.2 | | Accept-Credentials | Section 16.2 |
| | | | | |
| Accept-Ranges | Section 14.5 | | Accept-Ranges | Section 16.5 |
| | | | | |
| Connection-Credentials | Section 14.12 | | Connection-Credentials | Section 16.12 |
| | | | | |
| ETag | Section 14.21 | | ETag | Section 16.21 |
| | | | | |
| Location | Section 14.28 | | Location | Section 16.28 |
| | | | | |
| Proxy-Authenticate | Section 14.29 | | Proxy-Authenticate | Section 16.30 |
| | | | | |
| Public | Section 14.33 | | Public | Section 16.34 |
| | | | | |
| Range | Section 14.34 | | Range | Section 16.35 |
| | | | | |
| Retry-After | Section 14.36 | | Retry-After | Section 16.37 |
| | | | | |
| RTP-Info | Section 14.38 | | RTP-Info | Section 16.39 |
| | | | | |
| Scale | Section 14.39 | | Scale | Section 16.40 |
| | | | | |
| Session | Section 14.42 | | Session | Section 16.43 |
| | | | | |
| Server | Section 14.41 | | Server | Section 16.42 |
| | | | | |
| Speed | Section 14.40 | | Speed | Section 16.41 |
| | | | | |
| Transport | Section 14.45 | | Transport | Section 16.46 |
| | | | | |
| Unsupported | Section 14.46 | | Unsupported | Section 16.47 |
| | | | | |
| Vary | Section 14.48 | | Vary | Section 16.49 |
| | | | | |
| WWW-Authenticate | Section 14.50 | | WWW-Authenticate | Section 16.51 |
+------------------------+--------------------+ +------------------------+--------------------+
Table 5: The RTSP response headers Table 5: The RTSP response headers
Response-header field names can be extended reliably only in Response-header field names can be extended reliably only in
combination with a change in the protocol version. However the usage combination with a change in the protocol version. However the usage
of feature-tags in the request allows the responding party to learn of feature-tags in the request allows the responding party to learn
the capability of the receiver of the response. New or experimental the capability of the receiver of the response. New or experimental
header fields MAY be given the semantics of response-header fields if header fields MAY be given the semantics of response-header fields if
all parties in the communication recognize them to be response-header all parties in the communication recognize them to be response-header
fields. Unrecognized header fields in responses are treated as fields. Unrecognized header fields in responses are treated as
entity-header fields. entity-header fields.
8. Entity 9. Entity
Request and Response messages MAY transfer an entity if not otherwise Request and Response messages MAY transfer an entity if not otherwise
restricted by the request method or response status code. An entity restricted by the request method or response status code. An entity
consists of entity-header fields and an entity-body, although some consists of entity-header fields and an entity-body, although some
responses will only include the entity-headers. responses will only include the entity-headers.
The SETPARAMETER and GETPARAMETER request and response, and DESCRIBE The SETPARAMETER and GET_PARAMETER request and response, and DESCRIBE
response MAY have an entity. All 4xx and 5xx responses MAY also have response MAY have an entity. All 4xx and 5xx responses MAY also have
an entity. an entity.
In this section, both sender and recipient refer to either the client In this section, both sender and recipient refer to either the client
or the server, depending on who sends and who receives the entity. or the server, depending on who sends and who receives the entity.
8.1. Entity Header Fields 9.1. Entity Header Fields
Entity-header fields define meta-information about the entity-body Entity-header fields define meta-information about the entity-body
or, if no body is present, about the resource identified by the or, if no body is present, about the resource identified by the
request. The entity header fields are listed in Table 6. request. The entity header fields are listed in Table 6.
+------------------+--------------------+ +------------------+--------------------+
| Header | Defined in Section | | Header | Defined in Section |
+------------------+--------------------+ +------------------+--------------------+
| Allow | Section 14.6 | | Allow | Section 16.6 |
| | | | | |
| Content-Base | Section 14.13 | | Content-Base | Section 16.13 |
| | | | | |
| Content-Encoding | Section 14.14 | | Content-Encoding | Section 16.14 |
| | | | | |
| Content-Language | Section 14.15 | | Content-Language | Section 16.15 |
| | | | | |
| Content-Length | Section 14.16 | | Content-Length | Section 16.16 |
| | | | | |
| Content-Location | Section 14.17 | | Content-Location | Section 16.17 |
| | | | | |
| Content-Type | Section 14.18 | | Content-Type | Section 16.18 |
| | | | | |
| Expires | Section 14.22 | | Expires | Section 16.22 |
| | | | | |
| Last-Modified | Section 14.27 | | Last-Modified | Section 16.27 |
+------------------+--------------------+ +------------------+--------------------+
Table 6: The RTSP entity headers Table 6: The RTSP entity headers
The extension-header mechanism allows additional entity-header fields The extension-header mechanism allows additional entity-header fields
to be defined without changing the protocol, but these fields cannot to be defined without changing the protocol, but these fields cannot
be assumed to be recognizable by the recipient. Unrecognized header be assumed to be recognizable by the recipient. Unrecognized header
fields SHOULD be ignored by the recipient and forwarded by proxies. fields SHOULD be ignored by the recipient and forwarded by proxies.
8.2. Entity Body 9.2. Entity Body
See [H7.2] with the addition that an RTSP message with an entity body See [H7.2] with the addition that an RTSP message with an entity body
MUST include the Content-Type and Content-Length headers. MUST include the Content-Type and Content-Length headers.
9. Connections 10. Connections
RTSP requests can be transmitted using the two different connection RTSP requests can be transmitted using the two different connection
scenarios listed below: scenarios listed below:
o persistent - a transport connection is used for several request/ o persistent - a transport connection is used for several request/
response transactions; response transactions;
o transient - a transport connection is used for a single request/ o transient - a transport connection is used for a single request/
response transaction. response transaction.
skipping to change at page 44, line 27 skipping to change at page 45, line 27
RTSP messages in connectionless mode over a transport protocol such RTSP messages in connectionless mode over a transport protocol such
as UDP. However, it was not specified in sufficient detail to allow as UDP. However, it was not specified in sufficient detail to allow
for interoperable implementations. In an attempt to reduce for interoperable implementations. In an attempt to reduce
complexity and scope, and due to lack of interest, RTSP 2.0 does not complexity and scope, and due to lack of interest, RTSP 2.0 does not
attempt to define a mechanism for supporting RTSP over UDP or other attempt to define a mechanism for supporting RTSP over UDP or other
connectionless transport protocols. A side-effect of this is that connectionless transport protocols. A side-effect of this is that
RTSP requests SHALL NOT be sent to multicast groups since no RTSP requests SHALL NOT be sent to multicast groups since no
connection can be established with a specific receiver in multicast connection can be established with a specific receiver in multicast
environments. environments.
Certain RTSP headers, such as the CSeq header Section 14.19), which Certain RTSP headers, such as the CSeq header Section 16.19), which
may appear to be relevant only to connectionless transport scenarios may appear to be relevant only to connectionless transport scenarios
are still retained and must be implemented according to the are still retained and must be implemented according to the
specification. In the case of CSeq, it is quite useful for matching specification. In the case of CSeq, it is quite useful for matching
responses to requests if the requests are pipelined (see responses to requests if the requests are pipelined (see Section 12).
Section 9.2). It is also useful in proxies for keeping track of the It is also useful in proxies for keeping track of the different
different requests when aggregating several client requests on a requests when aggregating several client requests on a single TCP
single TCP connection. connection.
9.1. Reliability and Acknowledgements 10.1. Reliability and Acknowledgements
When RTSP messages are transmitted using reliable transport When RTSP messages are transmitted using reliable transport
protocols, they MUST NOT be retransmitted at the RTSP protocol level. protocols, they MUST NOT be retransmitted at the RTSP protocol level.
Instead, the implementation must rely on the underlying transport to Instead, the implementation must rely on the underlying transport to
provide reliability. The RTSP implementation may use any indication provide reliability. The RTSP implementation may use any indication
of reception acknowledgement of the message from the underlying of reception acknowledgement of the message from the underlying
transport protocols to optimize the RTSP behavior. transport protocols to optimize the RTSP behavior.
If both the underlying reliable transport such as TCP and the RTSP If both the underlying reliable transport such as TCP and the RTSP
application retransmit requests, each packet loss or message loss application retransmit requests, each packet loss or message loss
may result in two retransmissions. The receiver typically cannot may result in two retransmissions. The receiver typically cannot
take advantage of the application-layer retransmission since the take advantage of the application-layer retransmission since the
transport stack will not deliver the application-layer transport stack will not deliver the application-layer
retransmission before the first attempt has reached the receiver. retransmission before the first attempt has reached the receiver.
If the packet loss is caused by congestion, multiple If the packet loss is caused by congestion, multiple
retransmissions at different layers will exacerbate the retransmissions at different layers will exacerbate the
congestion. congestion.
Lack of acknowledgement of an RTSP request should be handled within Lack of acknowledgement of an RTSP request should be handled within
the constraints of the connection timeout considerations described the constraints of the connection timeout considerations described
below (Section 9.4). below (Section 10.4).
9.2. Using Connections 10.2. Using Connections
A TCP transport can be used for both persistent connections (for A TCP transport can be used for both persistent connections (for
several message exchanges) and transient connections (for a single several message exchanges) and transient connections (for a single
message exchange). Implementations of this specification MUST message exchange). Implementations of this specification MUST
support RTSP over TCP. The scheme of the RTSP URI (Section 3.2) support RTSP over TCP. The scheme of the RTSP URI (Section 4.2)
indicates the default port that the server will listen on. indicates the default port that the server will listen on.
A server MUST handle both persistent and transient connections. A server MUST handle both persistent and transient connections.
Transient connections facilitate mechanisms for fault tolerance. Transient connections facilitate mechanisms for fault tolerance.
They also allow for application layer mobility. A server and They also allow for application layer mobility. A server and
client pair that support transient connections can survive the client pair that support transient connections can survive the
loss of a TCP connection; e.g., due to a NAT timeout. When the loss of a TCP connection; e.g., due to a NAT timeout. When the
client has discovered that the TCP connection has been lost, it client has discovered that the TCP connection has been lost, it
can set up a new one when there is need to communicate again. can set up a new one when there is need to communicate again.
skipping to change at page 46, line 15 skipping to change at page 47, line 15
session to the client but is not able to do so because it cannot session to the client but is not able to do so because it cannot
reach the client. reach the client.
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.
Also, this is the only way that requests from a server to its Also, this is the only way that requests from a server to its
client are likely to traverse firewalls. client are likely to traverse firewalls.
In light of the above, it is RECOMMENDED that clients use persistent In light of the above, it is RECOMMENDED that clients use persistent
connections whenever possible. A client that supports persistent connections whenever possible. A client that supports persistent
connections MAY "pipeline" its requests (i.e., send multiple requests connections MAY "pipeline" its requests (see Section 12).
without waiting for each response). A server MUST send its responses
to those requests in the order that the requests were received.
9.3. Closing Connections 10.3. Closing Connections
The client MAY close a connection at any point when no outstanding The client MAY close a connection at any point when no outstanding
request/response transactions exist for any RTSP session being request/response transactions exist for any RTSP session being
managed through the connection. The server, however, SHOULD NOT managed through the connection. The server, however, SHOULD NOT
close a connection until all RTSP sessions being managed through the close a connection until all RTSP sessions being managed through the
connection have been timed out (Section 14.42). A server SHOULD NOT connection have been timed out (Section 16.43). A server SHOULD NOT
close a connection immediately after responding to a session-level close a connection immediately after responding to a session-level
TEARDOWN request for the last RTSP session being controlled through TEARDOWN request for the last RTSP session being controlled through
the connection. Instead, it should wait for a reasonable amount of the connection. Instead, it should wait for a reasonable amount of
time for the client to receive the TEARDOWN response, take time for the client to receive the TEARDOWN response, take
appropriate action, and initiate the connection closing. The server appropriate action, and initiate the connection closing. The server
SHOULD wait at least 10 seconds after sending the TEARDOWN response SHOULD wait at least 10 seconds after sending the TEARDOWN response
before closing the connection. before closing the connection.
This is to ensure that the client has time to issue a SETUP for a This is to ensure that the client has time to issue a SETUP for a
new session on the existing connection after having torn the last new session on the existing connection after having torn the last
one down. 10 seconds should give the client ample opportunity get one down. 10 seconds should give the client ample opportunity get
its message to the server. 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 13.4.12) are used for negotiating capabilities Allowed" (Section 15.4.12) are used for negotiating capabilities
of a server with respect to content or other factors. In such of a server with respect to content or other factors. In such
cases, it is inefficient for the server to close a connection on cases, it is inefficient for the server to close a connection on
an error response. Also, such behavior would prevent an error response. Also, such behavior would prevent
implementation of advanced/special types of requests or result in implementation of advanced/special types of requests or result in
extra overhead for the client when testing for new features. On extra overhead for the client when testing for new features. On
the flip side, keeping connections open after sending an error the flip side, keeping connections open after sending an error
response poses a Denial of Service security risk (Section 20). response poses a Denial of Service security risk (Section 22).
If a server initiates a connection close while the client is If a server initiates a connection close while the client is
attempting to send a new request, the client will have to close its attempting to send a new request, the client will have to close its
current connection, establish a new connection and send its request current connection, establish a new connection and send its request
over the new connection. over the new connection.
An RTSP message should not be terminated by closing the connection. An RTSP message should not be terminated by closing the connection.
Such a message MAY be considered to be incomplete by the receiver and Such a message MAY be considered to be incomplete by the receiver and
discarded. An RTSP message is properly terminated as defined in discarded. An RTSP message is properly terminated as defined in
Section Section 4. Section 5.
9.4. Timing Out Connections and RTSP Messages 10.4. Timing Out Connections and RTSP Messages
Receivers of a request (responder) SHOULD respond to requests in a Receivers of a request (responder) SHOULD respond to requests in a
timely manner even when a reliable transport such as TCP is used. timely manner even when a reliable transport such as TCP is used.
Similarly, the sender of a request (requestor) SHOULD wait for a Similarly, the sender of a request (requestor) SHOULD wait for a
sufficient time for a response before concluding that the responder sufficient time for a response before concluding that the responder
will not be acting upon its request. will not be acting upon its request.
A responder SHOULD respond to all requests within 5 seconds. If the A responder SHOULD respond to all requests within 5 seconds. If the
responder recognizes that processing of a request will take longer responder recognizes that processing of a request will take longer
than 5 seconds, it SHOULD send a 100 (Continue) response as soon as than 5 seconds, it SHOULD send a 100 (Continue) response as soon as
skipping to change at page 47, line 41 skipping to change at page 48, line 38
A requestor SHOULD wait at least 10 seconds for a response before A requestor 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 requestor SHOULD continue waiting After receiving a 100 response, the requestor 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 requestor MAY assume that the responder receiving any response, the requestor MAY assume that the responder
is unresponsive and abort the connection. is unresponsive and abort the connection.
A requestor SHOULD wait longer than 10 seconds for a response if it A requestor 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 requestor is capable of determining the RTT of the responder. The requestor is capable of determining the RTT of the
request/response cycle using the Timestamp header (Section 14.44) in request/response cycle using the Timestamp header (Section 16.45) in
any RTSP request. any RTSP request.
9.5. Use of IPv6 10.5. Use of IPv6
Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP
2.0 has been updated for explicit IPv6 support. Implementations of 2.0 has been updated for explicit IPv6 support. Implementations of
RTSP 2.0 MUST understand literal IPv6 addresses in URIs and headers. RTSP 2.0 MUST understand literal IPv6 addresses in URIs and headers.
10. Capability Handling 11. Capability Handling
This section describes the capability handling mechanism available in This section describes the capability handling mechanism available in
RTSP which allows RTSP to be extended. Extensions to this version of RTSP which allows RTSP to be extended. Extensions to this version of
the protocol are basically done in two ways. First, new headers can the protocol are basically done in two ways. First, new headers can
be added. Secondly, new methods can be added. The capability be added. Secondly, new methods can be added. The capability
handling mechanism is designed to handle both cases. handling mechanism is designed to handle both cases.
When a method is added, the involved parties can use the OPTIONS When a method is added, the involved parties can use the OPTIONS
method to discover wether it is supported. This is done by issuing a method to discover wether it is supported. This is done by issuing a
OPTIONS request to the other party. Depending on the URI it will OPTIONS request to the other party. Depending on the URI it will
skipping to change at page 50, line 5 skipping to change at page 51, line 5
Require header. Require header.
Unsupported: This header is used in a 551 error response, to Unsupported: This header is used in a 551 error response, to
indicate which feature(s) that was not supported. Such a indicate which feature(s) that was not supported. Such a
response is only the result of the usage of the Require and/or response is only the result of the usage of the Require and/or
Proxy-Require header where one or more feature where not Proxy-Require header where one or more feature where not
supported. This information allows the requestor to make the supported. This information allows the requestor to make the
best of situations as it knows which features are not best of situations as it knows which features are not
supported. supported.
11. Method Definitions 12. Pipelining Support
Pipelining is a general method to improve performance of request
response protocols by allowing the requesting entity to have more
than one request outstanding and send them over the same persistent
connection. For RTSP where the relative order of requests will
matter it is important to maintain the order of the requests.
Because of this the the responding entity SHALL process the incoming
requests in their sending order. The sending order can be determined
by the CSeq header and its sequence number. For TCP the delivery
order will be the same as the sending order. The processing of the
request SHALL also have been finished before processing the next
request from the same entity. The responses MUST be sent in the
order the requests was processed.
RTSP 2.0 has extended support for pipelining compared to RTSP 1.0.
The major improvement is to allow all requests to setup and initiate
media playback to be pipelined after each other. This is
accomplished by the utilization of the Pipelined-Requests header (See
Section 16.29). This header allows a client to request that two or
more requests is to be processed in the same RTSP session context
which the first request creates. In other words a client can request
that two or more media streams are set-up and then played without
needing to wait for a single response. This speeds up the initial
startup time for an RTSP session with at least one RTT.
When pipelining requests care must be taken. If a pipelined request
builds on the succesful completion of one or more prior requests the
requestor must verify that all requests was executed as expected. O
common example will be two SETUP requests and a PLAY request. In
case one of the SETUP fails unexpectedly, the PLAY request can still
be succesfully executed. However, not as expected by the requesting
client as only a single media instead of two will be played. In this
case the client can send a PAUSE request, correct the failing SETUP
request and then request it to be played.
13. Method Definitions
The method indicates what is to be performed on the resource The method indicates what is to be performed on the resource
identified by the Request-URI. The method name is case-sensitive. identified by the Request-URI. The method name is case-sensitive.
New methods may be defined in the future. Method names SHALL NOT New methods may be defined in the future. Method names SHALL NOT
start with a $ character (decimal 24) and MUST be a token as defined start with a $ character (decimal 24) and MUST be a token as defined
by the ABNF [RFC4234] in the syntax chapter Section 19. The methods by the ABNF [RFC4234] in the syntax chapter Section 21. The methods
are summarized in Table 7. are summarized in Table 7.
+--------------+-----------+--------+---------------+---------------+ +---------------+-----------+--------+--------------+---------------+
| method | direction | object | Server req. | Client req. | | method | direction | object | Server req. | Client req. |
+--------------+-----------+--------+---------------+---------------+ +---------------+-----------+--------+--------------+---------------+
| DESCRIBE | C -> S | P,S | recommended | recommended | | DESCRIBE | C -> S | P,S | recommended | recommended |
| | | | | | | | | | | |
| GETPARAMETER | C -> S | P,S | optional | optional | | GET_PARAMETER | C -> S | P,S | optional | optional |
| | | | | | | | | | | |
| | S -> C | | | | | | S -> C | | | |
| | | | | | | | | | | |
| OPTIONS | C -> S | P,S | R=Req, Sd=Opt | Sd=Req, R=Opt | | OPTIONS | C -> S | P,S | R=Req, | Sd=Req, R=Opt |
| | | | Sd=Opt | |
| | | | | | | | | | | |
| | S -> C | | | | | | S -> C | | | |
| | | | | | | | | | | |
| PAUSE | C -> S | P,S | required | required | | PAUSE | C -> S | P,S | required | required |
| | | | | | | | | | | |
| PLAY | C -> S | P,S | required | required | | PLAY | C -> S | P,S | required | required |
| | | | | | | | | | | |
| REDIRECT | S -> C | P,S | optional | required | | REDIRECT | S -> C | P,S | optional | required |
| | | | | | | | | | | |
| SETUP | C -> S | S | required | required | | SETUP | C -> S | S | required | required |
| | | | | | | | | | | |
| SETPARAMETER | C -> S | P,S | required | optional | | SETPARAMETER | C -> S | P,S | required | optional |
| | | | | | | | | | | |
| | S -> C | | | | | | S -> C | | | |
| | | | | | | | | | | |
| TEARDOWN | C -> S | P,S | required | required | | TEARDOWN | C -> S | P,S | 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. Legend: R=Respond, (P: presentation, S: stream) they operate on. Legend: R=Respond,
Sd=Send, Opt: Optional, Req: Required Sd=Send, Opt: Optional, Req: Required
Note on Table 7: GETPARAMETER is recommended, but not required. Note on Table 7: GET_PARAMETER is recommended, but not required.
For example, a fully functional server can be built to deliver For example, a fully functional server can be built to deliver
media without any parameters. SETPARAMETER is required however media without any parameters. SETPARAMETER is required however
due to its usage for keep-alive. PAUSE is now required due to due to its usage for keep-alive. PAUSE is now required due to
that it is the only way of getting out of the state machines play that it is the only way of getting out of the state machines play
state without terminating the whole session. 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.
11.1. OPTIONS 13.1. OPTIONS
The semantics of the RTSP OPTIONS method is equivalent to that of the The semantics of the RTSP OPTIONS method is equivalent to that of the
HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is
bi-directional, in that a client can request it to a server and vice bi-directional, in that a client can request it to a server and vice
versa. A client MUST implement the capability to send an OPTIONS versa. A client MUST implement the capability to send an OPTIONS
request and a server or a proxy MUST implement the capability to request and a server or a proxy MUST implement the capability to
respond to an OPTIONS request. The client, server or proxy MAY also respond to an OPTIONS request. The client, server or proxy MAY also
implement the converse of their required capability. implement the converse of their required capability.
An OPTIONS request may be issued at any time. Such a request does An OPTIONS request may be issued at any time. Such a request does
skipping to change at page 51, line 46 skipping to change at page 53, line 46
included in the response to enumerate the set of methods that are included in the response to enumerate the set of methods that are
allowed for that resource unless the set of methods completely allowed for that resource unless the set of methods completely
matches the set in the Public header. If the given resource is not matches the set in the Public header. If the given resource is not
available, the RTSP agent SHOULD return an appropriate response code available, the RTSP agent SHOULD return an appropriate response code
such as 3rr or 4xx. The Supported header MAY be included in the such as 3rr or 4xx. The Supported header MAY be included in the
request to query the set of features that are supported by the request to query the set of features that are supported by the
responding RTSP agent. responding RTSP agent.
The OPTIONS method can be used to keep an RTSP session alive. The OPTIONS method can be used to keep an RTSP session alive.
However, it is not the preferred means of session keep-alive However, it is not the preferred means of session keep-alive
signalling, see Section 14.42. An OPTIONS request intended for signalling, see Section 16.43. An OPTIONS request intended for
keeping alive an RTSP session MUST include the Session header with keeping alive an RTSP session MUST include the Session header with
the associated session ID. Such a request SHOULD also use the media the associated session ID. Such a request SHOULD also use the media
or the aggregated control URI as the Request-URI. or the aggregated control URI as the Request-URI.
Example: Example:
C->S: OPTIONS * RTSP/2.0 C->S: OPTIONS * RTSP/2.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Require: Require:
skipping to change at page 52, line 21 skipping to change at page 54, line 21
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
Supported: play.basic, implicit-play, gzipped-messages Supported: play.basic, implicit-play, gzipped-messages
Server: PhonyServer/1.1 Server: PhonyServer/1.1
Note that some of the feature-tags in Require and Proxy-Require are Note that some of the feature-tags in Require and Proxy-Require are
fictional features. fictional features.
11.2. DESCRIBE 13.2. DESCRIBE
The DESCRIBE method is used to retrieve the description of a The DESCRIBE method is used to retrieve the description of a
presentation or media object from a server. The Request-URI of the presentation or media object from a server. The Request-URI of the
DESCRIBE request identifies the media resource of interest. The DESCRIBE request identifies the media resource of interest. The
client MAY include the Accept header in the request to list the client MAY include the Accept header in the request to list the
description formats that it understands. The server SHALL respond description formats that it understands. The server SHALL respond
with a description of the requested resource and return the with a description of the requested resource and return the
description in the entity of the response. The DESCRIBE reply- description in the entity of the response. The DESCRIBE reply-
response pair constitutes the media initialization phase of RTSP. response pair constitutes the media initialization phase of RTSP.
skipping to change at page 54, line 14 skipping to change at page 56, line 14
If a client obtains a valid description from an alternate source, the If a client obtains a valid description from an alternate source, the
client MAY use this description for initialization purposes without client MAY use this description for initialization purposes without
issuing a DESCRIBE request for the same media. issuing a DESCRIBE request for the same media.
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.
11.3. SETUP 13.3. SETUP
The SETUP request for an URI specifies the transport mechanism to be The SETUP request for an URI specifies the transport mechanism to be
used for the streamed media. The SETUP method may be used in three used for the streamed media. The SETUP method may be used in three
different cases; Create an RTSP session, add a media to a session, different cases; Create an RTSP session, add a media to a session,
and change the transport parameters of already set up media stream. and change the transport parameters of already set up media stream.
When in PLAY state, using SETUP to create or add media to a session When in PLAY state, using SETUP to create or add media to a session
when in PLAY state is unspecified. Otherwise SETUP can be used in when in PLAY state is unspecified. Otherwise 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. change the transport parameters.
The Transport header, see Section 14.45, specifies the transport The Transport header, see Section 16.46, specifies the transport
parameters acceptable to the client for data transmission; the parameters acceptable to the client for data transmission; the
response will contain the transport parameters selected by the response will contain the transport parameters selected by the
server. This allows the client to enumerate in priority order the server. This allows the client to enumerate in descending order of
transport mechanisms and parameters acceptable to it, while the preference the transport mechanisms and parameters acceptable to it,
server can select the most appropriate. It is expected that the while the server can select the most appropriate. It is expected
session description format used will enable the client to select a that the session description format used will enable the client to
limited number possible configurations that are offered to the server select a limited number possible configurations that are offered to
to choose from. All transport related parameters shall be included the server to choose from. All transport related parameters shall be
in the Transport header, the use of other headers for this purpose is included in the Transport header, the use of other headers for this
discouraged due to middle boxes such as firewalls, or NATs. purpose is discouraged due to middle boxes such as firewalls, or
NATs.
For the benefit of any intervening firewalls, a client SHALL indicate For the benefit of any intervening firewalls, a client SHALL indicate
the known transport parameters, even if it has no influence over the known transport parameters, even if it has no influence over
these parameters, for example, where the server advertises a fixed these parameters, for example, where the server advertises a fixed
multicast address as destination. multicast address as destination.
Since SETUP includes all transport initialization information, Since SETUP includes all transport initialization information,
firewalls and other intermediate network devices (which need this firewalls and other intermediate network devices (which need this
information) are spared the more arduous task of parsing the information) are spared the more arduous task of parsing the
DESCRIBE response, which has been reserved for media DESCRIBE response, which has been reserved for media
skipping to change at page 55, line 10 skipping to change at page 57, line 11
The client SHALL include the Accept-Ranges header in the request The client SHALL include the Accept-Ranges header in the request
indicating all supported unit formats in the Range header. This indicating all supported unit formats in the Range header. This
allows the server to know which format it may use in future session allows the server to know which format it may use in future session
related responses, such as PLAY response without any range in the related responses, such as PLAY response without any range in the
request. If the client does not support a time format necessary for request. If the client does not support a time format necessary for
the presentation the server SHALL respond using 456 (Header Field Not the presentation the server SHALL respond using 456 (Header Field Not
Valid for Resource) and include the Accept-Ranges header with the Valid for Resource) and include the Accept-Ranges header with the
range unit formats supported for the resource. range unit formats supported for the resource.
In a SETUP response the server SHALL include the Accept-Ranges header In a SETUP response the server SHALL include the Accept-Ranges header
(see Section 14.5) to indicate which time formats that are acceptable (see Section 16.5) to indicate which time formats that are acceptable
to use for this media resource. to use for this media resource.
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302 CSeq: 302
Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589", Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589",
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, UTC
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 302 CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1 Server: PhonyServer 1.1
Session: 47112344;timeout=60 Session: 47112344;timeout=60
Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589"; Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589";
src_addr="192.0.2.241:6256"/"192.0.2.241:6257"; src_addr="192.0.2.241:6256"/"192.0.2.241:6257";
ssrc=2A3F93ED ssrc=2A3F93ED
Accept-Ranges: NPT Accept-Ranges: NPT
skipping to change at page 55, line 41 skipping to change at page 57, line 44
UDP (UDP per default) to be received on client port 4588 and 4589 or UDP (UDP per default) to be received on client port 4588 and 4589 or
RTP/AVP interleaved on the RTSP control channel. The server selects RTP/AVP interleaved on the RTSP control channel. The server selects
the RTP/AVP/UDP transport and adds the ports it will send and the RTP/AVP/UDP transport and adds the ports it will send and
received RTP and RTCP from, and the RTP SSRC that will be used by the received 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, in which case the server MUST bundle this setup a session identifier, in which case the server MUST bundle this setup
request into the existing session (aggregated session) or return request into the existing session (aggregated session) or return
error 459 (Aggregate Operation Not Allowed) (see Section 13.4.11). error 459 (Aggregate Operation Not Allowed) (see Section 15.4.11).
An Aggregate control URI MUST be used to control an aggregated An Aggregate control URI MUST be used to control an aggregated
session. This URI MUST be different from the stream control URIs of session. This URI MUST be different from the stream control URIs of
the individual media streams included in the aggregate. The the individual media streams included in the aggregate. The
Aggregate control URI is to be specified by the session description Aggregate control URI is to be specified by the session description
if the server supports aggregated control and aggregated control is if the server supports aggregated control and aggregated control is
desired for the session. However even if aggregated control is desired for the session. However even if aggregated control is
offered the client MAY chose to not set up the session in aggregated offered the client MAY chose to not set up the session in aggregated
control. If an Aggregate control URI is not specified in the session control. If an Aggregate control URI is not specified in the session
description, it is normally an indication that non-aggregated control description, it is normally an indication that non-aggregated control
should be used. The SETUP of media streams in an aggregate which has should be used. The SETUP of media streams in an aggregate which has
skipping to change at page 56, line 21 skipping to change at page 58, line 24
route the request to the appropriate server, and for logging, route the request to the appropriate server, and for logging,
where it is useful to note the actual resource that a request was where it is useful to note the actual resource that a request was
operating on. operating on.
A session will exist until it is either removed by a TEARDOWN request A session will exist until it is either removed by a TEARDOWN request
or is timed-out by the server. The server MAY remove a session that or is timed-out by the server. The server MAY remove a session that
has not demonstrated liveness signs from the client(s) within a has not demonstrated liveness signs from the client(s) within a
certain timeout period. The default timeout value is 60 seconds; the certain timeout period. The default timeout value is 60 seconds; the
server MAY set this to a different value and indicate so in the server MAY set this to a different value and indicate so in the
timeout field of the Session header in the SETUP response. For timeout field of the Session header in the SETUP response. For
further discussion see Section 14.42. Signs of liveness for an RTSP further discussion see Section 16.43. Signs of liveness for an RTSP
session are: session are:
o Any RTSP request from a client(s) which includes a Session header o Any RTSP request from a client(s) which includes a Session header
with that session's ID. with that session's ID.
o If RTP is used as a transport for the underlying media streams, an o If RTP is used as a transport for the underlying media streams, an
RTCP sender or receiver report from the client(s) for any of the RTCP sender or receiver report from the client(s) for any of the
media streams in that RTSP session. RTCP Sender Reports may for media streams in that RTSP session. RTCP Sender Reports may for
example be received in sessions where the server is invited into a example be received in sessions where the server is invited into a
conference session and is as valid for keep-alive. conference session and is as valid for keep-alive.
If a SETUP request on a session fails for any reason, the session If a SETUP request on a session fails for any reason, the session
state, as well as transport and other parameters for associated state, as well as transport and other parameters for associated
streams SHALL remain unchanged from their values as if the SETUP streams SHALL remain unchanged from their values as if the SETUP
request had never been received by the server. request had never been received by the server.
11.3.1. Changing Transport Parameters 13.3.1. Changing Transport Parameters
A client MAY issue a SETUP request for a stream that is already set A client MAY issue a SETUP request for a stream that is already set
up or playing in the session to change transport parameters, which a up or playing in the session to change transport parameters, which a
server MAY allow. If it does not allow changing of parameters, it server MAY allow. If it does not allow changing of parameters, it
MUST respond with error 455 (Method Not Valid In This State). MUST respond with error 455 (Method Not Valid In This State).
Reasons to support changing transport parameters, is to allow for Reasons to support changing transport parameters, is to allow for
application layer mobility and flexibility to utilize the best application layer mobility and flexibility to utilize the best
available transport as it becomes available. If a client receives a available transport as it becomes available. If a client receives a
455 when trying to change transport parameters while the server is in 455 when trying to change transport parameters while the server is in
play state, it MAY try to put the server in ready state using PAUSE, play state, it MAY try to put the server in ready state using PAUSE,
skipping to change at page 57, line 28 skipping to change at page 59, line 31
the response the "rtp_time" parameter and range MUST be for the the response the "rtp_time" parameter and range MUST be for the
corresponding time, i.e. be used in the same way as for PLAY to corresponding time, i.e. be used in the same way as for PLAY to
ensure the correct synchronization information is available. ensure the correct synchronization information is available.
If the transport parameters change while in PLAY state results in a If the transport parameters change while in PLAY state results in a
change of synchronization related information, for example changing change of synchronization related information, for example changing
RTP SSRC, the server MUST provide in the SETUP response the necessary RTP SSRC, the server MUST provide in the SETUP response the necessary
synchronization information. However the server is RECOMMENDED to synchronization information. However the server is RECOMMENDED to
avoid changing the synchronization information if possible. avoid changing the synchronization information if possible.
11.4. PLAY 13.4. PLAY
The PLAY method tells the server to start sending data via the The PLAY method tells the server to start sending data via the
mechanism specified in SETUP. PLAY requests are valid when the mechanism specified in SETUP. PLAY requests are valid when the
session is in READY or PLAY states. A PLAY request MUST include a session is in READY or PLAY states. A PLAY request MUST include a
Session header to indicate which session the request applies to. Session header to indicate which session the request applies to.
For aggregated sessions where the initial SETUP request (creating a For aggregated sessions where the initial SETUP request (creating a
session) is followed by one or more additional SETUP request, a PLAY session) is followed by one or more additional SETUP request, a PLAY
request MAY be pipelined after those additional SETUP requests request MAY be pipelined after those additional SETUP requests
without awaiting their responses. This can procedure can reduce the without awaiting their responses. This can procedure can reduce the
skipping to change at page 58, line 9 skipping to change at page 60, line 12
can halt the media playout using PAUSE and try to establish the can halt the media playout using PAUSE and try to establish the
intended state again before issuing another PLAY request. intended state again before issuing another PLAY request.
In an aggregated session the PLAY request MUST contain an aggregated In an aggregated session the PLAY request MUST contain an aggregated
control URI. A server SHALL responde with error 460 (Only Aggregate control URI. A server SHALL responde with error 460 (Only Aggregate
Operation Allowed) if the client PLAY Request-URI is for one of the Operation Allowed) if the client PLAY Request-URI is for one of the
media. The media in an aggregate SHALL be played in sync. If a media. The media in an aggregate SHALL be played in sync. If a
client want individual control of the media it needs to use separate client want individual control of the media it needs to use separate
RTSP sessions for each media. RTSP sessions for each media.
The PLAY request SHALL position the normal play time to the beginning Upon receipt of the PLAY request, the server SHALL position the
of the range specified by the Range header and delivers stream data normal play time to the beginning of the range specified in the
until the end of the range if given, else to the end of the media is received Range header and delivers stream data until the end of the
reached. To allow for precise composition multiple ranges MAY be range if given, or until a new PLAY request is received, else to the
specified in one PLAY Request. The range values are valid if all end of the media is reached. To allow for precise composition
given ranges are part of any media within the aggregate. If a given multiple ranges MAY be specified in one PLAY Request. The range
range value points outside of the media, the response SHALL be the values are valid if all given ranges are part of any media within the
457 (Invalid Range) error code. aggregate. If a given range value points outside of the media, the
response SHALL be the 457 (Invalid Range) error code.
The below example will first play seconds 10 through 15, then, The below example will first play seconds 10 through 15, then,
immediately following, seconds 20 to 25, and finally seconds 30 immediately following, seconds 20 to 25, and finally seconds 30
through the end. through the end.
C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0 C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Range: npt=10-15, npt=20-25, npt=30- Range: npt=10-15, npt=20-25, npt=30-
User-Agent: PhonyClient/1.2
See the description of the PAUSE request for further examples. See the description of the PAUSE request for further examples.
A PLAY request without a Range header is legal. It SHALL start A PLAY request without a Range header is legal. It SHALL start
playing a stream from the beginning (npt=0-) unless the stream has playing a stream from the beginning (npt=0-) unless the stream has
been paused or is currently playing. If a stream has been paused via been paused or is currently playing. If a stream has been paused via
PAUSE, stream delivery resumes at the pause point. If a stream is PAUSE, stream delivery resumes at the pause point. If a stream is
currently playing, the new PLAY begins at the current stream currently playing, the new PLAY begins at the current stream
position. The stream SHALL play until the end of the media. position. The stream SHALL play until the end of the media.
skipping to change at page 59, line 21 skipping to change at page 61, line 25
points. Also, some media format have a very long duration per points. Also, some media format have a very long duration per
individual data unit, therefore it might be necessary for the client individual data unit, therefore it might be necessary for the client
to parse the data unit, and select where to start. to parse the data unit, and select where to start.
Example: Single audio stream (MIDI) Example: Single audio stream (MIDI)
C->S: PLAY rtsp://example.com/audio RTSP/2.0 C->S: PLAY rtsp://example.com/audio RTSP/2.0
CSeq: 836 CSeq: 836
Session: 12345678 Session: 12345678
Range: npt=7.05- Range: npt=7.05-
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 836 CSeq: 836
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=3.52- Range: npt=3.52-
RTP-Info:url="rtsp://example.com/audio" RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545 ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTP Packet TS=2345962545 => NPT=3.52 S->C: RTP Packet TS=2345962545 => NPT=3.52
Duration: 4.15 seconds Duration=4.15 seconds
In this example the client receives the first media packet that In this example the client receives the first media packet that
stretches all the way up and past the requested playtime. Thus, it stretches all the way up and past the requested playtime. Thus, it
is the client's decision if to render to the user the time between is the client's decision if to render to the user the time between
3.52 and 7.05, or to skip it. In most cases it is probably most 3.52 and 7.05, or to skip it. In most cases it is probably most
suitable to not render that time period. suitable to not render that time period.
For live media sources it might be impossible to specify from which For live media sources it might be impossible to specify from which
point in time all media streams carrying active content can actually point in time all media streams carrying active content can actually
be delivered. Therefore a server MAY specify a start time (or now-) be delivered. Therefore a server MAY specify a start time (or now-)
skipping to change at page 60, line 6 skipping to change at page 62, line 12
still be returned in the reply. If the medias that are part of an still be returned in the reply. If the medias that are part of an
aggregate has different lengths, the PLAY request SHALL be performed aggregate has different lengths, the PLAY request SHALL be performed
as long as the given range is valid for any media, for example the as long as the given range is valid for any media, for example the
longest media. Media will be sent whenever it is available for the longest media. Media will be sent whenever it is available for the
given play-out point. given play-out point.
A PLAY response MAY include a header(s) carrying synchronization A PLAY response MAY include a header(s) carrying synchronization
information. As the information necessary is dependent on the media information. As the information necessary is dependent on the media
transport format, further rules specifying the header and its usage transport format, further rules specifying the header and its usage
is needed. For RTP the RTP-Info header is specified, see is needed. For RTP the RTP-Info header is specified, see
Section 14.38. Section 16.39.
After playing the desired range, the presentation does NOT transition After playing the desired range, the presentation does NOT transition
to the READY state, media delivery simply stops. A PAUSE request to the READY state, media delivery simply stops. A PAUSE request
MUST be issued before the stream enters the READY state. A PLAY MUST be issued before the stream enters the READY state. A PLAY
request while the stream is still in the PLAYING state is legal, and request while the stream is still in the PLAYING state is legal, and
can be issued without an intervening PAUSE request. Such a request can be issued without an intervening PAUSE request. Such a request
SHALL replace the current PLAY action with the new one requested, SHALL replace the current PLAY action with the new one requested,
i.e. being handle the same as the request was received in ready i.e. being handle the same as the request was received in ready
state. In the case the first time range in Range header has a open state. In the case the first time range in Range header has a open
start time (-endtime), the server SHALL continue to play from where start time (-endtime), the server SHALL continue to play from where
skipping to change at page 60, line 36 skipping to change at page 62, line 42
pause point in a Range header SHALL be included. pause point in a Range header SHALL be included.
The following example plays the whole presentation starting at SMPTE The following example plays the whole presentation starting at SMPTE
time code 0:10:20 until the end of the clip. Note: The RTP-Info time code 0:10:20 until the end of the clip. Note: The RTP-Info
headers has been broken into several lines to fit the page. headers has been broken into several lines to fit the page.
C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0
CSeq: 833 CSeq: 833
Session: 12345678 Session: 12345678
Range: smpte=0:10:20- Range: smpte=0:10:20-
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 833 CSeq: 833
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: smpte=0:10:22-0:15:45 Range: smpte=0:10:22-0:15:45
RTP-Info:url="rtsp://example.com/twister.en" RTP-Info:url="rtsp://example.com/twister.en"
ssrc=0D12F123:seq=14783;rtptime=2345962545 ssrc=0D12F123:seq=14783;rtptime=2345962545
For playing back a recording of a live presentation, it may be For playing back a recording of a live presentation, it may be
desirable to use clock units: desirable to use clock units:
C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Range: clock=19961108T142300Z-19961108T143520Z Range: clock=19961108T142300Z-19961108T143520Z
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 835 CSeq: 835
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server:PhonyServer 1.0 Server:PhonyServer 1.0
Range: clock=19961108T142300Z-19961108T143520Z Range: clock=19961108T142300Z-19961108T143520Z
RTP-Info:url="rtsp://example.com/meeting.en" RTP-Info:url="rtsp://example.com/meeting.en"
ssrc=0D12F123:seq=53745;rtptime=484589019 ssrc=0D12F123:seq=53745;rtptime=484589019
All range specifiers in this specification allow for ranges with All range specifiers in this specification allow for ranges with
skipping to change at page 61, line 43 skipping to change at page 63, line 46
without a range header in PLAY state, has also been deprecated. without a range header in PLAY state, has also been deprecated.
Instead a client can use, SETPARAMETER (recommended) or OPTIONS Instead a client can use, SETPARAMETER (recommended) or OPTIONS
(allowed) for keep alive. (allowed) for keep alive.
An example of using PLAY request to change the behavior, if a server An example of using PLAY request to change the behavior, if a server
has received requests to play ranges 10 to 15 and then 13 to 20 (that has received requests to play ranges 10 to 15 and then 13 to 20 (that
is, overlapping ranges), a PLAY request 4 seconds after the first is, overlapping ranges), a PLAY request 4 seconds after the first
would take effect while the server plays the first range. Thus would take effect while the server plays the first range. Thus
changing the behavior to continue to play to 25 seconds, i.e. the changing the behavior to continue to play to 25 seconds, i.e. the
played range equal play with range: npt=10-25. If the second PLAY played range equal play with range: npt=10-25. If the second PLAY
request would arrive after the second range in the first range was request would arrive as the second range in the first request was
playing, then the equivalent request would be play with range:npt=10- playing, then the equivalent request would be play with range:npt=10-
15,npt=13-25. 15,npt=13-25.
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
Range: npt=10-15, npt=13-20 Range: npt=10-15, npt=13-20
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 834 CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=10-15, npt=13-20 Range: npt=10-15, npt=13-20
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921, ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792482193 ssrc=789DAF12:seq=57654;rtptime=2792482193
Session: 12345678 Session: 12345678
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Range: npt=-25 Range: npt=-25
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 835 CSeq: 835
Date: 23 Jan 1997 15:35:09 GMT Date: 23 Jan 1997 15:35:09 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=14-15, npt=13-25 Range: npt=14-25
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934239921, ssrc=0D12F123:seq=5712;rtptime=934239921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792842193 ssrc=789DAF12:seq=57654;rtptime=2792842193
Session: 12345678 Session: 12345678
11.5. PAUSE 13.5. PAUSE
The PAUSE request causes the stream delivery to immediately be The PAUSE request causes the stream delivery to immediately be
interrupted (halted). A PAUSE request MUST be done with the interrupted (halted). A PAUSE request MUST be done either with the
aggregated control URI for aggregated sessions, resulting in all aggregated control URI for aggregated sessions, resulting in all
media being halted, or the media URI for non-aggregated sessions. media being halted, or the media URI for non-aggregated sessions.
Any attempt to do muting of a single media with an PAUSE request in Any attempt to do muting of a single media with an PAUSE request in
an aggregated session SHALL be responded with error 460 (Only an aggregated session SHALL be responded with error 460 (Only
Aggregate Operation Allowed). After resuming playback, Aggregate Operation Allowed). After resuming playback,
synchronization of the tracks MUST be maintained. Any server synchronization of the tracks MUST be maintained. Any server
resources are kept, though servers MAY close the session and free resources are kept, though servers MAY close the session and free
resources after being paused for the duration specified with the resources after being paused for the duration specified with the
timeout parameter of the Session header in the SETUP message. timeout parameter of the Session header in the SETUP message.
Example: Example:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 834 CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Range: npt=45.76- Range: npt=45.76-
The PAUSE request causes stream delivery to be interrupted The PAUSE request causes stream delivery to be interrupted
immediately on receipt of the message and the pause point is set to immediately on receipt of the message and the pause point is set to
the current point in the presentation. That pause point in the media the current point in the presentation. That pause point in the media
stream needs to be maintained. A subsequent PLAY request without stream needs to be maintained. A subsequent PLAY request without
skipping to change at page 64, line 9 skipping to change at page 65, line 35
client by adding a Range header with what remains unplayed of the client by adding a Range header with what remains unplayed of the
PLAY request's ranges, i.e. including all the remaining ranges part PLAY request's ranges, i.e. including all the remaining ranges part
of multiple range specification. If one desires to resume playing a of multiple range specification. If one desires to resume playing a
ranged request, one simply includes the Range header from the PAUSE ranged request, one simply includes the Range header from the PAUSE
response. response.
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
Range: npt=10-30 Range: npt=10-30
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 834 CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=10-30 Range: npt=10-30
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921, ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=4FAD8726:seq=57654;rtptime=2792482193 ssrc=4FAD8726:seq=57654;rtptime=2792482193
Session: 12345678 Session: 12345678
after 11 seconds, i.e. at 21 seconds into the presentation: after 11 seconds, i.e. at 21 seconds into the presentation:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 835 CSeq: 835
Date: 23 Jan 1997 15:35:09 GMT Date: 23 Jan 1997 15:35:09 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=21-30 Range: npt=21-30
Session: 12345678 Session: 12345678
If a client issues a PAUSE request and the server acknowledges and If a client issues a PAUSE request and the server acknowledges and
enters the READY state, the proper server response, if the player enters the READY state, the proper server response, if the player
issues another PAUSE, is still 200 OK. The 200 OK response MUST issues another PAUSE, is still 200 OK. The 200 OK response MUST
include the Range header with the current pause point. See examples include the Range header with the current pause point. See examples
below: below:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Range: npt=45.76-98.36 Range: npt=45.76-98.36
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Date: 23 Jan 1997 15:35:07 GMT Date: 23 Jan 1997 15:35:07 GMT
Range: npt=45.76-98.36 Range: npt=45.76-98.36
11.6. TEARDOWN 13.6. TEARDOWN
The TEARDOWN client to server request stops the stream delivery for The TEARDOWN client to server request stops the stream delivery for
the given URI, freeing the resources associated with it. A TEARDOWN the given URI, freeing the resources associated with it. A TEARDOWN
request MAY be performed on either an aggregated or a media control request MAY be performed on either an aggregated or a media control
URI. However some restrictions apply depending on the current state. URI. However some restrictions apply depending on the current state.
The TEARDOWN request SHALL contain a Session header indicating what The TEARDOWN request SHALL contain a Session header indicating what
session the request applies to. session the request applies to.
A TEARDOWN using the aggregated control URI or the media URI in a A TEARDOWN using the aggregated control URI or the media URI in a
session under non-aggregated control (single media session) MAY be session under non-aggregated control (single media session) MAY be
skipping to change at page 66, line 8 skipping to change at page 67, line 24
that will exist after the processing of the TEARDOWN request SHALL in that will exist after the processing of the TEARDOWN request SHALL 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 existing 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
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 892 CSeq: 892
Server: PhonyServer 1.0 Server: PhonyServer 1.0
11.7. GETPARAMETER 13.7. GET_PARAMETER
The GETPARAMETER request retrieves the value of a parameter or The GET_PARAMETER request retrieves the value of a parameter or
parameters for a presentation or stream specified in the URI. If the parameters for a presentation or stream specified in the URI. If the
Session header is present in a request, the value of a parameter MUST Session header is present in a request, the value of a parameter MUST
be retrieved in the specified session context. The content of the be retrieved in the specified session context. The content of the
reply and response is left to the implementation. reply and response is left to the implementation.
The method MAY also be used without a body (entity). If the this The method MAY also be used without a body (entity). If the this
request is successful, i.e. a 200 OK response is received, then the request is successful, i.e. a 200 OK response is received, then the
keep-alive timer has been updated. Any non-required header present keep-alive timer has been updated. Any non-required header present
in such a request may or may not been processed. To allow a client in such a request may or may not been processed. To allow a client
to determine if any such header has been processed, it is necessary to determine if any such header has been processed, it is necessary
skipping to change at page 66, line 37 skipping to change at page 68, line 10
is RECOMMENDED that any parameters to be retrieved are sent in the is RECOMMENDED that any parameters to be retrieved are sent in the
body, rather than using any header. body, rather than using any header.
Example: Example:
S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 431 CSeq: 431
Content-Type: text/parameters Content-Type: text/parameters
Session: 12345678 Session: 12345678
Content-Length: 26 Content-Length: 26
User-Agent: PhonyClient/1.2
packets_received packets_received
jitter jitter
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 431 CSeq: 431
Content-Length: 38 Content-Length: 38
Content-Type: text/parameters Content-Type: text/parameters
packets_received: 10 packets_received: 10
skipping to change at page 67, line 4 skipping to change at page 68, line 22
packets_received packets_received
jitter jitter
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 431 CSeq: 431
Content-Length: 38 Content-Length: 38
Content-Type: text/parameters Content-Type: text/parameters
packets_received: 10 packets_received: 10
jitter: 0.3838 jitter: 0.3838
The "text/parameters" section is only an example type for a body The "text/parameters" section is only an example type for a body
carrying parameters. carrying parameters.
11.8. SET_PARAMETER 13.8. SET_PARAMETER
This method requests to set the value of a parameter or a set of This method requests to set the value of a parameter or a set of
parameters for a presentation or stream specified by the URI. The parameters for a presentation or stream specified by the URI. The
method MAY also be used without a body (entity). It is the method MAY also be used without a body (entity). It is the
RECOMMENDED method to use in request sent for the sole purpose of RECOMMENDED method to use in request sent for the sole purpose of
updating the keep-alive timer. If this request is successful, i.e. a updating the keep-alive timer. If this request is successful, i.e. a
200 OK response is received, then the keep-alive timer has been 200 OK response is received, then the keep-alive timer has been
updated. Any non-required header present in such a request may or updated. Any non-required header present in such a request may or
may not been processed. To allow a client to determine if any such may not been processed. To allow a client to determine if any such
header has been processed, it is necessary to use a feature tag and header has been processed, it is necessary to use a feature tag and
skipping to change at page 68, line 7 skipping to change at page 69, line 20
can be more meaningful error indications. However, it may make can be more meaningful error indications. However, it may make
sense to allow the setting of several parameters if an atomic sense to allow the setting of several parameters if an atomic
setting is desirable. Imagine device control where the client setting is desirable. Imagine device control where the client
does not want the camera to pan unless it can also tilt to the does not want the camera to pan unless it can also tilt to the
right angle at the same time. right angle at the same time.
Example: Example:
C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 421 CSeq: 421
User-Agent: PhonyClient/1.2
Content-length: 20 Content-length: 20
Content-type: text/parameters Content-type: text/parameters
barparam: barstuff barparam: barstuff
S->C: RTSP/2.0 451 Parameter Not Understood S->C: RTSP/2.0 451 Parameter Not Understood
CSeq: 421 CSeq: 421
Content-length: 10 Content-length: 10
Content-type: text/parameters Content-type: text/parameters
barparam: barstuff barparam: barstuff
The "text/parameters" section is only an example type for The "text/parameters" section is only an example type for
parameters. This method is intentionally loosely defined with the parameters. This method is intentionally loosely defined with the
intention that the reply content and response content will be intention that the reply content and response content will be
defined by the one desiring to use this mechanism. defined by the one desiring to use this mechanism.
11.9. REDIRECT 13.9. REDIRECT
The REDIRECT method is issued by a server to inform a client that it The REDIRECT method is issued by a server to inform a client that it
required to connect to another server location to access the resource required to connect to another server location to access the resource
indicated by the Request-URI. The presence of the Session header in indicated by the Request-URI. The presence of the Session header in
a REDIRECT request indicates the scope of the request, and determines a REDIRECT request indicates the scope of the request, and determines
the specific semantics of the request. the specific semantics of the request.
A REDIRECT request with a Session header has end-to-end (i.e. server A REDIRECT request with a Session header has end-to-end (i.e. server
to client) scope and applies only to the given session. Any to client) scope and applies only to the given session. Any
intervening proxies SHOULDNOT disconnect the control channel while intervening proxies SHOULDNOT disconnect the control channel while
skipping to change at page 70, line 12 skipping to change at page 71, line 27
reached, a client MUST issue a TEARDOWN request and SHOULD close the reached, a client MUST issue a TEARDOWN request and SHOULD close the
signalling connection after receiving a 2xx response. The normal signalling connection after receiving a 2xx response. The normal
connection considerations apply for the server. connection considerations apply for the server.
The differentiation of REDIRECT requests with and without range The differentiation of REDIRECT requests with and without range
headers is to allow for clear and explicit state handling. As the headers is to allow for clear and explicit state handling. As the
state in the server needs to be kept until the point of state in the server needs to be kept until the point of
redirection, the handling becomes more clear if the client is redirection, the handling becomes more clear if the client is
required to TEARDOWN the session at the redirect point. required to TEARDOWN the session at the redirect point.
If the REDIRECT request times out following the rules in Section 9.4 If the REDIRECT request times out following the rules in Section 10.4
the server MAY terminate the session or transport connection that the server MAY terminate the session or transport connection that
would be redirected by the request. This is a safeguard against would be redirected by the request. This is a safeguard against
misbehaving clients that refuses to respond to a REDIRECT request. misbehaving clients that refuses to respond to a REDIRECT request.
That should not provide any benefit. That should not provide any benefit.
After a REDIRECT request has been processed, a client that wants to After a REDIRECT request has been processed, a client that wants to
continue to send or receive media for the resource identified by the continue to send or receive media for the resource identified by the
Request-URI will have to establish a new session with the designated Request-URI will have to establish a new session with the designated
host. If the URI given in the Location header is a valid resource host. If the URI given in the Location header is a valid resource
URI, a client SHOULD issue a DESCRIBE request for the URI. URI, a client SHOULD issue a DESCRIBE request for the URI.
skipping to change at page 71, line 4 skipping to change at page 72, line 13
server at the given absolute time: server at the given absolute time:
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 732 CSeq: 732
Location: rtsp://s2.example.com:8001 Location: rtsp://s2.example.com:8001
Range: npt=0- ;time=19960213T143205Z Range: npt=0- ;time=19960213T143205Z
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 732 CSeq: 732
User-Agent: PhonyClient/1.2
12. Embedded (Interleaved) Binary Data 14. Embedded (Interleaved) Binary Data
In order to fulfill certain requirements on the network side, e.g. in In order to fulfill certain requirements on the network side, e.g. in
conjunction with network address translators that block RTP traffic conjunction with network address translators that block RTP traffic
over UDP, it may be necessary to interleave RTSP messages and media over UDP, it may be necessary to interleave RTSP messages and media
stream data. This interleaving should generally be avoided unless stream data. This interleaving should generally be avoided unless
necessary since it complicates client and server operation and necessary since it complicates client and server operation and
imposes additional overhead. Also head of line blocking may cause imposes additional overhead. Also head of line blocking may cause
problems. Interleaved binary data SHOULD only be used if RTSP is problems. Interleaved binary data SHOULD only be used if RTSP is
carried over TCP. carried over TCP.
skipping to change at page 71, line 33 skipping to change at page 73, line 33
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "$" = 24 | Channel ID | Length in bytes | | "$" = 24 | Channel ID | Length in bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Length number of bytes of binary data : : Length number of bytes of binary data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The channel identifier is defined in the Transport header with the The channel identifier is defined in the Transport header with the
interleaved parameter (Section 14.45). interleaved parameter (Section 16.46).
When the transport choice is RTP, RTCP messages are also interleaved When the transport choice is RTP, RTCP messages are also interleaved
by the server over the TCP connection. The usage of RTCP messages is by the server over the TCP connection. The usage of RTCP messages is
indicated by including a range containing a second channel in the indicated by including a range containing a second channel in the
interleaved parameter of the Transport header, see Section 14.45. If interleaved parameter of the Transport header, see Section 16.46. If
RTCP is used, packets SHALL be sent on the first available channel RTCP is used, packets SHALL be sent on the first available channel
higher than the RTP channel. The channels are bi-directional and higher than the RTP channel. The channels are bi-directional and
therefore RTCP traffic are sent on the second channel in both therefore RTCP traffic are sent on the second channel in both
directions. directions.
RTCP is sometime needed for synchronization when two or more RTCP is sometime needed for synchronization when two or more
streams are interleaved in such a fashion. Also, this provides a streams are interleaved in such a fashion. Also, this provides a
convenient way to tunnel RTP/RTCP packets through the TCP control convenient way to tunnel RTP/RTCP packets through the TCP control
connection when required by the network configuration and transfer connection when required by the network configuration and transfer
them onto UDP when possible. them onto UDP when possible.
C->S: SETUP rtsp://example.com/bar.file RTSP/2.0 C->S: SETUP rtsp://example.com/bar.file RTSP/2.0
CSeq: 2 CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1 Transport: RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Date: 05 Jun 1997 18:57:18 GMT Date: 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;unicast;interleaved=5-6 Transport: RTP/AVP/TCP;unicast;interleaved=5-6
Session: 12345678 Session: 12345678
Accept-Ranges: NPT
C->S: PLAY rtsp://example.com/bar.file RTSP/2.0 C->S: PLAY rtsp://example.com/bar.file RTSP/2.0
CSeq: 3 CSeq: 3
Session: 12345678 Session: 12345678
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Session: 12345678 Session: 12345678
Date: 05 Jun 1997 18:59:15 GMT Date: 05 Jun 1997 18:59:15 GMT
RTP-Info: url="rtsp://example.com/bar.file" RTP-Info: url="rtsp://example.com/bar.file"
ssrc=0D12F123:seq=232433;rtptime=972948234 ssrc=0D12F123:seq=232433;rtptime=972948234
Range: npt=0-56.8
S->C: $005{2 byte length}{"length" bytes data, w/RTP header} S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
S->C: $005{2 byte length}{"length" bytes data, w/RTP header} S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
S->C: $006{2 byte length}{"length" bytes RTCP packet} S->C: $006{2 byte length}{"length" bytes RTCP packet}
13. Status Code Definitions 15. Status Code Definitions
Where applicable, HTTP status [H10] codes are reused. Status codes Where applicable, HTTP status [H10] codes are reused. Status codes
that have the same meaning are not repeated here. See Table 4 for a that have the same meaning are not repeated here. See Table 4 for a
listing of which status codes may be returned by which requests. All listing of which status codes may be returned by which requests. All
error messages, 4xx and 5xx MAY return a body containing further error messages, 4xx and 5xx MAY return a body containing further
information about the error. information about the error.
13.1. Success 1xx 15.1. Success 1xx
13.1.1. 100 Continue 15.1.1. 100 Continue
See, [H10.1.1]. See, [H10.1.1].
13.2. Success 2xx 15.2. Success 2xx
13.3. Redirection 3xx 15.3. Redirection 3xx
The notation "3rr" indicates response codes from 300 to 399 inclusive The notation "3rr" indicates response codes from 300 to 399 inclusive
which are meant for redirection. The response code 304 is excluded which are meant for redirection. The response code 304 is excluded
from this set, as it is not used for redirection. from this set, as it is not used for redirection.
See [H10.3] for definition of status code 300 to 305. However See [H10.3] for definition of status code 300 to 305. However
comments are given for some to how they apply to RTSP. comments are given for some to how they apply to RTSP.
Within RTSP, redirection may be used for load balancing or Within RTSP, redirection may be used for load balancing or
redirecting stream requests to a server topologically closer to the redirecting stream requests to a server topologically closer to the
skipping to change at page 74, line 5 skipping to change at page 76, line 5
established session about the need for redirecting the session. If established session about the need for redirecting the session. If
an 3rr response is received for an request in relation to a an 3rr response is received for an request in relation to a
established session, the client SHOULD send a TEARDOWN request for 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 the Location header is used in a response it SHALL contain an If the the Location header is used in a response it SHALL 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 SHALL NOT only contain the host name. to, the URI SHALL NOT only contain the host name.
13.3.1. 300 Multiple Choices 15.3.1. 300 Multiple Choices
See [H10.3.1]. See [H10.3.1].
13.3.2. 301 Moved Permanently 15.3.2. 301 Moved Permanently
The request resource are moved permanently and resides now at the URI The request resource are moved permanently and resides now at the URI
given by the location header. The user client SHOULD redirect 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.
13.3.3. 302 Found 15.3.3. 302 Found
The requested resource resides temporarily at the URI given by the The requested resource resides temporarily at the URI given by the
Location header. The Location header MUST be included in the Location header. The Location header MUST be included in the
response. This response is intended to be used for many types of response. This response is intended to be used for many types of
temporary redirects; e.g., load balancing. It is RECOMMENDED that temporary redirects; e.g., load balancing. It is RECOMMENDED that
the server set the reason phrase to something more meaningful than the server set the reason phrase to something more meaningful than
"Found" in these cases. The user client SHOULD redirect "Found" in these cases. The user client SHOULD redirect
automatically to the given URI. This response MUST NOT contain a automatically to the given URI. This response MUST NOT contain a
message-body. message-body.
This example shows a client being redirected to a different server: This example shows a client being redirected to a different server:
C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0 C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2 CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1 Transport: RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2
C->S: RTSP/2.0 302 Try Other Server S->C: RTSP/2.0 302 Try Other Server
CSeq: 2 CSeq: 2
Location: rtsp://s2.example.com:8001/fizzle/foo Location: rtsp://s2.example.com:8001/fizzle/foo
13.3.4. 303 See Other 15.3.4. 303 See Other
This status code SHALL NOT be used in RTSP. However as it was This status code SHALL NOT be used in RTSP. However as it was
allowed to use in RTSP 1.0 (RFC 2326). allowed to use in RTSP 1.0 (RFC 2326).
13.3.5. 304 Not Modified 15.3.5. 304 Not Modified
If the client has performed a conditional DESCRIBE or SETUP (see If the client has performed a conditional DESCRIBE or SETUP (see
Section 14.25) and the requested resource has not been modified, the Section 16.25) and the requested resource has not been modified, the
server SHOULD send a 304 response. This response MUST NOT contain a server SHOULD send a 304 response. This response MUST NOT contain a
message-body. message-body.
The response MUST include the following header fields: The response MUST include the following header fields:
o Date o Date
o ETag and/or Content-Location, if the header(s) would have been o ETag and/or Content-Location, if the header(s) would have been
sent in a 200 response to the same request. sent in a 200 response to the same request.
o Expires, Cache-Control, and/or Vary, if the field-value might o Expires, Cache-Control, and/or Vary, if the field-value might
differ from that sent in any previous response for the same differ from that sent in any previous response for the same
variant. variant.
This response is independent for the DESCRIBE and SETUP requests. This response is independent for the DESCRIBE and SETUP requests.
That is, a 304 response to DESCRIBE does NOT imply that the resource That is, a 304 response to DESCRIBE does NOT imply that the resource
content is unchanged (only the session description) and a 304 content is unchanged (only the session description) and a 304
skipping to change at page 75, line 18 skipping to change at page 77, line 21
differ from that sent in any previous response for the same differ from that sent in any previous response for the same
variant. variant.
This response is independent for the DESCRIBE and SETUP requests. This response is independent for the DESCRIBE and SETUP requests.
That is, a 304 response to DESCRIBE does NOT imply that the resource That is, a 304 response to DESCRIBE does NOT imply that the resource
content is unchanged (only the session description) and a 304 content is unchanged (only the session description) and a 304
response to SETUP does NOT imply that the resource description is response to SETUP does NOT imply that the resource description is
unchanged. The ETag and If-Match headers may be used to link the unchanged. The ETag and If-Match headers may be used to link the
DESCRIBE and SETUP in this manner. DESCRIBE and SETUP in this manner.
13.3.6. 305 Use Proxy 15.3.6. 305 Use Proxy
See [H10.3.6]. See [H10.3.6].
13.4. Client Error 4xx 15.4. Client Error 4xx
13.4.1. 400 Bad Request 15.4.1. 400 Bad Request
The request could not be understood by the server due to malformed The request could not be understood by the server due to malformed
syntax. The client SHOULDNOT repeat the request without syntax. The client SHOULDNOT repeat the request without
modifications [H10.4.1]. If the request does not have a CSeq header, modifications [H10.4.1]. If the request does not have a CSeq header,
the server MUST NOT include a CSeq in the response. the server MUST NOT include a CSeq in the response.
13.4.2. 405 Method Not Allowed 15.4.2. 405 Method Not Allowed
The method specified in the request is not allowed for the resource The method specified in the request is not allowed for the resource
identified by the Request-URI. The response MUST include an Allow identified by the Request-URI. The response MUST include an Allow
header containing a list of valid methods for the requested resource. header containing a list of valid methods for the requested resource.
This status code is also to be used if a request attempts to use a This status code is also to be used if a request attempts to use a
method not indicated during SETUP, e.g., if a RECORD request is method not indicated during SETUP.
issued even though the mode parameter in the Transport header only
specified PLAY.
13.4.3. 451 Parameter Not Understood 15.4.3. 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 entity body containing the offending sender SHOULD return a entity body containing the offending
parameter(s). parameter(s).
13.4.4. 452 reserved 15.4.4. 452 reserved
This error code was removed from RFC 2326 [RFC2326] and is obsolete. This error code was removed from RFC 2326 [RFC2326] and is obsolete.
13.4.5. 453 Not Enough Bandwidth 15.4.5. 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.
13.4.6. 454 Session Not Found 15.4.6. 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.
13.4.7. 455 Method Not Valid in This State 15.4.7. 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 SHALL contain an Allow header to make error state. The response SHALL contain an Allow header to make error
recovery possible. recovery possible.
13.4.8. 456 Header Field Not Valid for Resource 15.4.8. 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 SHALL be returned to inform the client of the Accept-Ranges header SHALL be returned to inform the client of
which format(s) that are allowed. which format(s) that are allowed.
13.4.9. 457 Invalid Range 15.4.9. 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.
13.4.10. 458 Parameter Is Read-Only 15.4.10. 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 entity body containing the offending parameter(s). a entity body containing the offending parameter(s).
13.4.11. 459 Aggregate Operation Not Allowed 15.4.11. 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.
13.4.12. 460 Only Aggregate Operation Allowed 15.4.12. 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.
13.4.13. 461 Unsupported Transport 15.4.13. 461 Unsupported Transport
The Transport field did not contain a supported transport The Transport field did not contain a supported transport
specification. specification.
13.4.14. 462 Destination Unreachable 15.4.14. 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.
13.4.15. 463 Destination Prohibited 15.4.15. 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.
13.4.16. 464 Data Transport Not Ready Yet 15.4.16. 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 entity still expects ready for carrying data. However the responding entity still expects
that the data transmission channel will be established at this point that the data transmission channel will be established at this point
in time. Note however that this may result in a permanent failure in time. Note however that this may result in a permanent failure
like 462 "Destination Unreachable". like 462 "Destination Unreachable".
An example when this error may occur is in the case a client sends a An example when this error may occur is in the case a client sends a
PLAY request to a server prior to ensuring that the TCP connections PLAY request to a server prior to ensuring that the TCP connections
negotiated for carrying media data was successful established (In negotiated for carrying media data was successful 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.
13.4.17. 470 Connection Authorization Required 15.4.17. 470 Connection Authorization Required
The secured connection attempt need user or client authorization The secured connection attempt need user or client authorization
before proceeding. The next hops certificate is included in this before proceeding. The next hops certificate is included in this
response in the Accept-Credentials header. response in the Accept-Credentials header.
13.4.18. 471 Connection Credentials not accepted 15.4.18. 471 Connection Credentials not accepted
When performing a secure connection over multiple connections, a When performing a secure connection over multiple connections, a
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.
13.5. Server Error 5xx 15.4.19. 472 Failure to establish secure connection
13.5.1. 551 Option not supported 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
handshake, for example due to server not accepting any cipher suits.
15.5. Server Error 5xx
15.5.1. 551 Option not supported
A feature-tag given in the Require or the Proxy-Require fields was A feature-tag given in the Require or the Proxy-Require fields was
not supported. The Unsupported header SHALL be returned stating the not supported. The Unsupported header SHALL be returned stating the
feature for which there is no support. feature for which there is no support.
14. Header Field Definitions 16. Header Field Definitions
+--------------+----------------+--------+---------+------+ +---------------+----------------+--------+---------+------+
| method | direction | object | acronym | Body | | method | direction | object | acronym | Body |
+--------------+----------------+--------+---------+------+ +---------------+----------------+--------+---------+------+
| DESCRIBE | C -> S | P,S | DES | r | | DESCRIBE | C -> S | P,S | DES | r |
| | | | | | | | | | | |
| GETPARAMETER | C -> S, S -> C | P,S | GPR | R,r | | GET_PARAMETER | C -> S, S -> C | P,S | GPR | R,r |
| | | | | | | | | | | |
| OPTIONS | C -> S | P,S | OPT | | | OPTIONS | C -> S | P,S | OPT | |
| | | | | | | | | | | |
| | S -> C | | | | | | S -> C | | | |
| | | | | | | | | | | |
| PAUSE | C -> S | P,S | PSE | | | PAUSE | C -> S | P,S | PSE | |
| | | | | | | | | | | |
| PLAY | C -> S | P,S | PLY | | | PLAY | C -> S | P,S | PLY | |
| | | | | | | | | | | |
| REDIRECT | S -> C | P,S | RDR | | | REDIRECT | S -> C | P,S | RDR | |
| | | | | | | | | | | |
| SETUP | C -> S | S | STP | | | SETUP | C -> S | S | STP | |
| | | | | | | | | | | |
| SETPARAMETER | C -> S, S -> C | P,S | SPR | R,r | | SETPARAMETER | C -> S, S -> C | P,S | SPR | R,r |
| | | | | | | | | | | |
| TEARDOWN | C -> S | P,S | TRD | | | TEARDOWN | C -> S | P,S | TRD | |
+--------------+----------------+--------+---------+------+ +---------------+----------------+--------+---------+------+
Table 8: Overview of RTSP methods, their direction, and what objects Table 8: Overview of RTSP methods, their direction, and what objects
(P: presentation, S: stream) they operate on. Body notes if a method (P: presentation, S: stream) they operate on. Body notes if a method
is allowed to carry body and in which direction, R = Request, is allowed to carry body and in which direction, R = Request,
r=response. Note: It is allowed for all error messages 4xx and 5xx to r=response. Note: It is allowed for all error messages 4xx and 5xx to
have a body have a body
The general syntax for header fields is covered in Section The general syntax for header fields is covered in Section 5.2. This
Section 4.2 This section lists the full set of header fields along section lists the full set of header fields along with notes on
with notes on meaning, and usage. The syntax definition for header meaning, and usage. The syntax definition for header fields are
fields are present in section Section 19.2.3. Throughout this present in Section 21.2.3. Throughout this section, we use [HX.Y] to
section, we use [HX.Y] to refer to Section X.Y of the current refer to Section X.Y of the current HTTP/1.1 specification RFC 2616
HTTP/1.1 specification RFC 2616 [RFC2616]. Examples of each header [RFC2616]. Examples of each header field are given.
field are given.
Information about header fields in relation to methods and proxy Information about header fields in relation to methods and proxy
processing is summarized in Table 9, Table 10, Table 11, and processing is summarized in Table 9, Table 10, Table 11, and
Table 12. Table 12.
The "where" column describes the request and response types in which The "where" column describes the request and response types in which
the header field can be used. Values in this column are: the header field can be used. Values in this column are:
R: header field may only appear in requests; R: header field may only appear in requests;
skipping to change at page 80, line 46 skipping to change at page 82, line 46
context of the message. context of the message.
m: The header field is mandatory. m: The header field is mandatory.
m*: The header field SHOULD be sent, but clients/servers need to be m*: The header field SHOULD be sent, but clients/servers need to be
prepared to receive messages without that header field. prepared to receive messages without that header field.
o: The header field is optional. o: The header field is optional.
*: The header field is SHALL be present if the message body is not *: The header field is SHALL be present if the message body is not
empty. See Section 14.16, Section 14.18 and Section 4.3 for empty. See Section 16.16, Section 16.18 and Section 5.3 for
details. details.
-: The header field is not applicable. -: The header field is not applicable.
"Optional" means that a Client/Server MAY include the header field in "Optional" means that a Client/Server MAY include the header field in
a request or response. The Client/Server behavior when receiving a request or response. The Client/Server behavior when receiving
such headers varies, for some it may ignore the header field, in such headers varies, for some it may ignore the header field, in
other case it is request to process the header. This is regulated by other case it is request to process the header. This is regulated by
the method and header descriptions. Example of such headers that the method and header descriptions. Example of such 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 14.37 and Section 14.31. A "mandatory" header discussed in Section 16.38 and Section 16.32. A "mandatory" header
field MUST be present in a request, and MUST be understood by the field MUST be present in a request, and MUST be understood by the
Client/Server receiving the request. A mandatory response header Client/Server receiving the request. A mandatory response header
field MUST be present in the response, and the header field MUST be field MUST be present in the response, and the header field MUST be
understood by the Client/Server processing the response. "Not understood by the Client/Server processing the response. "Not
applicable" means that the header field MUST NOT be present in a applicable" means that the header field MUST NOT be present in a
request. If one is placed in a request by mistake, it MUST be request. If one is placed in a request by mistake, it MUST be
ignored by the Client/Server receiving the request. Similarly, a ignored by the Client/Server receiving the request. Similarly, a
header field labeled "not applicable" for a response means that the header field labeled "not applicable" for a response means that the
Client/Server MUST NOT place the header field in the response, and Client/Server MUST NOT place the header field in the response, and
the Client/Server MUST ignore the header field in the response. the Client/Server MUST ignore the header field in the response.
skipping to change at page 83, line 36 skipping to change at page 85, line 36
| Location | 3rr | | o | o | o | o | o | o | | Location | 3rr | | o | o | o | o | o | o |
+----------------+------+-----+-----+-----+------+-----+------+-----+ +----------------+------+-----+-----+-----+------+-----+------+-----+
Table 9: Overview of RTSP header fields (A-L) related to methods Table 9: Overview of RTSP header fields (A-L) related to methods
DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.
+------------+-------+------+----+-----+-------+------+-------+-----+ +------------+-------+------+----+-----+-------+------+-------+-----+
| Header | Where | Prox | DE | OPT | SETUP | PLAY | PAUSE | TRD | | Header | Where | Prox | DE | OPT | SETUP | PLAY | PAUSE | TRD |
| | | y | S | | | | | | | | | y | S | | | | | |
+------------+-------+------+----+-----+-------+------+-------+-----+ +------------+-------+------+----+-----+-------+------+-------+-----+
| Pipelined- | | amdr | - | o | o | o | o | o |
| Requests | | | | | | | | |
| | | | | | | | | |
| Proxy- | 407 | amr | m | m | m | m | m | m | | Proxy- | 407 | amr | m | m | m | m | m | m |
| Authentica | | | | | | | | | | Authentica | | | | | | | | |
| te | | | | | | | | | | te | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Proxy- | R | rd | o | o | o | o | o | o | | Proxy- | R | rd | o | o | o | o | o | o |
| Authorizat | | | | | | | | | | Authorizat | | | | | | | | |
| ion | | | | | | | | | | ion | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Proxy- | R | ar | o | o | o | o | o | o | | Proxy- | R | ar | o | o | o | o | o | o |
| Require | | | | | | | | | | Require | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Proxy- | r | r | c | c | c | c | c | c | | Proxy- | r | r | c | c | c | c | c | c |
| Require | | | | | | | | | | Require | | | | | | | | |
| | | | | | | | | |
| Proxy- | R | amr | c | c | c | c | c | c | | Proxy- | R | amr | c | c | c | c | c | c |
| Supported | | | | | | | | | | Supported | | | | | | | | |
| | | | | | | | | |
| Proxy- | r | | c | c | c | c | c | c | | Proxy- | r | | c | c | c | c | c | c |
| Supported | | | | | | | | | | Supported | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Public | r | admr | - | m | - | - | - | - | | Public | r | admr | - | m | - | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Public | 501 | admr | m | m | m | m | m | m | | Public | 501 | admr | m | m | m | m | m | m |
| | | | | | | | | | | | | | | | | | | |
| Range | R | | - | - | - | o | - | - | | Range | R | | - | - | - | o | - | - |
| | | | | | | | | | | | | | | | | | | |
| Range | r | | - | - | c | m | m | - | | Range | r | | - | - | c | m | m | - |
| | | | | | | | | | | | | | | | | | | |
| Referer | R | | o | o | o | o | o | o | | Referer | R | | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Require | R | | o | o | o | o | o | o | | Require | R | | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Retry-Afte | 3rr,5 | | o | o | o | - | - | - | | Retry-Afte | 3rr,5 | | o | o | o | - | - | - |
| r | 03 | | | | | | | | | r | 03 | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| RTP-Info | r | | - | - | o | c | - | - | | RTP-Info | r | | - | - | c | c | - | - |
| | | | | | | | | | | | | | | | | | | |
| Scale | | | - | - | - | o | - | - | | Scale | | | - | - | - | o | - | - |
| | | | | | | | | | | | | | | | | | | |
| Session | R | r | - | o | o | m | m | m | | Session | R | r | - | o | o | m | m | m |
| | | | | | | | | | | | | | | | | | | |
| Session | r | r | - | c | m | m | m | o | | Session | r | r | - | c | m | m | m | o |
| | | | | | | | | | | | | | | | | | | |
| Server | R | r | - | o | - | - | - | - | | Server | R | r | - | o | - | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Server | r | r | o | o | o | o | o | o | | Server | r | r | o | o | o | o | o | o |
skipping to change at page 85, line 4 skipping to change at page 87, line 7
| Timestamp | c | admr | m | m | m | m | m | m | | Timestamp | c | admr | m | m | m | m | m | m |
| | | | | | | | | | | | | | | | | | | |
| Transport | | amr | - | - | m | - | - | - | | Transport | | amr | - | - | m | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Unsupporte | r | | c | c | c | c | c | c | | Unsupporte | r | | c | c | c | c | c | c |
| d | | | | | | | | | | d | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| User-Agent | R | | m* | m* | m* | m* | m* | m* | | User-Agent | R | | m* | m* | m* | m* | m* | m* |
| | | | | | | | | | | | | | | | | | | |
| Vary | r | | c | c | c | c | c | c | | Vary | r | | c | c | c | c | c | c |
| | | | | | | | | |
| Via | R | amr | o | o | o | o | o | o | | Via | R | amr | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Via | c | dr | m | m | m | m | m | m | | Via | c | dr | m | m | m | m | m | m |
| | | | | | | | | | | | | | | | | | | |
| WWW- | 401 | | m | m | m | m | m | m | | WWW- | 401 | | m | m | m | m | m | m |
| Authentica | | | | | | | | | | Authentica | | | | | | | | |
| te | | | | | | | | | | te | | | | | | | | |
+------------+-------+------+----+-----+-------+------+-------+-----+ +------------+-------+------+----+-----+-------+------+-------+-----+
Table 10: Overview of RTSP header fields (P-W) related to methods Table 10: Overview of RTSP header fields (P-W) related to methods
skipping to change at page 85, line 48 skipping to change at page 88, line 4
| | | | | | | | | | | | | |
| Content-Encoding | R | r | o | o | - | | Content-Encoding | R | r | o | o | - |
| | | | | | | | | | | | | |
| Content-Encoding | r | r | o | o | - | | Content-Encoding | r | r | o | o | - |
| | | | | | | | | | | | | |
| Content-Encoding | 4xx,5xx | r | o | o | o | | Content-Encoding | 4xx,5xx | r | o | o | o |
| | | | | | | | | | | | | |
| Content-Language | R | r | o | o | - | | Content-Language | R | r | o | o | - |
| | | | | | | | | | | | | |
| Content-Language | r | r | o | o | - | | Content-Language | r | r | o | o | - |
| | | | | | |
| Content-Language | 4xx,5xx | r | o | o | o | | Content-Language | 4xx,5xx | r | o | o | o |
| | | | | | | | | | | | | |
| Content-Length | R | r | * | * | - | | Content-Length | R | r | * | * | - |
| | | | | | |
| Content-Length | r | r | * | * | - | | Content-Length | r | r | * | * | - |
| | | | | | | | | | | | | |
| Content-Length | 4xx,5xx | r | * | * | * | | Content-Length | 4xx,5xx | r | * | * | * |
| | | | | | | | | | | | | |
| Content-Location | R | | o | o | - | | Content-Location | R | | o | o | - |
| | | | | | | | | | | | | |
| Content-Location | r | | o | o | - | | Content-Location | r | | o | o | - |
| | | | | | | | | | | | | |
| Content-Location | 4xx,5xx | | o | o | o | | Content-Location | 4xx,5xx | | o | o | o |
| | | | | | | | | | | | | |
skipping to change at page 86, line 36 skipping to change at page 88, line 40
| From | R | r | o | o | o | | From | R | r | o | o | o |
| | | | | | | | | | | | | |
| Last-Modified | R | r | - | - | - | | Last-Modified | R | r | - | - | - |
| | | | | | | | | | | | | |
| Last-Modified | r | r | o | - | - | | Last-Modified | r | r | o | - | - |
| | | | | | | | | | | | | |
| Location | 3rr | | o | o | o | | Location | 3rr | | o | o | o |
| | | | | | | | | | | | | |
| Location | R | | - | - | m | | Location | R | | - | - | m |
| | | | | | | | | | | | | |
| Pipelined-Requests | | amdr | o | o | o |
| | | | | | |
| Proxy-Authenticate | 407 | amr | m | m | m | | Proxy-Authenticate | 407 | amr | m | m | m |
| | | | | | | | | | | | | |
| Proxy-Authorization | R | rd | o | o | o | | Proxy-Authorization | R | rd | o | o | o |
| | | | | | | | | | | | | |
| Proxy-Require | R | ar | o | o | o | | Proxy-Require | R | ar | o | o | o |
| | | | | | | | | | | | | |
| Proxy-Require | r | r | c | c | c | | Proxy-Require | r | r | c | c | c |
| | | | | | | | | | | | | |
| Proxy-Supported | R | amr | c | c | c | | Proxy-Supported | R | amr | c | c | c |
| | | | | | | | | | | | | |
skipping to change at page 87, line 46 skipping to change at page 90, line 4
| | | | | | | | | | | | | |
| User-Agent | R | r | m* | m* | - | | User-Agent | R | r | m* | m* | - |
| | | | | | | | | | | | | |
| User-Agent | r | r | - | - | m* | | User-Agent | r | r | - | - | m* |
| | | | | | | | | | | | | |
| Vary | r | | c | c | - | | Vary | r | | c | c | - |
| | | | | | | | | | | | | |
| Via | R | amr | o | o | o | | Via | R | amr | o | o | o |
| | | | | | | | | | | | | |
| Via | c | dr | m | m | m | | Via | c | dr | m | m | m |
| | | | | | |
| WWW-Authenticate | 401 | | m | m | m | | WWW-Authenticate | 401 | | m | m | m |
+------------------+---------+-------+-----+-----+-----+ +------------------+---------+-------+-----+-----+-----+
Table 12: Overview of RTSP header fields (R-W) related to methods Table 12: Overview of RTSP header fields (R-W) related to methods
GETPARAMETER, SETPARAMETER, and REDIRECT. GETPARAMETER, SETPARAMETER, and REDIRECT.
14.1. Accept 16.1. Accept
The Accept request-header field can be used to specify certain The Accept request-header field can be used to specify certain
presentation description content types which are acceptable for the presentation description content types which are acceptable for the
response. response.
See [H14.1] for syntax. See [H14.1] for syntax.
Example of use: Example of use:
Accept: application/example q=1.0, application/sdp Accept: application/example q=1.0, application/sdp
14.2. Accept-Credentials 16.2. Accept-Credentials
The Accept-Credentials header is a request header used to indicate to The Accept-Credentials header is a request header used to indicate to
any trusted intermediary how to handle further secured connections to any trusted intermediary how to handle further secured connections to
proxies or servers. See Section Section 18 for the usage of this proxies or servers. See Section 20 for the usage of this header. It
header. It SHALL NOT be included in server to client requests. SHALL NOT be included in server to client requests.
In a request the header SHALL contain the method (User, Proxy, or In a request the header SHALL contain the method (User, Proxy, or
Any) for approving credentials selected by the requestor. The method Any) for approving credentials selected by the requestor. The method
SHALL NOT be changed by any proxy. If the method is "User" the SHALL NOT be changed by any proxy, unless it is "proxy" when a proxy
header contains zero or more of credentials that the client accept. MAY change it to "user" to take the role of user approving each
The header may contain zero credentials in the first RTSP request to further hop. If the method is "User" the header contains zero or
a RTSP server when using the "User" method. This as the client has more of credentials that the client accept. The header may contain
not yet received any credentials to accept. Each credential SHALL zero credentials in the first RTSP request to a RTSP server when
consist of one URI identifying the proxy or server, the hash using the "User" method. This as the client has not yet received any
algorithm identifier, and the hash over that entity's DER encoded credentials to accept. Each credential SHALL consist of one URI
certificate [RFC3280]"/> in Base64. All RTSP clients and proxies identifying the proxy or server, the hash algorithm identifier, and
SHALL implement the SHA-1[FIPS-pub-180-1] algorithm for computation the hash over that entity's DER encoded certificate [RFC3280] in
of the hash of the DER encoded certificate. The SHA-1 algorithm is Base64 [RFC4648]. All RTSP clients and proxies SHALL implement the
identified by the token "sha-1". SHA-256[FIPS-pub-180-2] 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. for this purpose is intended to be extremely limited. A feature tag
can be used to ensure that support for the replacement algorithm
exist.
Example: Example:
Accept-Credentials:User, Accept-Credentials:User
"rtsps://proxy2.example.com/";sha-1;exaIl9VMbQMOFGClx5rXnPJKVNI=, "rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=,
"rtsps://server.example.com/";sha-1;lurbjj5khhB0NhIuOXtt4bBRH1M= "rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M=
14.3. Accept-Encoding 16.3. Accept-Encoding
See [H14.3]. See [H14.3].
14.4. Accept-Language 16.4. Accept-Language
See [H14.4]. Note that the language specified applies to the See [H14.4]. Note that the language specified applies to the
presentation description and any reason phrases, not the media presentation description and any reason phrases, not the media
content. content.
14.5. Accept-Ranges 16.5. Accept-Ranges
The Accept-Ranges request and response-header field allows indication The Accept-Ranges request and response-header field allows indication
of the format supported in the Range header. The client SHALL of the format supported in the Range header. The client SHALL
include the header in SETUP requests to indicate which formats it include the header in SETUP requests to indicate which formats it
support to receive in PLAY and PAUSE responses, and REDIRECT support to receive in PLAY and PAUSE responses, and REDIRECT
requests. The server SHALL include the header in SETUP and 456 error requests. The server SHALL include the header in SETUP and 456 error
responses to indicate the formats supported for the resource responses to indicate the formats supported for the resource
indicated by the request URI. indicated by the request URI.
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
This header has the same syntax as [H14.5] and the syntax is defined This header has the same syntax as [H14.5] and the syntax is defined
in Section 19.2.3. However, new range-units are defined. in Section 21.2.3. However, new range-units are defined.
14.6. Allow 16.6. Allow
The Allow entity-header field lists the methods supported by the The Allow entity-header field lists the methods supported by the
resource identified by the Request-URI. The purpose of this field is resource identified by the Request-URI. The purpose of this field is
to strictly inform the recipient of valid methods associated with the to strictly inform the recipient of valid methods associated with the
resource. An Allow header field MUST be present in a 405 (Method Not resource. An Allow header field MUST be present in a 405 (Method Not
Allowed) response. See [H14.7] for syntax definition. The Allow Allowed) response. See [H14.7] for syntax definition. The Allow
header MUST also be present in all OPTIONS responses where the header MUST also be present in all OPTIONS responses where the
content of the header will not include exactly the same methods as content of the header will not include exactly the same methods as
listed in the Public header. listed in the Public header.
The Allow SHALL also be included in SETUP and DESCRIBE responses, if The Allow SHALL also be included in SETUP and DESCRIBE responses, if
the methods allowed for the resource is different than the minimal the methods allowed for the resource is different than the minimal
implementation set. implementation set.
Example of use: Example of use:
Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE
14.7. Authorization 16.7. Authorization
See [H14.8]. See [H14.8].
14.8. Bandwidth 16.8. Bandwidth
The Bandwidth request-header field describes the estimated bandwidth The Bandwidth request-header field describes the estimated bandwidth
available to the client, expressed as a positive integer and measured available to the client, expressed as a positive integer and measured
in bits per second. The bandwidth available to the client may change in bits per second. The bandwidth available to the client may change
during an RTSP session, e.g., due to mobility, congestion, etc. during an RTSP session, e.g., due to mobility, congestion, etc.
Example: Example:
Bandwidth: 62360 Bandwidth: 62360
14.9. Blocksize 16.9. Blocksize
The Blocksize request-header field is sent from the client to the The Blocksize request-header field is sent from the client to the
media server asking the server for a particular media packet size. media server asking the server for a particular media packet size.
This packet size does not include lower-layer headers such as IP, This packet size does not include lower-layer headers such as IP,
UDP, or RTP. The server is free to use a blocksize which is lower UDP, or RTP. The server is free to use a blocksize which is lower
than the one requested. The server MAY truncate this packet size to than the one requested. The server MAY truncate this packet size to
the closest multiple of the minimum, media-specific block size, or the closest multiple of the minimum, media-specific block size, or
override it with the media-specific size if necessary. The block override it with the media-specific size if necessary. The block
size MUST be a positive decimal number, measured in octets. The size MUST be a positive decimal number, measured in octets. The
server only returns an error (4xx) if the value is syntactically server only returns an error (4xx) if the value is syntactically
invalid. invalid.
14.10. Cache-Control 16.10. Cache-Control
The Cache-Control general-header field is used to specify directives The Cache-Control general-header field is used to specify directives
that MUST be obeyed by all caching mechanisms along the request/ that MUST be obeyed by all caching mechanisms along the request/
response chain. response chain.
Cache directives MUST be passed through by a proxy or gateway Cache directives MUST be passed through by a proxy or gateway
application, regardless of their significance to that application, application, regardless of their significance to that application,
since the directives may be applicable to all recipients along the since the directives may be applicable to all recipients along the
request/response chain. It is not possible to specify a cache- request/response chain. It is not possible to specify a cache-
directive for a specific cache. directive for a specific cache.
Cache-Control should only be specified in a SETUP request and its Cache-Control should only be specified in a SETUP request and its
response. Note: Cache-Control does em not govern the caching of response. Note: Cache-Control does em not govern the caching of
responses as for HTTP, instead it applies to the media stream responses as for HTTP, instead it applies to the media stream
identified by the SETUP request. The RTSP requests are generally not identified by the SETUP request. The RTSP requests are generally not
cacheable, for further information see section Section 16. Below is cacheable, for further information see Section 18. Below is the
the description of the cache directives that can be included in the description of the cache directives that can be included in the
Cache-Control header. Cache-Control header.
no-cache: Indicates that the media stream MUST NOT be cached no-cache: Indicates that the media stream MUST NOT be cached
anywhere. This allows an origin server to prevent caching even anywhere. This allows an origin server to prevent caching even
by caches that have been configured to return stale responses by caches that have been configured to return stale responses
to client requests. to client requests. Note, there are no security function
enforcing that the content can't be cached.
public: Indicates that the media stream is cacheable by any cache. public: Indicates that the media stream is cacheable by any cache.
private: Indicates that the media stream is intended for a single private: Indicates that the media stream is intended for a single
user and MUST NOT be cached by a shared cache. A private (non- user and MUST NOT be cached by a shared cache. A private (non-
shared) cache may cache the media streams. shared) cache may cache the media streams.
no-transform: An intermediate cache (proxy) may find it useful to no-transform: An intermediate cache (proxy) may find it useful to
convert the media type of a certain stream. A proxy might, for convert the media type of a certain stream. A proxy might, for
example, convert between video formats to save cache space or example, convert between video formats to save cache space or
skipping to change at page 93, line 5 skipping to change at page 95, line 5
making its request. If the server replies with 304 (Not Modified), making its request. If the server replies with 304 (Not Modified),
then the cache can return its now validated copy to the client with a then the cache can return its now validated copy to the client with a
200 (OK) response. If the server replies with a new entity and cache 200 (OK) response. If the server replies with a new entity and cache
validator, however, the intermediate cache can compare the returned validator, however, the intermediate cache can compare the returned
validator with the one provided in the client's request, using the validator with the one provided in the client's request, using the
strong comparison function. If the client's validator is equal to strong comparison function. If the client's validator is equal to
the origin server's, then the intermediate cache simply returns 304 the origin server's, then the intermediate cache simply returns 304
(Not Modified). Otherwise, it returns the new entity with a 200 (OK) (Not Modified). Otherwise, it returns the new entity with a 200 (OK)
response. response.
14.11. Connection 16.11. Connection
See [H14.10]. The use of the connection option "close" in RTSP See [H14.10]. The use of the connection option "close" in RTSP
messages SHOULD be limited to error messages when the server is messages SHOULD be limited to error messages when the server is
unable to recover and therefore see it necessary to close the unable to recover and therefore see it necessary to close the
connection. The reason is that the client has the choice of connection. The reason is that the client has the choice of
continuing using a connection indefinitely, as long as it sends valid continuing using a connection indefinitely, as long as it sends valid
messages. messages.
14.12. Connection-Credentials 16.12. Connection-Credentials
The Connection-Credentials response header is used to carry the The Connection-Credentials response header is used to carry the chain
credentials of any next hop that need to be approved by the of credentials of any next hop that need to be approved by the
requestor. It SHALL only be used in server to client responses. requestor. It SHALL only be used in server to client responses.
The Connection-Credentials header in an RTSP response SHALL, if The Connection-Credentials header in an RTSP response SHALL, if
included, contain the credentials information of the next hop that an included, contain the credential information (in form of a list of
intermediary needs to securely connect to. The credential MUST certificates providing the chain of certification) of the next hop
include the URI of the next proxy or server and the DER encoded that an intermediary needs to securely connect to. The header MUST
X.509v3[RFC3280] certificate in base64 [RFC3548]. include the URI of the next hop (proxy or server) and a base64
[RFC4648] encoded binary structure containg a sequence of DER encoded
X.509v3 certificates[RFC3280] .
The binary structure starts with the number of certificates
(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
octets of each DER encoded certificate. This is followed by NR_CERTS
number of DER encoded X.509v3 certificates in a sequence (chain).
The proxy or server's certificate must come first in the structure.
Each following certificate must directly certify the one preceding
it. Because certificate validation requires that root keys be
distributed independently, the self-signed certificate which
specifies the root certificate authority may optionally be omitted
from the chain, under the assumption that the remote end must already
possess it in order to validate it in any case.
Example: Example:
Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC... Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC...
14.13. Content-Base Where MIIDNTCC... is a BASE64 encoding of the following structure:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of certifcates | Size of certificate #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size of certificate #2 | Size of certificate #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DER Encoding of Certificate #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DER Encoding of Certificate #2 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DER Encoding of Certificate #3 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16.13. Content-Base
The Content-Base entity-header field may be used to specify the base The Content-Base entity-header field may be used to specify the base
URI for resolving relative URIs within the entity. URI for resolving relative URIs within the entity.
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 entity is If no Content-Base field is present, the base URI of an entity is
defined either by its Content-Location (if that Content-Location URI defined either by its Content-Location (if that Content-Location URI
is an absolute URI) or the URI used to initiate the request, in that 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 order of precedence. Note, however, that the base URI of the
contents within the entity-body may be redefined within that entity- contents within the entity-body may be redefined within that entity-
body. body.
14.14. Content-Encoding 16.14. Content-Encoding
See [H14.11]. See [H14.11].
14.15. Content-Language 16.15. Content-Language
See [H14.12]. See [H14.12].
14.16. Content-Length 16.16. Content-Length
The Content-Length general-header field contains the length of the The Content-Length general-header field contains the length of the
body (entity) of the message (i.e. after the double CRLF following body (entity) of the message (i.e. after the double CRLF following
the last header). Unlike HTTP, it MUST be included in all messages the last header). Unlike HTTP, it MUST be included in all messages
that carry body beyond the header portion of the message. If it is that carry body beyond the header portion of the message. If it is
missing, a default value of zero is assumed. It is interpreted missing, a default value of zero is assumed. It is interpreted
according to [H14.13]. according to [H14.13].
14.17. Content-Location 16.17. Content-Location
See [H14.14]. See [H14.14].
14.18. Content-Type 16.18. Content-Type
See [H14.17]. Note that the content types suitable for RTSP are See [H14.17]. Note that the content types suitable for RTSP are
likely to be restricted in practice to presentation descriptions and likely to be restricted in practice to presentation descriptions and
parameter-value types. parameter-value types.
14.19. CSeq 16.19. CSeq
The CSeq general-header field specifies the sequence number for an The CSeq general-header field specifies the sequence number for an
RTSP request-response pair. This field MUST be present in all RTSP request-response pair. This field MUST be present in all
requests and responses. For every RTSP request containing the given requests and responses. For every RTSP request containing the given
sequence number, the corresponding response will have the same sequence number, the corresponding response will have the same
number. Any retransmitted request MUST contain the same sequence number. Any retransmitted request MUST contain the same sequence
number as the original (i.e. the sequence number is em not number as the original (i.e. the sequence number is em not
incremented for retransmissions of the same request). For each new incremented for retransmissions of the same request). For each new
RTSP request the CSeq value SHALL be incremented by one. The initial RTSP request the CSeq value SHALL be incremented by one. The initial
sequence number MAY be any number, however it is RECOMMENDED to start sequence number MAY be any number, however it is RECOMMENDED to start
skipping to change at page 94, line 48 skipping to change at page 97, line 39
Each requester and responder is identified with its network address. Each requester and responder is identified with its network address.
Proxies that aggregate several sessions on the same transport will Proxies that aggregate several sessions on the same transport will
regularly need to renumber the CSeq header field in requests and regularly need to renumber the CSeq header field in requests and
responses to fulfill the rules for the header. responses to fulfill the rules for the header.
Example: Example:
CSeq: 239 CSeq: 239
14.20. Date 16.20. Date
See [H14.18]. An RTSP message containing a body MUST include a Date See [H14.18]. An RTSP message containing a body MUST include a Date
header if the sending host has a clock. Servers SHOULD include a header if the sending host has a clock. Servers SHOULD include a
Date header in all other RTSP messages. Date header in all other RTSP messages.
14.21. ETag 16.21. ETag
The ETag response header MAY be included in DESCRIBE or SETUP The ETag response header MAY be included in DESCRIBE or SETUP
responses. The entity tags (Section 3.8) returned in a DESCRIBE responses. The entity tags (Section 4.8) returned in a DESCRIBE
response, and the one in SETUP refers to the presentation, i.e. both response, and the one in SETUP refers to the presentation, i.e. both
the returned session description and the media stream. This allows the returned session description and the media stream. This allows
for verification that one has the right session description to a for verification that one has the right session description to a
media resource at the time of the SETUP request. However it has the media resource at the time of the SETUP request. However it has the
disadvantage that a change in any of the parts results in disadvantage that a change in any of the parts results in
invalidation of all the parts. invalidation of all the parts.
If the ETag is provided both inside the entity, e.g. within the If the ETag is provided both inside the entity, e.g. within the
"a=etag" attribute in SDP, and in the response message, then both "a=etag" attribute in SDP, and in the response message, then both
tags SHALL be identical. It is RECOMMENDED that the ETag is tags SHALL be identical. It is RECOMMENDED that the ETag is
primarily given in the RTSP response message, to ensure that caches primarily given in the RTSP response message, to ensure that caches
can use the ETag without requiring content inspection. However for can use the ETag without requiring content inspection. However for
session descriptions that are distributed outside of RTSP, for session descriptions that are distributed outside of RTSP, for
example using HTTP, etc. it will be necessary to include the entity example using HTTP, etc. it will be necessary to include the entity
tag in the session description as specified in Appendix C.1.9. tag in the session description as specified in Appendix C.1.9.
SETUP and DESCRIBE requests can be made conditional upon the ETag SETUP and DESCRIBE requests can be made conditional upon the ETag
using the headers If-Match (Section Section 14.24) and If-None-Match using the headers If-Match (Section 16.24) and If-None-Match (
( Section 14.26). Section 16.26).
14.22. Expires 16.22. Expires
The Expires entity-header field gives a date and time after which the The Expires entity-header field gives a date and time after which the
description or media-stream should be considered stale. The description or media-stream should be considered stale. The
interpretation depends on the method: interpretation depends on the method:
DESCRIBE response: The Expires header indicates a date and time DESCRIBE response: The Expires header indicates a date and time
after which the presentation description (body) SHOULD be after which the presentation description (body) SHOULD be
considered stale. considered stale.
SETUP response: The Expires header indicate a date and time after SETUP response: The Expires header indicate a date and time after
which the media stream SHOULD be considered stale. which the media stream SHOULD be considered stale.
A stale cache entry may not normally be returned by a cache (either a A stale cache entry may not normally be returned by a cache (either a
proxy cache or an user agent cache) unless it is first validated with proxy cache or an user agent cache) unless it is first validated with
the origin server (or with an intermediate cache that has a fresh the origin server (or with an intermediate cache that has a fresh
copy of the entity). See Section 16 for further discussion of the copy of the entity). See Section 18 for further discussion of the
expiration model. expiration model.
The presence of an Expires field does not imply that the original The presence of an Expires field does not imply that the original
resource will change or cease to exist at, before, or after that resource will change or cease to exist at, before, or after that
time. time.
The format is an absolute date and time as defined by HTTP-date in The format is an absolute date and time as defined by HTTP-date in
[H3.3]; it MUST be in RFC1123-date format: [H3.3]; it MUST be in RFC1123-date format:
An example of its use is An example of its use is
skipping to change at page 96, line 24 skipping to change at page 99, line 16
To mark a response as "already expired," an origin server should use To mark a response as "already expired," an origin server should use
an Expires date that is equal to the Date header value. To mark a an Expires date that is equal to the Date header value. To mark a
response as "never expires," an origin server SHOULD use an Expires response as "never expires," an origin server SHOULD use an Expires
date approximately one year from the time the response is sent. date approximately one year from the time the response is sent.
RTSP/2.0 servers SHOULDNOT send Expires dates more than one year in RTSP/2.0 servers SHOULDNOT send Expires dates more than one year in
the future. the future.
The presence of an Expires header field with a date value of some The presence of an Expires header field with a date value of some
time in the future on a media stream that otherwise would by default time in the future on a media stream that otherwise would by default
be non-cacheable indicates that the media stream is cacheable, unless be non-cacheable indicates that the media stream is cacheable, unless
indicated otherwise by a Cache-Control header field (Section indicated otherwise by a Cache-Control header field (Section 16.10).
Section 14.10).
14.23. From 16.23. From
See [H14.22]. See [H14.22].
14.24. If-Match 16.24. If-Match
See [H14.24]. See [H14.24].
The If-Match request-header field is especially useful for ensuring The If-Match request-header field is especially useful for ensuring
the integrity of the presentation description, in both the case where the integrity of the presentation description, in both the case where
it is fetched via means external to RTSP (such as HTTP), or in the it is fetched via means external to RTSP (such as HTTP), or in the
case where the server implementation is guaranteeing the integrity of case where the server implementation is guaranteeing the integrity of
the description between the time of the DESCRIBE message and the the description between the time of the DESCRIBE message and the
SETUP message. By including the ETag given in or with the session SETUP message. By including the ETag given in or with the session
description in a SETUP request, the client ensures that resources set description in a SETUP request, the client ensures that resources set
up are matching the description. A SETUP request for which the ETag up are matching the description. A SETUP request for which the ETag
validation check fails, SHALL responde using 412 (Precondition validation check fails, SHALL responde using 412 (Precondition
Failed). Failed).
This validation check is also very useful if a session has been This validation check is also very useful if a session has been
redirected from one server to another. redirected from one server to another.
14.25. If-Modified-Since 16.25. If-Modified-Since
The If-Modified-Since request-header field is used with the DESCRIBE The If-Modified-Since request-header field is used with the DESCRIBE
and SETUP methods to make them conditional. If the requested variant and SETUP methods to make them conditional. If the requested variant
has not been modified since the time specified in this field, a has not been modified since the time specified in this field, a
description will not be returned from the server (DESCRIBE) or a description will not be returned from the server (DESCRIBE) or a
stream will not be set up (SETUP). Instead, a 304 (Not Modified) stream will not be set up (SETUP). Instead, a 304 (Not Modified)
response SHALL be returned without any message-body. response SHALL 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
14.26. If-None-Match 16.26. If-None-Match
See [H14.26]. See [H14.26].
This request header can be used with one or several entity tags to This request header can be used with one or several entity tags to
make DESCRIBE requests conditional. A new session description is make DESCRIBE requests conditional. A new session description is
retrieved only if another entity than the ones already available retrieved only if another entity than the ones already available
would be included. If the entity available for delivery is matching would be included. If the entity available for delivery is matching
the one the client already has, then a 304 (Not Modified) response is the one the client already has, then a 304 (Not Modified) response is
given. given.
14.27. Last-Modified 16.27. Last-Modified
The Last-Modified entity-header field indicates the date and time at The Last-Modified entity-header field indicates the date and time at
which the origin server believes the presentation description or which the origin server believes the presentation description or
media stream was last modified. See [H14.29]. For the methods media stream was last modified. See [H14.29]. For the methods
DESCRIBE, the header field indicates the last modification date and DESCRIBE, the header field indicates the last modification date and
time of the description, for SETUP that of the media stream. time of the description, for SETUP that of the media stream.
14.28. Location 16.28. Location
See [H14.30]. See [H14.30].
14.29. Proxy-Authenticate 16.29. Pipelined-Requests
The Pipelined-Requests general header is used to indicate that a
request is to be executed in the context created by previous
requests. The primary usage of this header is to allow pipelining of
SETUP requests so that any additional SETUP request after the first
one doesn't need to wait for the session ID to be sent back to the
requesting entity. The header contains a unique identifier that is
scoped by thepersistent connection used to send the requests.
Upon receiving a request with the Pipelined-Requests the responding
entity SHALL look up if there exist a binding between this Pipelined-
Requests identifier for the current persistent connection and an RTSP
session ID. If that exist then the received request is processed the
same way as if it did contain the Session header with the looked up
session ID. If there doesn't exist a mapping and no Session header
is included in the request, the responding entity SHALL create a
binding upon the succesful completion of a session creating request,
i.e. SETUP. If the request failed to create an RTSP session no
binding SHALL be created. In case the request contains both a
Session header and the Pipelined-Requests header the Pipelined-
Requests SHALL be ignored.
Note: Based on the above definition at least the first request
containing a new unique Pipelined-Requests will be required to be a
SETUP request (unless the protocol is extended with new methods of
creating a session). After that first one, additional SETUP requests
or request of any type using the RTSP session context may includ the
Pipelined-Requests header.
For all responses to request that contained the Pipelined-Requests,
the Session header and the Pipelined-Requests SHALL both be included,
assuming that it is allowed for that response and that the binding
between the header values exist. Pipelined-Requests SHOULD NOT be
used in requests after that the client has received the RTSP Session
ID. This as using the real session ID allows the request to be used
also in cases the persistent connection has been terminated and a new
connection is needed.
It is the sender of the request that is responsible for using a
previously unused identifier within this transport connection scope
when a new RTSP session is to be cretated with this method. A server
side binding SHALL be deleted upon the termination of the related
RTSP session. Note: Although this definition would allow for reusing
previously used pipelining identifiers, this is NOT RECOMMENDED to
allow for better error handling and logging.
RTSP Proxies may need to translate Pipelined-Requests identifier
values from incoming request to outgoing to allow for aggregation of
requests onto a persistent connection.
16.30. Proxy-Authenticate
See [H14.33]. See [H14.33].
14.30. Proxy-Authorization 16.31. Proxy-Authorization
See [H14.34]. See [H14.34].
14.31. Proxy-Require 16.32. Proxy-Require
The Proxy-Require request-header field is used to indicate proxy- The Proxy-Require request-header field is used to indicate proxy-
sensitive features that MUST be supported by the proxy. Any Proxy- sensitive features that MUST be supported by the proxy. Any Proxy-
Require header features that are not supported by the proxy MUST be Require header features that are not supported by the proxy MUST be
negatively acknowledged by the proxy to the client using the negatively acknowledged by the proxy to the client using the
Unsupported header. The proxy SHALL use the 551 (Option Not Unsupported header. The proxy SHALL use the 551 (Option Not
Supported) status code in the response. Any feature-tag included in Supported) status code in the response. Any feature-tag included in
the Proxy-Require does not apply to the end-point (server or client). the Proxy-Require does not apply to the end-point (server or client).
To ensure that a feature is supported by both proxies and servers the To ensure that a feature is supported by both proxies and servers the
tag needs to be included in also a Require header. tag needs to be included in also a Require header.
See SectionSection 14.37 for more details on the mechanics of this See Section 16.38 for more details on the mechanics of this message
message and a usage example. and a usage example.
Example of use: Example of use:
Proxy-Require: play.basic Proxy-Require: play.basic
14.32. Proxy-Supported 16.33. Proxy-Supported
The Proxy-Supported header field enumerates all the extensions The Proxy-Supported header field enumerates all the extensions
supported by the proxy using feature-tags. The header carries the supported by the proxy using feature-tags. The header carries the
intersection of extensions supported by the forwarding proxies. The intersection of extensions supported by the forwarding proxies. The
Proxy-Supported header MAY be included in any request by a proxy. It Proxy-Supported header MAY be included in any request by a proxy. It
SHALL be added by any proxy if the Supported header is present in a SHALL be added by any proxy if the Supported header is present in a
request. When present in a request, the receiver MUST in the request. When present in a request, the receiver MUST in the
response copy the received Proxy-Supported header. response copy the received Proxy-Supported header.
The Proxy-Supported header field contains a list of feature-tags The Proxy-Supported header field contains a list of feature-tags
applicable to proxies, as described in SectionSection 3.7. The list applicable to proxies, as described in Section 4.7. The list are the
are the intersection of all feature-tags understood by the proxies. intersection of all feature-tags understood by the proxies. To
To achieve an intersection, the proxy adding the Proxy-Supported achieve an intersection, the proxy adding the Proxy-Supported header
header includes all proxy feature-tags it understands. Any proxy includes all proxy feature-tags it understands. Any proxy receiving
receiving a request with the header, checks the list and removes any a request with the header, checks the list and removes any feature-
feature-tag it do not support. A Proxy-Supported header present in tag it do not support. A Proxy-Supported header present in the
the response SHALL NOT be touched by the proxies. response SHALL NOT be touched by the proxies.
Example: Example:
C->P1: OPTIONS rtsp://example.com/ RTSP/2.0 C->P1: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech Supported: foo, bar, blech
User-Agent: PhonyClient/1.2
P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0 P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech Supported: foo, bar, blech
Proxy-Supported: proxy-foo, proxy-bar, proxy-blech Proxy-Supported: proxy-foo, proxy-bar, proxy-blech
Via: 2.0 prox1.example.com Via: 2.0 prox1.example.com
P2->S: OPTIONS rtsp://example.com/ RTSP/2.0 P2->S: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech Supported: foo, bar, blech
Proxy-Supported: proxy-foo, proxy-blech Proxy-Supported: proxy-foo, proxy-blech
Via: 2.0 prox1.example.com, 2.0 prox2.example.com Via: 2.0 prox1.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 prox1.example.com, 2.0 prox2.example.com Via: 2.0 prox1.example.com, 2.0 prox2.example.com
14.33. Public 16.34. 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 14.7) MAY be used to indicate methods allowed for a (section 14.7) MAY be used to indicate methods allowed for a
particular URI. particular URI.
Example of use: Example of use:
skipping to change at page 100, line 5 skipping to change at page 103, line 34
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.
14.34. Range 16.35. Range
The Range header specifies a time range in PLAY ( Section 11.4), The Range header specifies a time range in PLAY ( Section 13.4),
PAUSE (Section 11.5), SETUP (Section 11.3), and REDIRECT ( PAUSE (Section 13.5), SETUP (Section 13.3), and REDIRECT (
Section 11.9) requests and responses. Section 13.9) requests and responses.
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 (SectionSection 3.4), npt (SectionSection 3.5), and defines smpte (Section 4.4), npt (Section 4.5), and clock
clock (SectionSection 3.6) range units. While byte ranges [H14.35.1] (Section 4.6) range units. While byte ranges [H14.35.1] and other
and other extended units MAY be used, their behavior is unspecified extended units MAY be used, their behavior is unspecified since they
since they are not normally meaningful in RTSP. Servers supporting are not normally meaningful in RTSP. Servers supporting the Range
the Range header MUST understand the NPT range format and SHOULD header MUST understand the NPT range format and SHOULD understand the
understand the SMPTE range format. If the Range header is sent in a SMPTE range format. If the Range header is sent in a time format
time format that is not understood, the recipient SHOULD return 456 that is not understood, the recipient SHOULD return 456 (Header Field
(Header Field Not Valid for Resource) and include an Accept-Ranges Not Valid for Resource) and include an Accept-Ranges header
header indicating the supported time formats for the given resource. indicating the supported time formats for the given resource.
The Range header MAY contain a time parameter in UTC, specifying the The Range header MAY contain a time parameter in UTC, specifying the
time at which the operation is to be made effective. This time at which the operation is to be made effective. This
functionality SHALL be used only with the REDIRECT method. functionality SHALL be used only with the REDIRECT method.
Ranges are half-open intervals, including the first point, but Ranges are half-open intervals, including the first point, but
excluding the second point. In other words, a range of A-B starts excluding the second point. In other words, a range of A-B starts
exactly at time A, but stops just before B. Only the start time of a exactly at time A, but stops just before B. Only the start time of a
media unit such as a video or audio frame is relevant. For example, media unit such as a video or audio frame is relevant. For example,
assume that video frames are generated every 40 ms. A range of 10.0- assume that video frames are generated every 40 ms. A range of 10.0-
skipping to change at page 101, line 4 skipping to change at page 104, line 33
well as from the current location to a given point. well as from the current location to a given point.
By default, range intervals increase, where the second point is By default, range intervals increase, where the second point is
larger than the first point. larger than the first point.
Example: Example:
Range: npt=10-15 Range: npt=10-15
However, range intervals can also decrease if the Scale header (see However, range intervals can also decrease if the Scale header (see
sectionSection 14.39) indicates a negative scale value. For example, Section 16.40) indicates a negative scale value. For example, this
this would be the case when a playback in reverse is desired. would be the case when a playback in reverse is desired.
Example: Example:
Scale: -1 Scale: -1
Range: npt=15-10 Range: npt=15-10
Decreasing ranges are still half open intervals as described above. Decreasing ranges are still half open intervals as described above.
Thus, for range A-B, A is closed and B is open. In the above Thus, for range A-B, A is closed and B is open. In the above
example, 15 is closed and 10 is open. An exception to this rule is example, 15 is closed and 10 is open. An exception to this rule is
the case when B=0 in a decreasing range. In this case, the range is the case when B=0 in a decreasing range. In this case, the range is
skipping to change at page 101, line 30 skipping to change at page 105, line 11
Example: Example:
Scale: -1 Scale: -1
Range: npt=15-0 Range: npt=15-0
In this range both 15 and 0 are closed. In this range both 15 and 0 are closed.
A decreasing range interval without a corresponding negative Scale A decreasing range interval without a corresponding negative Scale
header is not valid. header is not valid.
14.35. Referer 16.36. Referer
See [H14.36]. The URI refers to that of the presentation See [H14.36]. The URI refers to that of the presentation
description, typically retrieved via HTTP. description, typically retrieved via HTTP.
14.36. Retry-After 16.37. Retry-After
See [H14.37]. See [H14.37].
14.37. Require 16.38. Require
The Require request-header field is used by clients or servers to The Require request-header field is used by clients or servers to
ensure that the other end-point supports features that are required ensure that the other end-point supports features that are required
in respect to this request. It can also be used to query if the in respect to this request. It can also be used to query if the
other end-point supports certain features, however the use of the other end-point supports certain features, however the use of the
Supported (SectionSection 14.43) is much more effective in this Supported (Section 16.44) is much more effective in this purpose.
purpose. The server MUST respond to this header by using the The server MUST respond to this header by using the Unsupported
Unsupported header to negatively acknowledge those feature-tags which header to negatively acknowledge those feature-tags which are NOT
are NOT supported. The response SHALL use the error code 551 (Option supported. The response SHALL use the error code 551 (Option Not
Not Supported). This header does not apply to proxies, for the same Supported). This header does not apply to proxies, for the same
functionality in respect to proxies see, header Proxy-Require functionality in respect to proxies see, header Proxy-Require (
(Section Section 14.31). Section 16.32).
This is to make sure that the client-server interaction will This is to make sure that the client-server interaction will
proceed without delay when all features are understood by both proceed without delay when all features are understood by both
sides, and only slow down if features are not understood (as in sides, and only slow down if features are not understood (as in
the example below). For a well-matched client-server pair, the the example below). For a well-matched client-server pair, the
interaction proceeds quickly, saving a round-trip often required interaction proceeds quickly, saving a round-trip often required
by negotiation mechanisms. In addition, it also removes state by negotiation mechanisms. In addition, it also removes state
ambiguity when the client requires features that the server does ambiguity when the client requires features that the server does
not understand. not understand.
Example: Example (Not complete):
C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/2.0 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302 CSeq: 302
Require: funky-feature Require: funky-feature
Funky-Parameter: funkystuff Funky-Parameter: funkystuff
S->C: RTSP/2.0 551 Option not supported S->C: RTSP/2.0 551 Option not supported
CSeq: 302 CSeq: 302
Unsupported: funky-feature Unsupported: funky-feature
In this example, "funky-feature" is the feature-tag which indicates In this example, "funky-feature" is the feature-tag which indicates
to the client that the fictional Funky-Parameter field is required. to the client that the fictional Funky-Parameter field is required.
The relationship between "funky-feature" and Funky-Parameter is not The relationship between "funky-feature" and Funky-Parameter is not
communicated via the RTSP exchange, since that relationship is an communicated via the RTSP exchange, since that relationship is an
immutable property of "funky-feature" and thus should not be immutable property of "funky-feature" and thus should not be
transmitted with every exchange. transmitted with every exchange.
Proxies and other intermediary devices SHALL ignore this header. If Proxies and other intermediary devices SHALL ignore this header. If
a particular extension requires that intermediate devices support it, a particular extension requires that intermediate devices support it,
the extension should be tagged in the Proxy-Require field instead the extension should be tagged in the Proxy-Require field instead
(see SectionSection 14.31). (see Section 16.32).
14.38. RTP-Info 16.39. RTP-Info
The RTP-Info response-header field is used to set RTP-specific The RTP-Info response-header field is used to set RTP-specific
parameters in the PLAY response. For streams using RTP as transport parameters in the PLAY response. For streams using RTP as transport
protocol the RTP-Info header SHOULD be part of a 200 response to protocol the RTP-Info header SHOULD be part of a 200 response to
PLAY. PLAY.
The exclusion of the RTP-Info in a PLAY response for RTP The exclusion of the RTP-Info in a PLAY response for RTP
transported media will result in that a client needs to transported media will result in that a client needs to
synchronize the media streams using RTCP. This may have negative synchronize the media streams using RTCP. This may have negative
impact as the RTCP can be lost, and does not need to be impact as the RTCP can be lost, and does not need to be
particulary timely in their arrival. Also functionality as particulary timely in their arrival. Also functionality as
informing the client from which packet a seek has occurred is informing the client from which packet a seek has occurred is
affected. affected.
The RTP-Info MAY also be included in SETUP responses to provide The RTP-Info MAY also be included in SETUP responses to provide
synchronization information when changing transport parameters, see synchronization information when changing transport parameters, see
Section 11.3. Section 13.3.
The header can carry the following parameters: The header can carry the following parameters:
url: Indicates the stream URI which for which the following RTP url: Indicates the stream URI which for which the following RTP
parameters correspond, this URI MUST be the same used in the parameters correspond, this URI MUST be the same used in the
SETUP request for this media stream. Any relative URI SHALL SETUP request for this media stream. Any relative URI SHALL
use the Request-URI as base URI. This parameter SHALL be use the Request-URI as base URI. This parameter SHALL be
present. present.
ssrc: The Synchronization source (SSRC) that the RTP timestamp and ssrc: The Synchronization source (SSRC) that the RTP timestamp and
skipping to change at page 104, line 28 skipping to change at page 108, line 26
Video V PV Video V PV
X: NPT time value = 3.25, from Range header. X: NPT time value = 3.25, from Range header.
A: RTP timestamp value for Audio from RTP-Info header (12345678). A: RTP timestamp value for Audio from RTP-Info header (12345678).
V: RTP timestamp value for Video from RTP-Info header (29567112). V: RTP timestamp value for Video from RTP-Info header (29567112).
PA: RTP audio packet carrying an RTP timestamp of 12344878. Which PA: RTP audio packet carrying an RTP timestamp of 12344878. Which
corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2 corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2
PV: RTP video packet carrying an RTP timestamp of 29573412. Which PV: RTP video packet carrying an RTP timestamp of 29573412. Which
corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32 corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32
14.39. Scale 16.40. Scale
A scale value of 1 indicates normal play at the normal forward A scale value of 1 indicates normal play at the normal forward
viewing rate. If not 1, the value corresponds to the rate with viewing rate. If not 1, the value corresponds to the rate with
respect to normal viewing rate. For example, a ratio of 2 indicates respect to normal viewing rate. For example, a ratio of 2 indicates
twice the normal viewing rate ("fast forward") and a ratio of 0.5 twice the normal viewing rate ("fast forward") and a ratio of 0.5
indicates half the normal viewing rate. In other words, a ratio of 2 indicates half the normal viewing rate. In other words, a ratio of 2
has normal play time increase at twice the wallclock rate. For every has normal play time increase at twice the wallclock rate. For every
second of elapsed (wallclock) time, 2 seconds of content will be second of elapsed (wallclock) time, 2 seconds of content will be
delivered. A negative value indicates reverse direction. For delivered. A negative value indicates reverse direction. For
certain media transports this may require certain considerations to certain media transports this may require certain considerations to
work consistent, see section Appendix B.1 for description on how RTP work consistent, see Appendix B.1 for description on how RTP handles
handles this. this.
Unless requested otherwise by the Speed parameter, the data rate Unless requested otherwise by the Speed parameter, the data rate
SHOULD not be changed. Implementation of scale changes depends on SHOULD not be changed. Implementation of scale changes depends on
the server and media type. For video, a server may, for example, the server and media type. For video, a server may, for example,
deliver only key frames or selected key frames. For audio, it may deliver only key frames or selected key frames. For audio, it may
time-scale the audio while preserving pitch or, less desirably, time-scale the audio while preserving pitch or, less desirably,
deliver fragments of audio. deliver fragments of audio.
The server should try to approximate the viewing rate, but may The server should try to approximate the viewing rate, but may
restrict the range of scale values that it supports. The response restrict the range of scale values that it supports. The response
MUST contain the actual scale value chosen by the server. MUST contain the actual scale value chosen by the server.
If the server does not implement the possibility to scale, it will If the server does not implement the possibility to scale, it will
not return a Scale header. A server supporting Scale operations for not return a Scale header. A server supporting Scale operations for
PLAY SHALL indicate this with the use of the "play.scale" feature- PLAY SHALL indicate this with the use of the "play.scale" feature-
tags. tags.
When indicating a negative scale for a reverse playback, the Range When indicating a negative scale for a reverse playback, the Range
header MUST indicate a decreasing range as described in header MUST indicate a decreasing range as described in
sectionSection 14.34. Section 16.35.
Example of playing in reverse at 3.5 times normal rate: Example of playing in reverse at 3.5 times normal rate:
Scale: -3.5 Scale: -3.5
Range: npt=15-10 Range: npt=15-10
14.40. Speed 16.41. Speed
The Speed request-header field requests the server to deliver data to The Speed request-header field requests the server to deliver data to
the client at a particular speed, contingent on the server's ability the client at a particular speed, contingent on the server's ability
and desire to serve the media stream at the given speed. and desire to serve the media stream at the given speed.
Implementation by the server is OPTIONAL. The default is the bit Implementation by the server is OPTIONAL. The default is the bit
rate of the stream. rate of the stream.
The parameter value is expressed as a decimal ratio, e.g., a value of The parameter value is expressed as a decimal ratio, e.g., a value of
2.0 indicates that data is to be delivered twice as fast as normal. 2.0 indicates that data is to be delivered twice as fast as normal.
A speed of zero is invalid. All speeds may not be possible to A speed of zero is invalid. All speeds may not be possible to
skipping to change at page 106, line 5 skipping to change at page 110, line 5
presentation at a higher or lower rate is necessary. Implementors presentation at a higher or lower rate is necessary. 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. When data is delivered over UDP, it is highly may be necessary. When data is delivered over UDP, it is highly
recommended that means such as RTCP be used to track packet loss recommended that means such as RTCP be used to track packet loss
rates. If the data transport is performed over non-dedicated best- rates. If the data transport is performed over non-dedicated best-
effort networks the sender is required to perform congestion control effort networks the sender is required to perform congestion control
of the stream(s). This can result in that the communicated speed is of the stream(s). This can result in that the communicated speed is
impossible to maintain. impossible to maintain.
14.41. Server 16.42. Server
See [H14.38], however the header syntax is corrected in section See [H14.38], however the header syntax is corrected in
Section 19.2.3. Section 21.2.3.
14.42. Session 16.43. Session
The Session request-header and response-header field identifies an The Session request-header and response-header field identifies an
RTSP session. An RTSP session is created by the server as a result RTSP session. An RTSP session is created by the server as a result
of a successful SETUP request and in the response the session of a successful SETUP request and in the response the session
identifier is given to the client. The RTSP session exist until identifier is given to the client. The RTSP session exist until
destroyed by a TEARDOWN or timed out by the server. destroyed by a TEARDOWN or timed out by the server.
The session identifier is chosen by the server (see The session identifier is chosen by the server (see Section 4.3) and
SectionSection 3.3) and MUST be returned in the SETUP response. Once MUST be returned in the SETUP response. Once a client receives a
a client receives a session identifier, it SHALL be included in any session identifier, it SHALL be included in any request related to
request related to that session. This means that the Session header that session. This means that the Session header MUST be included in
MUST be included in a request using the following methods: PLAY, a request using the following methods: PLAY, PAUSE, and TEARDOWN, and
PAUSE, and TEARDOWN, and MAY be included in SETUP, OPTIONS, MAY be included in SETUP, OPTIONS, SETPARAMETER, GET_PARAMETER, and
SETPARAMETER, GETPARAMETER, and REDIRECT, and SHALL NOT be included REDIRECT, and SHALL NOT be included in DESCRIBE. In an RTSP response
in DESCRIBE. In an RTSP response the session header SHALL be the session header SHALL be included in methods, SETUP, PLAY, and
included in methods, SETUP, PLAY, and PAUSE, and MAY be included in PAUSE, and MAY be included in methods, TEARDOWN, and REDIRECT, and if
methods, TEARDOWN, and REDIRECT, and if included in the request of included in the request of the following methods it SHALL also be
the following methods it SHALL also be included in the response, included in the response, OPTIONS, GET_PARAMETER, and SETPARAMETER,
OPTIONS, GETPARAMETER, and SETPARAMETER, and SHALL NOT be included in and SHALL NOT be included in DESCRIBE.
DESCRIBE.
The timeout parameter MAY be included in a SETUP response, and SHALL The timeout parameter MAY be included in a SETUP response, and SHALL
NOT be included in requests. The server uses it to indicate to the NOT be included in requests. The server uses it to indicate to the
client how long the server is prepared to wait between RTSP commands client how long the server is prepared to wait between RTSP commands
or other signs of life before closing the session due to lack of or other signs of life before closing the session due to lack of
activity (see below and Section Appendix A). The timeout is measured activity (see below and Appendix A). The timeout is measured in
in seconds, with a default of 60 seconds (1 minute). The length of seconds, with a default of 60 seconds (1 minute). The length of the
the session timeout SHALL NOT be changed in a established session. session timeout SHALL NOT be changed in a established session.
The mechanisms for showing liveness of the client is, any RTSP The mechanisms for showing liveness of the client is, any RTSP
request with a Session header, if RTP & RTCP is used an RTCP message, request with a Session header, if RTP & RTCP is used an RTCP message,
or through any other used media protocol capable of indicating or through any other used media protocol capable of indicating
liveness of the RTSP client. It is RECOMMENDED that a client does liveness of the RTSP client. It is RECOMMENDED that a client does
not wait to the last second of the timeout before trying to send a not wait to the last second of the timeout before trying to send a
liveness message. The RTSP message may be lost or when using liveness message. The RTSP message may be lost or when using
reliable protocols, such as TCP, the message may take some time to reliable protocols, such as TCP, the message may take some time to
arrive safely at the receiver. To show liveness between RTSP request arrive safely at the receiver. To show liveness between RTSP request
issued to accomplish other things, the following mechanisms can be issued to accomplish other things, the following mechanisms can be
skipping to change at page 107, line 46 skipping to change at page 111, line 46
acceptable for a given method. However, multiple "user" sessions for acceptable for a given method. However, multiple "user" sessions for
the same URI from the same client will require use of different the same URI from the same client will require use of different
session identifiers. session identifiers.
The session identifier is needed to distinguish several delivery The session identifier is needed to distinguish several delivery
requests for the same URI coming from the same client. requests for the same URI coming from the same client.
The response 454 (Session Not Found) SHALL be returned if the session The response 454 (Session Not Found) SHALL be returned if the session
identifier is invalid. identifier is invalid.
14.43. Supported 16.44. Supported
The Supported header field enumerates all the extensions supported by The Supported header field enumerates all the extensions supported by
the client or server using feature tags. The header carries the the client or server using feature tags. The header carries the
extensions supported by the message sending entity. The Supported extensions supported by the message sending entity. The Supported
header MAY be included in any request. When present in a request, header MAY be included in any request. When present in a request,
the receiver MUST respond with its corresponding Supported header. the receiver MUST respond with its corresponding Supported header.
Note, also in 4xx and 5xx responses is the supported header included. Note, also in 4xx and 5xx responses is the supported header included.
The Supported header field contains a list of feature-tags, described The Supported header field contains a list of feature-tags, described
in SectionSection 3.7, that are understood by the client or server. in Section 4.7, that are understood by the client or server.
Example: Example:
C->S: OPTIONS rtsp://example.com/ RTSP/2.0 C->S: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech Supported: foo, bar, blech
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
Supported: bar, blech, baz Supported: bar, blech, baz
14.44. Timestamp 16.45. Timestamp
The Timestamp general-header field describes when the agent sent the The Timestamp general-header field describes when the agent sent the
request. The value of the timestamp is of significance only to the request. The value of the timestamp is of significance only to the
agent and may use any timescale. The responding agent MUST echo the agent and may use any timescale. The responding agent MUST echo the
exact same value and MAY, if it has accurate information about this, exact same value and MAY, if it has accurate information about this,
add a floating point number indicating the number of seconds that has add a floating point number indicating the number of seconds that has
elapsed since it has received the request. The timestamp is used by elapsed since it has received the request. The timestamp is used by
the agent to compute the round-trip time to the responding agent so the agent to compute the round-trip time to the responding agent so
that it can adjust the timeout value for retransmissions. It also that it can adjust the timeout value for retransmissions. It also
resolves retransmission ambiguities for unreliable transport of RTSP. resolves retransmission ambiguities for unreliable transport of RTSP.
14.45. Transport 16.46. Transport
The Transport request and response header field indicates which The Transport request and response header field indicates which
transport protocol is to be used and configures its parameters such transport protocol is to be used and configures its parameters such
as destination address, compression, multicast time-to-live and as destination address, compression, multicast time-to-live and
destination port for a single stream. It sets those values not destination port for a single stream. It sets those values not
already determined by a presentation description. already determined by a presentation description.
Transports are comma separated, listed in order of preference. Transports are comma separated, listed in order of preference.
Parameters may be added to each transport, separated by a semicolon. Parameters may be added to each transport, separated by a semicolon.
The server SHOULD return a Transport response-header field in the The server SHOULD return a Transport response-header field in the
skipping to change at page 110, line 41 skipping to change at page 114, line 41
destination entity per transport spec is intended. The usage destination entity per transport spec is intended. The usage
of multiple destination to distribute a single media to of multiple destination to distribute a single media to
multiple entities is unspecified. multiple entities is unspecified.
The client originating the RTSP request MAY specify the The client originating the RTSP request MAY specify the
destination address of the stream recipient with the host destination address of the stream recipient with the host
address part of the tuple. When the destination address is address part of the tuple. When the destination address is
specified, the recipient may be a different party than the specified, the recipient may be a different party than the
originator of the request. To avoid becoming the unwitting originator of the request. To avoid becoming the unwitting
perpetrator of a remote-controlled denial-of-service attack, a perpetrator of a remote-controlled denial-of-service attack, a
server MUST perform security checks (see Section Section 20.1) server MUST perform security checks (see Section 22.1) and
and SHOULD log such attempts before allowing the client to SHOULD log such attempts before allowing the client to direct a
direct a media stream to a recipient address not chosen by the media stream to a recipient address not chosen by the server.
server. Implementations cannot rely on TCP as reliable means Implementations cannot rely on TCP as reliable means of client
of client identification. If the server does not allow the identification. If the server does not allow the host address
host address part of the tuple to be set, it SHALL return 463 part of the tuple to be set, it SHALL return 463 (Destination
(Destination Prohibited). Prohibited).
The host address part of the tuple MAY be empty, for example The host address part of the tuple MAY be empty, for example
":58044", in cases when only destination port is desired to be ":58044", in cases when only destination port is desired to be
specified. specified.
src_addr: A general source address parameter that can contain one or src_addr: A general source address parameter that can contain one or
more address specifications. Each combination of Protocol/ more address specifications. Each combination of Protocol/
Profile/Lower Transport needs to have the format and Profile/Lower Transport needs to have the format and
interpretation of its address specification defined. For RTP/ interpretation of its address specification defined. For RTP/
AVP/UDP and RTP/AVP/TCP, the address specification is a tuple AVP/UDP and RTP/AVP/TCP, the address specification is a tuple
skipping to change at page 111, line 41 skipping to change at page 115, line 41
information should be in the SETUP response. information should be in the SETUP response.
mode: The mode parameter indicates the methods to be supported for mode: The mode parameter indicates the methods to be supported for
this session. Valid values are PLAY and RECORD. If not this session. Valid values are PLAY and RECORD. If not
provided, the default is PLAY. The RECORD value was defined in provided, the default is PLAY. The RECORD value was defined in
RFC 2326 and is in this specification unspecified but reserved. RFC 2326 and is in this specification unspecified but reserved.
interleaved: The interleaved parameter implies mixing the media interleaved: The interleaved parameter implies mixing the media
stream with the control stream in whatever protocol is being stream with the control stream in whatever protocol is being
used by the control stream, using the mechanism defined in used by the control stream, using the mechanism defined in
SectionSection 12. The argument provides the channel number to Section 14. The argument provides the channel number to be
be used in the $ statement and MUST be present. This parameter used in the $ statement and MUST be present. This parameter
MAY be specified as a range, e.g., tt interleaved=4-5 in cases MAY be specified as a range, e.g., tt interleaved=4-5 in cases
where the transport choice for the media stream requires it, where the transport choice for the media stream requires it,
e.g. for RTP with RTCP. The channel number given in the e.g. for RTP with RTCP. The channel number given in the
request are only a guidance from the client to the server on request are only a guidance from the client to the server on
what channel number(s) to use. The server MAY set any valid what channel number(s) to use. The server MAY set any valid
channel number in the response. The declared channel(s) are channel number in the response. The declared channel(s) are
bi-directional, so both end-parties MAY send data on the given bi-directional, so both end-parties MAY send data on the given
channel. One example of such usage is the second channel used channel. One example of such usage is the second channel used
for RTCP, where both server and client sends RTCP packets on for RTCP, where both server and client sends RTCP packets on
the same channel. the same channel.
skipping to change at page 114, line 15 skipping to change at page 118, line 15
Below is a usage example, showing a client advertising the capability Below is a usage example, showing a client advertising the capability
to handle multicast or unicast, preferring multicast. Since this is to handle multicast or unicast, preferring multicast. Since this is
a unicast-only stream, the server responds with the proper transport a unicast-only stream, the server responds with the proper transport
parameters for unicast. parameters for unicast.
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302 CSeq: 302
Transport: RTP/AVP;multicast;mode="PLAY", Transport: RTP/AVP;multicast;mode="PLAY",
RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
"192.0.2.5:3457";mode="PLAY" "192.0.2.5:3457";mode="PLAY"
Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 302 CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344 Session: 47112344
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
"192.0.2.5:3457";src_addr="192.0.2.224:6256" "192.0.2.5:3457";src_addr="192.0.2.224:6256"
/"192.0.2.224:6257";mode="PLAY" /"192.0.2.224:6257";mode="PLAY"
Accept-Ranges: NPT
14.46. Unsupported 16.47. Unsupported
The Unsupported response-header field lists the features not The Unsupported response-header field lists the features not
supported by the server. In the case where the feature was specified supported by the server. In the case where the feature was specified
via the Proxy-Require field (SectionSection 14.31), if there is a via the Proxy-Require field (Section 16.32), if there is a proxy on
proxy on the path between the client and the server, the proxy MUST the path between the client and the server, the proxy MUST send a
send a response message with a status code of 551 (Option Not response message with a status code of 551 (Option Not Supported).
Supported). The request SHALL NOT be forwarded. The request SHALL NOT be forwarded.
See Section 14.37 for a usage example. See Section 16.38 for a usage example.
14.47. User-Agent 16.48. User-Agent
See [H14.43] for explanation, however the syntax is clarified due to See [H14.43] for explanation, however the syntax is clarified due to
an error in RFC 2616. A Client SHOULD include this header in all an error in RFC 2616. A Client SHOULD include this header in all
RTSP messages it sends. RTSP messages it sends.
14.48. Vary 16.49. Vary
See [H14.44]. See [H14.44].
14.49. Via 16.50. Via
See [H14.45]. See [H14.45].
14.50. WWW-Authenticate 16.51. WWW-Authenticate
See [H14.47]. See [H14.47].
15. Proxies 17. Proxies
RTSP Proxies are RTSP agents that sit in between a client and a RTSP Proxies are RTSP agents that sit in between a client and a
server. A proxy can take on both the role as a client and as server server. A proxy can take on both the role as a client and as server
depending on what it tries to accomplish. Proxies are also depending on what it tries to accomplish. Proxies are also
introduced for several different reasons. introduced for several different reasons.
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 a presentation, both servers and connections. By caching a presentation, both
description and media streams the proxy can serve a client description and media streams the proxy can serve a client
content without requesting it from the server once it has been content without requesting it from the server once it has been
cached and hasn't become stale. See the caching cached and hasn't become stale. See the caching Section 18.
SectionSection 16.
Access Proxy: This type of proxy is used to ensure that a RTSP Access Proxy: This type of proxy is used to ensure that a RTSP
client get access to servers on an external network. Thus this client get access to servers on an external network. Thus this
proxy is placed on the border between two domains, e.g. a proxy is placed on the border between two domains, e.g. a
private address space and the public internet. The proxy private address space and the public internet. The proxy
performs the necessary translation, usually addresses, and performs the necessary translation, usually addresses, and
often also media stream translation or redirection. often also media stream translation or redirection.
Security Proxy: This type of proxy is used to help facilitate Security Proxy: This type of proxy is used to help facilitate
security functions around RTSP. For example when having a security functions around RTSP. For example when having a
firewalled network, the security proxy request that the firewalled network, the security proxy request that the
necessary pinholes in the firewall is opened when a client in necessary pinholes in the firewall is opened when a client in
the protected network want to access media streams on the the protected network want to access media streams on the
external side. It can also provide network owners with a external side. It can also provide network owners with a
logging and audit point for RTSP sessions, e.g. for logging and audit point for RTSP sessions, e.g. for
corporations that tracks or limits their employees access to corporations that tracks or limits their employees access to
certain type of content. certain type of content.
All type of proxies can be used also when using secured communication All type of proxies can be used also when using secured communication
with TLS as RTSP 2.0 allows the client to approve certificates for with TLS as RTSP 2.0 allows the client to approve certificate chains
connection establishment from a proxy, see SectionSection 18.3.2. used for connection establishment from a proxy, see Section 20.3.2.
However that trust model may not be suitable for all type of However that trust model may not be suitable for all type of
deployment, and instead secured sessions do by-pass of the proxies. deployment, and instead secured sessions do by-pass of the proxies.
Access proxies SHOULD NOT be used in equipment like NATs and Access proxies SHOULD NOT be used in equipment like NATs and
firewalls that aren't expected to be regularly maintained, like home firewalls that aren't expected to be regularly maintained, like home
or small office equipment. In these cases it is better to use the or small office equipment. In these cases it is better to use the
NAT traversal procedures defined for RTSP 2.0 NAT traversal procedures defined for RTSP 2.0
[I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is [I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is
that any extensions of RTSP resulting in new media transport that any extensions of RTSP resulting in new media transport
protocols or profiles, new parameters etc may fail in a proxy that protocols or profiles, new parameters etc may fail in a proxy that
isn't maintained. Thus resulting in blocking further development of isn't maintained. Thus resulting in blocking further development of
RTSP and its usage. RTSP and its usage.
The existence of proxies must always be considered when developing The existence of proxies must always be considered when developing
new RTSP extensions. There must be definition of how proxies may new RTSP extensions. There must be definition of how proxies may
handle the extension, if it is required to understand it, thus handle the extension, if it is required to understand it, thus
requiring a feature-tag to be used in the Proxy-Require header. requiring a feature-tag to be used in the Proxy-Require header.
16. Caching 18. Caching
In HTTP, response-request pairs are cached. RTSP differs In HTTP, response-request pairs are cached. RTSP differs
significantly in that respect. Responses are not cacheable, with the significantly in that respect. Responses are not cacheable, with the
exception of the presentation description returned by DESCRIBE. exception of the presentation description returned by DESCRIBE.
(Since the responses for anything but DESCRIBE and GETPARAMETER do (Since the responses for anything but DESCRIBE and GET_PARAMETER do
not return any data, caching is not really an issue for these not return any data, caching is not really an issue for these
requests.) However, it is desirable for the continuous media data, requests.) However, it is desirable for the continuous media data,
typically delivered out-of-band with respect to RTSP, to be cached, typically delivered out-of-band with respect to RTSP, to be cached,
as well as the session description. as well as the session description.
On receiving a SETUP or PLAY request, a proxy ascertains whether it On receiving a SETUP or PLAY request, a proxy ascertains whether it
has an up-to-date copy of the continuous media content and its has an up-to-date copy of the continuous media content and its
description. It can determine whether the copy is up-to-date by description. It can determine whether the copy is up-to-date by
issuing a SETUP or DESCRIBE request, respectively, and comparing the issuing a SETUP or DESCRIBE request, respectively, and comparing the
Last-Modified header with that of the cached copy. If the copy is Last-Modified header with that of the cached copy. If the copy is
not up-to-date, it modifies the SETUP transport parameters as not up-to-date, it modifies the SETUP transport parameters as
appropriate and forwards the request to the origin server. appropriate and forwards the request to the origin server.
Subsequent control commands such as PLAY or PAUSE then pass the proxy Subsequent control commands such as PLAY or PAUSE then pass the proxy
unmodified. The proxy delivers the continuous media data to the unmodified. The proxy delivers the continuous media data to the
client, while possibly making a local copy for later reuse. The client, while possibly making a local copy for later reuse. The
exact behavior allowed to the cache is given by the cache-response exact behavior allowed to the cache is given by the cache-response
directives described in SectionSection 14.10. A cache MUST answer directives described in Section 16.10. A cache MUST answer any
any DESCRIBE requests if it is currently serving the stream to the DESCRIBE requests if it is currently serving the stream to the
requestor, as it is possible that low-level details of the stream requestor, as it is possible that low-level details of the stream
description may have changed on the origin-server. description may have changed on the origin-server.
Note that an RTSP cache, unlike the HTTP cache, is of the "cut- Note that an RTSP cache, unlike the HTTP cache, is of the "cut-
through" variety. Rather than retrieving the whole resource from the through" variety. Rather than retrieving the whole resource from the
origin server, the cache simply copies the streaming data as it origin server, the cache simply copies the streaming data as it
passes by on its way to the client. Thus, it does not introduce passes by on its way to the client. Thus, it does not introduce
additional latency. additional latency.
To the client, an RTSP proxy cache appears like a regular media To the client, an RTSP proxy cache appears like a regular media
skipping to change at page 118, line 5 skipping to change at page 123, line 5
cache has to store the content type, content language, and so on for cache has to store the content type, content language, and so on for
the objects it caches, a media cache has to store the presentation the objects it caches, a media cache has to store the presentation
description. Typically, a cache eliminates all transport-references description. Typically, a cache eliminates all transport-references
(that is, e.g. multicast information) from the presentation (that is, e.g. multicast information) from the presentation
description, since these are independent of the data delivery from description, since these are independent of the data delivery from
the cache to the client. Information on the encodings remains the the cache to the client. Information on the encodings remains the
same. If the cache is able to translate the cached media data, it same. If the cache is able to translate the cached media data, it
would create a new presentation description with all the encoding would create a new presentation description with all the encoding
possibilities it can offer. possibilities it can offer.
17. Examples 19. Examples
This section contains several different examples trying to illustrate This section contains several different examples trying to illustrate
possible ways of using RTSP. The examples can also help with the possible ways of using RTSP. The examples can also help with the
understanding of how functions of RTSP work. However remember that understanding of how functions of RTSP work. However remember that
this is examples and the normative and syntax description in the this is examples and the normative and syntax description in the
other sections takes precedence. Please also note that many of the other sections takes precedence. Please also note that many of the
example contain syntax illegal line breaks to accommodate the example contain syntax illegal line breaks to accommodate the
formatting restriction that the RFC series impose. formatting restriction that the RFC series impose.
17.1. Media on Demand (Unicast) 19.1. Media on Demand (Unicast)
The is an example of media on demand streaming of a media stored in a The is an example of media on demand streaming of a media stored in a
container file. For purposes of this example, a container file is a container file. For purposes of this example, a container file is a
storage entity in which multiple continuous media types pertaining to storage entity in which multiple continuous media types pertaining to
the same end-user presentation are present. In effect, the container the same end-user presentation are present. In effect, the container
file represents an RTSP presentation, with each of its components file represents an RTSP presentation, with each of its components
being RTSP controlled media streams. Container files are a widely being RTSP controlled media streams. Container files are a widely
used means to store such presentations. While the components are used means to store such presentations. While the components are
transported as independent streams, it is desirable to maintain a transported as independent streams, it is desirable to maintain a
common context for those streams at the server end. common context for those streams at the server end.
skipping to change at page 119, line 31 skipping to change at page 125, line 4
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=control: trackID=1 a=control: trackID=1
m=video 0 RTP/AVP 26 m=video 0 RTP/AVP 26
a=control: trackID=4 a=control: trackID=4
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2 CSeq: 2
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Require: play.basic Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001"
Accept-Ranges: NPT, SMPTE, UTC
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001; Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001;
src_addr="192.0.2.5:9000"/"192.0.2.5:9001" src_addr="192.0.2.5:9000"/"192.0.2.5:9001"
ssrc=93CB001E ssrc=93CB001E
Session: 12345678 Session: 12345678
Expires: 24 Jan 1997 15:35:12 GMT Expires: 24 Jan 1997 15:35:12 GMT
Date: 23 Jan 1997 15:35:12 GMT Date: 23 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT Accept-Ranges: NPT
C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Require: play.basic Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
Session: 12345678 Session: 12345678
Accept-Ranges: NPT, SMPTE, UTC
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003; Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003;
src_addr="192.0.2.5:9002"/"192.0.2.5:9003"; src_addr="192.0.2.5:9002"/"192.0.2.5:9003";
ssrc=A813FC13 ssrc=A813FC13
Session: 12345678 Session: 12345678
Expires: 24 Jan 1997 15:35:13 GMT Expires: 24 Jan 1997 15:35:13 GMT
Date: 23 Jan 1997 15:35:13 GMT Date: 23 Jan 1997 15:35:13 GMT
skipping to change at page 121, line 11 skipping to change at page 126, line 33
CSeq: 6 CSeq: 6
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:36:01 GMT Date: 23 Jan 1997 15:36:01 GMT
Session: 12345678 Session: 12345678