draft-ietf-mmusic-rfc2326bis-17.txt   draft-ietf-mmusic-rfc2326bis-18.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: August 28, 2008 Cisco Expires: November 6, 2008 Cisco
R. Lanphier R. Lanphier
Real Networks
M. Westerlund M. Westerlund
Ericsson AB Ericsson AB
M. Stiemerling (Ed.) M. Stiemerling (Ed.)
NEC NEC
February 25, 2008 May 5, 2008
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-17.txt draft-ietf-mmusic-rfc2326bis-18.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 41 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 August 28, 2008. This Internet-Draft will expire on November 6, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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.
The Real Time Streaming Protocol, or RTSP, is an application-level The Real Time Streaming Protocol, or RTSP, is an application-level
protocol for control over the delivery of data with real-time protocol for control over the delivery of data with real-time
properties. RTSP provides an extensible framework to enable properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and controlled, on-demand delivery of real-time data, such as audio and
video. Sources of data can include both live data feeds and stored video. Sources of data can include both live data feeds and stored
clips. This protocol is intended to control multiple data delivery clips. This protocol is intended to control multiple data delivery
sessions, provide a means for choosing delivery channels such as UDP, sessions, provide a means for choosing delivery channels such as UDP,
multicast UDP and TCP, and provide a means for choosing delivery multicast UDP and TCP, and provide a means for choosing delivery
mechanisms based upon RTP (RFC 3550). mechanisms based upon RTP (RFC 3550).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1. Scope and Background . . . . . . . . . . . . . . . . . . 8 1.1. Scope and Background . . . . . . . . . . . . . . . . . . 9
1.2. RTSP Specificication Update . . . . . . . . . . . . . . 9 1.2. RTSP Specificication Update . . . . . . . . . . . . . . 10
1.3. Notational Conventions . . . . . . . . . . . . . . . . . 9 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 10
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . 10 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . 11
2. RTSP Introduction . . . . . . . . . . . . . . . . . . . . . . 14 1.5. Media Properties . . . . . . . . . . . . . . . . . . . . 14
2.1. Protocol Properties . . . . . . . . . . . . . . . . . . 14 1.5.1. Random Access . . . . . . . . . . . . . . . . . . . 15
2.2. RTSP's Relationship to HTTP . . . . . . . . . . . . . . 15 1.5.2. Retention . . . . . . . . . . . . . . . . . . . . . 15
2.3. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 16 1.5.3. Content Modifications . . . . . . . . . . . . . . . 16
2.4. Overall Operation . . . . . . . . . . . . . . . . . . . 17 1.5.4. Mapping to the Attributes . . . . . . . . . . . . . 16
2.5. RTSP States . . . . . . . . . . . . . . . . . . . . . . 18 2. RTSP Introduction . . . . . . . . . . . . . . . . . . . . . . 17
2.6. Relationship with Other Protocols . . . . . . . . . . . 19 2.1. Protocol Properties . . . . . . . . . . . . . . . . . . 17
3. RTSP Use Cases . . . . . . . . . . . . . . . . . . . . . . . 20 2.2. RTSP's Relationship to HTTP . . . . . . . . . . . . . . 18
3.1. On-demand Playback of Stored Content . . . . . . . . . . 20 2.3. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 19
3.2. Unicast distribution of Live Content . . . . . . . . . . 21 2.4. Overall Operation . . . . . . . . . . . . . . . . . . . 20
3.3. On-demand Playback using Multicast . . . . . . . . . . . 22 2.5. RTSP States . . . . . . . . . . . . . . . . . . . . . . 21
3.4. Inviting an RTSP server into a conference . . . . . . . 22 2.6. Relationship with Other Protocols . . . . . . . . . . . 22
3.5. Live Content using Multicast . . . . . . . . . . . . . . 23 3. RTSP Use Cases . . . . . . . . . . . . . . . . . . . . . . . 23
4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 25 3.1. On-demand Playback of Stored Content . . . . . . . . . . 23
4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 25 3.2. Unicast distribution of Live Content . . . . . . . . . . 24
4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 25 3.3. On-demand Playback using Multicast . . . . . . . . . . . 25
4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 27 3.4. Inviting an RTSP server into a conference . . . . . . . 25
4.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . 27 3.5. Live Content using Multicast . . . . . . . . . . . . . . 26
4.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 27 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 28
4.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . 28 4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 28
4.7. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 28 4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 28
4.8. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 29 4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 30
5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 30 4.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . 30
5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 30 4.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 30
5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 30 4.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . 31
5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 30 4.7. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 31
5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 30 4.8. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 32
6. General Header Fields . . . . . . . . . . . . . . . . . . . . 32 5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 33
7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 33
7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 33 5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 34
7.2. Request Header Fields . . . . . . . . . . . . . . . . . 35 5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 34
8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 34
8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 37 6. General Header Fields . . . . . . . . . . . . . . . . . . . . 35
8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 37 7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.2. Response Header Fields . . . . . . . . . . . . . . . . . 40 7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 36
9. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 7.2. Request Header Fields . . . . . . . . . . . . . . . . . 38
9.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 43 8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 44 8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 40
10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 40
10.1. Reliability and Acknowledgements . . . . . . . . . . . . 45 8.2. Response Header Fields . . . . . . . . . . . . . . . . . 43
10.2. Using Connections . . . . . . . . . . . . . . . . . . . 46 9. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
10.3. Closing Connections . . . . . . . . . . . . . . . . . . 47 9.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 46
10.4. Timing Out Connections and RTSP Messages . . . . . . . . 48 9.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 47
10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 48 10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 48
10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 49 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 48
11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 50 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 49
12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 52 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 50
13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 53 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 51
13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 54 10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 51
13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 55 10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 52
13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 57 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 53
13.3.1. Changing Transport Parameters . . . . . . . . . . . 59 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 55
13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 60 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 56
13.5. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 65 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 57
13.6. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 68 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 58
13.7. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 69 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 60
13.8. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 70 13.3.1. Changing Transport Parameters . . . . . . . . . . . 63
13.9. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 71 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 64
14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 74 13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 64
15. Status Code Definitions . . . . . . . . . . . . . . . . . . . 76 13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 68
15.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 76 13.4.3. Updating current PLAY Requests . . . . . . . . . . . 68
15.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 76 13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 70
15.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 76 13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 71
15.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 76 13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 71
15.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 76 13.4.7. Playing Live with Recording . . . . . . . . . . . . 72
15.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 77 13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 72
15.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 77 13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 73
15.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 77 13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 74
15.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 77 13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 75
15.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 77 13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 76
15.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 78 13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 77
15.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 78 13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 79
15.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 78 13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 80
15.4.2. 405 Method Not Allowed . . . . . . . . . . . . . . . 78 13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 81
15.4.3. 451 Parameter Not Understood . . . . . . . . . . . . 78 13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 82
15.4.4. 452 reserved . . . . . . . . . . . . . . . . . . . . 78 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 86
15.4.5. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 79 15. Status Code Definitions . . . . . . . . . . . . . . . . . . . 88
15.4.6. 454 Session Not Found . . . . . . . . . . . . . . . 79 15.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 88
15.4.7. 455 Method Not Valid in This State . . . . . . . . . 79 15.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 88
15.4.8. 456 Header Field Not Valid for Resource . . . . . . 79 15.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 88
15.4.9. 457 Invalid Range . . . . . . . . . . . . . . . . . 79 15.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 88
15.4.10. 458 Parameter Is Read-Only . . . . . . . . . . . . . 79 15.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 88
15.4.11. 459 Aggregate Operation Not Allowed . . . . . . . . 79 15.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 89
15.4.12. 460 Only Aggregate Operation Allowed . . . . . . . . 79 15.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 89
15.4.13. 461 Unsupported Transport . . . . . . . . . . . . . 80 15.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 89
15.4.14. 462 Destination Unreachable . . . . . . . . . . . . 80 15.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 89
15.4.15. 463 Destination Prohibited . . . . . . . . . . . . . 80 15.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 89
15.4.16. 464 Data Transport Not Ready Yet . . . . . . . . . . 80 15.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 90
15.4.17. 470 Connection Authorization Required . . . . . . . 80 15.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 90
15.4.18. 471 Connection Credentials not accepted . . . . . . 80 15.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 90
15.4.19. 472 Failure to establish secure connection . . . . . 81 15.4.2. 405 Method Not Allowed . . . . . . . . . . . . . . . 90
15.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 81 15.4.3. 451 Parameter Not Understood . . . . . . . . . . . . 90
15.5.1. 551 Option not supported . . . . . . . . . . . . . . 81 15.4.4. 452 reserved . . . . . . . . . . . . . . . . . . . . 90
16. Header Field Definitions . . . . . . . . . . . . . . . . . . 82 15.4.5. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 91
16.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 91 15.4.6. 454 Session Not Found . . . . . . . . . . . . . . . 91
16.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 91 15.4.7. 455 Method Not Valid in This State . . . . . . . . . 91
16.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 92 15.4.8. 456 Header Field Not Valid for Resource . . . . . . 91
16.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 92 15.4.9. 457 Invalid Range . . . . . . . . . . . . . . . . . 91
16.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 92 15.4.10. 458 Parameter Is Read-Only . . . . . . . . . . . . . 91
16.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 92 15.4.11. 459 Aggregate Operation Not Allowed . . . . . . . . 91
16.7. Authorization . . . . . . . . . . . . . . . . . . . . . 93 15.4.12. 460 Only Aggregate Operation Allowed . . . . . . . . 91
16.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 93 15.4.13. 461 Unsupported Transport . . . . . . . . . . . . . 92
16.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 93 15.4.14. 462 Destination Unreachable . . . . . . . . . . . . 92
16.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 93 15.4.15. 463 Destination Prohibited . . . . . . . . . . . . . 92
16.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 96 15.4.16. 464 Data Transport Not Ready Yet . . . . . . . . . . 92
16.12. Connection-Credentials . . . . . . . . . . . . . . . . . 96 15.4.17. 465 Notification Reason Unknown . . . . . . . . . . 92
16.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 97 15.4.18. 470 Connection Authorization Required . . . . . . . 92
16.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 97 15.4.19. 471 Connection Credentials not accepted . . . . . . 93
16.15. Content-Language . . . . . . . . . . . . . . . . . . . . 97 15.4.20. 472 Failure to establish secure connection . . . . . 93
16.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 97 15.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 93
16.17. Content-Location . . . . . . . . . . . . . . . . . . . . 98 15.5.1. 551 Option not supported . . . . . . . . . . . . . . 93
16.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 98 16. Header Field Definitions . . . . . . . . . . . . . . . . . . 94
16.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 98 16.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 103
16.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 98 16.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 103
16.21. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 98 16.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 104
16.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 99 16.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 104
16.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 100 16.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 104
16.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 100 16.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 105
16.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 100 16.7. Authorization . . . . . . . . . . . . . . . . . . . . . 105
16.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 101 16.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 105
16.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 101 16.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 105
16.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 101 16.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 106
16.29. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 101 16.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 108
16.30. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 102 16.12. Connection-Credentials . . . . . . . . . . . . . . . . . 108
16.31. Proxy-Authorization . . . . . . . . . . . . . . . . . . 102 16.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 109
16.32. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 102 16.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 109
16.33. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 103 16.15. Content-Language . . . . . . . . . . . . . . . . . . . . 109
16.34. Public . . . . . . . . . . . . . . . . . . . . . . . . . 103 16.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 110
16.35. Range . . . . . . . . . . . . . . . . . . . . . . . . . 104 16.17. Content-Location . . . . . . . . . . . . . . . . . . . . 110
16.36. Referer . . . . . . . . . . . . . . . . . . . . . . . . 106 16.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 110
16.37. Retry-After . . . . . . . . . . . . . . . . . . . . . . 106 16.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 110
16.38. Require . . . . . . . . . . . . . . . . . . . . . . . . 106 16.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 110
16.39. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 107 16.21. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 111
16.40. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 109 16.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 111
16.41. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 109 16.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 112
16.42. Server . . . . . . . . . . . . . . . . . . . . . . . . . 110 16.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 112
16.43. Session . . . . . . . . . . . . . . . . . . . . . . . . 110 16.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 112
16.44. Supported . . . . . . . . . . . . . . . . . . . . . . . 111 16.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 113
16.45. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 111 16.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 113
16.46. Transport . . . . . . . . . . . . . . . . . . . . . . . 112 16.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 113
16.47. Unsupported . . . . . . . . . . . . . . . . . . . . . . 117 16.29. Media-Properties . . . . . . . . . . . . . . . . . . . . 113
16.48. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 118 16.30. Media-Range . . . . . . . . . . . . . . . . . . . . . . 115
16.49. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 118 16.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 115
16.50. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 118 16.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 115
16.51. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 118 16.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 116
17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 16.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 116
18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 16.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 116
19. Security Framework . . . . . . . . . . . . . . . . . . . . . 122 16.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 117
19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 122 16.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 118
19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 122 16.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 119
19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 123 16.39. Referer . . . . . . . . . . . . . . . . . . . . . . . . 120
19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 124 16.40. Retry-After . . . . . . . . . . . . . . . . . . . . . . 120
19.3.2. User approved TLS procedure . . . . . . . . . . . . 125 16.41. Request-Status . . . . . . . . . . . . . . . . . . . . . 120
20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 16.42. Require . . . . . . . . . . . . . . . . . . . . . . . . 121
20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 127 16.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 122
20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 129 16.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 123
20.2.1. Generic Protocol elements . . . . . . . . . . . . . 129 16.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 124
20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 132 16.46. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 125
20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 136 16.47. Server . . . . . . . . . . . . . . . . . . . . . . . . . 126
20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 143 16.48. Session . . . . . . . . . . . . . . . . . . . . . . . . 126
21. Security Considerations . . . . . . . . . . . . . . . . . . . 144 16.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 127
21.1. Remote denial of Service Attack . . . . . . . . . . . . 146 16.50. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 127
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 148 16.51. Transport . . . . . . . . . . . . . . . . . . . . . . . 127
22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 148 16.52. Unsupported . . . . . . . . . . . . . . . . . . . . . . 133
22.1.1. Description . . . . . . . . . . . . . . . . . . . . 148 16.53. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 134
22.1.2. Registering New Feature-tags with IANA . . . . . . . 149 16.54. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 134
22.1.3. Registered entries . . . . . . . . . . . . . . . . . 149 16.55. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 134
22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 149 16.56. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 134
22.2.1. Description . . . . . . . . . . . . . . . . . . . . 149 17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
22.2.2. Registering New Methods with IANA . . . . . . . . . 149 18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 150 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 138
22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 150 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 138
22.3.1. Description . . . . . . . . . . . . . . . . . . . . 150 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 138
22.3.2. Registering New Status Codes with IANA . . . . . . . 150 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 139
22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 150 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 140
22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 150 19.3.2. User approved TLS procedure . . . . . . . . . . . . 141
22.4.1. Description . . . . . . . . . . . . . . . . . . . . 150 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
22.4.2. Registering New Headers with IANA . . . . . . . . . 151 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 143
22.4.3. Registered entries . . . . . . . . . . . . . . . . . 151 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 145
22.5. Transport Header Registries . . . . . . . . . . . . . . 152 20.2.1. Generic Protocol elements . . . . . . . . . . . . . 145
22.5.1. Transport Protocol Specification . . . . . . . . . . 152 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 148
22.5.2. Transport modes . . . . . . . . . . . . . . . . . . 153 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 152
22.5.3. Transport Parameters . . . . . . . . . . . . . . . . 154 20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 160
22.6. Cache Directive Extensions . . . . . . . . . . . . . . . 154 21. Security Considerations . . . . . . . . . . . . . . . . . . . 161
22.7. Accept-Credentials . . . . . . . . . . . . . . . . . . . 155 21.1. Remote denial of Service Attack . . . . . . . . . . . . 163
22.7.1. Accept-Credentials policies . . . . . . . . . . . . 155 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 165
22.7.2. Accept-Credentials hash algorithms . . . . . . . . . 155 22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 165
22.8. Range header formats . . . . . . . . . . . . . . . . . . 156 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 165
22.9. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 156 22.1.2. Registering New Feature-tags with IANA . . . . . . . 166
22.9.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 156 22.1.3. Registered entries . . . . . . . . . . . . . . . . . 166
22.9.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 157 22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 166
22.9.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 158 22.2.1. Description . . . . . . . . . . . . . . . . . . . . 166
22.10. SDP attributes . . . . . . . . . . . . . . . . . . . . . 159 22.2.2. Registering New Methods with IANA . . . . . . . . . 166
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 160 22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 167
23.1. Normative References . . . . . . . . . . . . . . . . . . 160 22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 167
23.2. Informative References . . . . . . . . . . . . . . . . . 162 22.3.1. Description . . . . . . . . . . . . . . . . . . . . 167
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 165 22.3.2. Registering New Status Codes with IANA . . . . . . . 167
A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 165 22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 167
A.2. Media on Demand using Pipelining . . . . . . . . . . . . 169 22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 167
A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 171 22.4.1. Description . . . . . . . . . . . . . . . . . . . . 167
A.4. Single Stream Container Files . . . . . . . . . . . . . 175 22.4.2. Registering New Headers with IANA . . . . . . . . . 168
A.5. Live Media Presentation Using Multicast . . . . . . . . 177 22.4.3. Registered entries . . . . . . . . . . . . . . . . . 168
A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 178 22.5. Transport Header Registries . . . . . . . . . . . . . . 169
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 180 22.5.1. Transport Protocol Specification . . . . . . . . . . 169
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 180 22.5.2. Transport modes . . . . . . . . . . . . . . . . . . 170
B.2. State variables . . . . . . . . . . . . . . . . . . . . 180 22.5.3. Transport Parameters . . . . . . . . . . . . . . . . 171
B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 180 22.6. Cache Directive Extensions . . . . . . . . . . . . . . . 171
B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 181 22.7. Accept-Credentials . . . . . . . . . . . . . . . . . . . 172
Appendix C. Media Transport Alternatives . . . . . . . . . . . . 186 22.7.1. Accept-Credentials policies . . . . . . . . . . . . 172
C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 186 22.7.2. Accept-Credentials hash algorithms . . . . . . . . . 172
C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 186 22.8. Range header formats . . . . . . . . . . . . . . . . . . 173
C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 186 22.9. Media Property Values . . . . . . . . . . . . . . . . . 173
C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 187 22.9.1. Description . . . . . . . . . . . . . . . . . . . . 173
C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 188 22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 173
C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 188 22.9.3. Registered Values . . . . . . . . . . . . . . . . . 174
C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 188 22.10. Notify-Reason header . . . . . . . . . . . . . . . . . . 174
C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 189 22.10.1. Description . . . . . . . . . . . . . . . . . . . . 174
C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 189 22.10.2. Registration Rules . . . . . . . . . . . . . . . . . 174
C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 189 22.10.3. Registered Values . . . . . . . . . . . . . . . . . 174
C.2.3. Handling NPT Jumps in the RTP Media Layer . . . . . 193 22.11. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 175
C.2.4. Handling RTP Timestamps after PAUSE . . . . . . . . 196 22.11.1. Description . . . . . . . . . . . . . . . . . . . . 175
C.2.5. RTSP / RTP Integration . . . . . . . . . . . . . . . 198 22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 175
C.2.6. Scaling with RTP . . . . . . . . . . . . . . . . . . 198 22.11.3. Registered Values . . . . . . . . . . . . . . . . . 175
22.12. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 175
22.12.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 175
22.12.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 176
22.12.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 177
22.13. SDP attributes . . . . . . . . . . . . . . . . . . . . . 178
22.14. Media Type Registration for text/parameters . . . . . . 179
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 181
23.1. Normative References . . . . . . . . . . . . . . . . . . 181
23.2. Informative References . . . . . . . . . . . . . . . . . 183
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 186
A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 186
A.2. Media on Demand using Pipelining . . . . . . . . . . . . 190
A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 192
A.4. Single Stream Container Files . . . . . . . . . . . . . 196
A.5. Live Media Presentation Using Multicast . . . . . . . . 198
A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 199
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 201
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 201
B.2. State variables . . . . . . . . . . . . . . . . . . . . 201
B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 201
B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 202
Appendix C. Media Transport Alternatives . . . . . . . . . . . . 207
C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 207
C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 207
C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 207
C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 208
C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 209
C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 209
C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 209
C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 210
C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 210
C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 210
C.2.3. Handling NPT Jumps in the RTP Media Layer . . . . . 214
C.2.4. Handling RTP Timestamps after PAUSE . . . . . . . . 217
C.2.5. RTSP / RTP Integration . . . . . . . . . . . . . . . 219
C.2.6. Scaling with RTP . . . . . . . . . . . . . . . . . . 219
C.2.7. Maintaining NPT synchronization with RTP C.2.7. Maintaining NPT synchronization with RTP
timestamps . . . . . . . . . . . . . . . . . . . . . 198 timestamps . . . . . . . . . . . . . . . . . . . . . 219
C.2.8. Continuous Audio . . . . . . . . . . . . . . . . . . 198 C.2.8. Continuous Audio . . . . . . . . . . . . . . . . . . 219
C.2.9. Multiple Sources in an RTP Session . . . . . . . . . 198 C.2.9. Multiple Sources in an RTP Session . . . . . . . . . 219
C.2.10. Usage of SSRCs and the RTCP BYE Message During an C.2.10. Usage of SSRCs and the RTCP BYE Message During an
RTSP Session . . . . . . . . . . . . . . . . . . . . 198 RTSP Session . . . . . . . . . . . . . . . . . . . . 219
C.3. Future Additions . . . . . . . . . . . . . . . . . . . . 199 C.3. Future Additions . . . . . . . . . . . . . . . . . . . . 220
Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 200 Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 221
D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 200 D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 221
D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 200 D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 221
D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 201 D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 222
D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 202 D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 223
D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 202 D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 223
D.1.5. Directionality of media stream . . . . . . . . . . . 202 D.1.5. Directionality of media stream . . . . . . . . . . . 223
D.1.6. Range of Presentation . . . . . . . . . . . . . . . 203 D.1.6. Range of Presentation . . . . . . . . . . . . . . . 224
D.1.7. Time of Availability . . . . . . . . . . . . . . . . 204 D.1.7. Time of Availability . . . . . . . . . . . . . . . . 225
D.1.8. Connection Information . . . . . . . . . . . . . . . 204 D.1.8. Connection Information . . . . . . . . . . . . . . . 225
D.1.9. Entity Tag . . . . . . . . . . . . . . . . . . . . . 204 D.1.9. Entity Tag . . . . . . . . . . . . . . . . . . . . . 225
D.2. Aggregate Control Not Available . . . . . . . . . . . . 205 D.2. Aggregate Control Not Available . . . . . . . . . . . . 226
D.3. Aggregate Control Available . . . . . . . . . . . . . . 205 D.3. Aggregate Control Available . . . . . . . . . . . . . . 226
D.4. RTSP external SDP delivery . . . . . . . . . . . . . . . 206 D.4. RTSP external SDP delivery . . . . . . . . . . . . . . . 227
Appendix E. Minimal RTSP Implementation . . . . . . . . . . . . 208 Appendix E. Text format for Parameters . . . . . . . . . . . . . 229
E.1. Minimal Core Implementation . . . . . . . . . . . . . . 208 Appendix F. Requirements for Unreliable Transport of RTSP . . . 230
E.2. Recommended Core Implementation . . . . . . . . . . . . 208 Appendix G. Backwards Compatibility Considerations . . . . . . . 232
E.3. The Basic Playback Feature Support . . . . . . . . . . . 209 G.1. Play Request in Play mode . . . . . . . . . . . . . . . 232
E.3.1. Client . . . . . . . . . . . . . . . . . . . . . . . 209 G.2. Using Persistent Connections . . . . . . . . . . . . . . 232
E.3.2. Server . . . . . . . . . . . . . . . . . . . . . . . 209 Appendix H. Open Issues . . . . . . . . . . . . . . . . . . . . 233
E.3.3. Proxy . . . . . . . . . . . . . . . . . . . . . . . 210 Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 235
E.4. Secure Transport . . . . . . . . . . . . . . . . . . . . 210 Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 242
Appendix F. Requirements for Unreliable Transport of RTSP . . . 211 J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 242
Appendix G. Backwards Compatibility Considerations . . . . . . . 213 Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 244
G.1. Play Request in Play mode . . . . . . . . . . . . . . . 213 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 245
G.2. Using Persistent Connections . . . . . . . . . . . . . . 213 Intellectual Property and Copyright Statements . . . . . . . . . 246
Appendix H. Open Issues . . . . . . . . . . . . . . . . . . . . 214
Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 216
I.1. Changes needing to be updated . . . . . . . . . . . . . 221
Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 223
J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 223
Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 225
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 226
Intellectual Property and Copyright Statements . . . . . . . . . 227
1. Introduction 1. Introduction
1.1. Scope and Background 1.1. Scope and Background
This memo defines version 2.0 of the Real Time Streaming Protocol This memo defines version 2.0 of the Real Time Streaming Protocol
(RTSP 2.0) which is an application-level protocol for control over (RTSP 2.0) which is an application-level protocol for control over
the delivery of data with real-time properties, typically streaming the delivery of data with real-time properties, typically streaming
media. Streaming media is, for instance, video on demand or audio media. Streaming media is, for instance, video on demand or audio
life streaming. Put simply, RTSP acts as a "network remote control" live streaming. Put simply, RTSP acts as a "network remote control"
for multimedia servers, as you know it from your TV set. for multimedia servers, as you know it from your TV set.
The protocol operates between RTSP 2.0 clients and servers, but also The protocol operates between RTSP 2.0 clients and servers, but also
supports the usage of RTSP 2.0 proxies between clients and servers. supports the usage of RTSP 2.0 proxies between clients and servers.
Basically, clients can request information about streaming media from Basically, clients can request information about streaming media from
servers, by asking for a description of the media or use media servers, by asking for a description of the media or use media
description provided externally. Based on the media description description provided externally. Based on the media description
clients can request to play out the media, pause it, or stop it clients can request to play out the media, pause it, or stop it
completely, as known from a regular TV remote control. The requested completely, as known from a regular TV remote control. The requested
media can consist of multiple audio and video streams that are media can consist of multiple audio and video streams that are
delivered as a time- synchronized stream from servers to clients. delivered as a time-synchronized streams from servers to clients.
This memorandum describes the use of RTSP over a reliable connection This memorandum describes the use of RTSP over a reliable connection
based transport level protocol, such as TCP. For security, TLS over based transport level protocol, such as TCP. For security, TLS over
a connection oriented transport is supported. a connection oriented transport is supported.
There is no notion of an RTSP connection in the protocol. Instead, There is no dependency on an special RTSP connection in the protocol.
an RTSP server maintains a session labeled by an identifier to Instead, an RTSP server maintains a session labeled by an identifier
associate groups of media streams and their states. An RTSP session to associate groups of media streams and their states. An RTSP
is not tied to a transport-level connection such as a TCP connection. session is not tied to a transport-level connection such as a TCP
During a session, a client may open and close multiple reliable connection. During a session, a client may open and close multiple
transport connections to the server to issue RTSP requests for that reliable transport connections to the server to issue RTSP requests
session. for that session.
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 D describes how for the presentation description. However Appendix D 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. may also be applied to RTSP.
The RTSP 2.0 protocol supports the following operations: The RTSP 2.0 protocol supports the following operations:
Retrieval of media from media server: The client can either request Retrieval of media from media server: The client can either request
a presentation description via RTSP DESCRIBE, HTTP or some a presentation description via RTSP DESCRIBE, HTTP or some
other method. If the presentation is being multicast, the other method. If the presentation is being multicast, the
presentation description contains the multicast addresses and presentation description contains the multicast addresses and
ports to be used for the continuous media. If the presentation ports to be used for the continuous media. If the presentation
is to be sent only to the client via unicast, the client is to be sent only to the client via unicast, the client
provides the destination. provides the destination.
skipping to change at page 9, line 35 skipping to change at page 10, line 35
This memorandum specifies RTSP 2.0 which is an update of RTSP 1.0, a 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 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 to correct the many flaws that have been identified in RTSP 1.0 since
its publication. The corrections are such that backwards its publication. The corrections are such that backwards
compatibility was impossible. Thus a new version was deemed the most compatibility was impossible. Thus a new version was deemed the most
appropriate solution to get a more functional protocol. There are no appropriate solution to get a more functional protocol. There are no
plans to revise RTSP 1.0. Appendix I catalogs the changes of this plans to revise RTSP 1.0. Appendix I catalogs the changes of this
version in relation to RTSP 1.0. version in relation to RTSP 1.0.
RTSP 2.0 has reduced functionality compared to RTSP 1.0 and aims at RTSP 2.0 as specified in this memo has reduced functionality compared
specifying the RTSP core, functionality and rules for extensions, and to RTSP 1.0 and aims at specifying the RTSP core, functionality and
basic interaction with the media delivery protocol RTP [RFC3550]. rules for extensions, and basic interaction with the media delivery
protocol RTP [RFC3550].
Any other functionality would need to be published as extension Any other functionality would need to be published as extension
documents. This specification provides rules for such extensions and documents. This specification provides rules for such extensions and
defines registries to avoid naming collisions. 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 some 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 [RFC5234].
Indented and smaller-type paragraphs are used to provide informative Indented and smaller-type paragraphs are used to provide informative
background and motivation. This is intended to give readers who were background and motivation. This is intended to give readers who were
not involved with the formulation of the specification an not involved with the formulation of the specification an
understanding of why things are the way they are in RTSP. understanding of why things are the way they are in RTSP.
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].
skipping to change at page 14, line 5 skipping to change at page 14, line 26
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. Media Properties
When RTSP handles media it is important to consider the different
properties a media instance for playback can have. This
specification considers the below listed media properties in its
protocol operations. They are derived from the differencies between
a number of supported usages.
On-demand: Media that has a fixed (given) duration that doesn't
change during the life time of the RTSP session and are known at
the time of the creation of the session. It is expected that the
content of the media will not change, even if the representation,
i.e encoding, quality, etc, may change. Generally one can seek
within the media i.e. randomly access any range of the media
stream to playback.
Dynamic On-demand: This is a variation of the on-demand case where
external methods are used to manipulate the actual content of the
media setup for the RTSP session. The main example is where a
playlist determines the content of the session.
Live: Live media represents a progressing content stream (such as
broadcast TV) where the duration may or may not be known. It is
not seakable, only the content presently being delivered can be
accessed.
Live with Recording: A Live stream that is combined with a server
side capability to store and retain the content of the live
session for random access playback within the part of the already
recorded content. The actual behavior of the media stream is very
much depending on the retention policy for the media stream.
Either the server will be able to capture the complete media
stream, or it will have a limitation in how much will be retained.
The media range will dynamically change as the session progress.
For servers with a limited amount of storage available for
recording, there will be a sliding window that goes forwards while
data is made available and content that is older than the
limitation will be discarded.
Considering the above usages one get the following media properties
and their different instance values.
1.5.1. Random Access
Random Access, i.e. if one can request that the playback point is
moved from one point in the media duration to another. The following
different values are considered:
Random Access: Yes the media are seekable to any out of a large
number of points within the media. Due to media encoding
limitations a particular point may not be reachable, but seeking
to a point close by is enabled. A floating point number of
seconds may be provied to express the worst case distance between
random access points.
Return To Start: Seeking is only possible to begining of the
content.
No seeking: Seeking is not possible at all.
1.5.2. Retention
Media may have different retention policy in place that affect the
operation on the media. The following different media retention
policies are envisioned and taken into consideration where
applicable.
Unlimited: The media will not be removed as long as the RTSP session
are in existence.
Time Limited: The media will at least not be removed before given
wall clock time. After that time it may or may not be available
any more.
Duration limited Each indiviudal unit of the media will be retained
for the specified duration.
1.5.3. Content Modifications
There is also the question of how the content may change during time
for a give media resource:
Unmutable: The content of the media will not change, even if the
representation, i.e encoding, quality, etc, may change.
Dynamic: Between explicit updates the media content will not change,
but the content may change due to external methods or triggers,
such as playlists.
Time Progressing: As times progress new content will become
available. If the content also is retained it will become longer
and longer as everything between the start point and the point in
currently being made available can be accessed.
1.5.4. Mapping to the Attributes
This section exemplifies how one would map the above listed usages to
the properties and their values.
On-demand: Random Access: Random Access=5s, Content Modifications:
Unmutable, Retention: unlimted or time limited.
Dynamic On-demand: Random Access: Random Access=3s, Content
Modifications: Dynamic, Retention: unlimted or time limited.
Live: Random Access: No seeking, Content Modifications: Time
Progressing, Retention: Duration limited=0.0s
Live with Recording: Random Access: Random Access=3s, Content
Modifications: Time Progressing, Retention: Duration limited=2H
2. RTSP Introduction 2. RTSP Introduction
2.1. Protocol Properties 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.
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
digest authentication ([RFC2617]) are directly applicable. digest authentication ([RFC2617]) are directly applicable.
Transport-independent: RTSP does not preclude the use of unreliable Transport-independent: RTSP does not preclude the use of unreliable
datagram protocol (UDP) ([RFC0768]) as it would be possible to datagram protocol (UDP) ([RFC0768]) as it would be possible to
implement application-level reliability. The use of a implement application-level reliability. The use of a
connectionless datagram protocol such as UDP requires additional connectionless datagram protocol such as UDP requires additional
definition that may be provided as extensions to the core RTSP definition that may be provided as extensions to the core RTSP
skipping to change at page 15, line 33 skipping to change at page 18, line 33
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.
2.2. RTSP's Relationship to HTTP 2.2. RTSP's Relationship to HTTP
RTSP is intentionally similar in syntax and operation to HTTP/1.1 RTSP is intentionally similar in syntax and operation to HTTP/1.1
[RFC2616] so that extension mechanisms to HTTP can in most cases also [RFC2616] so that extension mechanisms to HTTP can in some cases also
be applied to RTSP. However, RTSP differs in a number of important be applied to RTSP. However, RTSP differs in a number of important
aspects from HTTP: 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.
skipping to change at page 16, line 43 skipping to change at page 19, line 43
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 16.32). Require headers (see Section 16.35).
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
skipping to change at page 18, line 46 skipping to change at page 21, line 46
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 16.44) to identify the RTSP session whose state is being (Section 16.49) 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 13.3). SETUP requests (Section 13.3).
2.6. Relationship with Other Protocols 2.6. 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
skipping to change at page 22, line 31 skipping to change at page 25, line 31
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. This memo has to rely on a
external solution to solve this issue.
3.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.
skipping to change at page 23, line 35 skipping to change at page 26, line 37
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.
3.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 [RFC2974] and SDP are intended to handle. However in use cases where
advanced features like access control to the multicast session are more advanced features like access control to the multicast session
desired, RTSP could be used for session establishment. are desired, RTSP could be used for session establishment.
A client desiring to join a live multicasted media session with A client desiring to join a live multicasted media session with
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
gives all interested an RTSP URI. The client connects to the server gives all interested an RTSP URI. The client connects to the server
and requests the presentation description, allowing configuration for and requests the presentation description, allowing configuration for
reception of the media. In this step it is possible for the client reception of the media. In this step it is possible for the client
to use secured transport and any desired level of authentication; for to use secured transport and any desired level of authentication; for
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.
skipping to change at page 24, line 15 skipping to change at page 27, line 16
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 for this multicast group with the RTSP server. The RTSP RTSP session for this multicast group with the RTSP server. The RTSP
server will not transmit any media, but instead will point to the server will not transmit any media, but instead will point to the
multicast group. The client and server will be able to keep the multicast group. The client and server will be able to keep the
session alive for as long as the receiver participates in the session session alive for as long as the receiver participates in the session
thus enabling, for 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 the
method like ANNOUNCE (see [RFC2326]) might be suitable; however, it PLAY_NOTIFY method (see Section 13.5) with a suitable extension could
will require a RTSP extension to revive the method. provide clear benefits.
4. Protocol Parameters 4. Protocol Parameters
4.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.
4.2. RTSP IRI and URI 4.2. RTSP IRI and URI
skipping to change at page 28, line 44 skipping to change at page 31, line 44
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
4.7. Feature-tags 4.7. Feature-tags
Feature-tags are unique identifiers used to designate features in Feature-tags are unique identifiers used to designate features in
RTSP. These tags are used in Require (Section 16.38), Proxy-Require RTSP. These tags are used in Require (Section 16.42), Proxy-Require
(Section 16.32), Proxy-Supported (Section 16.33), Unsupported (Section 16.35), Proxy-Supported (Section 16.36), and Unsupported
(Section 16.47), and header fields. (Section 16.52) header fields.
A feature-tag definition MUST indicate which combination of clients, A feature-tag definition MUST indicate which combination of clients,
servers or proxies they applies to. servers or proxies 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 22). IANA Section 22).
skipping to change at page 30, line 32 skipping to change at page 33, line 32
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.
5.1. Message Types 5.1. Message Types
See [H4.1]. RTSP messages consist of requests from client to server or server to
client and responses in the reverse direction. Request Section 7 and
Response Section 8 messages use the generic message format of RFC 822
[9] for transferring entities (the payload of the message). Both
types of message consist of a start-line, zero or more header fields
(also known as "headers"), an empty line (i.e., a line with nothing
preceding the CRLF) indicating the end of the header fields, and
possibly a message-body.
generic-message = start-line
*(message-header CRLF)
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
In the interest of robustness, servers SHOULD ignore any empty
line(s) received where a Request-Line is expected. In other words,
if the server is reading the protocol stream at the beginning of a
message and receives a CRLF first, it should ignore the CRLF.
5.2. Message Headers 5.2. Message Headers
See [H4.2]. See [H4.2].
5.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
skipping to change at page 32, line 23 skipping to change at page 35, line 23
| Header Name | Defined in Section | | Header Name | Defined in Section |
+--------------------+--------------------+ +--------------------+--------------------+
| Cache-Control | Section 16.10 | | Cache-Control | Section 16.10 |
| | | | | |
| Connection | Section 16.11 | | Connection | Section 16.11 |
| | | | | |
| CSeq | Section 16.19 | | CSeq | Section 16.19 |
| | | | | |
| Date | Section 16.20 | | Date | Section 16.20 |
| | | | | |
| Pipelined-Requests | Section 16.29 | | Media-Properties | Section 16.29 |
| | | | | |
| Proxy-Supported | Section 16.33 | | Media-Range | Section 16.30 |
| | | | | |
| Supported | Section 16.44 | | Pipelined-Requests | Section 16.32 |
| | | | | |
| Timestamp | Section 16.45 | | Proxy-Supported | Section 16.36 |
| | | | | |
| Via | Section 16.50 | | Seek-Style | Section 16.45 |
| | |
| Supported | Section 16.49 |
| | |
| Timestamp | Section 16.50 |
| | |
| Via | Section 16.55 |
+--------------------+--------------------+ +--------------------+--------------------+
Table 1: The general headers used in RTSP Table 1: The general headers used in RTSP
7. Request 7. Request
A request message uses the format outlined below regardless of the A request message uses the format outlined below regardless of the
direction of a request, client to server or server to client: direction of a request, 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,
skipping to change at page 34, line 10 skipping to change at page 37, line 10
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 13.2 | | DESCRIBE | Section 13.2 |
| | | | | |
| GET_PARAMETER | Section 13.7 | | GET_PARAMETER | Section 13.8 |
| | | | | |
| OPTIONS | Section 13.1 | | OPTIONS | Section 13.1 |
| | | | | |
| PAUSE | Section 13.5 | | PAUSE | Section 13.6 |
| | | | | |
| PLAY | Section 13.4 | | PLAY | Section 13.4 |
| | | | | |
| REDIRECT | Section 13.9 | | PLAY_NOTIFY | Section 13.5 |
| | |
| REDIRECT | Section 13.10 |
| | | | | |
| SETUP | Section 13.3 | | SETUP | Section 13.3 |
| | | | | |
| SET_PARAMETER | Section 13.8 | | SET_PARAMETER | Section 13.9 |
| | | | | |
| TEARDOWN | Section 13.6 | | TEARDOWN | Section 13.7 |
+---------------+--------------------+ +---------------+--------------------+
Table 2: The RTSP Methods Table 2: The RTSP Methods
The syntax of the RTSP request line is the following: The syntax of the RTSP request line is the following:
<Method> <Request-URI> <RTSP-Version> CRLF <Method> <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
skipping to change at page 35, line 49 skipping to change at page 38, line 51
| Blocksize | Section 16.9 | | Blocksize | Section 16.9 |
| | | | | |
| From | Section 16.23 | | From | Section 16.23 |
| | | | | |
| If-Match | Section 16.24 | | If-Match | Section 16.24 |
| | | | | |
| If-Modified-Since | Section 16.25 | | If-Modified-Since | Section 16.25 |
| | | | | |
| If-None-Match | Section 16.26 | | If-None-Match | Section 16.26 |
| | | | | |
| Proxy-Require | Section 16.32 | | Notify-Reason | Section 16.31 |
| | | | | |
| Range | Section 16.35 | | Proxy-Require | Section 16.35 |
| | | | | |
| Referer | Section 16.36 | | Range | Section 16.38 |
| | | | | |
| Require | Section 16.38 | | Referer | Section 16.39 |
| | | | | |
| Scale | Section 16.40 | | Request-Status | Section 16.41 |
| | | | | |
| Session | Section 16.43 | | Require | Section 16.42 |
| | | | | |
| Speed | Section 16.41 | | Scale | Section 16.44 |
| | | | | |
| Supported | Section 16.44 | | Session | Section 16.48 |
| | | | | |
| Transport | Section 16.46 | | Speed | Section 16.46 |
| | | | | |
| User-Agent | Section 16.48 | | Supported | Section 16.49 |
| | |
| Transport | Section 16.51 |
| | |
| User-Agent | Section 16.53 |
+--------------------+--------------------+ +--------------------+--------------------+
Table 3: The RTSP request headers Table 3: The RTSP request headers
Detailed headers definition are provided in Section 16. 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 processing of the header. actually happens.
8. 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.
skipping to change at page 40, line 10 skipping to change at page 43, line 10
| 460 | Only Aggregate Operation Allowed | all | | 460 | Only Aggregate Operation Allowed | all |
| | | | | | | |
| 461 | Unsupported Transport | all | | 461 | Unsupported Transport | all |
| | | | | | | |
| 462 | Destination Unreachable | all | | 462 | Destination Unreachable | all |
| | | | | | | |
| 463 | Destination Prohibited | SETUP | | 463 | Destination Prohibited | SETUP |
| | | | | | | |
| 464 | Data Transport Not Ready Yet | PLAY | | 464 | Data Transport Not Ready Yet | PLAY |
| | | | | | | |
| 465 | Notification Reason Unknown | PLAY_NOTIFY |
| | | |
| 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 | | 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 |
skipping to change at page 41, line 18 skipping to change at page 44, line 18
| Accept-Credentials | Section 16.2 | | Accept-Credentials | Section 16.2 |
| | | | | |
| Accept-Ranges | Section 16.5 | | Accept-Ranges | Section 16.5 |
| | | | | |
| Connection-Credentials | Section 16.12 | | Connection-Credentials | Section 16.12 |
| | | | | |
| ETag | Section 16.21 | | ETag | Section 16.21 |
| | | | | |
| Location | Section 16.28 | | Location | Section 16.28 |
| | | | | |
| Proxy-Authenticate | Section 16.30 | | Proxy-Authenticate | Section 16.33 |
| | | | | |
| Public | Section 16.34 | | Public | Section 16.37 |
| | | | | |
| Range | Section 16.35 | | Range | Section 16.38 |
| | | | | |
| Retry-After | Section 16.37 | | Retry-After | Section 16.40 |
| | | | | |
| RTP-Info | Section 16.39 | | RTP-Info | Section 16.43 |
| | | | | |
| Scale | Section 16.40 | | Scale | Section 16.44 |
| | | | | |
| Session | Section 16.43 | | Session | Section 16.48 |
| | | | | |
| Server | Section 16.42 | | Server | Section 16.47 |
| | | | | |
| Speed | Section 16.41 | | Speed | Section 16.46 |
| | | | | |
| Transport | Section 16.46 | | Transport | Section 16.51 |
| | | | | |
| Unsupported | Section 16.47 | | Unsupported | Section 16.52 |
| | | | | |
| Vary | Section 16.49 | | Vary | Section 16.54 |
| | | | | |
| WWW-Authenticate | Section 16.51 | | WWW-Authenticate | Section 16.56 |
+------------------------+--------------------+ +------------------------+--------------------+
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.
9. 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 GET_PARAMETER request and response, and DESCRIBE The SET_PARAMETER and GET_PARAMETER request and response, and
response MAY have an entity. All 4xx and 5xx responses MAY also have DESCRIBE response MAY have an entity. All 4xx and 5xx responses MAY
an entity. also have 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.
9.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.
skipping to change at page 47, line 23 skipping to change at page 50, line 23
In light of the above, it is RECOMMENDED that clients use persistent In light of the above, it is RECOMMENDED that clients use persistent
connections whenever possible. A client that supports persistent connections whenever possible. A client that supports persistent
connections MAY "pipeline" its requests (see Section 12). connections MAY "pipeline" its requests (see Section 12).
10.3. Closing Connections 10.3. Closing Connections
The client MAY close a connection at any point when no outstanding The client MAY close a connection at any point when no outstanding
request/response transactions exist for any RTSP session being request/response transactions exist for any RTSP session being
managed through the connection. The server, however, SHOULD NOT managed through the connection. The server, however, SHOULD NOT
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 16.43). A server SHOULD NOT connection have been timed out (Section 16.48). 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
skipping to change at page 48, line 38 skipping to change at page 51, 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 16.45) in request/response cycle using the Timestamp header (Section 16.50) in
any RTSP request. any RTSP request.
10.5. Showing Liveness 10.5. Showing Liveness
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
skipping to change at page 49, line 16 skipping to change at page 52, line 16
RTCP: If RTP is used for media transport RTCP SHOULD be used. If RTCP: If RTP is used for media transport RTCP SHOULD be used. If
RTCP is used to report transport statistics, it SHALL also work RTCP is used to report transport statistics, it SHALL also work
as keep alive. The server can determine the client by used as keep alive. The server can determine the client by used
network address and port together with the fact that the client network address and port together with the fact that the client
is reporting on the servers SSRC(s). A downside of using RTCP is reporting on the servers SSRC(s). A downside of using RTCP
is that it only gives statistical guarantees to reach the is that it only gives statistical guarantees to reach the
server. However that probability is so low that it can be server. However that probability is so low that it can be
ignored in most cases. For example, a session with 60 seconds ignored in most cases. For example, a session with 60 seconds
timeout and enough bitrate assigned to RTCP messages to send a timeout and enough bitrate assigned to RTCP messages to send a
message from client to server on average every 5 seconds. That message from client to server on average every 5 seconds. That
client have for a network with 5 \% packet loss, the client have for a network with 5 % packet loss, the probability
probability to fail showing liveness sign in that session to fail showing liveness sign in that session within the
within the timeout interval of 2.4*E-16. In sessions with timeout interval of 2.4*E-16. In sessions with shorter timeout
shorter timeout times, or much higher packet loss, or small times, or much higher packet loss, or small RTCP bandwidths
RTCP bandwidths SHOULD also use any of the mechanisms below. SHOULD also use any of the mechanisms below.
SETPARAMETER: When using SETPARAMETER for keep alive, no body SHOULD SET_PARAMETER: When using SET_PARAMETER for keep alive, no body
be included. This method is the RECOMMENDED RTSP method to use SHOULD be included. This method is the RECOMMENDED RTSP method
in request only intended to perform keep-alive. to use in request only intended to perform keep-alive.
OPTIONS: This method does also work. However it causes the server OPTIONS: This method does also work. However it causes the server
to perform more unnecessary processing and result in bigger to perform more unnecessary processing and result in bigger
responses than necessary for the task. The reason for this is responses than necessary for the task. The reason for this is
that the server needs to determine what capabilities that are that the server needs to determine what capabilities that are
associated with the media resource to correctly populate the associated with the media resource to correctly populate the
Public and Allow headers. Public and Allow headers.
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
skipping to change at page 52, line 24 skipping to change at page 55, line 24
by the CSeq header and its sequence number. For TCP the delivery by the CSeq header and its sequence number. For TCP the delivery
order will be the same as the sending order. The processing of the order will be the same as the sending order. The processing of the
request SHALL also have been finished before processing the next request SHALL also have been finished before processing the next
request from the same entity. The responses MUST be sent in the request from the same entity. The responses MUST be sent in the
order the requests was processed. order the requests was processed.
RTSP 2.0 has extended support for pipelining compared to RTSP 1.0. 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 The major improvement is to allow all requests to setup and initiate
media playback to be pipelined after each other. This is media playback to be pipelined after each other. This is
accomplished by the utilization of the Pipelined-Requests header (see accomplished by the utilization of the Pipelined-Requests header (see
Section 16.29). This header allows a client to request that two or Section 16.32). This header allows a client to request that two or
more requests is to be processed in the same RTSP session context more requests is to be processed in the same RTSP session context
which the first request creates. In other words a client can request 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 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 needing to wait for a single response. This speeds up the initial
startup time for an RTSP session with at least one RTT. startup time for an RTSP session with at least one RTT.
If a pipelined request builds on the succesful completion of one or If a pipelined request builds on the succesful completion of one or
more prior requests the requestor must verify that all requests were more prior requests the requestor must verify that all requests were
executed as expected. A common example will be two SETUP requests executed as expected. A common example will be two SETUP requests
and a PLAY request. In case one of the SETUP fails unexpectedly, the and a PLAY request. In case one of the SETUP fails unexpectedly, the
skipping to change at page 53, line 11 skipping to change at page 56, line 11
two will be played. In this case the client can send a PAUSE 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 request, correct the failing SETUP request and then request it to be
played. played.
13. Method Definitions 13. Method Definitions
The method indicates what is to be performed on the resource The method indicates what is to be performed on the resource
identified by the Request-URI. The method name is case-sensitive. identified by the Request-URI. The method name is case-sensitive.
New methods may be defined in the future. Method names 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 20. The methods by the ABNF [RFC5234] in the syntax chapter Section 20. 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 |
| | | | | | | | | | | |
| GET_PARAMETER | 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=Req, R=Opt | | OPTIONS | C -> S | P,S | R=Req, | Sd=Req, R=Opt |
| | | | Sd=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 |
| | | | | | | | | | | |
| PLAY_NOTIFY | S -> C | 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 |
| | | | | | | | | | | |
| SET_PARAMETER | C -> S | P,S | required | optional | | SET_PARAMETER | C -> S | P,S | required | optional |
| | | | | | | | | | | |
| | S -> C | | | | | | S -> C | | | |
| | | | | | | | | | | |
| TEARDOWN | C -> S | P,S | required | required | | TEARDOWN | C -> S | P,S | required | required |
+---------------+-----------+--------+--------------+---------------+ +---------------+-----------+--------+--------------+---------------+
skipping to change at page 54, line 46 skipping to change at page 58, line 4
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 16.43. An OPTIONS request intended for signalling, see Section 16.48. 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 56, line 12 skipping to change at page 59, line 12
Example: Example:
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
CSeq: 312 CSeq: 312
User-Agent: PhonyClient 1.2 User-Agent: PhonyClient 1.2
Accept: application/sdp, application/example Accept: application/sdp, application/example
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 312 CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1 Server: PhonyServer 1.1
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 367 Content-Length: 367
v=0 v=0
o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
u=http://www.example.com/lectures/sdp.ps u=http://www.example.com/lectures/sdp.ps
e=seminar@example.com (Seminar Management) e=seminar@example.com (Seminar Management)
skipping to change at page 57, line 17 skipping to change at page 60, line 17
It is RECOMMENDED that minimal servers support the DESCRIBE method, It is RECOMMENDED that minimal servers support the DESCRIBE method,
and highly recommended that minimal clients support the ability to and highly recommended that minimal clients support the ability to
act as "helper applications" that accept a media initialization file act as "helper applications" that accept a media initialization file
from a user interface, and/or other means that are appropriate to the from a user interface, and/or other means that are appropriate to the
operating environment of the clients. operating environment of the clients.
13.3. SETUP 13.3. SETUP
The 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 two
different cases; Create an RTSP session, add a media to a session, different cases; Create an RTSP session and change the transport
and change the transport parameters of already set up media stream. parameters of already set up media stream. SETUP can be used in all
Using SETUP to add media to an existing session, when the session is
in PLAY state, is unspecified. Otherwise SETUP can be used in all
three states; INIT, and READY, for both purposes and in PLAY to three states; INIT, and READY, for both purposes and in PLAY to
change the transport parameters. change the transport parameters. There is also a third possibile
usage for the SETUP method which is not specified in this memo:
adding a media to a session. Using SETUP to add media to an existing
session, when the session is in PLAY state, is unspecified.
The Transport header, see Section 16.46, specifies the transport The Transport header, see Section 16.51, 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 descending order of server. This allows the client to enumerate in descending order of
preference the transport mechanisms and parameters acceptable to it, preference the transport mechanisms and parameters acceptable to it,
while the server can select the most appropriate. It is expected while the server can select the most appropriate. It is expected
that the session description format used will enable the client to that the session description format used will enable the client to
select a limited number possible configurations that are offered to select a limited number possible configurations that are offered to
the server to choose from. All transport related parameters shall be the server to choose from. All transport related parameters shall be
included in the Transport header, the use of other headers for this included in the Transport header, the use of other headers for this
purpose is discouraged due to middleboxes, such as firewalls or NATs. purpose is discouraged due to middleboxes, such as firewalls or NATs.
skipping to change at page 58, line 13 skipping to change at page 61, line 14
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 16.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.
The SETUP response 200 OK SHALL include the Media-Properties header
(see Section 16.29 ). The combination of the parameters of the
Media-Properties header indicate the nature of the content (see also
Section 1.5). For example, a live stream with time shifting is
indicated by
o Random Access set to Random-Access,
o Content Modifications set to Time Progressing,
o Retention set to Time-Duration (with specific recording window
time value).
The SETUP response 200 OK SHALL include the Media-Range header (see
Section 16.30) if the media is Time-Progressing.
A basic example for SETUP:
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 Accept-Ranges: NPT, UTC
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 302 CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1 Server: PhonyServer 1.1
Session: 47112344;timeout=60 Session: 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
Media-Properties: Random-Access=3.2, Time-Progressing,
Time-Duration=3600.0
Media-Range: npt=0-2893.23
In the above example the client wants to create an RTSP session In the above example the client wants to create an RTSP session
containing the media resource "rtsp://example.com/foo/bar/baz.rm". containing the media resource "rtsp://example.com/foo/bar/baz.rm".
The transport parameters acceptable to the client is either RTP/AVP/ The transport parameters acceptable to the client is either RTP/AVP/
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
skipping to change at page 59, line 10 skipping to change at page 62, line 32
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
not been given an aggregated control URI is unspecified. not been given an aggregated control URI is unspecified.
While the session ID sometimes has enough information for While the session ID sometimes has enough information for
aggregate control of a session, the Aggregate control URI is still aggregate control of a session, the Aggregate control URI is still
important for some methods such as SETPARAMETER where the control important for some methods such as SET_PARAMETER where the control
URI enables the resource in question to be easily identified. The URI enables the resource in question to be easily identified. The
Aggregate control URI is also useful for proxies, enabling them to Aggregate control URI is also useful for proxies, enabling them to
route the request to the appropriate server, and for logging, route the request to the appropriate server, and for logging,
where it is useful to note the actual resource that a request was where it is useful to note the actual resource that a request was
operating on. operating on.
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 16.43. Signs of liveness for an RTSP further discussion see Section 16.48. 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.
skipping to change at page 60, line 32 skipping to change at page 64, line 7
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.
13.4. PLAY 13.4. PLAY
The PLAY method tells the server to start sending data via the This section describes the usage of the PLAY method in general, for
mechanism specified in SETUP. PLAY requests are valid when the aggregated sessions, and in different usage scenarios.
session is in READY or PLAY states. A PLAY request MUST include a
Session header to indicate which session the request applies to.
For aggregated sessions where the initial SETUP request (creating a 13.4.1. General Usage
session) is followed by one or more additional SETUP request, a PLAY
request MAY be pipelined after those additional SETUP requests
without awaiting their responses. This procedure can reduce the
delay from start of session establishment until media play-out has
started with one round trip time. However an client needs to be
aware that using this procedure will result in the playout of the
server state established at the time of processing the PLAY, i.e.,
after the processing of all the requests prior to the PLAY request in
the pipeline. This may not be the intended one due to failure of any
of the prior requests. However a client easily determine this based
on the responses from those requests. In case of failure the client
can halt the media playout using PAUSE and try to establish the
intended state again before issuing another PLAY request.
In an aggregated session the PLAY request MUST contain an aggregated The PLAY method tells the server to start sending data via the
control URI. A server SHALL responde with error 460 (Only Aggregate mechanism specified in SETUP and which part of the media should be
Operation Allowed) if the client PLAY Request-URI is for one of the played out. PLAY requests are valid when the session is in READY or
media. The media in an aggregate SHALL be played in sync. If a PLAY states. A PLAY request MUST include a Session header to
client want individual control of the media it needs to use separate indicate which session the request applies to.
RTSP sessions for each media.
Upon receipt of the PLAY request, the server SHALL position the Upon receipt of the PLAY request, the server SHALL position the
normal play time to the beginning of the range specified in the normal play time to the beginning of the range specified in the
received Range header and delivers stream data until the end of the received Range header and delivers stream data until the end of the
range if given, or until a new PLAY request is received, else to the range if given, or until a new PLAY request is received, else to the
end of the media is reached. To allow for precise composition end of the media is reached. To allow for precise composition
multiple ranges MAY be specified in one PLAY Request. The range multiple ranges MAY be specified in one PLAY Request. The range
values are valid if all given ranges are part of any media within the values are valid if all given ranges are part of any media within the
aggregate. If a given range value points outside of the media, the aggregate. If a given range value points outside of the media, the
response SHALL be the 457 (Invalid Range) error code. 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-
Seek-Style: RAP
User-Agent: PhonyClient/1.2 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. The
Range header MUST NOT contain a time parameter. The usage of time in
PLAY method has been deprecated. If a request with time parameter is
received the server SHOULD respond with a 457 (Invalid Range) to
indicate that the time parameter is not supported. If no range is
specified in the request, the start position SHALL still be returned
in the reply. If the medias that are part of an aggregate has
different lengths, the PLAY request SHALL be performed 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 given play-out
point.
The Range header MUST NOT contain a time parameter. The usage of A client desiring to play the media from the beginning MUST send a
time in PLAY method has been deprecated. If a request with time PLAY request with a Range header pointing at the beginning, e.g.
parameter is received the server SHOULD respond with a 457 (Invalid npt=0-. If a PLAY request is received without a Range header when
Range) to indicate that the time parameter is not supported. media delivery has stopped at the end, the server SHOULD respond with
a 457 "Invalid Range" error response. In that response the current
pause point in a Range header SHALL be included.
All range specifiers in this specification allow for ranges with
unspecified begin times (e.g. "npt=-30"). When used in a PLAY
request, the server treats this as a request to start/resume playback
from the current pause point, ending at the end time specified in the
Range header. If the pause point is located later than the given end
value, a 457 (Invalid Range) response SHALL be given.
Server MUST include a "Range" header in any PLAY response. The Server MUST include a "Range" header in any PLAY response. The
response MUST use the same format as the request's range header response MUST use the same format as the request's range header
contained. If no Range header was in the request, the NPT time contained. If no Range header was in the request, the format used in
format SHOULD be used unless the client showed support for an other any previous PLAY request within the session SHOULD be used. If no
format more appropriate. Also for a session with live media streams format has been indicated in a previous request the server MAY use
the Range header MUST indicate a valid time. It is RECOMMENDED that any time format supported by the media and indicated in the Accept-
normal play time is used, either the "now" indicator, for example Ranges header in the SETUP respone. It is RECOMMENDED that NPT is
"npt=now-", or the time since session start as an open interval, e.g. used if supported by the media.
"npt=96.23-". An absolute time value (clock) for the corresponding
time MAY be given, i.e. "clock=20030213T143205Z-". The UTC clock
format SHOULD only be used if client has shown support for it.
For an on-demand stream, the server MUST reply with the actual range A PLAY response MAY include a header(s) carrying synchronization
that will be played back, i.e. for which duration any media (having information. As the information necessary is dependent on the media
content at this time) is delivered. This may differ from the transport format, further rules specifying the header and its usage
requested range if alignment of the requested range to valid frame is needed. For RTP the RTP-Info header is specified, see
boundaries is required for the media source. Note that some media Section 16.43, and used in the following example.
streams in an aggregate may need to be delivered from even earlier
points. Also, some media format have a very long duration per Here is a simple example for a single audio stream where the client
individual data unit, therefore it might be necessary for the client requests the media starting from 3.52 seconds. The server sends a
to parse the data unit, and select where to start. 200 OK response with the actual play time (equal to the requested in
this case) and the RTP-Info header that contains the necessary
parameters for the RTP stack.
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- User-Agent: PhonyClient/1.2 Range: npt=3.52-
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: Thu, 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 For media with random-access, the server MUST reply with the actual
stretches all the way up and past the requested playtime. Thus, it range that will be played back, i.e. for which duration any media
is the client's decision if to render to the user the time between (having content at this time) is delivered. This may differ from the
requested range if alignment of the requested range to valid frame
boundaries is required for the media source. Note that some media
streams in an aggregate may need to be delivered from even earlier
points. Also, some media format have a very long duration per
individual data unit, therefore it might be necessary for the client
to parse the data unit, and select where to start. The client can
express its desired handling by the server by including the Seek-
Style header (Section 16.45) in the PLAY request, if desired.
In the following example the client receives the first media packet
that 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
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 C->S: PLAY rtsp://example.com/audio RTSP/2.0
point in time all media streams carrying active content can actually CSeq: 836
be delivered. Therefore a server MAY specify a start time (or now-) Session: 12345678
in the range header, for which not all media will be available from. Range: npt=7.05- User-Agent: PhonyClient/1.2
If no range is specified in the request, the start position SHALL S->C: RTSP/2.0 200 OK
still be returned in the reply. If the medias that are part of an CSeq: 836
aggregate has different lengths, the PLAY request SHALL be performed Date: Thu, 23 Jan 1997 15:35:06 GMT
as long as the given range is valid for any media, for example the Server: PhonyServer 1.0
longest media. Media will be sent whenever it is available for the Range: npt=3.52-
given play-out point. RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545
A PLAY response MAY include a header(s) carrying synchronization S->C: RTP Packet TS=2345962545 => NPT=3.52
information. As the information necessary is dependent on the media Duration=4.15 seconds
transport format, further rules specifying the header and its usage
is needed. For RTP the RTP-Info header is specified, see
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
it currently was until the specified end point. This is useful to it currently was until the specified end point. This is useful to
change ongoing playback to play another sequence, or end at another change ongoing playback to play another sequence, or end at another
point than in the previous request. point than in the previous request.
A client desiring to play the media from the beginning MUST send a
PLAY request with a Range header pointing at the beginning, e.g.
npt=0-. If a PLAY request is received without a Range header when
media delivery has stopped at the end, the server SHOULD respond with
a 457 "Invalid Range" error response. In that response the current
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 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: Thu, 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 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: Thu, 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 13.4.2. Aggregated Sessions
unspecified begin times (e.g. "npt=-30"). When used in a PLAY
request, the server treats this as a request to start/resume playback
from the current pause point, ending at the end time specified in the
Range header. If the pause point is located later than the given end
value, a 457 (Invalid Range) response SHALL be given.
The possibility to replace a current PLAY request with a new one PLAY requests can operate on sessions controlling a single media and
replaces two RTSP 1.0 functions: on aggregated sessions controlling multiple media.
In an aggregated session the PLAY request MUST contain an aggregated
control URI. A server SHALL responde with error 460 (Only Aggregate
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
client wants individual control of the media it needs to use separate
RTSP sessions for each media.
For aggregated sessions where the initial SETUP request (creating a
session) is followed by one or more additional SETUP request, a PLAY
request MAY be pipelined after those additional SETUP requests
without awaiting their responses. This procedure can reduce the
delay from start of session establishment until media play-out has
started with one round trip time. However an client needs to be
aware that using this procedure will result in the playout of the
server state established at the time of processing the PLAY, i.e.,
after the processing of all the requests prior to the PLAY request in
the pipeline. This may not be the intended one due to failure of any
of the prior requests. However a client easily determine this based
on the responses from those requests. In case of failure the client
can halt the media playout using PAUSE and try to establish the
intended state again before issuing another PLAY request.
13.4.3. Updating current PLAY Requests
Clients can issue PLAY request while the stream is In PLAYING state
and thus updating their request. The possibility to replace a
current PLAY request with a new one replaces the following RTSP 1.0
functions based on PLAY in play state:
o The queued play functionality described in RFC 2326 [RFC2326] is o The queued play functionality described in RFC 2326 [RFC2326] is
removed and multiple ranges can be used to achieve a similar removed and multiple ranges can be used to achieve a similar
functionality. functionality in combination with the possibility to replace
previous play messages.
o The use of PLAY for keep-alive signaling, i.e. PLAY request o The use of PLAY for keep-alive signaling, i.e. PLAY request
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, SET_PARAMETER (recommended) or OPTIONS
(allowed) for keep alive. (allowed) for keep alive.
An example of using PLAY request to change the behavior, if a server The important difference compared to a PLAY request in ready state is
has received requests to play ranges 10 to 15 and then 13 to 20 (that the handling of the current playpoint and how the range header in
is, overlapping ranges), a PLAY request 4 seconds after the first request is constructed. The session is actively playing media and
would take effect while the server plays the first range. Thus the playpoint will be moving making the exact time a request will
changing the behavior to continue to play to 25 seconds, i.e. the take action is hard to predict. Depending on how the PLAY header
played range equal play with range: npt=10-25. If the second PLAY appears two different cases exist: total replacement or continuation.
request would arrive as the second range in the first request was A total replacement is signalled by having the first range
playing, then the equivalent request would be play with range:npt=10- specification have an explicit start value, e.g. npt=45- or
15,npt=13-25. npt=45-60, in which case the server stops playout at the current
playout point and then starts delivering media according to the Range
header. This is equivalent to having the client first send a PAUSE
and then a new play request that isn't based on the pause point. In
the case of continuation the first range specifier has an open start
point and a explict stop value (Z), e.g. npt=-60, which indicate that
it SHALL convert the range specifier being played prior to this PLAY
request (X to Y) into (X to Z) and continue as this was the request
originally played. For both total replacement and continuation the
PLAY request SHALL remove any additional range specifiers present in
the previous request and add any that is present in the new PLAY
request.
An example of this behavior. The server has received requests to
play ranges 10 to 15 and then 13 to 20 (that is, overlapping ranges).
If the new PLAY request arrives at the server 4 seconds after the
previous one, it will take effect while the server plays the first
range (10-15). Thus changing the behavior of this range to continue
to play to 25 seconds, i.e. the equivalent single request would be
PLAY with range: npt=10-25. Note that the second range (13-20) is
deleted and never comes into effect. If the new PLAY request would
arrive as the second range in the first request was playing (13-20
and shown below), then the equivalent single request would be play
with range:npt=10-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 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: Thu, 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 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: Thu, 23 Jan 1997 15:35:09 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=14-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
13.5. PAUSE 13.4.4. Playing On-Demand Media
On-demand media is indicated by the content of the Media-Properties
header in the SETUP response by (see also Section 16.29):
o Random-Access property is set to Random Acces;
o Content Modifications set to unmutable;
o Retetion set Unlimited or Time-Limited.
Playing on-demand media follows the general usage as described in
Section 13.4.1.
13.4.5. Playing Dynamic On-Demand Media
Dynamic on-demand media is indicated by the content of the Media-
Properties header in the SETUP response by (see also Section 16.29):
o Random-Access set to Random Access;
o Content Modifications set to dynamic;
o Retetion set unlimited or Time-Limited.
Playing on-demand media follows the general usage as described in
Section 13.4.1 as long as the media has not been changed.
There are ways for the client to get informed about changed of media
resources in play state, if the resource was changed. The client
will receive a PLAY_NOTIFY request with Notify-Reason header set to
media-properties-update (see Section 13.5.2. The client can use the
value of the Media-Range to decide further actions, if the Media-
Range header is present in the PLAY_NOTIFY request. The second way
is that the client issues a GET_PARAMETER request without a body but
including a Media-Range header. The 200 OK response SHALL include
the current Media-Range header (see Section 16.30).
13.4.6. Playing Live Media
Live media is indicated by the content of the Media-Properties header
in the SETUP response by (see also Section 16.29):
o Random-Access set to no-seeking;
o Content Modifications set to Time-Progressing;
o Retetion with Time-Duration set to 0.0.
For live media, the SETUP response 200 OK SHALL include the Media-
Range header (see Section 16.30).
A client MAY send PLAY requests without the Range header, if the
request include the Range header it SHALL use a symbolic value
representing "now". For NPT that range specification is "npt=now-".
The server SHALL include the Range header in the response and it MUST
indicate a explict time value and not a symbolic value. In other
words npt=now- is not a valid to use in the respone. Instead the
time since session start is recommended expressed as an open
interval, e.g. "npt=96.23-". An absolute time value (clock) for the
corresponding time MAY be given, i.e. "clock=20030213T143205Z-". The
UTC clock format SHOULD only be used if client has shown support for
it.
13.4.7. Playing Live with Recording
Certain media server may offer recording services of live sessions to
their clients. This recording would normally be from the begining of
the media session. Clients can randomly access the media between now
and the begining of the media session. This live media with
recording is indicated by the content of the Media-Properties header
in the SETUP response by (see also Section 16.29):
o Random-Access set to random-access;
o Content Modifications set to Time-Progressing;
o Retetion set to Time-limited or Unlimited
The SETUP response 200 OK SHALL include the Media-Range header (see
Section 16.30) for this type of media. For live media with recording
the Range header indicates the current playback time in the media and
the Media Range indicates the currently available media window around
the current time. This window can cover recorded content in the past
(seen from current time in the media) or recorded content in the
future (seen from current time in the media). The server adjusts the
play point to the requested border of the window, if the client
requests a play point that is located outside the recording windows,
e.g., if requested to far in the past, the server selects the oldest
range in the recording. The considerations in Section 13.5.3 apply,
if a client requests playback at Scale (Section 16.44) values other
than 1.0 (Normal playback rate) while playing live media with
recording.
13.4.8. Playing Live with Time-Shift
Certain media server may offer time-shift services to their clients.
This time shift records a fixed interval in the past, i.e., a sliding
window recording mechanism, but not past this interval. Clients can
randomly access the media between now and the interval. This live
media with recording is indicated by the content of the Media-
Properties header in the SETUP response by (see also Section 16.29):
o Random-Access set to random-access;
o Content Modifications set to Time-Progressing;
o Retetion set to Time-Duration and a value indicating the recording
interval (>0).
The SETUP response 200 OK SHALL include the Media-Range header (see
Section 16.30) for this type of media. For live media with recording
the Range header indicates the current time in the media and the
Media Range indicates a window around the current time. This window
can cover recorded content in the past (seen from current time in the
media) or recorded content in the future (seen from current time in
the media). The server adjusts the play point to the requested
border of the window, if the client requests a play point that is
located outside the recording windows, e.g., if requested to far in
the past, the server selects the oldest range in the recording. The
considerations in Section 13.5.3 apply, if a client requests playback
at Scale (Section 16.44) values other than 1.0 (Normal playback rate)
while playing live media with time-shift.
13.5. PLAY_NOTIFY
The PLAY_NOTIFY method is issued by a server to inform a client about
an ansynchronous event for a session in play state. The Session
header MUST be presented in a PLAY_NOTIFY request and indicates the
scope of the request. Sending of PLAY_NOTIFY requests requires a
persistent connection between server and client, otherwise there is
no way for the server to send this request method to the client.
PLAY_NOTIFY requests have an end-to-end (i.e. server to client)
scope, as they carry the Session header, and apply only to the given
session. The client SHOULD immediately return a response to the
server.
PLAY_NOTIFY requests MAY be used with a message body, depending on
the value of the Notify-Reason header. It is described in the
particular section for each Notify-Reason if a message body is used.
However, currently there is no Notify-Reason that allows using a
message body. There is the need to obey some limitations, when
adding new Notify-Reasons that intend to use a message body: The
server can send any type of message body, but it is not ensured that
the client can understand the received message body. This is related
to DESCRIBE (seeSection 13.2 ), but there the client can state its
acceptable message bodies by using the Accept header. In case of
PLAY_NOTIFY, the server does not know which message bodies are
understood by the client.
The Notify-Reason header (see Section 16.31) specifies the reason why
the server sends the PLAY_NOTIFY request. This is extensible and new
reasons MAY be added in the future. In case the client does not
understand the reason for the notification it SHALL respond with an
465 (Notification Reason Unknown) (Section 15.4.17) error code.
Servers can send PLAY_NOTIFY with these types:
o end-of-stream (see Section 13.5.1);
o media-properties-update (see Section 13.5.2);
o and scale-change (see Section 13.5.3).
13.5.1. End-of-Stream
A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream
indicates the end of the media streams has been reached or will be in
the near future for the given session aggregate. The request SHALL
NOT be issued unless the server is in the playing state. The end of
the media stream delivery notification may be for either succesful
completion of the PLAY request currently being served or indicate
some error resulting in failure to complete the request. The
Request-Status header (Section 16.41) SHALL be included to indicate
which request the notification is for and its completion status. The
message response status codes (Section 8.1.1) are used to indicate
how the PLAY request concluded. In case a PLAY_NOTIFY was issues
prior to the actual completion and some error occured resulting in
that the previosuly sent was in error a new Notification MUST be sent
including the correct status for the completion and all additional
information.
PLAY_NOTIFY requests with Notify-Reason header set to end-of-stream
MUST include a Range header. The Range header indicates the point in
the stream or streams where delivery was/are ending with the
timescale that has been used by the client in the PLAY request being
fulfilled. For normal play time it is not alllowed to use "now" as
server do know the real ending time of the media stream and now
carries no information to determine what has/will be delivered. When
end-of-stream notifications are issued prior to having sent the last
media packets, this is evident as the end time in the Range header is
beyond the current time in the media being received by the client,
e.g., npt=-15, if npt is currently at 14.2 seconds.
If RTP is used as media transport, a RTP-Info header MUST be
included, and the RTP-Info header MUST indicate the last sequence
number in the seq parameter.
A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream
MUST NOT carry a message body.
This example request notifies the client about a future end-of-stream
event:
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 854
Notify-Reason: end-of-stream
Request-Status: cseq=853 status=200 reason="OK"
Range: npt=-145
RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545
Session: uZ3ci0K+Ld-M
C->S: RTSP/2.0 200 OK
CSeq: 854
User-Agent: PhonyClient/1.2
13.5.2. Media-Properties-Update
A PLAY_NOTIFY request with Notify-Reason header set to media-
properties-update indicates an update of the media properties for the
given session (see Section 16.29) and/or the available media range
that can be played as indicated by Media-Range (Section 16.30).
PLAY_NOTIFY requests with Notify-Reason header set to media-
properties-update MUST include a Media-Properties and Date header and
SHOULD include a Media-Range header.
This notification SHALL be sent for media that are time-progressing
every time a event happens that changes the basis for making
estimations on how the media range progress. In addition it is
RECOMMENDED that the server sends these notification every 5 minutes
for time-progressing content to ensure the long term stability of the
client estimation and allowing for clock skew detection by the
client. Requests for the just mentioned reasons SHALL include Media-
Range header to provide current Media duration and the Range header
to indicate the current playing point and any remaining parts of the
requsted range.
A PLAY_NOTIFY request with Notify-Reason header set to media-
properties-update MUST NOT carry a message body.
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
Date: Tue, 14 Apr 2008 15:48:06 GMT
CSeq: 854
Notify-Reason: media-properties-update
Session: uZ3ci0K+Ld-M
Media-Properties: Time-Progressing,
Time-Limited=20080415T153919.36Z, Random-Access=5.0
Media-Range: npt=0-1:37:21.394
Range: npt=1:15:49.873-
C->S: RTSP/2.0 200 OK
CSeq: 854
User-Agent: PhonyClient/1.2
13.5.3. Scale-Change
When a client request playback at Scale (Section 16.44) values other
than 1.0 (Normal playback rate) then the server may be forced to
changed the rate. For time progressing media with some retention,
i.e. the server stores already sent content, a client requesting to
play with Scale values larger than 1 may catch up with front end of
the media. The server will be unable to continue provide content at
Scale larger than 1 as content only made available by the server at
Scale=1. Another case is when Scale < 1 and the media retention is
time_duration limited. In this case the playback point can reach the
the oldest media unit available, and further playback at this scale
becomes impossible as there will be no media available. To avoid
having the client loose any media, the scale will need to be adjusted
to the same rate which the media is removed from the storage buffer,
commonly scale=1.0.
To minimize impact on playback in any of the above cases the server
SHALL modify the playback properties and set Scale to a supportable
value (commonly 1.0) and continue delivery the media. When doing
this modification it MUST send a PLAY_NOTIFY message with the Notify-
Reason header set to "Scale-Change". The request SHALL contain a
Range header with the media time where the change took effect, a
Scale header with the new value in use, Session header with the ID
for the session it applies to and a Date header with the server wall
clock time of the change. For time progressing content also the
Media-Range and the Media-Properties at this point in time SHALL be
included.
For media streams being delivered using RTP also a RTP-Info header
SHALL be included. It MUST contain the rtptime parameter with a
value corresponding to the point of change in that media and
optionally the sequence number.
A PLAY_NOTIFY request with Notify-Reason header set to "Scale-Change"
MUST NOT carry a message body.
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
Date: Tue, 14 Apr 2008 15:48:06 GMT
CSeq: 854
Notify-Reason: scale-change
Session: uZ3ci0K+Ld-M
Media-Properties: Time-Progressing,
Time-Limited=20080415T153919.36Z, Random-Access=5.0
Media-Range: npt=0-1:37:21.394
Range: npt=1:37:21.394-
Scale: 1
RTP-Info: url="rtsp://example.com/fizzle/foo/audio"
ssrc=0D12F123:rtptime=2345962545
C->S: RTSP/2.0 200 OK
CSeq: 854
User-Agent: PhonyClient/1.2
13.6. PAUSE
The PAUSE request causes the stream delivery to immediately be The PAUSE request causes the stream delivery to immediately be
interrupted (halted). A PAUSE request MUST be done either with the interrupted (halted). A PAUSE request MUST be done either with the
aggregated control URI for aggregated sessions, resulting in all aggregated control URI for aggregated sessions, resulting in all
media being halted, or the media URI for non-aggregated sessions. media being halted, or the media URI for non-aggregated sessions.
Any attempt to do muting of a single media with an PAUSE request in Any attempt to do muting of a single media with 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
skipping to change at page 66, line 14 skipping to change at page 77, line 48
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 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: Thu, 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
Range header SHALL resume from the pause point and play until media Range header SHALL resume from the pause point and play until media
end. end.
The pause point after any PAUSE request SHALL be returned to the The pause point after any PAUSE request SHALL be returned to the
client by adding a Range header with what remains unplayed of the client by adding a Range header with what remains unplayed of the
PLAY request's 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. For media with random access
ranged request, one simply includes the Range header from the PAUSE properties If one desires to resume playing a ranged request, one
response. simply includes the Range header from the PAUSE response. Any play-
request including symbolic values, such as the NPT timescale's "now"
MUST be resolved into the actual stream position where the pause
point is. For example a Play request with a range specification of
"npt=now-" will need to be responded with an explicit value such as
"npt=157.321-". For media that is time-progressing and has retention
duration=0 the follow-up PLAY request to start media delivery again,
will need to use "npt=now-" and not the answer in the pause-respone.
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
Range: npt=10-30 Range: npt=10-30
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
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: Thu, 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
skipping to change at page 68, line 13 skipping to change at page 79, line 18
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 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: Thu, 23 Jan 1997 15:35:06 GMT
Range: npt=45.76-98.36 Range: npt=45.76-98.36
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 835 CSeq: 835
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
13.6. TEARDOWN 13.7. 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 69, line 16 skipping to change at page 80, line 21
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 892 CSeq: 892
Session: 12345678 Session: 12345678
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 892 CSeq: 892
Server: PhonyServer 1.0 Server: PhonyServer 1.0
13.7. GET_PARAMETER 13.8. GET_PARAMETER
The GET_PARAMETER request retrieves the value of a parameter or The GET_PARAMETER request retrieves the value of any specified
parameters for a presentation or stream specified in the URI. If the parameter or parameters for a presentation or stream specified in the
Session header is present in a request, the value of a parameter MUST URI. If the Session header is present in a request, the value of a
be retrieved in the specified session context. The content of the parameter MUST be retrieved in the specified session context. There
reply and response is left to the implementation. exist two ways of specifying the parameters to retrive. The first is
by including headers that has been defined such that you can use them
for this purpose. Header for this purpose should allow empty, or
stripped value parts to avoid having to specify bogus data when
indicating the desire to retrive a value. The succesful completion
of the request should also be evident from any filled out values in
the response. The Media-Range header (Section 16.30) is one such
header. The other is to specify a body (entity) that lists the
parameter(s) that are desirable to retrieve. The Content-Type header
(Section 16.18) is used to specify which format the entity has.
The method MAY also be used without a body (entity). If the request The method MAY also be used without a body (entity) or any header
is successful, i.e., a 200 OK response is received, then the keep- that request parameters for keep-alive purpose. Any request that is
alive timer has been updated. Any non-required header present in successful, i.e., a 200 OK response is received, then the keep-alive
such a request may or may not been processed. To allow a client to timer has been updated. Any non-required header present in such a
determine if any such header has been processed, it is necessary to request may or may not been processed. Normaly the presence of
use a feature-tag and the Require header. Due to this reason it is filled out values in the header will be indication that the header
RECOMMENDED that any parameters to be retrieved are sent in the body, has been processed. However, for cases when this is difficult to
rather than using any header. determine, it is recommended to use a feature-tag and the Require
header. Due to this reason it is usually easier if any parameters to
be retrieved are sent in the body, rather than using any header.
Parameters specified within the body of the message must all be
understood by the request receiving agent. If one or more parameters
are not understood a 451 (Parameter Not Understood) SHALL be sent
including a body listing these parameters that wasn't understood. If
all parameters are understood their value is filled in and returned
in the response message body.
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 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
jitter: 0.3838 jitter: 0.3838
The "text/parameters" section is only an example type for a body
carrying parameters.
13.8. SET_PARAMETER 13.9. SET_PARAMETER
This method requests to set the value of a parameter or a set of This method requests to set the value of a parameter or a set of
parameters for a presentation or stream specified by the URI. The parameters for a presentation or stream specified by the URI. The
method MAY also be used without a 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 70, line 30 skipping to change at page 81, line 51
A request is RECOMMENDED to only contain a single parameter to allow A request is RECOMMENDED to only contain a single parameter to allow
the client to determine why a particular request failed. If the the client to determine why a particular request failed. If the
request contains several parameters, the server MUST only act on the request contains several parameters, the server MUST only act on the
request if all of the parameters can be set successfully. A server request if all of the parameters can be set successfully. A server
MUST allow a parameter to be set repeatedly to the same value, but it MUST allow a parameter to be set repeatedly to the same value, but it
MAY disallow changing parameter values. If the receiver of the MAY disallow changing parameter values. If the receiver of the
request does not understand or cannot locate a parameter, error 451 request does not understand or cannot locate a parameter, error 451
(Parameter Not Understood) SHALL be used. In the case a parameter is (Parameter Not Understood) SHALL be used. In the case a parameter is
not allowed to change, the error code is 458 (Parameter Is Read- not allowed to change, the error code is 458 (Parameter Is Read-
Only). The response body SHOULD contain only the parameters that Only). The response body SHALL contain only the parameters that have
have errors. Otherwise no body SHALL be returned. errors. Otherwise no body SHALL be returned.
Note: transport parameters for the media stream MUST only be set with Note: transport parameters for the media stream MUST only be set with
the SETUP command. the SETUP command.
Restricting setting transport parameters to SETUP is for the Restricting setting transport parameters to SETUP is for the
benefit of firewalls. benefit of firewalls.
The parameters are split in a fine-grained fashion so that there The parameters are split in a fine-grained fashion so that there
can be more meaningful error indications. However, it may make can be more meaningful error indications. However, it may make
sense to allow the setting of several parameters if an atomic sense to allow the setting of several parameters if an atomic
skipping to change at page 71, line 20 skipping to change at page 82, line 36
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 13.10. REDIRECT
parameters. This method is intentionally loosely defined with the
intention that the reply content and response content will be
defined by the one desiring to use this mechanism.
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 SHOULD NOT disconnect the control channel while intervening proxies SHOULD NOT disconnect the control channel while
skipping to change at page 74, line 32 skipping to change at page 86, line 32
protocol data unit, e.g., one RTP packet. protocol data unit, e.g., one RTP packet.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "$" = 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 16.46). interleaved parameter (Section 16.51).
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 16.46. If interleaved parameter of the Transport header, see Section 16.51. 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 Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Date: 05 Jun 1997 18:57:18 GMT Date: Thu, 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;unicast;interleaved=5-6 Transport: RTP/AVP/TCP;unicast;interleaved=5-6
Session: 12345678 Session: 12345678
Accept-Ranges: NPT 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 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: Thu, 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 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}
15. Status Code Definitions 15. Status Code Definitions
skipping to change at page 80, line 39 skipping to change at page 92, line 39
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.
15.4.17. 470 Connection Authorization Required 15.4.17. 465 Notification Reason Unknown
The client has received a PLAY_NOTIFY (Section 13.5) with a Notify-
Reason header (Section 16.31) indicates a reson that are unknown to
the client.
15.4.18. 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.
15.4.18. 471 Connection Credentials not accepted 15.4.19. 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.
15.4.19. 472 Failure to establish secure connection 15.4.20. 472 Failure to establish secure connection
A proxy fails to establish a secure connection to the next hop RTSP A proxy fails to establish a secure connection to the next hop RTSP
agent. This is primarily caused by a fatal failure at the TLS agent. This is primarily caused by a fatal failure at the TLS
handshake, for example due to server not accepting any cipher suits. handshake, for example due to server not accepting any cipher suits.
15.5. Server Error 5xx 15.5. Server Error 5xx
15.5.1. 551 Option not supported 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
skipping to change at page 82, line 22 skipping to change at page 94, line 22
| GET_PARAMETER | 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 | |
| | | | | | | | | | | |
| PLAY_NOTIFY | S -> C | P,S | PNY | R |
| | | | | |
| 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 | | SET_PARAMETER | 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
skipping to change at page 84, line 7 skipping to change at page 96, line 7
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 16.38 and Section 16.32. A "mandatory" header discussed in Section 16.42 and Section 16.35. 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 86, line 36 skipping to change at page 98, 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 | | | | | |
+------------+-------+------+----+-----+-------+------+-------+-----+ +------------+-------+------+----+-----+-------+------+-------+-----+
| Media- | | | - | - | r | r | r | - |
| Properties | | | | | | | | |
| | | | | | | | | |
| Media- | | | - | - | r | r | r | - |
| Range | | | | | | | | |
| | | | | | | | | |
| Pipelined- | | amdr | - | o | o | o | o | o | | Pipelined- | | amdr | - | o | o | o | o | o |
| Requests | | | | | | | | | | 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 |
| | | | | | | | | | | | | | | | | | | |
| Request- | R | | - | - | - | - | - | - |
| Status | | | | | | | | |
| | | | | | | | | |
| 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 | | - | - | c | c | - | - | | RTP-Info | r | | - | - | c | c | - | - |
| | | | | | | | | | | | | | | | | | | |
| Scale | | | - | - | - | o | - | - | | Scale | | | - | - | - | o | - | - |
| | | | | | | | | | | | | | | | | | | |
| Seek-Style | R | | - | - | - | o | - | - |
| | | | | | | | | |
| Seek-Style | r | | - | - | - | m | - | - |
| | | | | | | | | |
| 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 |
| | | | | | | | | | | | | | | | | | | |
| Speed | | | - | - | - | o | - | - | | Speed | | | - | - | - | o | - | - |
| | | | | | | | | | | | | | | | | | | |
skipping to change at page 88, line 20 skipping to change at page 100, line 33
| 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
DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.
+------------------------+---------+-------+-----+-----+-----+ +------------------------+---------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | | Header | Where | Proxy | GPR | SPR | RDR | PNY |
+------------------------+---------+-------+-----+-----+-----+ +------------------------+---------+-------+-----+-----+-----+-----+
| Accept-Credentials | R | r | o | o | o | | Accept-Credentials | R | r | o | o | o | - |
| | | | | | | | | | | | | | |
| Allow | 405 | amr | m | m | m | | Allow | 405 | amr | m | m | m | - |
| | | | | | | | | | | | | | |
| Authorization | R | | o | o | o | | Authorization | R | | o | o | o | - |
| | | | | | | | | | | | | | |
| Bandwidth | R | | - | o | - | | Bandwidth | R | | - | o | - | - |
| | | | | | | | | | | | | | |
| Blocksize | R | | - | o | - | | Blocksize | R | | - | o | - | - |
| | | | | | | | | | | | | | |
| Connection | | | o | o | o | | Connection | | | o | o | o | - |
| | | | | | | | | | | | | | |
| Connection-Credentials | 470,407 | ar | o | o | o | | Connection-Credentials | 470,407 | ar | o | o | o | - |
| | | | | | | | | | | | | | |
| Content-Base | R | | o | o | - | | Content-Base | R | | o | o | - | - |
| | | | | | | | | | | | | | |
| Content-Base | r | | o | o | - | | Content-Base | r | | o | o | - | - |
| | | | | | | | | | | | | | |
| Content-Base | 4xx,5xx | | o | o | o | | Content-Base | 4xx,5xx | | o | o | o | - |
| | | | | | | | | | | | | | |
| 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 | - |
| Content-Type | R | | * | * | - | | | | | | | | |
| | | | | | | | Content-Type | R | | * | * | - | - |
| Content-Type | r | | * | * | - | | | | | | | | |
| | | | | | | | Content-Type | r | | * | * | - | - |
| Content-Type | 4xx | | * | * | * | | | | | | | | |
| | | | | | | | Content-Type | 4xx | | * | * | * | - |
| CSeq | R,c | mr | m | m | m | | | | | | | | |
| | | | | | | | CSeq | R,c | mr | m | m | m | m |
| Date | R | a | o | o | m | | | | | | | | |
| | | | | | | | Date | R | a | o | o | m | - |
| Date | r | am | o | o | o | | | | | | | | |
| | | | | | | | Date | r | am | o | o | o | - |
| 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 | | | | | | | | |
| | | | | | | | Media-Properties | | | - | - | - | |
| Proxy-Authenticate | 407 | amr | m | m | m | | | | | | | | |
| | | | | | | | Media-Range | R | | o | - | - | c |
| Proxy-Authorization | R | rd | o | o | o | | | | | | | | |
| | | | | | | | Media-Range | r | | c | - | - | - |
| Proxy-Require | R | ar | o | o | o | | | | | | | | |
| | | | | | | | Notify-Reason | R | | - | - | - | m |
| Proxy-Require | r | r | c | c | c | | | | | | | | |
| | | | | | | | Pipelined-Requests | | amdr | o | o | o | - |
| Proxy-Supported | R | amr | c | c | c | | | | | | | | |
| | | | | | | | Proxy-Authenticate | 407 | amr | m | m | m | - |
| Proxy-Supported | r | | c | c | c | | | | | | | | |
| | | | | | | | Proxy-Authorization | R | rd | o | o | o | - |
| Public | 501 | admr | m | m | m | | | | | | | | |
+------------------------+---------+-------+-----+-----+-----+ | Proxy-Require | R | ar | o | o | o | - |
| | | | | | | |
| Proxy-Require | r | r | c | c | c | - |
| | | | | | | |
| Proxy-Supported | R | amr | c | c | c | - |
| | | | | | | |
| Proxy-Supported | r | | c | c | c | - |
| | | | | | | |
| Public | 501 | admr | m | m | m | - |
+------------------------+---------+-------+-----+-----+-----+-----+
Table 11: Overview of RTSP header fields (A-P) related to methods Table 11: Overview of RTSP header fields (A-P) related to methods
GETPARAMETER, SETPARAMETER, and REDIRECT. GETPARAMETER, SETPARAMETER, PLAY_NOTIFY, and REDIRECT.
+------------------+---------+-------+-----+-----+-----+ +------------------+---------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | | Header | Where | Proxy | GPR | SPR | RDR | PNY |
+------------------+---------+-------+-----+-----+-----+ +------------------+---------+-------+-----+-----+-----+-----+
| Range | R | | - | - | o | | Range | R | | - | - | o | m |
| | | | | | | | | | | | | | |
| Referer | R | | o | o | o | | Referer | R | | o | o | o | - |
| | | | | | | | | | | | | | |
| Require | R | r | o | o | o | | Request-Status | R | | - | - | - | m |
| | | | | | | | | | | | | | |
| Retry-After | 3rr,503 | | o | o | - | | Require | R | r | o | o | o | - |
| | | | | | | | | | | | | | |
| Scale | | | - | - | - | | Retry-After | 3rr,503 | | o | o | - | - |
| | | | | | | | | | | | | | |
| Session | R | r | o | o | o | | Scale | | | - | - | - | c |
| | | | | | | | | | | | | | |
| Session | r | r | c | c | o | | Seek-Style | | | - | - | - | - |
| | | | | | | | | | | | | | |
| Server | R | r | o | o | o | | Session | R | r | o | o | o | m |
| | | | | | | | Session | r | r | c | c | o | m |
| Server | r | r | o | o | - | | | | | | | | |
| | | | | | | | Server | R | r | o | o | o | - |
| Supported | R | adrm | o | o | o | | | | | | | | |
| | | | | | | | Server | r | r | o | o | - | - |
| Supported | r | adrm | c | c | c | | | | | | | | |
| | | | | | | | Supported | R | adrm | o | o | o | - |
| Timestamp | R | adrm | o | o | o | | | | | | | | |
| | | | | | | | Supported | r | adrm | c | c | c | - |
| Timestamp | c | adrm | m | m | m | | | | | | | | |
| | | | | | | | Timestamp | R | adrm | o | o | o | - |
| Unsupported | r | arm | c | c | c | | | | | | | | |
| | | | | | | | Timestamp | c | adrm | m | m | m | - |
| User-Agent | R | r | m* | m* | - | | | | | | | | |
| | | | | | | | Unsupported | r | arm | c | c | c | - |
| User-Agent | r | r | - | - | m* | | | | | | | | |
| | | | | | | | User-Agent | R | r | m* | m* | - | - |
| Vary | r | | c | c | - | | | | | | | | |
| | | | | | | | User-Agent | r | r | - | - | m* | - |
| Via | R | amr | o | o | o | | | | | | | | |
| | | | | | | | Vary | r | | c | c | - | - |
| Via | c | dr | m | m | m | | | | | | | | |
| WWW-Authenticate | 401 | | m | m | m | | Via | R | amr | o | o | o | - |
+------------------+---------+-------+-----+-----+-----+ | | | | | | | |
| Via | c | dr | 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, PLAY_NOTIFY, and REDIRECT.
16.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:
skipping to change at page 101, line 28 skipping to change at page 113, line 34
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.
16.28. Location 16.28. Location
See [H14.30]. See [H14.30].
16.29. Pipelined-Requests 16.29. Media-Properties
This general header is used in SETUP response or PLAY_NOTIFY requests
to indicate the media's properties that currently are applicable.
PLAY_NOTIFY MAY be used to modify these properties at any point.
However, the client MUST have received the update prior to any action
related to the new media properties take affect.
The header contains a list of property values that are applicable to
the currently setup media or aggregate of media as indicated by the
RTSP URI in the request. No ordering are enforced within the header.
Property values should be grouped into a single group that handles a
particular orthogonal property. Values or groups that express
multiple properties SHOULD NOT be used. The list of properties that
can be expressed MAY be extended at any time. Unknown property
values SHALL be ignored.
This specification defines the following 3 groups and their property
values:
Random Access:
Random-Access: Indicates that random access is possible. May
optionally include a floating point value in seconds indicating
the longest duration between any two random access points in
the media.
Begining-Only: Seeking is limited to the begining only.
No-Seeking: No seeking is possible.
Content Modifications
Unmutable: The content will not be changed during the life-time
of the RTSP session.
Dynamic: The content may be changed based on external methods or
triggers
Time-Progressing The media accesible progress as wall clock time
progresses.
Retention
Unlimited: Content will be retained for the duration of the life-
time of the RTSP session.
Time-Limited: Content will be retained at least until the
specified wall clock time. The time must be provided in the
absolute time format specified in Section Section 4.6.
Time-Duration Each individual media unit is retained for at least
the specified time duration. This definition allows for
retaining data with a time based sliding window. The time
duration is expressed as floating point number in seconds. 0.0
is a valid value as this indicates that no data is retained in
a time-progressing session.
An Example of this header for first an on-demand content and then a
live stream without recording.
On-demand:
Media-Properties: Random-Acess=2.5s, Unlimited, Unmutable
Live stream without recording/timeshifting:
Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0
16.30. Media-Range
The Media-Range general header is used to give the range of the media
at the time of sending the RTSP message. This header SHALL be
included in SETUP response, and PLAY and PAUSE response for media
that are Time-Progressing, and PLAY and PAUSE response after any
change for media that are Dynamic, and in PLAY_NOTIFY request that
are sent due to Media-Property-Update. Media-Range header without
any range specifications MAY be included in GET_PARAMETER requests to
the server to request the current value. The server SHALL in this
case include the curent value at the time of sending the response.
The header SHALL include range specification for all time formats
supported for the media, as indicated in Accept-Ranges header
(Section 16.5) when setting up the media. The server MAY include
more than one range specification of any given time format to
indicate media that has non-continous range.
For media that has the Time-Progressing property, the Media-Range
values will only be valid for the particular point in time when it
was issued. As wall clock progresses so will also the media range.
However it shall be assumed that media time progress in direct
relationship to wall clock time (with the exception of clock skew) so
that a reasoanbly accurate estiamation of the media range can be
calculated.
16.31. Notify-Reason
The Notify Reason header is solely used in the PLAY_NOTIFY method.
It indiciates the reason why the server has sent the asynchronous
PLAY-NOTIFY request (see Section 13.5).
16.32. Pipelined-Requests
The Pipelined-Requests general header is used to indicate that a The Pipelined-Requests general header is used to indicate that a
request is to be executed in the context created by previous request is to be executed in the context created by previous
requests. The primary usage of this header is to allow pipelining of requests. The primary usage of this header is to allow pipelining of
SETUP requests so that any additional SETUP request after the first 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 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 requesting entity. The header contains a unique identifier that is
scoped by the persistent connection used to send the requests. scoped by the persistent connection used to send the requests.
Upon receiving a request with the Pipelined-Requests the responding Upon receiving a request with the Pipelined-Requests the responding
skipping to change at page 102, line 30 skipping to change at page 116, line 39
when a new RTSP session is to be cretated with this method. A server 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 side binding SHALL be deleted upon the termination of the related
RTSP session. Note: Although this definition would allow for reusing RTSP session. Note: Although this definition would allow for reusing
previously used pipelining identifiers, this is NOT RECOMMENDED to previously used pipelining identifiers, this is NOT RECOMMENDED to
allow for better error handling and logging. allow for better error handling and logging.
RTSP Proxies may need to translate Pipelined-Requests identifier RTSP Proxies may need to translate Pipelined-Requests identifier
values from incoming request to outgoing to allow for aggregation of values from incoming request to outgoing to allow for aggregation of
requests onto a persistent connection. requests onto a persistent connection.
16.30. Proxy-Authenticate 16.33. Proxy-Authenticate
See [H14.33]. See [H14.33].
16.31. Proxy-Authorization 16.34. Proxy-Authorization
See [H14.34]. See [H14.34].
16.32. Proxy-Require 16.35. Proxy-Require
The Proxy-Require request-header field is used to indicate proxy- The Proxy-Require request-header field is used to indicate proxy-
sensitive features that MUST be supported by the proxy. Any Proxy- sensitive features that MUST be supported by the proxy. Any Proxy-
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 Section 16.38 for more details on the mechanics of this message See Section 16.42 for more details on the mechanics of this message
and a usage example. and a usage example.
Example of use: Example of use:
Proxy-Require: play.basic Proxy-Require: play.basic
16.33. Proxy-Supported 16.36. Proxy-Supported
The Proxy-Supported header field enumerates all the extensions The Proxy-Supported header field enumerates all the extensions
supported by the proxy using feature-tags. The header carries the supported by the proxy using feature-tags. The header carries the
intersection of extensions supported by the forwarding proxies. The intersection of extensions supported by the forwarding proxies. The
Proxy-Supported header MAY be included in any request by a proxy. It Proxy-Supported header MAY be included in any request by a proxy. It
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
skipping to change at page 103, line 48 skipping to change at page 118, line 25
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
16.34. Public 16.37. 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 104, line 27 skipping to change at page 119, line 5
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.
16.35. Range 16.38. Range
The Range header specifies a time range in PLAY (Section 13.4), PAUSE The Range header specifies a time range in PLAY (Section 13.4), PAUSE
(Section 13.5), SETUP (Section 13.3), and REDIRECT (Section 13.9) (Section 13.6), SETUP (Section 13.3), REDIRECT (Section 13.10), and
requests and responses. PLAY_NOTIFY (Section 13.5) 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 (Section 4.4), npt (Section 4.5), and clock defines smpte (Section 4.4), npt (Section 4.5), and clock
(Section 4.6) range units. While byte ranges [H14.35.1] and other (Section 4.6) range units. While byte ranges [H14.35.1] and other
extended units MAY be used, their behavior is unspecified since they extended units MAY be used, their behavior is unspecified since they
are not normally meaningful in RTSP. Servers supporting the Range are not normally meaningful in RTSP. Servers supporting the Range
header MUST understand the NPT range format and SHOULD understand the header MUST understand the NPT range format and SHOULD understand the
SMPTE range format. If the Range header is sent in a time format SMPTE range format. If the Range header is sent in a time format
that is not understood, the recipient SHOULD return 456 (Header Field that is not understood, the recipient SHOULD return 456 (Header Field
Not Valid for Resource) and include an Accept-Ranges header Not Valid for Resource) and include an Accept-Ranges header
skipping to change at page 105, line 26 skipping to change at page 119, line 51
beyond the interval. A range of 10.0-10.08, on the other hand, would beyond the interval. A range of 10.0-10.08, on the other hand, would
exclude the frame at 10.08. exclude the frame at 10.08.
By default, range intervals increase, where the second point is By default, range intervals increase, where the second point is
larger than the first point. larger than the first point.
Example: Example:
Range: npt=10-15 Range: npt=10-15
However, range intervals can also decrease if the Scale header (see However, range intervals can also decrease if the Scale header (see
Section 16.40) indicates a negative scale value. For example, this Section 16.44) indicates a negative scale value. For example, this
would be the case when a playback in reverse is desired. would be the case when a playback in reverse is desired.
Example: Example:
Scale: -1 Scale: -1
Range: npt=15-10 Range: npt=15-10
Decreasing ranges are still half open intervals as described above. Decreasing ranges are still half open intervals as described above.
Thus, for range A-B, A is closed and B is open. In the above Thus, for range A-B, A is closed and B is open. In the above
example, 15 is closed and 10 is open. An exception to this rule is example, 15 is closed and 10 is open. An exception to this rule is
the case when B=0 in a decreasing range. In this case, the range is the case when B=0 in a decreasing range. In this case, the range is
skipping to change at page 106, line 5 skipping to change at page 120, line 26
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.
16.36. Referer 16.39. 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.
16.37. Retry-After 16.40. Retry-After
See [H14.37]. See [H14.37].
16.38. Require 16.41. Request-Status
This request header is used to indicate the end result for requests
that takes time to complete, such a PLAY (Section 13.4). It is sent
in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report
how the PLAY request concluded, either in success or in failure. The
header carries a reference to the request is reports on using the
CSeq number for the session indicated by the Session header in the
request. It provies both a numerical status code (according to
Section 8.1.1) and a human readable reason phrase.
Example:
Request-Status: cseq=63 status=500 reason="Media data unavailable"
16.42. 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 (Section 16.44) is much more effective in this purpose. Supported (Section 16.49) is much more effective in this purpose.
The server MUST respond to this header by using the Unsupported The server MUST respond to this header by using the Unsupported
header to negatively acknowledge those feature-tags which are NOT header to negatively acknowledge those feature-tags which are NOT
supported. The response SHALL use the error code 551 (Option Not supported. The response SHALL use the error code 551 (Option Not
Supported). This header does not apply to proxies, for the same Supported). This header does not apply to proxies, for the same
functionality in respect to proxies see Proxy-Require header functionality in respect to proxies see Proxy-Require header
(Section 16.32). (Section 16.35).
This is to make sure that the client-server interaction will This is to make sure that the client-server interaction will
proceed without delay when all features are understood by both proceed without delay when all features are understood by both
sides, and only slow down if features are not understood (as in sides, and only slow down if features are not understood (as in
the example below). For a well-matched client-server pair, the the example below). For a well-matched client-server pair, the
interaction proceeds quickly, saving a round-trip often required interaction proceeds quickly, saving a round-trip often required
by negotiation mechanisms. In addition, it also removes state by negotiation mechanisms. In addition, it also removes state
ambiguity when the client requires features that the server does ambiguity when the client requires features that the server does
not understand. not understand.
skipping to change at page 107, line 8 skipping to change at page 121, line 48
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 Section 16.32). (see Section 16.35).
16.39. RTP-Info 16.43. 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
skipping to change at page 109, line 5 skipping to change at page 123, line 42
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
16.40. Scale 16.44. 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
skipping to change at page 109, line 37 skipping to change at page 124, line 26
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
Section 16.35. Section 16.38.
Example of playing in reverse at 3.5 times normal rate: Example of playing in reverse at 3.5 times normal rate:
Scale: -3.5 Scale: -3.5
Range: npt=15-10 Range: npt=15-10
16.41. Speed 16.45. Seek-Style
When a client sends a PLAY request with a Range header to perform a
random access to the media, the client does not know if the server
will pick the first media samples or the first random access point
prior to the request range. Depending on use case, the client may
have a strong preference. To express this preference and provide the
client with information on how the server actually acted on that
preference the Seek-Style header is defined.
Seek-Style is a general header that MAY be included in any PLAY
request to indicate the client's preference for any media stream that
has random access properties. The server SHALL always include the
header in any PLAY response for media with random access properties
to indicate what policy was applied. A Server that receives a
unknown Seek-Style policy SHALL ignore it and select the server
default policy.
This specification defines the following seek policies that may be
requested:
RAP: Random Access Point (RAP) is the behavior of requesting the
server to locate the closest previous random access point that
exist in the media aggregate and deliver from that. By requesting
a RAP media quality will be the best possible as all media will be
delivered from a point where full media state can be established
in the media decoder.
First-Prior: The first-prior policy will start delivery with the
media unit that has a playout time first prior to the requested
time. For discrete media that would only include media units that
would still be rendered at the request time. For continous media
that is media that will be render during the requested start time
of the range.
Next: The next media units after the provided start time of the
range. For continous framed media that would mean the first next
frame after the provided time. For discrete media the first unit
that is to be rendered after the provided time. The main usage is
for this case is when the client knows it has all media up to a
certain point and would like to continue delivery so that a
complete non-interrupted media playback can be achieved. Example
of such scenarios include switching from a broadcast/multicast
delivery to a unicast based delivery. This policy SHALL only be
used on the client's explicit request.
Please note that these expressed preferences exist for optimizing the
startup time or the media quality. The "Next" policy breaks the
normal definition of the Range header to enable a client to request
media with minimal overlap, although some may still occur for
aggregated sessions. RAP and First-Prior both fulfill the
requirement of providing media from the requested range and forward.
However, unless RAP is used, the media quality for many media codecs
using predictive methods can be severly degraded unless additional
data is available as, for example, already buffered, or through other
side channels.
16.46. 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
support. Therefore the actual used speed MUST be included in the support. Therefore the actual used speed MUST be included in the
response. The lack of a response header is indication of lack of response. The lack of a response header is indication of lack of
support from the server of this functionality. Support of the speed support from the server of this functionality. Support of the speed
functionality are indicated by the "play.speed" feature-tag. functionality are indicated by the "play.speed" feature-tag.
Example: Example:
Speed: 2.5 Speed: 2.5
Use of this field changes the bandwidth used for data delivery. It Use of this field changes the bandwidth used for data delivery. It
skipping to change at page 110, line 26 skipping to change at page 126, line 23
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.
16.42. Server 16.47. Server
See [H14.38], however the header syntax is corrected in See [H14.38], however the header syntax is corrected in
Section 20.2.3. Section 20.2.3.
16.43. Session 16.48. 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 Section 4.3) and The session identifier is chosen by the server (see Section 4.3) and
MUST be returned in the SETUP response. Once a client receives a MUST be returned in the SETUP response. Once a client receives a
session identifier, it SHALL be included in any request related to session identifier, it SHALL be included in any request related to
that session. This means that the Session header MUST be included in that session. This means that the Session header MUST be included in
a request using the following methods: PLAY, PAUSE, and TEARDOWN, and a request using the following methods: PLAY, PAUSE, and TEARDOWN, and
MAY be included in SETUP, OPTIONS, SETPARAMETER, GET_PARAMETER, and MAY be included in SETUP, OPTIONS, SET_PARAMETER, GET_PARAMETER, and
REDIRECT, and SHALL NOT be included in DESCRIBE. In an RTSP response REDIRECT, and SHALL NOT be included in DESCRIBE. In an RTSP response
the session header SHALL be included in methods, SETUP, PLAY, and the session header SHALL be included in methods, SETUP, PLAY, and
PAUSE, and MAY be included in methods, TEARDOWN, and REDIRECT, and if PAUSE, and MAY be included in methods, TEARDOWN, and REDIRECT, and if
included in the request of the following methods it SHALL also be included in the request of the following methods it SHALL also be
included in the response, OPTIONS, GET_PARAMETER, and SETPARAMETER, included in the response, OPTIONS, GET_PARAMETER, and SET_PARAMETER,
and SHALL NOT be included in DESCRIBE. and SHALL NOT be included in DESCRIBE.
Note that a session identifier identifies an RTSP session across Note that a session identifier identifies an RTSP session across
transport sessions or connections. RTSP requests for a given session transport sessions or connections. RTSP requests for a given session
can use different URIs (Presentation and media URIs). Note, that can use different URIs (Presentation and media URIs). Note, that
there are restrictions depending on the session which URIs that are there are restrictions depending on the session which URIs that are
acceptable for a given method. However, multiple "user" sessions for acceptable for a given method. However, multiple "user" sessions for
the same URI from the same client will require use of different the same URI from the same client will require use of different
session identifiers. session identifiers.
The session identifier is needed to distinguish several delivery The session identifier is needed to distinguish several delivery
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.
16.44. Supported 16.49. 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 Section 4.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 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
16.45. Timestamp 16.50. 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.
16.46. Transport 16.51. 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 117, line 38 skipping to change at page 133, line 38
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 Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 302 CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT Date: Thu, 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 Accept-Ranges: NPT
16.47. Unsupported 16.52. 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 (Section 16.32), if there is a proxy on via the Proxy-Require field (Section 16.35), if there is a proxy on
the path between the client and the server, the proxy MUST send a the path between the client and the server, the proxy MUST send a
response message with a status code of 551 (Option Not Supported). response message with a status code of 551 (Option Not Supported).
The request SHALL NOT be forwarded. The request SHALL NOT be forwarded.
See Section 16.38 for a usage example. See Section 16.42 for a usage example.
16.48. User-Agent 16.53. 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.
16.49. Vary 16.54. Vary
See [H14.44]. See [H14.44].
16.50. Via 16.55. Via
See [H14.45]. See [H14.45].
16.51. WWW-Authenticate 16.56. WWW-Authenticate
See [H14.47]. See [H14.47].
17. 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.
skipping to change at page 122, line 18 skipping to change at page 138, line 18
the pure authentication mechanisms based on HTTP authentication, and the pure authentication mechanisms based on HTTP authentication, and
the transport protection based on TLS, which is independent of RTSP. the transport protection based on TLS, which is independent of RTSP.
Because of the similarity in syntax and usage between RTSP servers Because of the similarity in syntax and usage between RTSP servers
and HTTP servers, the security for HTTP is re-used to a large extent. and HTTP servers, the security for HTTP is re-used to a large extent.
19.1. RTSP and HTTP Authentication 19.1. RTSP and HTTP Authentication
RTSP and HTTP share common authentication schemes, and thus follow RTSP and HTTP share common authentication schemes, and thus follow
the same usage guidelines as specified in[RFC2617] and also in [H15]. the same usage guidelines as specified in[RFC2617] and also in [H15].
Servers SHOULD implement both basic and digest [RFC2617] Servers SHOULD implement both basic and digest [RFC2617]
authentication. authentication. Client SHALL implement both basic and digest
authentication [RFC2617] so that Server who requires the client to
authenticate can trust that the capability is present.
It should be stressed that using the HTTP authentication alone does It should be stressed that using the HTTP authentication alone does
not provide full control message security. Therefore, in not provide full control message security. Therefore, in
environments requiring tighter security for the control messages, TLS environments requiring tighter security for the control messages, TLS
SHOULD be used, see Section 19.2. SHOULD be used, see Section 19.2.
19.2. RTSP over TLS 19.2. RTSP over TLS
RTSP SHALL follow the same guidelines with regards to TLS [RFC4346] RTSP SHALL follow the same guidelines with regards to TLS [RFC4346]
usage as specified for HTTP, see [RFC2818]. RTSP over TLS is usage as specified for HTTP, see [RFC2818]. RTSP over TLS is
skipping to change at page 127, line 8 skipping to change at page 143, line 8
process for approval for each hop. However after the first message process for approval for each hop. However after the first message
exchange the remaining message should not be delayed, if each message exchange the remaining message should not be delayed, if each message
contains the chain of proxies that the requestor accepts. The contains the chain of proxies that the requestor accepts. The
procedure of including the credentials in each request rather than procedure of including the credentials in each request rather than
building state in each proxy, avoids the need for revocation building state in each proxy, avoids the need for revocation
procedures. procedures.
20. Syntax 20. Syntax
The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF) The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF)
as defined in RFC 4234 [RFC4234]. It uses the basic definitions as defined in RFC 5234 [RFC5234]. It uses the basic definitions
present in RFC 4234. present in RFC 5234.
Please note that ABNF strings, e.g. "Accept", are case insensitive Please note that ABNF strings, e.g. "Accept", are case insensitive
as specified in section 2.3 of RFC 4234. as specified in section 2.3 of RFC 5234.
20.1. Base Syntax 20.1. Base Syntax
RTSP header field values can be folded onto multiple lines if the RTSP header field values can be folded onto multiple lines if the
continuation line begins with a space or horizontal tab. All linear continuation line begins with a space or horizontal tab. All linear
white space, including folding, has the same semantics as SP. A white space, including folding, has the same semantics as SP. A
recipient MAY replace any linear white space with a single SP before recipient MAY replace any linear white space with a single SP before
interpreting the field value or forwarding the message downstream. interpreting the field value or forwarding the message downstream.
This is intended to behave exactly as HTTP/1.1 as described in RFC This is intended to behave exactly as HTTP/1.1 as described in RFC
2616 [RFC2616]. The SWS construct is used when linear white space is 2616 [RFC2616]. The SWS construct is used when linear white space is
skipping to change at page 128, line 7 skipping to change at page 144, line 7
CR = %x0D ; US-ASCII CR, carriage return (13 CR = %x0D ; US-ASCII CR, carriage return (13
LF = %x0A ; US-ASCII LF, linefeed (10) LF = %x0A ; US-ASCII LF, linefeed (10)
SP = %x20 ; US-ASCII SP, space (32) SP = %x20 ; US-ASCII SP, space (32)
HT = %x09 ; US-ASCII HT, horizontal-tab (9) HT = %x09 ; US-ASCII HT, horizontal-tab (9)
DQ = %x22 ; US-ASCII double-quote mark (34) DQ = %x22 ; US-ASCII double-quote mark (34)
BACKSLASH = %x5C ; US-ASCII backslash (92) BACKSLASH = %x5C ; US-ASCII backslash (92)
CRLF = CR LF CRLF = CR LF
LWS = [CRLF] 1*( SP / HT ) LWS = [CRLF] 1*( SP / HT )
SWS = [LWS] ; sep whitespace SWS = [LWS] ; sep whitespace
HCOLON = *( SP / HT ) ":" SWS HCOLON = *( SP / HT ) ":" SWS
TEXT = %x20-7D / %x80-FF ; any OCTET except CTLs TEXT = %x20-7E / %x80-FF ; any OCTET except CTLs
tspecials = "(" / ")" / "<" / ">" / "@" tspecials = "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / BACKSLASH / DQ / "," / ";" / ":" / BACKSLASH / DQ
/ "/" / "[" / "]" / "?" / "=" / "/" / "[" / "]" / "?" / "="
/ "{" / "}" / SP / HT / "{" / "}" / SP / HT
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7A / %x7C / %x7E) / %x41-5A / %x5E-7A / %x7C / %x7E)
; 1*<any CHAR except CTLs or tspecials> ; 1*<any CHAR except CTLs or tspecials>
quoted-string = ( DQ *qdtext DQ ) quoted-string = ( DQ *qdtext DQ )
qdtext = %x20-21 / %x23-7D / %x80-FF ; any TEXT except <"> qdtext = %x20-21 / %x23-7E / %x80-FF ; any TEXT except <">
quoted-pair = BACKSLASH CHAR quoted-pair = BACKSLASH CHAR
ctext = %x20-27 / %x2A-7D ctext = %x20-27 / %x2A-7E
/ %x80-FF ; any OCTET except CTLs, "(" and ")" / %x80-FF ; any OCTET except CTLs, "(" and ")"
generic-param = token [ EQUAL gen-value ] generic-param = token [ EQUAL gen-value ]
gen-value = token / host / quoted-string gen-value = token / host / quoted-string
safe = "$" / "-" / "_" / "." / "+" safe = "$" / "-" / "_" / "." / "+"
extra = "!" / "*" / "'" / "(" / ")" / "," extra = "!" / "*" / "'" / "(" / ")" / ","
rtsp-extra = "!" / "*" / "'" / "(" / ")" rtsp-extra = "!" / "*" / "'" / "(" / ")"
HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
/ "a" / "b" / "c" / "d" / "e" / "f" / "a" / "b" / "c" / "d" / "e" / "f"
skipping to change at page 129, line 24 skipping to change at page 145, line 24
LAQUOT = SWS "<" ; left angle quote LAQUOT = SWS "<" ; left angle quote
TEXT-UTF8char = %x21-7E / UTF8-NONASCII TEXT-UTF8char = %x21-7E / UTF8-NONASCII
UTF8-NONASCII = %xC0-DF 1UTF8-CONT UTF8-NONASCII = %xC0-DF 1UTF8-CONT
/ %xE0-EF 2UTF8-CONT / %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT / %xF0-F7 3UTF8-CONT
/ %xF8-FB 4UTF8-CONT / %xF8-FB 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT / %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF UTF8-CONT = %x80-BF
FLOAT = ["-"] 1*39DIGIT ["." 1*46DIGIT]
POS-FLOAT = 1*39DIGIT ["." 1*46DIGIT]
20.2. RTSP Protocol Definition 20.2. RTSP Protocol Definition
20.2.1. Generic Protocol elements 20.2.1. Generic Protocol elements
RTSP-IRI = schemes ":" IRI-rest RTSP-IRI = schemes ":" IRI-rest
IRI-rest = ihier-part [ "?" iquery ] [ "#" ifragment ] IRI-rest = ihier-part [ "?" iquery ] [ "#" ifragment ]
ihier-part = "//" iauthority ipath-abempty ihier-part = "//" iauthority ipath-abempty
RTSP-IRI-ref = RTSP-IRI / irelative-ref RTSP-IRI-ref = RTSP-IRI / irelative-ref
irelative-ref = irelative-part [ "?" iquery ] [ "#" ifragment ] irelative-ref = irelative-part [ "?" iquery ] [ "#" ifragment ]
irelative-part = "//" iauthority ipath-abempty irelative-part = "//" iauthority ipath-abempty
/ ipath-absolute / ipath-absolute
skipping to change at page 133, line 7 skipping to change at page 149, line 7
session-id = 1*256( ALPHA / DIGIT / safe ) session-id = 1*256( ALPHA / DIGIT / safe )
extension-header = header-name HCOLON header-value extension-header = header-name HCOLON header-value
header-name = token header-name = token
header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) header-value = *(TEXT-UTF8char / UTF8-CONT / LWS)
20.2.2. Message Syntax 20.2.2. Message Syntax
RTSP-message = Request / Response ;RTSP/2.0 messages RTSP-message = Request / Response ;RTSP/2.0 messages
Request = Request-Line Request = Request-Line
*(general-header *((general-header
/ request-header / request-header
/ entity-header ) / entity-header) CRLF)
CRLF CRLF
[ message-body ] [ message-body ]
Response = Status-Line Response = Status-Line
*( general-header *((general-header
/ response-header / response-header
/ entity-header ) / entity-header) CRLF)
CRLF CRLF
[ message-body ] [ message-body ]
Request-Line = Method SP Request-URI SP RTSP-Version CRLF Request-Line = Method SP Request-URI SP RTSP-Version CRLF
Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF
Method = "DESCRIBE" Method = "DESCRIBE"
/ "GET_PARAMETER" / "GET_PARAMETER"
/ "OPTIONS" / "OPTIONS"
/ "PAUSE" / "PAUSE"
/ "PLAY" / "PLAY"
/ "PLAY_NOTIFY"
/ "REDIRECT" / "REDIRECT"
/ "SETUP" / "SETUP"
/ "SET_PARAMETER" / "SET_PARAMETER"
/ "TEARDOWN" / "TEARDOWN"
/ extension-method / extension-method
extension-method = token extension-method = token
Request-URI = "*" / RTSP-URI Request-URI = "*" / RTSP-URI
RTSP-Version = "RTSP/" 1*DIGIT "." 1*DIGIT RTSP-Version = "RTSP/" 1*DIGIT "." 1*DIGIT
skipping to change at page 135, line 4 skipping to change at page 150, line 51
/ extension-code / extension-code
extension-code = 3DIGIT extension-code = 3DIGIT
Reason-Phrase = *TEXT Reason-Phrase = *TEXT
general-header = Cache-Control general-header = Cache-Control
/ Connection / Connection
/ CSeq / CSeq
/ Date / Date
/ Media-Properties
/ Media-Range
/ Pipelined-Requests / Pipelined-Requests
/ Proxy-Supported / Proxy-Supported
/ Seek-Style
/ Supported / Supported
/ Timestamp / Timestamp
/ Via / Via
/ extension-header / extension-header
request-header = Accept request-header = Accept
/ Accept-Credentials / Accept-Credentials
/ Accept-Encoding / Accept-Encoding
/ Accept-Language / Accept-Language
/ Authorization / Authorization
/ Bandwidth / Bandwidth
/ Blocksize / Blocksize
/ From / From
/ If-Match / If-Match
/ If-Modified-Since / If-Modified-Since
/ If-None-Match / If-None-Match
/ Notify-Reason
/ Proxy-Require / Proxy-Require
/ Range / Range
/ Referer / Referer
/ Request-Status
/ Require / Require
/ Scale / Scale
/ Session / Session
/ Speed / Speed
/ Supported / Supported
/ Transport / Transport
/ User-Agent / User-Agent
/ extension-header / extension-header
response-header = Accept-Credentials response-header = Accept-Credentials
/ Accept-Ranges / Accept-Ranges
/ Connection-Credentials / Connection-Credentials
/ ETag / ETag
/ Location / Location
/ Proxy-Authenticate / Proxy-Authenticate
/ Public / Public
/ Range / Range
/ Retry-After / Retry-After
/ RTP-Info / RTP-Info
skipping to change at page 136, line 32 skipping to change at page 152, line 50
Accept = "Accept" HCOLON Accept = "Accept" HCOLON
[ accept-range *(COMMA accept-range) ] [ accept-range *(COMMA accept-range) ]
accept-range = media-range *(SEMI accept-param) accept-range = media-range *(SEMI accept-param)
media-range = ( "*/*" media-range = ( "*/*"
/ ( m-type SLASH "*" ) / ( m-type SLASH "*" )
/ ( m-type SLASH m-subtype ) / ( m-type SLASH m-subtype )
) *( SEMI m-parameter ) ) *( SEMI m-parameter )
accept-param = ("q" EQUAL qvalue) / generic-param accept-param = ("q" EQUAL qvalue) / generic-param
qvalue = ( "0" [ "." *3DIGIT ] ) qvalue = ( "0" [ "." *3DIGIT ] )
/ ( "1" [ "." *3("0") ] ) / ( "1" [ "." *3("0") ] )
Accept-Credentials = "Accept-Credentials" HCOLON cred-decision CRLF Accept-Credentials = "Accept-Credentials" HCOLON cred-decision
cred-decision = ("User" [LWS cred-info]) cred-decision = ("User" [LWS cred-info])
/ "Proxy" / "Proxy"
/ "Any" / "Any"
/ token [LWS 1*TEXT] ; For future extensions / token [LWS 1*TEXT] ; For future extensions
cred-info = cred-info-data *(COMMA cred-info-data) cred-info = cred-info-data *(COMMA cred-info-data)
cred-info-data = DQ RTSP-URI DQ SEMI hash-alg SEMI base64 cred-info-data = DQ RTSP-URI DQ SEMI hash-alg SEMI base64
hash-alg = "sha-256" / extension-alg hash-alg = "sha-256" / extension-alg
extension-alg = token extension-alg = token
Accept-Encoding = "Accept-Encoding" HCOLON Accept-Encoding = "Accept-Encoding" HCOLON
[ encoding *(COMMA encoding) ] [ encoding *(COMMA encoding) ]
encoding = codings *(SEMI accept-param) encoding = codings *(SEMI accept-param)
codings = content-coding / "*" codings = content-coding / "*"
content-coding = token content-coding = token
Accept-Language = "Accept-Language" HCOLON Accept-Language = "Accept-Language" HCOLON
[ language *(COMMA language) ] [ language *(COMMA language) ]
language = language-range *(SEMI accept-param) language = language-range *(SEMI accept-param)
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" ) language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" )
Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges CRLF Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges
acceptable-ranges = (range-unit *(COMMA range-unit)) acceptable-ranges = (range-unit *(COMMA range-unit))
/ "none" / "none"
range-unit = "NPT" / "SMPTE" / "UTC" / extension-format range-unit = "NPT" / "SMPTE" / "UTC" / extension-format
extension-format = token extension-format = token
Allow = "Allow" HCOLON [Method *(COMMA Method)] Allow = "Allow" HCOLON [Method *(COMMA Method)]
Authorization = "Authorization" HCOLON credentials Authorization = "Authorization" HCOLON credentials
credentials = ("Digest" LWS digest-response) credentials = ("Digest" LWS digest-response)
/ other-response / other-response
digest-response = dig-resp *(COMMA dig-resp) digest-response = dig-resp *(COMMA dig-resp)
skipping to change at page 137, line 37 skipping to change at page 154, line 7
nc-value = 8LHEX nc-value = 8LHEX
dresponse = "response" EQUAL request-digest dresponse = "response" EQUAL request-digest
request-digest = LDQUOT 32LHEX RDQUOT request-digest = LDQUOT 32LHEX RDQUOT
auth-param = auth-param-name EQUAL auth-param = auth-param-name EQUAL
( token / quoted-string ) ( token / quoted-string )
auth-param-name = token auth-param-name = token
other-response = auth-scheme LWS auth-param other-response = auth-scheme LWS auth-param
*(COMMA auth-param) *(COMMA auth-param)
auth-scheme = token auth-scheme = token
Bandwidth = "Bandwidth" HCOLON 1*DIGIT CRLF Bandwidth = "Bandwidth" HCOLON 1*DIGIT
Blocksize = "Blocksize" HCOLON 1*DIGIT CRLF Blocksize = "Blocksize" HCOLON 1*DIGIT
Cache-Control = "Cache-Control" HCOLON cache-directive CRLF
Cache-Control = "Cache-Control" HCOLON cache-directive
*(COMMA cache-directive) *(COMMA cache-directive)
cache-directive = cache-rqst-directive cache-directive = cache-rqst-directive
/ cache-rspns-directive / cache-rspns-directive
cache-rqst-directive = "no-cache" cache-rqst-directive = "no-cache"
/ "max-stale" [EQUAL delta-seconds] / "max-stale" [EQUAL delta-seconds]
/ "min-fresh" EQUAL delta-seconds / "min-fresh" EQUAL delta-seconds
/ "only-if-cached" / "only-if-cached"
/ cache-extension / cache-extension
skipping to change at page 138, line 27 skipping to change at page 154, line 34
/ "no-cache" / "no-cache"
/ "no-transform" / "no-transform"
/ "must-revalidate" / "must-revalidate"
/ "proxy-revalidate" / "proxy-revalidate"
/ "max-age" EQUAL delta-seconds / "max-age" EQUAL delta-seconds
/ cache-extension / cache-extension
cache-extension = token [EQUAL (token / quoted-string)] cache-extension = token [EQUAL (token / quoted-string)]
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
Connection-Credentials = "Connection-Credentials" HCOLON cred-chain CRLF Connection-Credentials = "Connection-Credentials" HCOLON cred-chain
cred-chain = DQ RTSP-URI DQ SEMI base64 cred-chain = DQ RTSP-URI DQ SEMI base64
Connection = "Connection" HCOLON (connection-token) Connection = "Connection" HCOLON (connection-token)
*(COMMA connection-token) CRLF *(COMMA connection-token)
connection-token = token connection-token = token
Content-Base = "Content-Base" HCOLON RTSP-URI-Ref CRLF Content-Base = "Content-Base" HCOLON RTSP-URI-Ref
Content-Encoding = "Content-Encoding" HCOLON Content-Encoding = "Content-Encoding" HCOLON
content-coding *(COMMA content-coding) content-coding *(COMMA content-coding)
Content-Language = "Content-Language" HCOLON Content-Language = "Content-Language" HCOLON
language-tag *(COMMA language-tag) language-tag *(COMMA language-tag)
language-tag = primary-tag *( "-" subtag ) language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA primary-tag = 1*8ALPHA
subtag = 1*8ALPHA subtag = 1*8ALPHA
Content-Length = "Content-Length" HCOLON 1*DIGIT Content-Length = "Content-Length" HCOLON 1*DIGIT
Content-Location = "Content-Location" HCOLON RTSP-URI-Ref Content-Location = "Content-Location" HCOLON RTSP-URI-Ref
Content-Type = ( "Content-Type" / "c" ) HCOLON media-type Content-Type = ( "Content-Type" / "c" ) HCOLON media-type
skipping to change at page 139, line 12 skipping to change at page 155, line 19
composite-type = "message" / "multipart" / extension-token composite-type = "message" / "multipart" / extension-token
extension-token = ietf-token / x-token extension-token = ietf-token / x-token
ietf-token = token ietf-token = token
x-token = "x-" token x-token = "x-" token
m-subtype = extension-token / iana-token m-subtype = extension-token / iana-token
iana-token = token iana-token = token
m-parameter = m-attribute EQUAL m-value m-parameter = m-attribute EQUAL m-value
m-attribute = token m-attribute = token
m-value = token / quoted-string m-value = token / quoted-string
CSeq = "Cseq" HCOLON 1*DIGIT CRLF CSeq = "Cseq" HCOLON cseq-nr
cseq-nr = 1*9DIGIT
Date = "Date" HCOLON RTSP-date Date = "Date" HCOLON RTSP-date
RTSP-date = rfc1123-date ; HTTP-date RTSP-date = rfc1123-date ; HTTP-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT" rfc1123-date = wkday "," SP date1 SP time SP "GMT"
date1 = 2DIGIT SP month SP 4DIGIT date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982) ; day month year (e.g., 02 Jun 1982)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59 ; 00:00:00 - 23:59:59
wkday = "Mon" / "Tue" / "Wed" wkday = "Mon" / "Tue" / "Wed"
/ "Thu" / "Fri" / "Sat" / "Sun" / "Thu" / "Fri" / "Sat" / "Sun"
month = "Jan" / "Feb" / "Mar" / "Apr" month = "Jan" / "Feb" / "Mar" / "Apr"
skipping to change at page 139, line 45 skipping to change at page 156, line 5
tag-param = "tag" EQUAL token tag-param = "tag" EQUAL token
If-Match = "If-Match" HCOLON ( "*" / entity-tag-list) If-Match = "If-Match" HCOLON ( "*" / entity-tag-list)
entity-tag-list = entity-tag *(COMMA entity-tag) entity-tag-list = entity-tag *(COMMA entity-tag)
entity-tag = [ weak ] opaque-tag entity-tag = [ weak ] opaque-tag
weak = "W/" weak = "W/"
opaque-tag = quoted-string opaque-tag = quoted-string
If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date
If-None-Match = "If-None-Match" HCOLON ("*" / entity-tag-list) If-None-Match = "If-None-Match" HCOLON ("*" / entity-tag-list)
Last-Modified = "Last-Modified" HCOLON RTSP-date Last-Modified = "Last-Modified" HCOLON RTSP-date
Location = "Location" HCOLON RTSP-URI Location = "Location" HCOLON RTSP-URI
Media-Properties = "Media-Properties" HCOLON media-prop-list
media-prop-list = media-prop-value *(COMMA media-prop-value)
media-prop-value = "Random-Access" EQUAL POS-FLOAT
/ "Begining-Only"
/ "No-Seeking"
/ "Unmutable"
/ "Dynamic"
/ "Time-Progressing"
/ "Unlimited"
/ "Time-Limited" EQUAL utc-range-spec
/ "Time-Duration" EQUAL POS-FLOAT
/ media-prop-ext
media-prop-ext = token [EQUAL SWS 1*rtsp-unreserved / quoted-string]
Media-Range = "Media-Range" HCOLON [ranges-list]
Notify-Reason = "Notify-Reason" HCOLON Notify-Reas-val
Notify-Reas-val = "end-of-stream"
/ "media-properties-update"
/ "scale-change"
/ Notify-Reason-extension
Notify-Reason-extension = token
Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id
startup-id = 1*8DIGIT startup-id = 1*8DIGIT
Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge
challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) challenge = ("Digest" LWS digest-cln *(COMMA digest-cln))
/ other-challenge / other-challenge
other-challenge = auth-scheme LWS auth-param other-challenge = auth-scheme LWS auth-param
*(COMMA auth-param) *(COMMA auth-param)
digest-cln = realm / domain / nonce digest-cln = realm / domain / nonce
/ opaque / stale / algorithm / opaque / stale / algorithm
/ qop-options / auth-param / qop-options / auth-param
skipping to change at page 140, line 25 skipping to change at page 157, line 25
*( 1*SP URI ) RDQUOT *( 1*SP URI ) RDQUOT
URI = RTSP-URI / RTSP-URI-Ref URI = RTSP-URI / RTSP-URI-Ref
nonce = "nonce" EQUAL nonce-value nonce = "nonce" EQUAL nonce-value
nonce-value = quoted-string nonce-value = quoted-string
opaque = "opaque" EQUAL quoted-string opaque = "opaque" EQUAL quoted-string
stale = "stale" EQUAL ( "true" / "false" ) stale = "stale" EQUAL ( "true" / "false" )
algorithm = "algorithm" EQUAL ("MD5" / "MD5-sess" / token) algorithm = "algorithm" EQUAL ("MD5" / "MD5-sess" / token)
qop-options = "qop" EQUAL LDQUOT qop-value qop-options = "qop" EQUAL LDQUOT qop-value
*("," qop-value) RDQUOT *("," qop-value) RDQUOT
qop-value = "auth" / "auth-int" / token qop-value = "auth" / "auth-int" / token
Proxy-Require = "Proxy-Require" HCOLON feature-tag CRLF Proxy-Require = "Proxy-Require" HCOLON feature-tag
*(COMMA feature-tag) *(COMMA feature-tag)
Proxy-Supported = "Proxy-Supported" HCOLON feature-tag Proxy-Supported = "Proxy-Supported" HCOLON feature-tag
*(COMMA feature-tag) CRLF *(COMMA feature-tag)
Public = "Public" HCOLON Method *(COMMA Method) CRLF Public = "Public" HCOLON Method *(COMMA Method)
Range = "Range" HCOLON ranges-list [exec-time] CRLF Range = "Range" HCOLON ranges-list [exec-time]
ranges-list = ranges-spec *(COMMA ranges-spec) ranges-list = ranges-spec *(COMMA ranges-spec)
exec-time = SEMI "time" EQUAL utc-time exec-time = SEMI "time" EQUAL utc-time
ranges-spec = npt-range / utc-range / smpte-range ranges-spec = npt-range / utc-range / smpte-range
/ range-ext / range-ext
range-ext = extension-format "=" range-value range-ext = extension-format "=" range-value
range-value = 1*(rtsp-unreserved / quoted-string / ":" ) range-value = 1*(rtsp-unreserved / quoted-string / ":" )
Referer = "Referer" HCOLON RTSP-URI-Ref Referer = "Referer" HCOLON RTSP-URI-Ref
Require = "Require" HCOLON feature-tag-list CRLF Request-Status = "Request-Status" HCOLON status-info
status-info = cseq-info LWS status-info LWS reason-info
cseq-info = "cseq" EQUAL cseq-nr
status-info = "status" EQUAL Status-Code
reason-info = "reason" EQUAL DQ Reason-Phrase DQ
Require = "Require" HCOLON feature-tag-list
feature-tag-list = feature-tag *(COMMA feature-tag) feature-tag-list = feature-tag *(COMMA feature-tag)
RTP-Info = "RTP-Info" HCOLON rtsp-info-spec RTP-Info = "RTP-Info" HCOLON rtsp-info-spec
*(COMMA rtsp-info-spec) CRLF *(COMMA rtsp-info-spec)
rtsp-info-spec = stream-url 1*ssrc-parameter rtsp-info-spec = stream-url 1*ssrc-parameter
stream-url = "url" EQUAL DQ RTSP-URI-Ref DQ stream-url = "url" EQUAL DQ RTSP-URI-Ref DQ
ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON
ri-parameter *(SEMI ri-parameter) ri-parameter *(SEMI ri-parameter)
ri-parameter = "seq" EQUAL 1*DIGIT ri-parameter = "seq" EQUAL 1*DIGIT
/ "rtptime" EQUAL 1*DIGIT / "rtptime" EQUAL 1*DIGIT
Retry-After = "Retry-After" HCOLON delta-seconds Retry-After = "Retry-After" HCOLON delta-seconds
[ comment ] *( SEMI retry-param ) [ comment ] *( SEMI retry-param )
retry-param = ("duration" EQUAL delta-seconds) retry-param = ("duration" EQUAL delta-seconds)
/ generic-param / generic-param
Scale = "Scale" HCOLON ["-"] 1*DIGIT [ "." *DIGIT ] CRLF Scale = "Scale" HCOLON ["-"] 1*DIGIT [ "." *DIGIT ]
Seek-Style = "Seek-Style" HCOLON Seek-S-values
Speed = "Speed" HCOLON 1*DIGIT [ "." *DIGIT ] CRLF Seek-S-values = "RAP"
/ "First-Prior"
/ "Next"
/ Seek-S-value-ext
Seek-S-value-ext = token
Speed = "Speed" HCOLON 1*DIGIT [ "." *DIGIT ]
Server = "Server" HCOLON ( product / comment ) Server = "Server" HCOLON ( product / comment )
*(LWS (product / comment)) CRLF *(LWS (product / comment))
product = token [SLASH product-version] product = token [SLASH product-version]
product-version = token product-version = token
comment = LPAREN *( ctext / quoted-pair) RPAREN comment = LPAREN *( ctext / quoted-pair) RPAREN
Session = "Session" HCOLON session-id Session = "Session" HCOLON session-id
[ SEMI "timeout" EQUAL delta-seconds ] CRLF [ SEMI "timeout" EQUAL delta-seconds ]
Supported = "Supported" HCOLON [feature-tag-list] CRLF Supported = "Supported" HCOLON [feature-tag-list]
Timestamp = "Timestamp" HCOLON timestamp-value LWS [delay] Timestamp = "Timestamp" HCOLON timestamp-value LWS [delay]
timestamp-value = *DIGIT [ "." *DIGIT ] timestamp-value = *DIGIT [ "." *DIGIT ]
delay = *DIGIT [ "." *DIGIT ] delay = *DIGIT [ "." *DIGIT ]
Transport = "Transport" HCOLON transport-spec Transport = "Transport" HCOLON transport-spec
*(COMMA transport-spec) CRLF *(COMMA transport-spec)
transport-spec = transport-id *tr-parameter transport-spec = transport-id *tr-parameter
transport-id = trans-id-rtp / other-trans transport-id = trans-id-rtp / other-trans
trans-id-rtp = "RTP/" profile ["/" lower-transport] trans-id-rtp = "RTP/" profile ["/" lower-transport]
; no LWS is allowed inside transport-id ; no LWS is allowed inside transport-id
other-trans = token *("/" token) other-trans = token *("/" token)
profile = "AVP" / "SAVP" / "AVPF" / token profile = "AVP" / "SAVP" / "AVPF" / token
lower-transport = "TCP" / "UDP" / token lower-transport = "TCP" / "UDP" / token
tr-parameter = SEMI ( "unicast" / "multicast" ) tr-parameter = SEMI ( "unicast" / "multicast" )
/ SEMI "interleaved" EQUAL channel [ "-" channel ] / SEMI "interleaved" EQUAL channel [ "-" channel ]
/ SEMI "append" / SEMI "append"
skipping to change at page 143, line 4 skipping to change at page 160, line 4
channel = 1*3DIGIT channel = 1*3DIGIT
mode-spec = ( DQ mode *(COMMA mode) DQ ) mode-spec = ( DQ mode *(COMMA mode) DQ )
mode = "PLAY" / token mode = "PLAY" / token
addr-list = quoted-addr *(SLASH quoted-addr) addr-list = quoted-addr *(SLASH quoted-addr)
quoted-addr = DQ (host-port / extension-addr) DQ quoted-addr = DQ (host-port / extension-addr) DQ
host-port = host [":" port] host-port = host [":" port]
/ ":" port / ":" port
extension-addr = 1*qdtext extension-addr = 1*qdtext
host = < As defined in RFC 3986> host = < As defined in RFC 3986>
port = < As defined in RFC 3986> port = < As defined in RFC 3986>
Unsupported = "Unsupported" HCOLON feature-tag-list CRLF Unsupported = "Unsupported" HCOLON feature-tag-list
User-Agent = "User-Agent" HCOLON ( product / comment ) User-Agent = "User-Agent" HCOLON ( product / comment )
0*(LWS (product / comment)) CRLF 0*(LWS (product / comment))
Vary = "Vary" HCOLON ( "*" / field-name-list) Vary = "Vary" HCOLON ( "*" / field-name-list)
field-name-list = field-name *(COMMA field-name) field-name-list = field-name *(COMMA field-name)
field-name = token field-name = token
Via = "Via" HCOLON via-parm *(COMMA via-parm) Via = "Via" HCOLON via-parm *(COMMA via-parm)
via-parm = sent-protocol LWS sent-by *( SEMI via-params ) via-parm = sent-protocol LWS sent-by *( SEMI via-params )
via-params = via-ttl / via-maddr via-params = via-ttl / via-maddr
/ via-received / via-branch / via-received / via-branch
/ via-extension / via-extension
via-ttl = "ttl" EQUAL ttl via-ttl = "ttl" EQUAL ttl
skipping to change at page 148, line 15 skipping to change at page 165, line 15
22. IANA Considerations 22. IANA Considerations
This section sets up a number of registries for RTSP 2.0 that should This section sets up a number of registries for RTSP 2.0 that should
be maintained by IANA. For each registry there is a description on be maintained by IANA. For each registry there is a description on
what it is required to contain, what specification is needed when what it is required to contain, what specification is needed when
adding a entry with IANA, and finally the entries that this document adding a entry with IANA, and finally the entries that this document
needs to register. See also the Section 2.3 "Extending RTSP". There needs to register. See also the Section 2.3 "Extending RTSP". There
is also an IANA registration of two SDP attributes. is also an IANA registration of two SDP attributes.
The sections describing how to register an item uses some of the The sections describing how to register an item uses some of the
requirements level described in RFC 2434 [RFC2434], namely "First requirements level described in RFC YYYY
Come, First Served", "Specification Required", and "Standards [I-D.narten-iana-considerations-rfc2434bis], namely "First Come,
Action". First Served", "Expert Review, "Specification Required", and
"Standards Action".
A registration request to IANA MUST contain the following A registration request to IANA MUST contain the following
information: information:
o A name of the item to register according to the rules specified by o A name of the item to register according to the rules specified by
the intended registry. the intended registry.
o Indication of who has change control over the feature (for o Indication of who has change control over the feature (for
example, IETF, ISO, ITU-T, other international standardization example, IETF, ISO, ITU-T, other international standardization
bodies, a consortium, a particular company or group of companies, bodies, a consortium, a particular company or group of companies,
or an individual); or an individual);
o A reference to a further description, if available, for example o A reference to a further description, if available, for example
(in order of preference) an RFC, a published standard, a published (in decreasing order of preference) an RFC, a published standard,
paper, a patent filing, a technical report, documented source code a published paper, a patent filing, a technical report, documented
or a computer manual; source code or a computer manual;
o For proprietary features, contact information (postal and email o For proprietary features, contact information (postal and email
address); address);
22.1. Feature-tags 22.1. Feature-tags
22.1.1. Description 22.1.1. Description
When a client and server try to determine what part and functionality When a client and server try to determine what part and functionality
of the RTSP specification and any future extensions that its counter of the RTSP specification and any future extensions that its counter
skipping to change at page 149, line 24 skipping to change at page 166, line 24
servers, or proxies only or any combinations of these. Any servers, or proxies only or any combinations of these. Any
proprietary feature SHALL have as the first part of the name a vendor proprietary feature SHALL have as the first part of the name a vendor
tag, which identifies the organization. tag, which identifies the organization.
22.1.3. Registered entries 22.1.3. Registered entries
The following feature-tags are in this specification defined and The following feature-tags are in this specification defined and
hereby registered. The change control belongs to the IETF. hereby registered. The change control belongs to the IETF.
play.basic: The minimal implementation for playback operations play.basic: The minimal implementation for playback operations
according to Appendix E. Applies for both clients, servers and according to this specification. Applies for both clients,
proxies. servers and proxies.
play.scale: Support of scale operations for media playback. Applies play.scale: Support of scale operations for media playback. Applies
only for servers. only for servers.
play.speed: Support of the speed functionality for playback. play.speed: Support of the speed functionality for playback.
Applies only for servers. Applies only for servers.
22.2. RTSP Methods 22.2. RTSP Methods
22.2.1. Description 22.2.1. Description
What a method is, is described in section Section 13. Extending the What a method is, is described in section Section 13. Extending the
protocol with new methods allow for totally new functionality. protocol with new methods allow for totally new functionality.
22.2.2. Registering New Methods with IANA 22.2.2. Registering New Methods with IANA
A new method MUST be registered through an IETF standard track A new method MUST be registered through an IETF Standards Action.
document. The reason is that new methods may radically change the The reason is that new methods may radically change the protocols
protocols behavior and purpose. behavior and purpose.
A specification for a new RTSP method MUST consist of the following A specification for a new RTSP method MUST consist of the following
items: items:
o A method name which follows the ABNF rules for methods. o A method name which follows the ABNF rules for methods.
o A clear specification on what action and response a request with o A clear specification on what action and response a request with
the method will result in. Which directions the method is used, the method will result in. Which directions the method is used,
C->S or S->C or both. How the use of headers, if any, modifies C->S or S->C or both. How the use of headers, if any, modifies
the behavior and effect of the method. the behavior and effect of the method.
o A list or table specifying which of the registered headers that o A list or table specifying which of the registered headers that
are allowed to use with the method in request or/and response. are allowed to use with the method in request or/and response.
o Describe how the method relates to network proxies. o Describe how the method relates to network proxies.
22.2.3. Registered Entries 22.2.3. Registered Entries
This specification, RFCXXXX, registers 9 methods: DESCRIBE, This specification, RFCXXXX, registers 10 methods: DESCRIBE,
GET_PARAMETER, OPTIONS, PAUSE, PLAY, REDIRECT, SETUP, SETPARAMETER, GET_PARAMETER, OPTIONS, PAUSE, PLAY, PLAY_NOTIFY REDIRECT, SETUP,
and TEARDOWN. SET_PARAMETER, and TEARDOWN.
22.3. RTSP Status Codes 22.3. RTSP Status Codes
22.3.1. Description 22.3.1. Description
A status code is the three digit numbers used to convey information A status code is the three digit numbers used to convey information
in RTSP response messages, seeSection 8. The number space is limited in RTSP response messages, seeSection 8. The number space is limited
and care should be taken not to fill the space. and care should be taken not to fill the space.
22.3.2. Registering New Status Codes with IANA 22.3.2. Registering New Status Codes with IANA
A new status code can only be registered by an IETF standards track A new status code can only be registered by an IETF Standards Action.
document. A specification for a new status code MUST specify the A specification for a new status code MUST specify the following:
following:
o The requested number. o The requested number.
o A description what the status code means and the expected behavior o A description what the status code means and the expected behavior
of the sender and receiver of the code. of the sender and receiver of the code.
22.3.3. Registered Entries 22.3.3. Registered Entries
RFCXXX, registers the numbered status code defined in the ABNF entry RFCXXX, registers the numbered status code defined in the ABNF entry
"Status-Code" except "extension-code" in Section 20.2.2. "Status-Code" except "extension-code" in Section 20.2.2.
skipping to change at page 151, line 7 skipping to change at page 168, line 7
By specifying new headers a method(s) can be enhanced in many By specifying new headers a method(s) can be enhanced in many
different ways. An unknown header will be ignored by the receiving different ways. An unknown header will be ignored by the receiving
entity. If the new header is vital for a certain functionality, a entity. If the new header is vital for a certain functionality, a
feature-tag for the functionality can be created and demanded to be feature-tag for the functionality can be created and demanded to be
used by the counter-part with the inclusion of a Require header used by the counter-part with the inclusion of a Require header
carrying the feature-tag. carrying the feature-tag.
22.4.2. Registering New Headers with IANA 22.4.2. Registering New Headers with IANA
A public available specification is required to register a header. Registrations in the registry can be done following the Expert Review
The specification SHOULD be a standards document, preferable an IETF policy. A specification SHOULD be provided, preferable an IETF RFC
RFC. or other Standards Developing Organization specification. The
minimal information in a registration request is the header name and
the contact information.
The specification MUST contain the following information: The specification SHOULD contain the following information:
o The name of the header. o The name of the header.
o An ABNF specification of the header syntax. o An ABNF specification of the header syntax.
o A list or table specifying when the header may be used, o A list or table specifying when the header may be used,
encompassing all methods, their request or response, the direction encompassing all methods, their request or response, the direction
(C->S or S->C). (C->S or S->C).
o How the header is to be handled by proxies. o How the header is to be handled by proxies.
skipping to change at page 152, line 7 skipping to change at page 169, line 9
o 3gpp-videopostdecbufsize defined in [3gpp-26234]. o 3gpp-videopostdecbufsize defined in [3gpp-26234].
o 3GPP-Link-Char defined in [3gpp-26234]. o 3GPP-Link-Char defined in [3gpp-26234].
o 3GPP-Adaptation defined in [3gpp-26234]. o 3GPP-Adaptation defined in [3gpp-26234].
o 3GPP-QoE-Metrics defined in [3gpp-26234]. o 3GPP-QoE-Metrics defined in [3gpp-26234].
o 3GPP-QoE-Feedback defined in [3gpp-26234]. o 3GPP-QoE-Feedback defined in [3gpp-26234].
The use of "X-" is NOT RECOMMENDED but the above headers in the The use of "x-" is NOT RECOMMENDED but the above headers in the
register list was defined prior to the clarification. register list was defined prior to the clarification.
22.5. Transport Header Registries 22.5. Transport Header Registries
The transport header contains a number of parameters which have The transport header contains a number of parameters which have
possibilities for future extensions. Therefore registries for these possibilities for future extensions. Therefore registries for these
needs to be defined. needs to be defined.
22.5.1. Transport Protocol Specification 22.5.1. Transport Protocol Specification
A registry for the parameter transport-protocol specification SHALL A registry for the parameter transport-protocol specification SHALL
be defined with the following rules: be defined with the following rules:
o Registering require an public available standards specification. o Registering uses the policy of Specification Required.
o A contact person or organization with address and email. o A contact person or organization with address and email.
o A value definition that are following the ABNF syntax definition. o A value definition that are following the ABNF syntax definition.
o A describing text that explains how the registered value are used o A describing text that explains how the registered value are used
in RTSP. in RTSP.
This specification registers the following values: This specification registers the following values:
RTP/AVP: Use of the RTP[RFC3550] protocol for media transport in RTP/AVP: Use of the RTP[RFC3550] protocol for media transport in
combination with the "RTP profile for audio and video combination with the "RTP profile for audio and video
conferences with minimal control"[RFC3551] over UDP. The usage conferences with minimal control"[RFC3551] over UDP. The usage
is explained in RFC XXXX, appendix Appendix C.1. is explained in RFC XXXX, appendix Appendix C.1.
RTP/AVP/UDP: the same as RTP/AVP. RTP/AVP/UDP: the same as RTP/AVP.
RTP/AVPF: Use of the RTP[RFC3550] protocol for media transport in RTP/AVPF: Use of the RTP[RFC3550] protocol for media transport in
combination with the "Extended RTP Profile for RTCP-based combination with the "Extended RTP Profile for RTCP-based
Feedback (RTP/AVPF)"[RFC4585] over UDP. The usage is explained Feedback (RTP/AVPF)" [RFC4585] over UDP. The usage is
in RFC XXXX, appendix Appendix C.1. explained in RFC XXXX, appendix Appendix C.1.
RTP/AVPF/UDP: the same as RTP/AVPF. RTP/AVPF/UDP: the same as RTP/AVPF.
RTP/SAVP: Use of the RTP[RFC3550] protocol for media transport in RTP/SAVP: Use of the RTP[RFC3550] protocol for media transport in
combination with the "The Secure Real-time Transport Protocol combination with the "The Secure Real-time Transport Protocol
(SRTP)" [RFC3711] over UDP. The usage is explained in RFC (SRTP)" [RFC3711] over UDP. The usage is explained in RFC
XXXX, appendix Appendix C.1. XXXX, appendix Appendix C.1.
RTP/SAVP/UDP: the same as RTP/SAVP. RTP/SAVP/UDP: the same as RTP/SAVP.
RTP/SAVPF: Use of the RTP[RFC3550] protocol for media transport in RTP/SAVPF: Use of the RTP[RFC3550] protocol for media transport in
combination with the "[I-D.ietf-avt-profile-savpf] over UDP. combination with the "[RFC5124] over UDP. The usage is
The usage is explained in RFC XXXX, appendix Appendix C.1. explained in RFC XXXX, appendix Appendix C.1.
RTP/SAVPF/UDP: the same as RTP/SAVPF. RTP/SAVPF/UDP: the same as RTP/SAVPF.
RTP/AVP/TCP: Use of the RTP[RFC3550] protocol for media transport in RTP/AVP/TCP: Use of the RTP[RFC3550] protocol for media transport in
combination with the "RTP profile for audio and video combination with the "RTP profile for audio and video
conferences with minimal control"[RFC3551] over TCP. The usage conferences with minimal control"[RFC3551] over TCP. The usage
is explained in RFC XXXX, appendix Appendix C.2.2. is explained in RFC XXXX, appendix Appendix C.2.2.
RTP/AVPF/TCP: Use of the RTP[RFC3550] protocol for media transport RTP/AVPF/TCP: Use of the RTP[RFC3550] protocol for media transport
in combination with the "Extended RTP Profile for RTCP-based in combination with the "Extended RTP Profile for RTCP-based
Feedback (RTP/AVPF)"[RFC4585] over TCP. The usage is explained Feedback (RTP/AVPF)"[RFC4585] over TCP. The usage is explained
in RFC XXXX, appendix Appendix C.2.2. in RFC XXXX, appendix Appendix C.2.2.
RTP/SAVP/TCP: Use of the RTP[RFC3550] protocol for media transport RTP/SAVP/TCP: Use of the RTP[RFC3550] protocol for media transport
in combination with the "The Secure Real-time Transport in combination with the "The Secure Real-time Transport
Protocol (SRTP)" [RFC3711] over TCP. The usage is explained in Protocol (SRTP)" [RFC3711] over TCP. The usage is explained in
RFC XXXX, appendix Appendix C.2.2. RFC XXXX, appendix Appendix C.2.2.
RTP/SAVPF/TCP: Use of the RTP[RFC3550] protocol for media transport RTP/SAVPF/TCP: Use of the RTP[RFC3550] protocol for media transport
in combination with the "[I-D.ietf-avt-profile-savpf] over TCP. in combination with the "[RFC5124] over TCP. The usage is
The usage is explained in RFC XXXX, appendix Appendix C.2.2. explained in RFC XXXX, appendix Appendix C.2.2.
22.5.2. Transport modes 22.5.2. Transport modes
A registry for the transport parameter mode SHALL be defined with the A registry for the transport parameter mode SHALL be defined with the
following rules: following rules:
o Registering requires an IETF standard tracks document. o Registering requires an IETF Standards Action.
o A contact person or organization with address and email. o A contact person or organization with address and email.
o A value definition that are following the ABNF token definition. o A value definition that are following the ABNF token definition.
o A describing text that explains how the registered value are used o A describing text that explains how the registered value are used
in RTSP. in RTSP.
This specification registers 1 value: This specification registers 1 value:
PLAY: See RFC XXXX. PLAY: See RFC XXXX.
22.5.3. Transport Parameters 22.5.3. Transport Parameters
A registry for parameters that may be included in the Transport A registry for parameters that may be included in the Transport
header SHALL be defined with the following rules: header SHALL be defined with the following rules:
o Registering required a Open Standards document. o Registering uses the Specification Required policy.
o A value definition that are following the ABNF token definition. o A value definition that are following the ABNF token definition.
o A describing text that explains how the registered value are used o A describing text that explains how the registered value are used
in RTSP. in RTSP.
This specification registers all the transport parameters defined in This specification registers all the transport parameters defined in
Section 16.46. Section 16.51.
22.6. Cache Directive Extensions 22.6. Cache Directive Extensions
There exist a number of cache directives which can be sent in the There exist a number of cache directives which can be sent in the
Cache-Control header. A registry for this cache directives SHALL be Cache-Control header. A registry for this cache directives SHALL be
defined with the following rules: defined with the following rules:
o Registering requires an IETF standard tracks document. o Registering requires an IETF Standards Action.
o A registration is required to contain a contact person. o A registration is required to contain a contact person.
o Name of the directive and a definition of the value, if any. o Name of the directive and a definition of the value, if any.
o Specification if it is an request or response directive. o Specification if it is an request or response directive.
o A describing text that explains how the cache directive is used o A describing text that explains how the cache directive is used
for RTSP controlled media streams. for RTSP controlled media streams.
skipping to change at page 155, line 24 skipping to change at page 172, line 24
The security framework's TLS connection mechanism has two The security framework's TLS connection mechanism has two
registerable entities. registerable entities.
22.7.1. Accept-Credentials policies 22.7.1. Accept-Credentials policies
In Section 19.3.1 three policies for how to handle certificates. In Section 19.3.1 three policies for how to handle certificates.
Further policies may be defined and SHALL be registered with IANA Further policies may be defined and SHALL be registered with IANA
using the following rules: using the following rules:
o Registering requires an IETF standard tracks document. o Registering requires an IETF Standards Action
o A registration is required name a contact person. o A registration is required to name a contact person.
o Name of the policy. o Name of the policy.
o A describing text that explains how the policy works for handling o A describing text that explains how the policy works for handling
the certificates. the certificates.
This specification registers the following values: This specification registers the following values:
Any Any
Proxy Proxy
User User
22.7.2. Accept-Credentials hash algorithms 22.7.2. Accept-Credentials hash algorithms
The Accept-Credentials header (See Section 16.2) allows for the usage The Accept-Credentials header (See Section 16.2) allows for the usage
of other algorithms for hashing the DER records of accepted entities. of other algorithms for hashing the DER records of accepted entities.
The registration of any future algorithm is expected to be extremely The registration of any future algorithm is expected to be extremely
rare and could also be an interoperability problem. Therefore the rare and could also be an interoperability problem. Therefore the
XXX bare for registering new algorithms is placed intentional high. bar for registering new algorithms is placed intentional high.
Any registration of a new hash algorithm SHALL meet the following Any registration of a new hash algorithm SHALL fulfill the following
requirement: requirement:
o Registration requires an IETF standard track document. o Follow the IETF Standards Action policy.
o A definition of the algorithm and its identifier meeting the o A definition of the algorithm and its identifier meeting the
"token" ABNF requirement. "token" ABNF requirement.
22.8. Range header formats 22.8. Range header formats
The Range header allows for different range formats. New ones may be The Range header allows for different range formats. New ones may be
registered, but moderation should be applied as it makes registered, but moderation should be applied as it makes
interoperability more difficult. A registration SHALL fulfill the interoperability more difficult. A registration SHALL fulfill the
following requirements: following requirements:
o A publicly available standards document. o Follow the Specification Required policy.
o A ABNF definition of the range format that fulfils the "range-ext" o A ABNF definition of the range format that fulfils the "range-ext"
definition. definition.
o A Contact person for the registration. o A Contact person for the registration.
o Rules for how one handles the range when using a negative Scale. o Rules for how one handles the range when using a negative Scale.
22.9. URI Schemes 22.9. Media Property Values
22.9.1. Description
The media streams being controlled by RTSP can have many different
properties. The media properties required to cover the use cases
that was in mind when writing the specification are defined.
However, it can be expected that further inovation will result in new
use cases or media streams with properties not covered by the one
specified here. Thus new ones can be specified. As new media
properties may need substantial amount of new definitions to
correctly specify behavior for this property the bar is intended to
be high.
22.9.2. Registration Rules
Registering new media property SHALL fulfill the following
requirements
o Follow the Specification Required policy and get the approval of
the designated Expert.
o Have a ABNF definition of the media property value name that meets
"media-prop-ext" definition
o A Contact Person for the Registration
o Description of all changes to the behavior of RTSP protocol as
result of these changes.
22.9.3. Registered Values
This specification registers the 9 values listed in Section 16.29.
22.10. Notify-Reason header
22.10.1. Description
Notify-Reason values are the way to indicate why a notification was
sent. It may also imply that certain headers shall or should be
present required for the client to act upon the information the
notification carries. New notification behaviors do need to be
described to result in interoperable usage, thus specification are
required.
22.10.2. Registration Rules
Registrations for new Notify-Reason value SHALL fulfill the following
requirements
o Follow the Specification Required policy and get the approval of
the designated Expert.
o Have a ABNF definition of the Notify reason value name that meets
"Notify-Reason-extension" definition
o A Contact Person for the Registration
o Description of which headers shall be included in the request and
response, when it should be sent, and any affect it has on the
server client state.
22.10.3. Registered Values
This specification registers 3 values defined in the Notify-Reas-val
ABNFSection 20.2.3:
o end-of-stream
o media-properties-update
o scale-change
22.11. Seek-Style
22.11.1. Description
New seek policies may be registered, however a large number of these
will complicate implementation substantially. The impact of unknown
policies is that the server will not honor the unknown and use the
server default policy instead.
22.11.2. Registration Rules
Registrations of new Seek-Style polcies SHALL fulfill the following
requirements
o Follow the Specification Required policy.
o Have a ABNF definition of the Seek-Style policy name that meets
"Seek-S-value-ext" definition
o A Contact Person for the Registration
o Description of which headers shall be included in the request and
response, when it should be sent, and any affect it has on the
server client state.
22.11.3. Registered Values
This specification registers 3 values:
o RAP
o First-Prior
o Next
22.12. URI Schemes
This specification defines two URI schemes ("rtsp" and "rtsps") and This specification defines two URI schemes ("rtsp" and "rtsps") and
reserves a third one ("rtspu"). Registrations are following RFC reserves a third one ("rtspu"). Registrations are following RFC
4395[RFC4395]. 4395[RFC4395].
22.9.1. The rtsp URI Scheme 22.12.1. The rtsp URI Scheme
URI scheme name: rtsp URI scheme name: rtsp
Status: Permanent Status: Permanent
URI scheme syntax: See Section 20.2.1 of RFC XXXX. URI scheme syntax: See Section 20.2.1 of RFC XXXX.
URI scheme semantics: The rtsp scheme is used to indicate resources URI scheme semantics: The rtsp scheme is used to indicate resources
accessible through the usage of the Real-time Streaming accessible through the usage of the Real-time Streaming
Protocol (RTSP). RTSP allows different operations on the Protocol (RTSP). RTSP allows different operations on the
resource identified by the URI, but the primary purpose is the resource identified by the URI, but the primary purpose is the
streaming delivery of the resource to a client. However the streaming delivery of the resource to a client. However the
operations that are currently defined are: Describing the operations that are currently defined are: Describing the
skipping to change at page 156, line 49 skipping to change at page 176, line 17
URI scheme semantics: The rtsp scheme is used to indicate resources URI scheme semantics: The rtsp scheme is used to indicate resources
accessible through the usage of the Real-time Streaming accessible through the usage of the Real-time Streaming
Protocol (RTSP). RTSP allows different operations on the Protocol (RTSP). RTSP allows different operations on the
resource identified by the URI, but the primary purpose is the resource identified by the URI, but the primary purpose is the
streaming delivery of the resource to a client. However the streaming delivery of the resource to a client. However the
operations that are currently defined are: Describing the operations that are currently defined are: Describing the
resource for the purpose of configuring the receiving entity resource for the purpose of configuring the receiving entity
(DESCRIBE), configuring the delivery method and its addressing (DESCRIBE), configuring the delivery method and its addressing
(SETUP), controlling the delivery (PLAY and PAUSE), reading or (SETUP), controlling the delivery (PLAY and PAUSE), reading or
setting of resource related parameters (SETPARAMETER and setting of resource related parameters (SET_PARAMETER and
GET_PARAMETER, and termination of the session context created GET_PARAMETER, and termination of the session context created
(TEARDOWN). (TEARDOWN).
Encoding considerations: IRIs in this scheme are defined and needs Encoding considerations: IRIs in this scheme are defined and needs
to be encoded as RTSP URIs when used within the RTSP protocol. to be encoded as RTSP URIs when used within the RTSP protocol.
That encoding is done according to RFC 3987 (XXX). That encoding is done according to RFC 3987.
Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC
2326), RTSP 2.0 (RFC XXXX) 2326), RTSP 2.0 (RFC XXXX)
Interoperability considerations: The change in URI syntax performed Interoperability considerations: The change in URI syntax performed
between RTSP 1.0 and 2.0 can create interoperability issues.