draft-ietf-mmusic-rfc2326bis-19.txt   draft-ietf-mmusic-rfc2326bis-20.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 Obsoletes: RFC 2326 A. Rao
Expires: May 7, 2009 Cisco (if approved) Cisco
R. Lanphier Intended status: Standards Track R. Lanphier
Expires: September 10, 2009
M. Westerlund M. Westerlund
Ericsson AB Ericsson AB
M. Stiemerling (Ed.) M. Stiemerling (Ed.)
NEC NEC
November 3, 2008 March 9, 2009
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-19 draft-ietf-mmusic-rfc2326bis-20
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
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 May 7, 2009. This Internet-Draft will expire on September 10, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This memorandum defines RTSP version 2.0 which is a revision of the This memorandum defines RTSP version 2.0 which obsoletes RTSP version
Proposed Standard RTSP version 1.0 which is defined in RFC 2326. 1.0 which is defined in RFC 2326.
The Real Time Streaming Protocol, or RTSP, is an application-level The Real Time Streaming Protocol, or RTSP, is an application-level
protocol for control over the delivery of data with real-time protocol for setup and control of the delivery of data with real-time
properties. RTSP provides an extensible framework to enable properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and controlled, on-demand delivery of real-time data, such as audio and
video. Sources of data can include both live data feeds and stored video. Sources of data can include both live data feeds and stored
clips. This protocol is intended to control multiple data delivery clips. This protocol is intended to control multiple data delivery
sessions, provide a means for choosing delivery channels such as UDP, sessions, provide a means for choosing delivery channels such as UDP,
multicast UDP and TCP, and provide a means for choosing delivery multicast UDP and TCP, and provide a means for choosing delivery
mechanisms based upon RTP (RFC 3550). mechanisms based upon RTP (RFC 3550).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1. Scope and Background . . . . . . . . . . . . . . . . . . 9 1.1. Notes on Copyright . . . . . . . . . . . . . . . . . . . 11
1.2. RTSP Specificication Update . . . . . . . . . . . . . . 10 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 13
1.3. Notational Conventions . . . . . . . . . . . . . . . . . 10 2.1. Content Description . . . . . . . . . . . . . . . . . . 13
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . 11 2.2. Session Establishment . . . . . . . . . . . . . . . . . 14
1.5. Media Properties . . . . . . . . . . . . . . . . . . . . 14 2.3. Playback Control . . . . . . . . . . . . . . . . . . . . 15
1.5.1. Random Access . . . . . . . . . . . . . . . . . . . 15 2.4. Session Parameter Manipulations . . . . . . . . . . . . 17
1.5.2. Retention . . . . . . . . . . . . . . . . . . . . . 15 2.5. Media Delivery . . . . . . . . . . . . . . . . . . . . . 17
1.5.3. Content Modifications . . . . . . . . . . . . . . . 16 2.5.1. Media Delivery Manipulations . . . . . . . . . . . . 18
1.5.4. Mapping to the Attributes . . . . . . . . . . . . . 16 2.6. Session Maintenance and Termination . . . . . . . . . . 20
2. RTSP Introduction . . . . . . . . . . . . . . . . . . . . . . 17 2.7. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 21
2.1. Protocol Properties . . . . . . . . . . . . . . . . . . 17 3. Document Conventions . . . . . . . . . . . . . . . . . . . . 23
2.2. RTSP's Relationship to HTTP . . . . . . . . . . . . . . 18 3.1. Notational Conventions . . . . . . . . . . . . . . . . . 23
2.3. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 19 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 23
2.4. Overall Operation . . . . . . . . . . . . . . . . . . . 20 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 27
2.5. RTSP States . . . . . . . . . . . . . . . . . . . . . . 21 4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 27
2.6. Relationship with Other Protocols . . . . . . . . . . . 22 4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 27
3. RTSP Use Cases . . . . . . . . . . . . . . . . . . . . . . . 23 4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 29
3.1. On-demand Playback of Stored Content . . . . . . . . . . 23 4.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . 29
3.2. Unicast distribution of Live Content . . . . . . . . . . 24
3.3. On-demand Playback using Multicast . . . . . . . . . . . 25
3.4. Inviting an RTSP server into a conference . . . . . . . 25
3.5. Live Content using Multicast . . . . . . . . . . . . . . 26
4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 28
4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 28
4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 28
4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 30
4.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . 30
4.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 30 4.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 30
4.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . 31 4.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . 31
4.7. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 31 4.7. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 31
4.8. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 32 4.8. Message Body Tags . . . . . . . . . . . . . . . . . . . 31
5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 33 4.9. Media Properties . . . . . . . . . . . . . . . . . . . . 32
5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 33 4.9.1. Random Access . . . . . . . . . . . . . . . . . . . 33
5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 34 4.9.2. Retention . . . . . . . . . . . . . . . . . . . . . 33
5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 34 4.9.3. Content Modifications . . . . . . . . . . . . . . . 33
5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 34 4.9.4. Supported Scale Factors . . . . . . . . . . . . . . 34
6. General Header Fields . . . . . . . . . . . . . . . . . . . . 35 4.9.5. Mapping to the Attributes . . . . . . . . . . . . . 34
7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 35
7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 36 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 35
7.2. Request Header Fields . . . . . . . . . . . . . . . . . 38 5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 36
8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 36
8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 40 5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 37
8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 40 6. General Header Fields . . . . . . . . . . . . . . . . . . . . 38
8.2. Response Header Fields . . . . . . . . . . . . . . . . . 43 7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
9. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 39
9.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 46 7.2. Request Header Fields . . . . . . . . . . . . . . . . . 41
9.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 47 8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 48 8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 43
10.1. Reliability and Acknowledgements . . . . . . . . . . . . 48 8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 43
10.2. Using Connections . . . . . . . . . . . . . . . . . . . 49 8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 46
10.3. Closing Connections . . . . . . . . . . . . . . . . . . 50 9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 49
10.4. Timing Out Connections and RTSP Messages . . . . . . . . 51 9.1. Message Body Header Fields . . . . . . . . . . . . . . . 49
10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 51 9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 50
10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 52 10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 51
11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 53 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 51
12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 55 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 52
13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 56 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 54
13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 57 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 55
13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 58 10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 55
13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 60 10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 56
13.3.1. Changing Transport Parameters . . . . . . . . . . . 63 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 57
13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 64 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 59
13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 64 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 60
13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 68 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 61
13.4.3. Updating current PLAY Requests . . . . . . . . . . . 68 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 62
13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 70 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 64
13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 71 13.3.1. Changing Transport Parameters . . . . . . . . . . . 67
13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 71 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 68
13.4.7. Playing Live with Recording . . . . . . . . . . . . 72 13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 68
13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 72 13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 72
13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 73 13.4.3. Updating current PLAY Requests . . . . . . . . . . . 73
13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 74 13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 74
13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 75 13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 75
13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 76 13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 75
13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 77 13.4.7. Playing Live with Recording . . . . . . . . . . . . 76
13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 79 13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 76
13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 80 13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 77
13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 81 13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 78
13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 82 13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 79
14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 86 13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 80
15. Status Code Definitions . . . . . . . . . . . . . . . . . . . 88 13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 81
15.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 88 13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 84
15.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 88 13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 84
15.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 88 13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 85
15.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 88 13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 86
15.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 88 13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 87
15.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 89 13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 89
15.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 89 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 92
15.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 89 15. Status Code Definitions . . . . . . . . . . . . . . . . . . . 94
15.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 89 15.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 94
15.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 89 15.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 94
15.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 90 15.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 94
15.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 90 15.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 94
15.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 90 15.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 94
15.4.2. 405 Method Not Allowed . . . . . . . . . . . . . . . 90 15.3.1. 301 Moved Permanently . . . . . . . . . . . . . . . 95
15.4.3. 451 Parameter Not Understood . . . . . . . . . . . . 90 15.3.2. 302 Found . . . . . . . . . . . . . . . . . . . . . 95
15.4.4. 452 reserved . . . . . . . . . . . . . . . . . . . . 90 15.3.3. 303 See Other . . . . . . . . . . . . . . . . . . . 95
15.4.5. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 91 15.3.4. 304 Not Modified . . . . . . . . . . . . . . . . . . 95
15.4.6. 454 Session Not Found . . . . . . . . . . . . . . . 91 15.3.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 96
15.4.7. 455 Method Not Valid in This State . . . . . . . . . 91 15.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 96
15.4.8. 456 Header Field Not Valid for Resource . . . . . . 91 15.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 96
15.4.9. 457 Invalid Range . . . . . . . . . . . . . . . . . 91 15.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 96
15.4.10. 458 Parameter Is Read-Only . . . . . . . . . . . . . 91 15.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 97
15.4.11. 459 Aggregate Operation Not Allowed . . . . . . . . 91 15.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 97
15.4.12. 460 Only Aggregate Operation Allowed . . . . . . . . 91 15.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 97
15.4.13. 461 Unsupported Transport . . . . . . . . . . . . . 92 15.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 97
15.4.14. 462 Destination Unreachable . . . . . . . . . . . . 92 15.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 97
15.4.15. 463 Destination Prohibited . . . . . . . . . . . . . 92 15.4.8. 407 Proxy Authentication Required . . . . . . . . . 98
15.4.16. 464 Data Transport Not Ready Yet . . . . . . . . . . 92 15.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 98
15.4.17. 465 Notification Reason Unknown . . . . . . . . . . 92 15.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 98
15.4.18. 470 Connection Authorization Required . . . . . . . 92 15.4.11. 411 Length Required . . . . . . . . . . . . . . . . 98
15.4.19. 471 Connection Credentials not accepted . . . . . . 93 15.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 99
15.4.20. 472 Failure to establish secure connection . . . . . 93 15.4.13. 413 Request Message Body Too Large . . . . . . . . . 99
15.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 93 15.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 99
15.5.1. 551 Option not supported . . . . . . . . . . . . . . 93 15.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 99
16. Header Field Definitions . . . . . . . . . . . . . . . . . . 94 15.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 99
16.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 103 15.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 99
16.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 103 15.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 100
16.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 104 15.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 100
16.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 104 15.4.20. 455 Method Not Valid in This State . . . . . . . . . 100
16.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 104 15.4.21. 456 Header Field Not Valid for Resource . . . . . . 100
16.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 105 15.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 100
16.7. Authorization . . . . . . . . . . . . . . . . . . . . . 105 15.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 100
16.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 105 15.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 100
16.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 105 15.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 100
16.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 106 15.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 101
16.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 108 15.4.27. 462 Destination Unreachable . . . . . . . . . . . . 101
16.12. Connection-Credentials . . . . . . . . . . . . . . . . . 108 15.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 101
16.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 109 15.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 101
16.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 109 15.4.30. 465 Notification Reason Unknown . . . . . . . . . . 101
16.15. Content-Language . . . . . . . . . . . . . . . . . . . . 109 15.4.31. 470 Connection Authorization Required . . . . . . . 101
16.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 110 15.4.32. 471 Connection Credentials not accepted . . . . . . 102
16.17. Content-Location . . . . . . . . . . . . . . . . . . . . 110 15.4.33. 472 Failure to establish secure connection . . . . . 102
16.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 110 15.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 102
16.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 110 15.5.1. 500 Internal Server Error . . . . . . . . . . . . . 102
16.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 110 15.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 102
16.21. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 111 15.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 102
16.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 111 15.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 102
16.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 112 15.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 103
16.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 112 15.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 103
16.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 112 15.5.7. 551 Option not supported . . . . . . . . . . . . . . 103
16.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 113 16. Header Field Definitions . . . . . . . . . . . . . . . . . . 104
16.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 113 16.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 113
16.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 113 16.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 114
16.29. Media-Properties . . . . . . . . . . . . . . . . . . . . 113 16.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 114
16.30. Media-Range . . . . . . . . . . . . . . . . . . . . . . 115 16.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 115
16.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 115 16.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 116
16.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 115 16.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 116
16.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 116 16.7. Authorization . . . . . . . . . . . . . . . . . . . . . 117
16.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 117 16.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 118
16.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 117 16.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 118
16.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 117 16.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 118
16.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 118 16.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 121
16.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 119 16.12. Connection-Credentials . . . . . . . . . . . . . . . . . 121
16.39. Referer . . . . . . . . . . . . . . . . . . . . . . . . 120 16.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 122
16.40. Retry-After . . . . . . . . . . . . . . . . . . . . . . 120 16.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 122
16.41. Request-Status . . . . . . . . . . . . . . . . . . . . . 120 16.15. Content-Language . . . . . . . . . . . . . . . . . . . . 123
16.42. Require . . . . . . . . . . . . . . . . . . . . . . . . 121 16.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 124
16.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 122 16.17. Content-Location . . . . . . . . . . . . . . . . . . . . 124
16.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 123 16.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 124
16.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 124 16.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 125
16.46. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 125 16.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 125
16.47. Server . . . . . . . . . . . . . . . . . . . . . . . . . 126 16.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 126
16.48. Session . . . . . . . . . . . . . . . . . . . . . . . . 126 16.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 127
16.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 127 16.23. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 127
16.50. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 127 16.24. If-Modified-Since . . . . . . . . . . . . . . . . . . . 128
16.51. Transport . . . . . . . . . . . . . . . . . . . . . . . 128 16.25. If-None-Match . . . . . . . . . . . . . . . . . . . . . 128
16.52. Unsupported . . . . . . . . . . . . . . . . . . . . . . 134 16.26. Last-Modified . . . . . . . . . . . . . . . . . . . . . 129
16.53. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 134 16.27. Location . . . . . . . . . . . . . . . . . . . . . . . . 130
16.54. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 134 16.28. Media-Properties . . . . . . . . . . . . . . . . . . . . 130
16.55. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 135 16.29. Media-Range . . . . . . . . . . . . . . . . . . . . . . 132
16.56. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 135 16.30. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 132
17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 16.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 133
17.1. Proxies and Protocol Extensions . . . . . . . . . . . . 137 16.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 133
18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 16.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 134
19. Security Framework . . . . . . . . . . . . . . . . . . . . . 140 16.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 134
19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 140 16.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 135
19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 140 16.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 135
19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 141 16.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 136
19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 142 16.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 137
19.3.2. User approved TLS procedure . . . . . . . . . . . . 143 16.39. Referer . . . . . . . . . . . . . . . . . . . . . . . . 138
20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 16.40. Retry-After . . . . . . . . . . . . . . . . . . . . . . 139
20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 145 16.41. Request-Status . . . . . . . . . . . . . . . . . . . . . 139
20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 147 16.42. Require . . . . . . . . . . . . . . . . . . . . . . . . 139
20.2.1. Generic Protocol elements . . . . . . . . . . . . . 147 16.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 140
20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 150 16.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 142
20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 154 16.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 143
20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 162 16.46. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 145
21. Security Considerations . . . . . . . . . . . . . . . . . . . 163 16.47. Server . . . . . . . . . . . . . . . . . . . . . . . . . 145
21.1. Remote denial of Service Attack . . . . . . . . . . . . 165 16.48. Session . . . . . . . . . . . . . . . . . . . . . . . . 146
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 167 16.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 147
22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 167 16.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 147
22.1.1. Description . . . . . . . . . . . . . . . . . . . . 167 16.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 148
22.1.2. Registering New Feature-tags with IANA . . . . . . . 168 16.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 148
22.1.3. Registered entries . . . . . . . . . . . . . . . . . 168 16.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 155
22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 168 16.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 155
22.2.1. Description . . . . . . . . . . . . . . . . . . . . 168 16.55. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 156
22.2.2. Registering New Methods with IANA . . . . . . . . . 168 16.56. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 157
22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 169 16.57. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 157
22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 169 17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
22.3.1. Description . . . . . . . . . . . . . . . . . . . . 169 17.1. Proxies and Protocol Extensions . . . . . . . . . . . . 159
22.3.2. Registering New Status Codes with IANA . . . . . . . 169 18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 169 18.1. Validation Model (HTTP) . . . . . . . . . . . . . . . . 162
22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 169 18.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 163
22.4.1. Description . . . . . . . . . . . . . . . . . . . . 169 18.1.2. Message Body Tag Cache Validators . . . . . . . . . 163
22.4.2. Registering New Headers with IANA . . . . . . . . . 170 18.1.3. Weak and Strong Validators . . . . . . . . . . . . . 163
22.4.3. Registered entries . . . . . . . . . . . . . . . . . 170 18.1.4. Rules for When to Use Entity Tags and
22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 171 Last-Modified Dates . . . . . . . . . . . . . . . . 166
22.5.1. Accept-Credentials policies . . . . . . . . . . . . 171 18.1.5. Non-validating Conditionals . . . . . . . . . . . . 167
22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 171 18.2. Invalidation After Updates or Deletions (HTTP) . . . . . 167
22.6. Cache-Control Cache Directive Extensions . . . . . . . 172 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 169
22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 172 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 169
22.7.1. Description . . . . . . . . . . . . . . . . . . . . 173 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 169
22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 173 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 170
22.7.3. Registered Values . . . . . . . . . . . . . . . . . 173 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 171
22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 173 19.3.2. User approved TLS procedure . . . . . . . . . . . . 172
22.8.1. Description . . . . . . . . . . . . . . . . . . . . 173 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 173 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 175
22.8.3. Registered Values . . . . . . . . . . . . . . . . . 174 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 177
22.9. Range header formats . . . . . . . . . . . . . . . . . . 174 20.2.1. Generic Protocol elements . . . . . . . . . . . . . 177
22.10. RTP-Info header parameters . . . . . . . . . . . . . . . 174 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 180
22.10.1. Desctiption . . . . . . . . . . . . . . . . . . . . 174 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 184
22.10.2. Registration Rules . . . . . . . . . . . . . . . . . 175 20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 193
22.10.3. Registered Values . . . . . . . . . . . . . . . . . 175 21. Security Considerations . . . . . . . . . . . . . . . . . . . 194
22.11. Seek-Style Policies . . . . . . . . . . . . . . . . . . 175 21.1. Remote denial of Service Attack . . . . . . . . . . . . 196
22.11.1. Description . . . . . . . . . . . . . . . . . . . . 175 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 198
22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 175 22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 198
22.11.3. Registered Values . . . . . . . . . . . . . . . . . 176 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 198
22.12. Transport Header Registries . . . . . . . . . . . . . . 176 22.1.2. Registering New Feature-tags with IANA . . . . . . . 199
22.12.1. Transport Protocol Specification . . . . . . . . . . 176 22.1.3. Registered entries . . . . . . . . . . . . . . . . . 199
22.12.2. Transport modes . . . . . . . . . . . . . . . . . . 177 22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 199
22.12.3. Transport Parameters . . . . . . . . . . . . . . . . 178 22.2.1. Description . . . . . . . . . . . . . . . . . . . . 199
22.13. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 178 22.2.2. Registering New Methods with IANA . . . . . . . . . 199
22.13.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 178 22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 200
22.13.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 179 22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 200
22.13.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 180 22.3.1. Description . . . . . . . . . . . . . . . . . . . . 200
22.14. SDP attributes . . . . . . . . . . . . . . . . . . . . . 181 22.3.2. Registering New Status Codes with IANA . . . . . . . 200
22.15. Media Type Registration for text/parameters . . . . . . 182 22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 200
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 184 22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 200
23.1. Normative References . . . . . . . . . . . . . . . . . . 184 22.4.1. Description . . . . . . . . . . . . . . . . . . . . 200
23.2. Informative References . . . . . . . . . . . . . . . . . 186 22.4.2. Registering New Headers with IANA . . . . . . . . . 201
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 189 22.4.3. Registered entries . . . . . . . . . . . . . . . . . 201
A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 189 22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 202
A.2. Media on Demand using Pipelining . . . . . . . . . . . . 193 22.5.1. Accept-Credentials policies . . . . . . . . . . . . 202
A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 195 22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 202
A.4. Single Stream Container Files . . . . . . . . . . . . . 199 22.6. Cache-Control Cache Directive Extensions . . . . . . . 203
A.5. Live Media Presentation Using Multicast . . . . . . . . 201 22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 203
A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 202 22.7.1. Description . . . . . . . . . . . . . . . . . . . . 204
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 204 22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 204
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 204 22.7.3. Registered Values . . . . . . . . . . . . . . . . . 204
B.2. State variables . . . . . . . . . . . . . . . . . . . . 204 22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 204
B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 204 22.8.1. Description . . . . . . . . . . . . . . . . . . . . 204
B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 205 22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 204
Appendix C. Media Transport Alternatives . . . . . . . . . . . . 210 22.8.3. Registered Values . . . . . . . . . . . . . . . . . 205
C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 210 22.9. Range header formats . . . . . . . . . . . . . . . . . . 205
C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 210 22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 205
C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 210 22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 205
C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 211 22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 206
C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 212 22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 206
C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 212 22.11.1. Description . . . . . . . . . . . . . . . . . . . . 206
C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 212 22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 206
C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 213 22.11.3. Registered Values . . . . . . . . . . . . . . . . . 206
C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 213 22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 207
C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 213 22.12.1. Description . . . . . . . . . . . . . . . . . . . . 207
C.2.3. Handling Media Clock Time Jumps in the RTP Media 22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 207
Layer . . . . . . . . . . . . . . . . . . . . . . . 217 22.12.3. Registered Values . . . . . . . . . . . . . . . . . 207
C.2.4. Handling RTP Timestamps after PAUSE . . . . . . . . 220 22.13. Transport Header Registries . . . . . . . . . . . . . . 207
C.2.5. RTSP / RTP Integration . . . . . . . . . . . . . . . 223 22.13.1. Transport Protocol Specification . . . . . . . . . . 208
C.2.6. Scaling with RTP . . . . . . . . . . . . . . . . . . 223 22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 209
C.2.7. Maintaining NPT synchronization with RTP 22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 209
timestamps . . . . . . . . . . . . . . . . . . . . . 223 22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 210
C.2.8. Continuous Audio . . . . . . . . . . . . . . . . . . 223 22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 210
C.2.9. Multiple Sources in an RTP Session . . . . . . . . . 223 22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 211
C.2.10. Usage of SSRCs and the RTCP BYE Message During an 22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 212
RTSP Session . . . . . . . . . . . . . . . . . . . . 223 22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 212
C.3. Future Additions . . . . . . . . . . . . . . . . . . . . 224 22.16. Media Type Registration for text/parameters . . . . . . 213
Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 225 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 215
D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 225 23.1. Normative References . . . . . . . . . . . . . . . . . . 215
D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 225 23.2. Informative References . . . . . . . . . . . . . . . . . 217
D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 226 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 219
D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 227 A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 219
D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 227 A.2. Media on Demand using Pipelining . . . . . . . . . . . . 222
D.1.5. Directionality of media stream . . . . . . . . . . . 227 A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 225
D.1.6. Range of Presentation . . . . . . . . . . . . . . . 228 A.4. Single Stream Container Files . . . . . . . . . . . . . 229
D.1.7. Time of Availability . . . . . . . . . . . . . . . . 229 A.5. Live Media Presentation Using Multicast . . . . . . . . 231
D.1.8. Connection Information . . . . . . . . . . . . . . . 229 A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 232
D.1.9. Entity Tag . . . . . . . . . . . . . . . . . . . . . 229 Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 234
D.2. Aggregate Control Not Available . . . . . . . . . . . . 230 B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 234
D.3. Aggregate Control Available . . . . . . . . . . . . . . 230 B.2. State variables . . . . . . . . . . . . . . . . . . . . 234
D.4. RTSP external SDP delivery . . . . . . . . . . . . . . . 231 B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 234
Appendix E. Text format for Parameters . . . . . . . . . . . . . 233 B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 235
Appendix F. Requirements for Unreliable Transport of RTSP . . . 234 Appendix C. Media Transport Alternatives . . . . . . . . . . . . 240
Appendix G. Backwards Compatibility Considerations . . . . . . . 236 C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 240
G.1. Play Request in Play mode . . . . . . . . . . . . . . . 236 C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 240
G.2. Using Persistent Connections . . . . . . . . . . . . . . 236 C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 240
Appendix H. Open Issues . . . . . . . . . . . . . . . . . . . . 237 C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 241
Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 238 C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 242
Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 245 C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 242
J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 245 C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 242
Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 247 C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 243
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 248 C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 244
Intellectual Property and Copyright Statements . . . . . . . . . 249 C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 244
C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 248
C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 251
C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 253
C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 253
C.7. Maintaining NPT synchronization with RTP timestamps . . 254
C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 254
C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 254
C.10. Usage of SSRCs and the RTCP BYE Message During an
RTSP Session . . . . . . . . . . . . . . . . . . . . . . 254
C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 255
Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 256
D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 256
D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 256
D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 257
D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 258
D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 258
D.1.5. Directionality of media stream . . . . . . . . . . . 258
D.1.6. Range of Presentation . . . . . . . . . . . . . . . 259
D.1.7. Time of Availability . . . . . . . . . . . . . . . . 260
D.1.8. Connection Information . . . . . . . . . . . . . . . 260
D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 260
D.2. Aggregate Control Not Available . . . . . . . . . . . . 261
D.3. Aggregate Control Available . . . . . . . . . . . . . . 261
D.4. RTSP external SDP delivery . . . . . . . . . . . . . . . 262
Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 264
E.1. On-demand Playback of Stored Content . . . . . . . . . . 264
E.2. Unicast Distribution of Live Content . . . . . . . . . . 265
E.3. On-demand Playback using Multicast . . . . . . . . . . . 266
E.4. Inviting an RTSP server into a conference . . . . . . . 266
E.5. Live Content using Multicast . . . . . . . . . . . . . . 267
Appendix F. Text format for Parameters . . . . . . . . . . . . . 269
Appendix G. Requirements for Unreliable Transport of RTSP . . . 270
Appendix H. Backwards Compatibility Considerations . . . . . . . 272
H.1. Play Request in Play mode . . . . . . . . . . . . . . . 272
H.2. Using Persistent Connections . . . . . . . . . . . . . . 272
Appendix I. Open Issues . . . . . . . . . . . . . . . . . . . . 273
Appendix J. Changes . . . . . . . . . . . . . . . . . . . . . . 274
Appendix K. Acknowledgements . . . . . . . . . . . . . . . . . . 281
K.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 281
Appendix L. RFC Editor Consideration . . . . . . . . . . . . . . 283
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 284
1. Introduction 1. Introduction
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). RTSP 2.0 is an application-level protocol for setup and
the delivery of data with real-time properties, typically streaming control over the delivery of data with real-time properties,
media. Streaming media is, for instance, video on demand or audio typically streaming media. Streaming media is, for instance, video
live streaming. Put simply, RTSP acts as a "network remote control" on demand or audio live streaming. Put simply, RTSP acts as a
for multimedia servers, as you know it from your TV set. "network remote control" 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 proxies placed between clients and servers.
Basically, clients can request information about streaming media from Clients can request information about streaming media from servers,
setranrvers, by asking for a description of the media or use media by asking for a description of the media or use media description
description provided externally. Based on the media description provided externally. Then establish the media delivery protocol to
clients can request to play out the media, pause it, or stop it be used for the media streams described by the media description.
Clients can then 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 streams 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 RTSP 2.0 is an replacement of RTSP 1.0 [RFC2326] that obsoletes that
based transport level protocol, such as TCP. For security, TLS over specification. This protocol is based on RTSP 1.0 but not backwards
a connection oriented transport is supported. compatible other than in the basic version negotiation mechanism.
The changes are documented in Appendix J. There are many reasons why
RTSP 2.0 can't be backwards compatible with RTSP 1.0 but some of the
main ones are; that most header that needed to be extensible didn't
define the allowed syntax preventing safe deployment of extensions;
the changed behavior of the PLAY method when received in playing
state; changed behavior of the extensibility model and its mechanism;
the change of syntax for some headers. The summary is that there is
so many small details that changing version become necessary to
enable clarification and consistent behavior.
There is no dependency on an special RTSP connection in the protocol. This document is structured in the way that it begins with an
Instead, an RTSP server maintains a session labeled by an identifier overview of the protocol operations and its functions in an informal
to associate groups of media streams and their states. An RTSP way. Then a set of definitions of used terms and document
session is not tied to a transport-level connection such as a TCP conventions is introduced. Then comes the actual protocol
connection. During a session, a client may open and close multiple specification. In the appendix some functionality that isn't core
reliable transport connections to the server to issue RTSP requests RTSP defined, but still important to enable some usage, like RTP and
for that session. SDP usage with RTSP. This is followed by a number of informational
parts discussing the changes, use cases, different considerations or
motivations.
The set of streams to be controlled in an RTSP session is defined by 1.1. Notes on Copyright
a presentation description. This memorandum does not define a format
for the presentation description. However Appendix D describes how
SDP [RFC4566] is used for this purpose. The streams controlled by
RTSP may use RTP [RFC3550] for their data transport, but the
operation of RTSP does not depend on the transport mechanism used to
carry continuous media. RTSP is intentionally similar in syntax and
operation to HTTP/1.1 [RFC2616] so that extension mechanisms to HTTP
may also be applied to RTSP.
The RTSP 2.0 protocol supports the following operations: The IETF has adopted new IPR contributor rules in [RFC5378], which
results in a changed model of copyright. The baseline is that "The
IETF Trust and the IETF must obtain the right to publish an IETF
Contribution as an RFC or an Internet-Draft from the Contributors."
(taken from Section 3.1 of [RFC5378]).
Retrieval of media from media server: The client can either request This memo has plenty of text taken from [RFC2326] and thus the
a presentation description via RTSP DESCRIBE, HTTP or some associated copyright. Magnus Westerlund has solicited the authors of
other method. If the presentation is being multicast, the [RFC2326] and this memo to transfer the copyright to the new model,
presentation description contains the multicast addresses and i.e., to the IETF trust and the IETF. Most of the authors have
ports to be used for the continuous media. If the presentation responded and transferred their copyright. However, not all of them
is to be sent only to the client via unicast, the client have. This is the first reason for the currently used boiler plate
provides the destination. (and thus the current status), i.e., with pre5378Trust200902. See
also this document [IETF-Trust-License-Policy] for more information.
Invitation of a media server to a conference: A media server can be Furthermore, this memo does contain text that has been copied and
"invited" to join an existing conference to play back media modified from [RFC2616]. Older versions of this memo solely linked
into the presentation. This mode is useful, for example, in to the particular places. Linking to the HTTP/1.1 specification was
distributed teaching applications. Several parties in the not appropriate anymore, as the text was not fitting to RTSP 2.0
conference may take turns "pushing the remote control buttons". needs and had to be adapted. Thus text copied from HTTP/1.1 is still
Note: This functionality will require RTSP external application under copyright prior to [RFC5378].
level functionality.
RTSP requests may be handled by proxies, tunnels and caches as in 2. Protocol Overview
HTTP/1.1 [RFC2616].
1.2. RTSP Specificication Update This section provides a informative overview of the different
mechanisms in the RTSP 2.0 protocol. This to enable a high level
understanding before getting into all the different details. In case
of conflict with this description and the later sections, the later
sections take precedence. For more information about considered use
cases for RTSP see Appendix E.
This memorandum specifies RTSP 2.0 which is an update of RTSP 1.0, a RTSP 2.0 is a bi-directional request and response protocol that first
proposed standard defined in [RFC2326]. The goal of this version is establish a context including content resources (the media) and then
to correct the many flaws that have been identified in RTSP 1.0 since controls the delivery of these content resources from the server to
its publication. The corrections are such that backwards the client. RTSP has 3 fundamental parts of interest, Session
compatibility was impossible. Thus a new version was deemed the most Establishment, Playback Control and its extensibility model, that is
appropriate solution to get a more functional protocol. There are no described below. It is also is based on some assumptions on existing
plans to revise RTSP 1.0. Appendix I catalogs the changes of this functionality that also will be touched upon to provide a complete
version in relation to RTSP 1.0. solution for client controlled real-time media delivery.
RTSP 2.0 as specified in this memo has reduced functionality compared RTSP uses text based messages that may contain a binary message body.
to RTSP 1.0 and aims at specifying the RTSP core, functionality and The RTSP messages starts with a method line that identify the method,
rules for extensions, and basic interaction with the media delivery the protocol and version and the resource to act on. Following the
protocol RTP [RFC3550]. method line follows a number of RTSP headers. This part is ended by
two consecutive control line feed (CRLF) character pairs. The
message body if present follows the two CRLF and the bodies length
are described by a message header. RTSP messages are sent over a
reliable transport protocol between client and server. RTSP 2.0
requires clients and servers to implement TCP and TLS over TCP as
mandatory transport for RTSP messages.
Any other functionality would need to be published as extension 2.1. Content Description
documents. This specification provides rules for such extensions and
defines registries to avoid naming collisions.
1.3. Notational Conventions RTSP exist to provide access to multi-media content, however it tries
to be agnostic to the media type or the actual media delivery
protocol that is used. To enable a client to implement a complete
system, an RTSP external mechanism for describing the content and the
delivery protocol(s) is used. RTSP assumes that this either
delivered completely out of bands or can be delivered as single data
object upon the clients request using the DESCRIBE method
(Section 13.2).
Since some of the definitions and syntax are identical to HTTP/1.1, Parameters that commonly have to be included in the Content
this specification only points to the section where they are defined Description are the following:
o Number of media streams
o The resource identifier for each media stream/resource that is to
be controlled by RTSP
o The protocol that each media stream is to be delivered over
o Transport protocol parameters that are not negotiated or varies
with each client
o Media encoding information enabling client to correctly decode it
upon reception
o An aggregate control resource identifier
RTSP uses its own URI schemes ("rtsp" and "rtsps") to reference media
resources and aggregates under common control.
This specification describes in Appendix D how one uses SDP [RFC4566]
for Content Description
2.2. Session Establishment
The RTSP client can request the establishment of an RTSP session
after having used the content description to determine which media
streams are available, and also which media delivery protocol is used
and their particular resource identifiers. The RTSP session is a
common context between the client and the server that consist of one
or more media resource that is to be under common playback control.
The client creates an RTSP session by sending an request using the
SETUP method (Section 13.3) to the server. In the SETUP request the
client also includes all the transport parameter necessary to enable
the media delivery protocol to function in the "Transport" header
(Section 16.52). This includes parameters are pre-established by the
content description but necessary for any middlebox to correctly
handle the media delivery protocol. The Transport header in a
request may contain multiple alternatives for media delivery to
enable the server to select what is preferred some an prioritized
list. However, RTSP builds on that the client can select a small
number of alternatives based on the content description.
The server will determine if the media resource is available upon
receiving a SETUP request and if any of the transport parameter
specifications are acceptable. If that is successful, an RTSP
session context is created and the relevant parameters and state is
stored. An identifier is created for the RTSP session and included
in the response in the Session header (Section 16.48). The SETUP
response message includes a Transport header that specifies which of
the alternatives that are selected and any parameters which the
server is required to fill in.
A SETUP request that references an existing RTSP session but
identifies a new media resource is a request to add that media
resource under common control with the already present media
resources in an aggregated session. A client can expect this to work
for all media resources under RTSP control within a multi-media
content. However, aggregating resources from different content are
likely to be refused by the server. The RTSP session as aggregate is
referenced by the aggregate control URI, even if the RTSP session
only contains a single media.
To avoid an extra round trip in the session establishment of
aggregated RTSP sessions, RTSP 2.0 supports pipelined requests. The
client uses client selected identifier in the Pipelined-Requests
header to instruct the server to bind multiple requests together as
if they included the session identifier.
The SETUP response also provides additional information about the
established sessions in couple of different headers. The Media-
Properties header include a number of properties that apply for the
aggregate that is valuable when doing playback control and
configuring user interface. The Accept-Ranges header inform the
client about which range formats that the server supports with these
media resources. The Media-Range header inform the client about the
time range of the media currently available.
2.3. Playback Control
Having established an RTSP session one can start controlling the
media playback. The basic operations are very simple starting media
delivery using the PLAY method (Section 13.4) or halt it by the PAUSE
method (Section 13.6). PLAY also allows for positioning where in the
media the server should deliver from if the media support such
operation. The positioning is done using the Range header
(Section 16.38) that support several different time formats, Normal
Play Time (Section 4.5), SMPTE Timestamps (Section 4.4) or absolute
time (Section 4.6). The Range header does also allow the client to
specify a position where playback should end, thus allowing a
specific interval to be played back.
The support for positioning/searching within a content depends on the
contents media properties. Content exist in a number of different
types, like on-demand, live, and live content being recorded. Even
within these categories there are differences in how the content is
generated and distributed that affects how it can be accessed for
playback. The properties applicable for the RTSP session are
provided by the server in the SETUP response using the Media-
Properties header (Section 16.28). These are expressed using one or
several attributes that are independent such as, Random Access that
express if positioning can happen at all or if only limited to
rewinding from start, and if possible what granularity that can be
expected. Another aspect possible to express if the content will
change during the lifetime of the session. While on-demand content
will provided in its completeness from the beginning, a live stream
being recorded while one watches it results in the content growing in
duration as the session goes on. There also exist content that is
dynamically built by another protocol than RTSP and thus also changes
in steps during the session but not continuously. When content is
recorded there are cases where not the complete content is maintained
only the last hour for example. All of these properties results in
the need for mechanisms that will be discussed below.
When the client access on-demand content that is possible to perform
random access in the client can issue the PLAY request for any point
in the content between the start and the end. The server will
deliver media from the closest random access point prior to the
requested point and indicate that in its PLAY response. If the
client issues a pause the delivery will be halted and the point at
which the server stopped will be reported back in the response. The
client can later resume by a PLAY request without a range header.
When the server is about to completed the PLAY request by delivering
the end of the content or the requested range the server will send a
PLAY_NOTIFY request indicating this.
When playing live content with no extra functions, such as recording,
the client will receive the media from the server after having sent a
PLAY request that is what happens now. Seeking in such content is
not working as the server does not store it, but only forwards it
from the source of the session. Thus delivery continues until the
client sends a PAUSE request, tears down the session or the content
ends.
For live sessions that are being recorded the client will need to
keep track of how the recording progress. Upon session establishment
the client will learn the current duration of the recording from the
Media-Range header. As the recording is ongoing the content grows in
direct relation to the passed time. Therefore, each server's
response to a PLAY request will contain the current Media-Range
header. The server should also send regularly every 5 minutes the
current media range in a PLAY_NOTIFY request. If the live
transmission ends the Server must send a PLAY_NOTIFY request with the
updated Media-Properties indicating that the content stopped being a
recorded live session and instead become a on-demand content. The
request also contains the final media range. While the live delivery
continues the client can request to play what is delivered just now
by using the NPT timescale symbol "now", or it can request a specific
point in the available content by an explicit range request for that
point. If the requested point is outside of the available interval
the server will adjust the position to the closest available point,
i.e., either at the beginning or the end.
A special case of recording is where the recording is not retained
longer than a specific time period, thus as the live delivery
continues the client can access any media within a moving window that
covers for example "now" to "now" minus 1 hour. A client that pause
on a specific point within the content may not retrieve the content
anymore, if the client waits long enough before resuming the pause
point, as the content may no longer be available. In this case the
pause point will adjusted to the end of the available media.
2.4. Session Parameter Manipulations
A session may have additional state or functionality that effects how
the server or client treats the session, content, how it functions,
or feedback on how well the session works. Such extensions are not
defined in this specification, but may be done in various extensions.
RTSP has two methods used to retrieve parameter values or to set them
on either the client or the server: GET_PARAMETER (Section 13.8) or
SET_PARAMETER (Section 13.9). These methods are carrying the
parameters in a message body of the appropriate format. One can also
use certain type of headers to query state with the GET_PARAMETER
method. As an example clients needing to know the current Media-
Range for a time-progressing session can use the GET_PARAMETER method
and include the media-range. Also synchronization information using
the combination of RTP-Info and Range can be requested.
RTSP 2.0 does not have a strong mechanism for providing negotiation
of which headers or parameters and their formats that can be used.
The protocol will indicate headers or parameters that it doesn't
support if tried. But determination a priori of what is available
needs to be done through out-of-band mechanism, like in the session
description, or through the usage of feature tags (Section 4.7).
2.5. Media Delivery
The delivery of media to the RTSP client is done with a protocol
outside of RTSP and this protocol is determined during the session
establishment. This document specifies how media is delivered with
RTP over UDP, TCP or the RTSP control connection. Additional
protocols may be specified in the future based on demand.
The usage of RTP as media delivery protocol does requires some
additional information to function well. The PLAY responses contains
synchronization information to enable reliable and timely deliver of
how a client should synchronize different sources in the different
RTP sessions. It also provides a mapping between RTP timestamps and
the content time scale. When the server is notifying the client
about the end of the PLAY request using the PLAY_NOTIFY, the request
include information about which the last RTP packets are for each
stream. Thus enabling correct handling of the buffer drainage at the
end.
2.5.1. Media Delivery Manipulations
The basic playback functionality of RTSP is to request content for a
particular range to be delivered to the client in a pace that enables
playback as intended by the creator. However, RTSP can also
manipulate how this delivery is done to the client in two ways.
Scale: The ratio of media content time delivered per unit playback
time.
Speed: The ratio of playback time delivered per unit of wallclock
time.
So both affects the media delivery per time unit. However, they are
manipulating two independent time scales and the effects are possible
to combine.
Scale is used for fast forward or slow motion control as it changes
the amount of content timescale that should be played back per time
unit. Scale > 1.0, means fast forward, e.g. Scale=2.0 results in
that 2 seconds of content is played back every second of playback.
Scale = 1.0 is the default value that is used if no Scale is
specified, i.e. playback at the contents original rate. Scale values
between 0 and 1.0 is providing for slow motion. Scale can be
negative to allow for reverse playback in either regular pace (Scale
= -1.0) or fast backwards (Scale < -1.0) or slow motion backwards
(-1.0 < Scale < 0). Scale = 0 is equal to pause and is not allowed.
In most cases the realization of scale means server side manipulation
of the media to ensure that the client can actually play it back.
These media manipulation and when they are needed are highly media
type dependent. Lets exemplify with two common media types audio and
video.
It is very difficult to modify the playback rate of audio. A maximum
of 10-30% is possible by changing the pitch-rate of speech. Music
goes out of tune if one tries to manipulate the playback rate by
resampling it. This is a well known problem and audio is commonly
muted or played back in short segments with skips to keep up with the
current playback point.
For video is possible to manipulate the number of frames that is
displayed per second. But the rendering capabilities are often
limited to certain frame rates. The decoding, handling capabilities
and bitrate of received encoded content also limits the number of
frames that can be delivered. Therefore when providing fast forward
one generally picks a subset of the frames from the original content
to be displayed. However, the video encoding methods use will
commonly limit the possibilities on which frames that can be chosen
and still be decoded by the receiver.
Due to the media restrictions a particular content will commonly be
restricted to a limited set of possible scale ratios. To handle this
correctly, RTSP has mechanism to indicate the supported Scale ratios
for the content. To support aggregated or dynamic content where this
may change during the ongoing session and dependent on the location
within the content a mechanism for updating the media properties and
the current used scale factor exist.
Speed affects how much of the playback timeline that is delivered in
a given wallclock period. The default is Speed = 1 which is to
deliver at the same rate the media is consumed. Speed > 1 means that
the receiver will get content faster than it regularly would consume
it. Speed < 1 means that delivery is slower than the regular media
rate. Speed values of 0 or lower has no meaning and are not allowed.
This mechanism enables two general functionalities. Client side
scale operations, i.e. the client receives all the frames and makes
the adjustment to the playback locally. The second usage is to
control delivery for buffering of media. By specifying a speed over
1.0 the client can build up the amount of playback time it has
present in its buffers to a level that is sufficient for its needs.
A naive implementation of Speed would only affect the transmission
schedule of the media and has a clear impact on the needed bandwidth.
This would result in the data rate being proportional to the speed
factor. Speed = 1.5, i.e. 50% faster than normal delivery, will then
result in a 50% increase in the data transport rate. If that can be
supported or not depends solely on the underlaying network path.
Scale may also have some impact on the required bandwidth due to the
manipulation of the content in the new playback schedule. An example
is fast forward where only the independently decodable intra frames
are included in the media stream. This usage of only intra frames
increase the data rate significantly compared to a normal sequence
with the same number of frames where most frames will be encoded
using prediction.
This potential increase of the data rate needs to be handled by the
media sender. The client has requested that the media is delivered
in a specific way, which should be honored. However, the media
sender can not ignore if the network path between the sender and the
receiver can't handle the resulting media stream. In that case the
media stream needs to be adapted to fit the available resources of
the path. This can result in that media quality has be reduced due
to the delivery modifications that the client has requested.
The need for bitrate adaptation becomes especially problematic in
regards to Speed. If the is target is to fill up the buffer then the
client may not want to do that at the cost of reduced quality. If
you like to do local playout changes then you may actually require
that the requested speed is honored. To resolve this issue the usage
of speed specifies a range so that both usages can be supported. The
server is request to use as high as possible speed value within the
range if the bandwidth is insufficient for the upper bound. As long
as the server can maintain a speed value within the range it shall
not change the media quality, instead modify the speed value in
response to available bandwidth. Only if the server becomes unable
to maintain the lower bound speed value does it need to modify the
media quality to maintain the lower bound speed value.
This functionality enables the local scaling implementation to use a
tight or even a range where lower bound equals upper bound to
identify that it requires the server to deliver the requested amount
of media time per delivery time independent of how much it needs to
adapt the media quality to fit within the available path bandwidth.
For buffer refilling it is suitable to use a range with a reasonable
span and with a lower bound at the nominal media rate like 1.0 - 2.5.
If one likes to reduce the buffer one specifies an upper bound that
is below 1.0 to force the server to deliver slower than nominal media
rate.
2.6. Session Maintenance and Termination
The session context that has been established is kept alive by having
the client show liveness. This is done in two main ways:
o Media transport protocol keep-alive. RTCP is possible to use when
using RTP.
o Any RTSP request referencing the session context.
Section 10.5 discusses the methods for showing liveness in more
depth. If the client fails to show liveness for more than the
established session timeout value (normally 60 seconds) the server
may terminate the context. Other values may be selected by the
server through the inclusion of the timeout parameter in the session
header.
The session context is normally terminated by the client by sending a
TEARDOWN request to the server referencing the aggregated control
URI. An individual media resource can be removed from a session
context by a TEARDOWN request referencing that particular media
resource. And if all media resources are removed from a session
context the session context is also terminated.
A client may keep the session alive indefinitely if allowed by the
server, however it is recommend to release the session context when
extended periods of time without media delivery activity has passed.
It can re-establish the session context if required later. One issue
is that what is extended periods of time is dependent on the server
and its usage. Because of that it is recommended that the client
terminate the session before 10*times the session timeout value has
passed. A server may terminate the session after one session timeout
period without any client activity beyond keep-alive. When a server
terminates the session context it does that by sending a TEARDOWN
request indicating the reason why.
A server can also request that the client tear down the session and
re-establish it at an alternative server when needed for maintenance
by using the REDIRECT method. The Terminate-Reason header is used to
indicate when and why. The Location header indicates where it should
connect if there are an alternative server available. When the
deadline expires the server simply stop providing service. So to
achieve a clean closure the client will need to initiate session
termination prior to the deadline. In case the server has no other
server to redirect and likes to close the session for maintenance it
shall use the TEARDOWN method with a Terminate-Reason header.
2.7. Extending RTSP
RTSP is quite a versatile protocol which supports extensions in many
different directions. Even this core specification contains several
blocks of functionality that are optional to implement. The use case
and need for the protocol deployment is what should determine what
gets implemented. Allowing for extension makes it possible for RTSP
to reach out to additional usages. However, extensions will affect
the interoperability of the protocol and therefore it is important
that it can be done in a structured way.
The client can learn the servers capability through the usage of the
OPTIONS method (Section 13.1) and the Supported header
(Section 16.49). It can also try and possibly fail by using new
methods or require that particular features are supported using the
Require or Proxy-Require header.
The RTSP protocol in itself can be extended in three ways, listed
here in order of the magnitude of changes supported:
o Existing methods can be extended with new parameters, for example,
headers, as long as these parameters can be safely ignored by the
recipient. If the client needs negative acknowledgement when a
method extension is not supported, a tag corresponding to the
extension may be added in the field of the Require or Proxy-
Require headers (see Section 16.35).
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 Implemented) so that the sender can avoid using this method
again. A client may also use the OPTIONS method to inquire about
methods supported by the server. The server must list the methods
it supports using the Public response header.
o A new version of the protocol can be defined, allowing almost all
aspects (except the position of the protocol version number) to
change. A new version of the protocol must be registered through
an IETF standard track document.
The basic capability discovery mechanism can be used to both discover
support for a certain feature and to ensure that a feature is
available when performing a request. For detailed explanation of
this see Section 11.
New media delivery protocols may be added and negotiated at session
establishment, in addition to extension to the core protocol.
Certain type of protocol manipulations can be done through parameter
formats using SET_PARAMETER and GET_PARAMETER.
3. Document Conventions
3.1. Notational Conventions
Since a few of the definitions are identical to HTTP/1.1, 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 [RFC5234]. 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
skipping to change at page 11, line 20 skipping to change at page 23, line 32
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The word, "unspecified" is used to indicate functionality or features The word, "unspecified" is used to indicate functionality or features
that are not defined in this specification. Such functionality that are not defined in this specification. Such functionality
cannot be used in a standardized manner without further definition in cannot be used in a standardized manner without further definition in
an extension specification to RTSP. an extension specification to RTSP.
1.4. Terminology 3.2. Terminology
Some of the terminology has been adopted from HTTP/1.1 [RFC2616].
Terms not listed here are defined as in HTTP/1.1.
Aggregate control: The concept of controlling multiple streams using Aggregate control: The concept of controlling multiple streams using
a single timeline, generally maintained by the server. A client, a single timeline, generally maintained by the server. A client,
for example, uses aggregate control when it issues a single play for example, uses aggregate control when it issues a single play
or pause message to simultaneously control both the audio and or pause message to simultaneously control both the audio and
video in a movie. A session which is under aggregate control is video in a movie. A session which is under aggregate control is
referred to as an aggregated session. referred to as an aggregated session.
Aggregate control URI: The URI used in an RTSP request to refer to Aggregate control URI: The URI used in an RTSP request to refer to
and control an aggregated session. It normally, but not always, and control an aggregated session. It normally, but not always,
corresponds to the presentation URI specified in the session corresponds to the presentation URI specified in the session
description. See Section 13.3 for more information. description. See Section 13.3 for more information.
Conference: A multiparty, multimedia presentation, where "multi"
implies greater than or equal to one.
Client: The client requests media service from the media server. Client: The client requests media service from the media server.
Connection: A transport layer virtual circuit established between Connection: A transport layer virtual circuit established between
two programs for the purpose of communication. two programs for the purpose of communication.
Container file: A file which may contain multiple media streams Container file: A file which may contain multiple media streams
which often constitutes a presentation when played together. The which often constitutes a presentation when played together. The
concept of a container file is not embedded in the protocol. concept of a container file is not embedded in the protocol.
However, RTSP servers may offer aggregate control on the media However, RTSP servers may offer aggregate control on the media
streams within these files. streams within these files.
Continuous media: Data where there is a timing relationship between Continuous media: Data where there is a timing relationship between
source and sink; that is, the sink needs to reproduce the timing source and sink; that is, the sink needs to reproduce the timing
relationship that existed at the source. The most common examples relationship that existed at the source. The most common examples
of continuous media are audio and motion video. Continuous media of continuous media are audio and motion video. Continuous media
can be real-time (interactive or conversational), where there is a can be real-time (interactive or conversational), where there is a
"tight" timing relationship between source and sink, or streaming "tight" timing relationship between source and sink, or streaming
(playback), where the relationship is less strict. (playback), where the relationship is less strict.
Entity: The information transferred as the payload of a request or
response. An entity consists of meta-information in the form of
entity-header fields and content in the form of an entity-body, as
described in Section 9.
Feature-tag: A tag representing a certain set of functionality, i.e. Feature-tag: A tag representing a certain set of functionality, i.e.
a feature. a feature.
IRI: Internationalized Resource Identifier, is the same as an URI, IRI: Internationalized Resource Identifier, is the same as an URI,
with the exception that it allows characters from the whole with the exception that it allows characters from the whole
Universal Character Set (Unicode/ISO 10646), rather than the US- Universal Character Set (Unicode/ISO 10646), rather than the US-
ASCII only. See [RFC3987] for more information. ASCII only. See [RFC3987] for more information.
Live: Normally used to describe a presentation or session with media Live: Normally used to describe a presentation or session with media
coming from an ongoing event. This generally results in the coming from an ongoing event. This generally results in the
skipping to change at page 12, line 46 skipping to change at page 24, line 47
Media parameter: Parameter specific to a media type that may be Media parameter: Parameter specific to a media type that may be
changed before or during stream playback. changed before or during stream playback.
Media server: The server providing playback services for one or more Media server: The server providing playback services for one or more
media streams. Different media streams within a presentation may media streams. Different media streams within a presentation may
originate from different media servers. A media server may reside originate from different media servers. A media server may reside
on the same host or on a different host from which the on the same host or on a different host from which the
presentation is invoked. presentation is invoked.
Media server indirection: Redirection of a media client to a
different media server.
(Media) stream: A single media instance, e.g., an audio stream or a (Media) stream: A single media instance, e.g., an audio stream or a
video stream as well as a single whiteboard or shared application video stream as well as a single whiteboard or shared application
group. When using RTP, a stream consists of all RTP and RTCP group. When using RTP, a stream consists of all RTP and RTCP
packets created by a source within an RTP session. packets created by a source within an RTP session.
Message: The basic unit of RTSP communication, consisting of a Message: The basic unit of RTSP communication, consisting of a
structured sequence of octets matching the syntax defined in structured sequence of octets matching the syntax defined in
Section 20 and transmitted over a connection or a connectionless Section 20 and transmitted over a connection or a connectionless
transport. transport.
Non-Aggregated Control: Control of a single media stream. This is Message Body: The information transferred as the payload of a
only possible in RTSP sessions with a single media. request or response. An message body consists of meta-information
in the form of message-header and content in the form of an
message-body, as described in Section 9.
Participant: Member of a conference. A participant may be a Non-Aggregated Control: Control of a single media stream.
machine, e.g., a playback server.
Presentation: A set of one or more streams presented to the client Presentation: A set of one or more streams presented to the client
as a complete media feed and described by a presentation as a complete media feed and described by a presentation
description as defined below. Presentations with more than one description as defined below. Presentations with more than one
media stream are often handled in RTSP under aggregate control. media stream are often handled in RTSP under aggregate control.
Presentation description: A presentation description contains Presentation description: A presentation description contains
information about one or more media streams within a presentation, information about one or more media streams within a presentation,
such as the set of encodings, network addresses and information such as the set of encodings, network addresses and information
about the content. Other IETF protocols such as SDP ([RFC4566]) about the content. Other IETF protocols such as SDP ([RFC4566])
skipping to change at page 13, line 39 skipping to change at page 25, line 40
Response: An RTSP response. If an HTTP response is meant, that is Response: An RTSP response. If an HTTP response is meant, that is
indicated explicitly. indicated explicitly.
Request: An RTSP request. If an HTTP request is meant, that is Request: An RTSP request. If an HTTP request is meant, that is
indicated explicitly. indicated explicitly.
Request-URI: The URI used in a request to indicate the resource on Request-URI: The URI used in a request to indicate the resource on
which the request is to be performed. which the request is to be performed.
RTSP agent: Refers to either an RTSP client, an RTSP server, or an RTSP agent: Refers to either an RTSP client, an RTSP server, or an
RTSP Proxy. In this specification, there are many capabilities RTSP proxy. In this specification, there are many capabilities
that are common to these three entities such as the capability to that are common to these three entities such as the capability to
send requests or receive responses. This term will be used when send requests or receive responses. This term will be used when
describing functionality that is applicable to all three of these describing functionality that is applicable to all three of these
entities. entities.
RTSP session: A stateful abstraction upon which the main control RTSP session: A stateful abstraction upon which the main control
methods of RTSP operate. An RTSP session is a server entity; it methods of RTSP operate. An RTSP session is a server entity; it
is created, maintained and destroyed by the server. It is is created, maintained and destroyed by the server. It is
established by an RTSP server upon the completion of a successful established by an RTSP server upon the completion of a successful
SETUP request (when a 200 OK response is sent) and is labelled SETUP request (when a 200 OK response is sent) and is labelled
skipping to change at page 14, line 26 skipping to change at page 27, line 5
URI: Universal Resource Identifier, see [RFC3986]. The URIs used in URI: Universal Resource Identifier, see [RFC3986]. The URIs used in
RTSP are generally URLs as they give a location for the resource. RTSP are generally URLs as they give a location for the resource.
As URLs are a subset of URIs, they will be referred to as URIs to As URLs are a subset of URIs, they will be referred to as URIs to
cover also the cases when an RTSP URI would not be an URL. cover also the cases when an RTSP URI would not be an URL.
URL: Universal Resource Locator, is an URI which identifies the URL: Universal Resource Locator, is an URI which identifies the
resource through its primary access mechanism, rather than resource through its primary access mechanism, rather than
identifying the resource by name or by some other attribute(s) of identifying the resource by name or by some other attribute(s) of
that resource. that resource.
1.5. 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.1. Protocol Properties
RTSP has the following properties:
Extendable: New methods and parameters can be easily added to RTSP.
Secure: RTSP re-uses web security mechanisms, either at the
transport level (TLS, [RFC5246]) or within the protocol itself.
All HTTP authentication mechanisms such as basic ([RFC2616]) and
digest authentication ([RFC2617]) are directly applicable.
Transport-independent: RTSP does not preclude the use of unreliable
datagram protocol (UDP) ([RFC0768]) as it would be possible to
implement application-level reliability. The use of a
connectionless datagram protocol such as UDP requires additional
definition that may be provided as extensions to the core RTSP
specification. The reliable stream protocol TCP ([RFC0793]) and
the secured reliable stream protocol TLS over TCP [RFC5246] are
the currently defined transport protocols for RTSP messages.
Media-delivery protocol independent: The operation of RTSP does not
depend on the transport mechanism used to carry continuous media.
While most real-time media will use RTP as a transport protocol,
RTSP does not preclude the use of other protocols such as MPEG-2
[ISO.13818-1.2000]. The use of other protocols requires
additional definition that may be provided as extensions to the
core RTSP specification.
Multi-server capable: Each media stream within a presentation can
reside on a different server. The client automatically
establishes several concurrent control sessions with the different
media servers. Media synchronization in those cases is performed
at the transport level.
Separation of stream control and conference initiation: Stream
control is divorced from inviting a media server to a conference.
In particular, SIP [RFC3261] or H.323 [ITU.H323.1996] may be used
to invite a server to a conference; however, the exact procedures
are unspecified.
Suitable for professional applications: RTSP supports frame- level
accuracy through SMPTE time stamps to allow remote digital
editing.
Presentation description neutral: The protocol does not impose a
particular presentation description or metafile format and can
convey the type of format to be used. However, the presentation
description is required to contain at least one RTSP URI.
Proxy and firewall friendly: The protocol should be readily handled
by both application and transport-layer (SOCKS [RFC1961])
firewalls. A firewall may need to understand the SETUP method to
open a "hole" for the media stream.
HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so that
the existing infrastructure can be reused. This infrastructure
includes PICS (Platform for Internet Content Selection
[W3C.REC-PICS-services] [W3C.REC-PICS-labels]) for associating
labels with content. However, RTSP does not just add methods to
HTTP since controlling continuous media requires server state in
most cases.
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 clients in such a way that clients cannot stop the stream.
Transport negotiation: The client can negotiate the transport method
prior to actually needing to process a continuous media stream.
2.2. RTSP's Relationship to HTTP
RTSP is intentionally similar in syntax and operation to HTTP/1.1
[RFC2616] so that extension mechanisms to HTTP can in some cases also
be applied to RTSP. However, RTSP differs in a number of important
aspects from HTTP:
* RTSP introduces a number of new methods and has a different
protocol identifier.
* RTSP has the notion of a session built into the protocol.
* An RTSP server needs to maintain state in almost all cases, as
opposed to the stateless nature of HTTP.
* Both an RTSP server and client can issue requests.
* Data is usually carried out-of-band by a different protocol.
Session descriptions returned in a DESCRIBE response (see
Section 13.2) and interleaving of RTP with RTSP over TCP are
exceptions to this rule (see Section 14).
* RTSP is defined to use ISO 10646 (UTF-8) rather than ISO
8859-1, consistent with HTML internationalization efforts
[RFC2070].
* The Request-URI always contains the absolute URI. Because of
backward compatibility with a historical blunder, HTTP/1.1
[RFC2616] carries only the absolute path in the request and
puts the host name in a separate header field.
This makes "virtual hosting" easier, where a single host with
one IP address hosts several document trees.
2.3. Extending RTSP
Since not all media servers have the same functionality, media
servers by necessity will support different sets of requests. For
example:
o A server may not be capable of seeking (absolute positioning) if
it is to support live events only.
o Some servers may not support setting stream parameters and thus
not support GET_PARAMETER and SET_PARAMETER.
o Some server may support an RTSP extension.
It is up to the creators of presentation descriptions not to ask the
impossible of a server. This situation is similar in HTTP/1.1
[RFC2616], where the methods described in [H19.5] are not likely to
be supported across all servers.
RTSP can be extended in three ways, listed here in order of the
magnitude of changes supported:
o Existing methods can be extended with new parameters, e.g.
headers, as long as these parameters can be safely ignored by the
recipient. If the client needs negative acknowledgement when a
method extension is not supported, a tag corresponding to the
extension may be added in the field of the Require or Proxy-
Require headers (see Section 16.35).
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 Implemented) so that the sender can avoid using this method
again. A client may also use the OPTIONS method to inquire about
methods supported by the server. The server MUST list the methods
it supports using the Public response header.
o A new version of the protocol can be defined, allowing almost all
aspects (except the position of the protocol version number) to
change. A new version of the protocol MUST be registered through
an IETF standard track document.
The basic capability discovery mechanism can be used to both discover
support for a certain feature and to ensure that a feature is
available when performing a request. For detailed explanation of
this see Section 11.
2.4. Overall Operation
Each presentation and media stream is identified by an RTSP URI. The
overall presentation and the properties of the media the presentation
is composed of are defined by a presentation description file, the
format of which is outside the scope of this specification. The
presentation description file may be obtained by the client using
HTTP or other means such as email and may not necessarily be stored
on the media server.
For the purposes of this specification, a presentation description is
assumed to describe one or more presentations, each of which
maintains a common time axis. For simplicity of exposition and
without loss of generality, it is assumed that the presentation
description contains exactly one such presentation. A presentation
may contain several media streams.
The presentation description file contains a description of the media
streams making up the presentation, including their encodings,
language, and other parameters that enable the client to choose the
most appropriate combination of media. In this presentation
description, each media stream that is individually controllable by
RTSP is identified by an RTSP URI, which points to the media server
handling that particular media stream and names the stream stored on
that server. Several media streams can be located on different
servers; for example, audio and video streams can be split across
servers for load sharing. The description also enumerates which
transport methods the server is capable of.
Besides the media parameters, the network destination address and
port need to be determined. Several modes of operation can be
distinguished:
Unicast: The media is transmitted to the source of the RTSP request
or the requested destination, with the port number chosen by the
client. Alternatively, the media is transmitted on the same
reliable stream as RTSP.
Multicast, server chooses address: The media server picks the
multicast address and port. This is the typical case for a live
or near-media-on-demand transmission. The address is provided by
the session description.
Multicast, client chooses address: If the server is to participate
in an existing multicast conference, the multicast address, port
and encryption key are given by the conference description,
established by means outside the scope of this specification, for
example by a SIP created conference.
2.5. RTSP States
RTSP controls a stream which may be sent via a separate protocol,
independent of the control channel. For example, RTSP control may be
transported on a TCP connection while the media data is conveyed via
UDP. Thus, data delivery continues even if no RTSP requests are
received by the media server. Also, during its lifetime a single
media stream may be controlled by RTSP requests issued sequentially
on different TCP connections. Therefore, the server needs to
maintain "session state" to be able to correlate RTSP requests with a
stream. The state transitions are described in Appendix A.
Many methods in RTSP do not contribute to state. However, the
following play a central role in defining the allocation and usage of
stream resources on the server: SETUP, PLAY, PAUSE, REDIRECT, and
TEARDOWN.
SETUP: Causes the server to allocate resources for a stream and
create an RTSP session.
PLAY: Starts data transmission on a stream allocated via SETUP.
PAUSE: Temporarily halts a stream without freeing server resources.
REDIRECT: Indicates that the session should be moved to a new server
or location
TEARDOWN: Frees resources associated with the stream. The RTSP
session ceases to exist on the server.
RTSP methods that contribute to state use the Session header field
(Section 16.49) to identify the RTSP session whose state is being
manipulated. The server generates session identifiers in response to
SETUP requests (Section 13.3).
2.6. Relationship with Other Protocols
RTSP has some overlap in functionality with HTTP. It also may
interact with HTTP in that the initial contact with streaming content
will often be made through a web page. The current protocol
specification aims to allow different hand-off points between a web
server and the media server implementing RTSP. For example, the
presentation description can be retrieved using HTTP or RTSP, which
reduces round trips in web-browser-based scenarios, yet also allows
for stand alone RTSP servers and clients which do not rely on HTTP at
all. However, RTSP differs fundamentally from HTTP in that most data
delivery takes place out-of-band in a different protocol. HTTP is an
asymmetric protocol where the client issues requests and the server
responds. In RTSP, both the media client and media server can issue
requests. RTSP requests are also stateful; they may set parameters
and continue to control a media stream long after the request has
been acknowledged.
Re-using HTTP functionality has advantages in at least two areas,
namely security and proxies. The requirements are very similar, so
having the ability to adopt HTTP work on caches, proxies and
authentication is valuable.
RTSP assumes the existence of a presentation description format that
can express both static and temporal properties of a presentation
containing several media streams. Session Description Protocol (SDP)
[RFC4566] is generally the format of choice; however, RTSP is not
bound to it. For data delivery, most real-time media will use RTP as
a transport protocol. While RTSP works well with RTP, it is not tied
to RTP.
3. RTSP Use Cases
This section describes the most important and considered use cases
for RTSP. They are listed in descending order of importance in
regards to ensuring that all necessary functionality is present.
This specification only fully supports usage of the two first. Also
in these first two cases, there are special cases or exceptions that
are not supported without extensions, e.g. the redirection of media
to another address than the controlling entity.
3.1. On-demand Playback of Stored Content
An RTSP capable server stores content suitable for being streamed to
a client. A client desiring playback of any of the stored content
uses RTSP to set up the media transport required to deliver the
desired content. RTSP is then used to initiate, halt and manipulate
the actual transmission (playout) of the content. RTSP is also
required to provide necessary description and synchronization
information for the content.
The above high level description can be broken down into a number of
functions that RTSP needs to be capable of.
Presentation Description: Provide initialization information about
the presentation (content); for example, which media codecs are
needed for the content. Other information that is important
includes the number of media stream the presentation contains,
the transport protocols used for the media streams, and
identifiers for these media streams. This information is
required before setup of the content is possible and to
determine if the client is even capable of using the content.
This information need not be sent using RTSP; other external
protocols can be used to transmit the transport presentation
descriptions. Two good examples are the use of HTTP [RFC2616]
or email to fetch or receive presentation descriptions like SDP
[RFC4566]
Setup: Set up some or all of the media streams in a presentation.
The setup itself consist of selecting the protocol for media
transport and the necessary parameters for the protocol, like
addresses and ports.
Control of Transmission: After the necessary media streams have been
established the client can request the server to start
transmitting the content. The client must be allowed to start
or stop the transmission of the content at arbitrary times.
The client must also be able to start the transmission at any
point in the timeline of the presentation.
Synchronization: For media transport protocols like RTP [RFC3550] it
might be beneficial to carry synchronization information within
RTSP. This may be due to either the lack of inter-media
synchronization within the protocol itself, or the potential
delay before the synchronization is established (which is the
case for RTP when using RTCP).
Termination: Terminate the established contexts.
For this use case there are a number of assumptions about how it
works. These are:
On-Demand content: The content is stored at the server and can be
accessed at any time during a time period when it is intended
to be available.
Independent sessions: A server is capable of serving a number of
clients simultaneously, including from the same piece of
content at different points in that presentations time-line.
Unicast Transport: Content for each individual client is transmitted
to them using unicast traffic.
It is also possible to redirect the media traffic to a different
destination than that of the entity controlling the traffic.
However, allowing this without appropriate mechanisms for checking
that the destination approves of this allows for distributed denial
of service attacks (DDoS).
3.2. Unicast distribution of Live Content
This use cases is similar to the above on-demand content case (see
Section 3.1) the difference is the nature of the content itself.
Live content is continuously distributed as it becomes available from
a source; i.e., the main difference from on-demand is that one starts
distributing content before the end of it has become available to the
server.
In many cases the consumer of live content is only interested in
consuming what is actually happens "now"; i.e., very similar to
broadcast TV. However in this case it is assumed that there exist no
broadcast or multicast channel to the users, and instead the server
functions as a distribution node, sending the same content to
multiple receivers, using unicast traffic between server and client.
This unicast traffic and the transport parameters are individually
negotiated for each receiving client.
Another aspect of live content is that it often has a very limited
time of availability, as it is only is available for the duration of
the event the content covers. An example of such a live content
could be a music concert which lasts 2 hour and starts at a
predetermined time. Thus there is need to announce when and for how
long the live content is available.
In some cases, the server providing live content may be saving some
or all of the content to allow clients to pause the stream and resume
it from the paused point, or to "rewind" and play continuously from a
point earlier than the live point. Hence, this use case does not
necessarily exclude playing from other than the live point of the
stream, playing with scales other than 1.0, etc.
3.3. On-demand Playback using Multicast
It is possible to use RTSP to request that media be delivered to a
multicast group. The entity setting up the session (the controller)
will then control when and what media is delivered to the group.
This use case has some potential for denial of service attacks by
flooding a multicast group. Therefore, a mechanism is needed to
indicate that the group actually accepts the traffic from the RTSP
server.
An open issue in this use case is how one ensures that all receivers
listening to the multicast or broadcast receives the session
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
If one has an established conference or group session, it is possible
to have an RTSP server distribute media to the whole group.
Transmission to the group is simplest when controlled by a single
participant or leader of the conference. Shared control might be
possible, but would require further investigation and possibly
extensions.
This use case assumes that there exists either multicast or a
conference focus that redistribute media to all participants.
This use case is intended to be able to handle the following
scenario: A conference leader or participant (hereafter called the
controller) has some pre-stored content on an RTSP server that he
wants to share with the group. The controller sets up an RTSP
session at the streaming server for this content and retrieves the
session description for the content. The destination for the media
content is set to the shared multicast group or conference focus.
When desired by the controller, he/she can start and stop the
transmission of the media to the conference group.
There are several issues with this use case that are not solved by
this core specification for RTSP:
Denial of service: To avoid an RTSP server from being an unknowing
participant in a denial of service attack the server needs to
be able to verify the destination's acceptance of the media.
Such a mechanism to verify the approval of received media does
not yet exist; instead, only policies can be used, which can be
made to work in controlled environments.
Distributing the presentation description to all participants in the
group: To enable a media receiver to correctly decode the content
the media configuration information needs to be distributed
reliably to all participants. This will most likely require
support from an external protocol.
Passing control of the session: If it is desired to pass control of
the RTSP session between the participants, some support will be
required by an external protocol to exchange state information
and possibly floor control of who is controlling the RTSP
session.
If there interest in this use case, further work is required on the
necessary extensions.
3.5. Live Content using Multicast
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
[RFC2974] and SDP are intended to handle. However in use cases where
more advanced features like access control to the multicast session
are desired, RTSP could be used for session establishment.
A client desiring to join a live multicasted media session with
cryptographic (encryption) access control could use RTSP in the
following way. The source of the session announces the session and
gives all interested an RTSP URI. The client connects to the server
and requests the presentation description, allowing configuration for
reception of the media. In this step it is possible for the client
to use secured transport and any desired level of authentication; for
example, for billing or access control. An RTSP link also allows for
load balancing between multiple servers.
If these were the only goals, they could be achieved by simply using
HTTP. However, for cases where the sender likes to keep track of
each individual receiver of a session, and possibly use the session
as a side channel for distributing key-updates or other information
on a per-receiver basis, and the full set of receivers is not know
prior to the session start, the state establishment that RTSP
provides can be beneficial. In this case a client would establish an
RTSP session for this multicast group with the RTSP server. The RTSP
server will not transmit any media, but instead will point to 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
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
some extensions to the server-to-client push mechanism. Here the
PLAY_NOTIFY method (see Section 13.5) with a suitable extension could
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 This specification defines version 2.0 of RTSP.
"RTSP". This specification defines version 2.0 of RTSP.
RTSP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. The protocol versioning policy is intended to allow
the sender to indicate the format of a message and its capacity for
understanding further RTSP communication, rather than the features
obtained via that communication. No change is made to the version
number for the addition of message components which do not affect
communication behavior or which only add to extensible field values.
The <minor> number is incremented when the changes made to the
protocol add features which do not change the general message parsing
algorithm, but which may add to the message semantics and imply
additional capabilities of the sender. The <major> number is
incremented when the format of a message within the protocol is
changed. The version of an RTSP message is indicated by an RTSP-
Version field in the first line of the message. Note that the major
and minor numbers MUST be treated as separate integers and that each
MAY be incremented higher than a single digit. Thus, RTSP/2.4 is a
lower version than RTSP/2.13, which in turn is lower than RTSP/12.3.
Leading zeros MUST be ignored by recipients and MUST NOT be sent.
4.2. RTSP IRI and URI 4.2. RTSP IRI and URI
RTSP 2.0 defines and registers three URI schemas "rtsp", "rtsps" and RTSP 2.0 defines and registers three URI schemes "rtsp", "rtsps" and
"rtspu". The usage of the last, "rtspu", is unspecified in RTSP 2.0, "rtspu". The usage of the last, "rtspu", is unspecified in RTSP 2.0,
and is defined here to register and reserve the URI scheme that is and is defined here to register and reserve the URI scheme that is
defined in RTSP 1.0. The "rtspu" scheme indicates undefined defined in RTSP 1.0. The "rtspu" scheme indicates undefined
transport of the RTSP messages over unreliable transport (UDP). The transport of the RTSP messages over unreliable transport (UDP). The
syntax of "rtsp" and "rtsps" URIs has been changed from RTSP 1.0. syntax of "rtsp" and "rtsps" URIs has been changed from RTSP 1.0.
This specification also defines the format of the RTSP IRI [RFC3987] This specification also defines the format of the RTSP IRI [RFC3987]
that can be used as RTSP resource identifiers and locators, in web that can be used as RTSP resource identifiers and locators, in web
pages, user interfaces, on paper, etc. However, the RTSP request pages, user interfaces, on paper, etc. However, the RTSP request
message format only allows usage of the absolute URI format. The message format only allows usage of the absolute URI format. The
RTSP IRI format SHALL use the rules and transformation for IRIs RTSP IRI format MUST use the rules and transformation for IRIs
defined in [RFC3987]. This way RTSP 2.0 URIs for request can be defined in [RFC3987]. This way RTSP 2.0 URIs for request can be
produced from an RTSP IRI. produced from an RTSP IRI.
The RTSP IRI and URI are both syntax restricted compared to the The RTSP IRI and URI are both syntax restricted compared to the
generic syntax defined in [RFC3986] and RFC [RFC3987]: generic syntax defined in [RFC3986] and RFC [RFC3987]:
o An absolute URI requires the authority part; i.e., a host identity o An absolute URI requires the authority part; i.e., a host identity
must be provided. must be provided.
o Parameters in the path element are prefixed with the reserved o Parameters in the path element are prefixed with the reserved
separator ";". separator ";".
The RTSP URI and IRI is case sensitive, with the exception of those The RTSP URI and IRI is case sensitive, with the exception of those
parts that [RFC3986] and [RFC3987] defines as case-insensitive; for parts that [RFC3986] and [RFC3987] defines as case-insensitive; for
example, the scheme and host part. example, the scheme and host part.
The fragment identifier is used as defined in sections 3.5 and 4.3 of The fragment identifier is used as defined in sections 3.5 and 4.3 of
[RFC3986], i.e. the fragment is to be stripped from the URI by the [RFC3986], i.e. the fragment is to be stripped from the IRI by the
requestor and not included in the request. The user agent also needs requester and not included in the request URI. The user agent needs
to interpret the value of the fragment based on the media type the to interpret the value of the fragment based on the media type the
request relates to; i.e., the media type indicated in Content-Type request relates to; i.e., the media type indicated in Content-Type
header in the response to DESCRIBE. header in the response to DESCRIBE.
The syntax of any URI query string is unspecified and responder The syntax of any URI query string is unspecified and responder
(usually the server) specific. The query is, from the requestor's (usually the server) specific. The query is, from the requester's
perspective, an opaque string and needs to be handled as such. perspective, an opaque string and needs to be handled as such.
Please note that relative URI with queries are difficult to handle
due to the RFC 3986 relative URI handling rules. Any change of the
path element using a relative URI results in the stripping of the
query. Which means the relative part needs to contain the query.
The URI scheme "rtsp" requires that commands are issued via a The URI scheme "rtsp" requires that commands are issued via a
reliable protocol (within the Internet, TCP), while the scheme reliable protocol (within the Internet, TCP), while the scheme
"rtsps" identifies a reliable transport using secure transport (TLS "rtsps" identifies a reliable transport using secure transport (TLS
[RFC5246], see (Section 19). [RFC5246], see (Section 19).
For the scheme "rtsp", if no port number is provided in the authority For the scheme "rtsp", if no port number is provided in the authority
part of the URI port number 554 SHALL be used. For the scheme part of the URI port number 554 MUST be used. For the scheme
"rtsps", the TCP port 322 is registered and SHALL be assumed. "rtsps", the TCP port 322 is registered and MUST be assumed.
A presentation or a stream is identified by a textual media A presentation or a stream is identified by a textual media
identifier, using the character set and escape conventions of URIs identifier, using the character set and escape conventions of URIs
[RFC3986]. URIs may refer to a stream or an aggregate of streams; [RFC3986]. URIs may refer to a stream or an aggregate of streams;
i.e., a presentation. Accordingly, requests described in i.e., a presentation. Accordingly, requests described in
(Section 13) can apply to either the whole presentation or an (Section 13) can apply to either the whole presentation or an
individual stream within the presentation. Note that some request individual stream within the presentation. Note that some request
methods can only be applied to streams, not presentations, and vice methods can only be applied to streams, not presentations, and vice
versa. versa.
skipping to change at page 30, line 12 skipping to change at page 29, line 33
with non-RTSP media control protocols simply by replacing the with non-RTSP media control protocols simply by replacing the
scheme in the URI. scheme in the URI.
4.3. Session Identifiers 4.3. Session Identifiers
Session identifiers are strings of any arbitrary length but with a Session identifiers are strings of any arbitrary length but with a
minimum length of 8 characters. A session identifier MUST be chosen minimum length of 8 characters. A session identifier MUST be chosen
cryptographically random (see [RFC4086]) and MUST be at least 8 cryptographically random (see [RFC4086]) and MUST be at least 8
characters long (can contain a maximum of 48 bits of entropy) to make characters long (can contain a maximum of 48 bits of entropy) to make
guessing it more difficult. It is RECOMMENDED that it contains 128 guessing it more difficult. It is RECOMMENDED that it contains 128
bits of entropy, i.e. approxamitely 22 characters from a high quality bits of entropy, i.e. approximately 22 characters from a high quality
generator. (see Section 21.) However, it needs to be noted that the generator. (see Section 21.) However, it needs to be noted that the
session identifier does not provide any security against session session identifier does not provide any security against session
hijacking unless it is kept confidential between client, server and hijacking unless it is kept confidential between client, server and
trusted proxies. trusted proxies.
4.4. SMPTE Relative Timestamps 4.4. SMPTE Relative Timestamps
A SMPTE relative timestamp expresses time relative to the start of A SMPTE relative timestamp expresses time relative to the start of
the clip. Relative timestamps are expressed as SMPTE time codes for the clip. Relative timestamps are expressed as SMPTE time codes for
frame-level access accuracy. The time code has the format frame-level access accuracy. The time code has the format
hours:minutes:seconds:frames.subframes, hours:minutes:seconds:frames.subframes,
with the origin at the start of the clip. The default smpte format with the origin at the start of the clip. The default SMPTE format
is "SMPTE 30 drop" format, with frame rate is 29.97 frames per is "SMPTE 30 drop" format, with frame rate is 29.97 frames per
second. Other SMPTE codes MAY be supported (such as "SMPTE 25") second. Other SMPTE codes MAY be supported (such as "SMPTE 25")
through the use of alternative use of "smpte-type". For SMPTE 30, through the use of alternative use of "smpte-type". For SMPTE 30,
the "frames" field in the time value can assume the values 0 through the "frames" field in the time value can assume the values 0 through
29. The difference between 30 and 29.97 frames per second is handled 29. The difference between 30 and 29.97 frames per second is handled
by dropping the first two frame indices (values 00 and 01) of every by dropping the first two frame indices (values 00 and 01) of every
minute, except every tenth minute. If the frame and the subframe minute, except every tenth minute. If the frame and the subframe
values are zero, they may be omitted. Subframes are measured in one- values are zero, they may be omitted. Subframes are measured in one-
hundredth of a frame. hundredth of a frame.
skipping to change at page 31, line 6 skipping to change at page 30, line 26
4.5. Normal Play Time 4.5. Normal Play Time
Normal play time (NPT) indicates the stream absolute position Normal play time (NPT) indicates the stream absolute position
relative to the beginning of the presentation, not to be confused relative to the beginning of the presentation, not to be confused
with the Network Time Protocol (NTP) [RFC1305]. The timestamp with the Network Time Protocol (NTP) [RFC1305]. The timestamp
consists of a decimal fraction. The part left of the decimal may be consists of a decimal fraction. The part left of the decimal may be
expressed in either seconds or hours, minutes, and seconds. The part expressed in either seconds or hours, minutes, and seconds. The part
right of the decimal point measures fractions of a second. right of the decimal point measures fractions of a second.
The beginning of a presentation corresponds to 0.0 seconds. Negative The beginning of a presentation corresponds to 0.0 seconds. Negative
values are not defined. The special constant "now" is defined as the values are not defined.
current instant of a live event. It MAY only be used for live
events, and SHALL NOT be used for on-demand (i.e., non-live) content. The special constant "now" is defined as the current instant of a
live event. It MAY only be used for live events, and MUST NOT be
used for on-demand (i.e., non-live) content.
NPT is defined as in DSM-CC [ISO.13818-6.1995]: "Intuitively, NPT is NPT is defined as in DSM-CC [ISO.13818-6.1995]: "Intuitively, NPT is
the clock the viewer associates with a program. It is often the clock the viewer associates with a program. It is often
digitally displayed on a VCR. NPT advances normally when in normal digitally displayed on a VCR. NPT advances normally when in normal
play mode (scale = 1), advances at a faster rate when in fast scan play mode (scale = 1), advances at a faster rate when in fast scan
forward (high positive scale ratio), decrements when in scan reverse forward (high positive scale ratio), decrements when in scan reverse
(high negative scale ratio) and is fixed in pause mode. NPT is (high negative scale ratio) and is fixed in pause mode. NPT is
(logically) equivalent to SMPTE time codes." (logically) equivalent to SMPTE time codes."
Examples: Examples:
skipping to change at page 31, line 46 skipping to change at page 31, line 20
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.42), Proxy-Require RTSP. These tags are used in Require (Section 16.42), Proxy-Require
(Section 16.35), Proxy-Supported (Section 16.36), and Unsupported (Section 16.35), Proxy-Supported (Section 16.36), and Unsupported
(Section 16.52) header fields. (Section 16.53) header fields.
A feature-tag definition MUST indicate which combination of clients, A feature-tag definition MUST indicate which combination of clients,
servers or proxies they applies to. servers or proxies 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).
The usage of feature-tags is further described in Section 11 that The usage of feature-tags is further described in Section 11 that
deals with capability handling. deals with capability handling.
4.8. Entity Tags 4.8. Message Body Tags
Entity tags are opaque strings that are used to compare two entities Message body tags are opaque strings that are used to compare two
from the same resource, for example in caches or to optimize setup message bodies from the same resource, for example in caches or to
after a redirect. Further explanation is present in [H3.11]. For an optimize setup after a redirect. Message body tags can be carried in
explanation of how to compare entity tags see [H13.3]. Entity tags the MTag header (see Section 16.30) or in SDP (see Appendix D.1.9).
can be carried in the ETag header (see Section 16.21) or in SDP (see
Appendix D.1.9).
Entity tags are used in RTSP to make some methods conditional. The A message body tag MUST be unique across all versions of all message
methods are made conditional through the inclusion of headers, see bodies associated with a particular resource. A given message body
Section 16.24 and Section 16.26. Note that RTSP entity tags apply to tag value MAY be used for message body obtained by requests on
the complete presentation; i.e., both the session description and the different URIs. The use of the same message body tag value in
individual media streams. Thus entity tags can be used to verify at conjunction with message bodies obtained by requests on different
setup time after a redirect that the same session description applies URIs does not imply the equivalence of those message bodies
to the media at the new location using the If-Match header.
Message body tags are used in RTSP to make some methods conditional.
The methods are made conditional through the inclusion of headers,
see Section 16.23 and Section 16.25. Note that RTSP message body
tags apply to the complete presentation; i.e., both the session
description and the individual media streams. Thus message body tags
can be used to verify at setup time after a redirect that the same
session description applies to the media at the new location using
the If-Match header.
4.9. 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 differences 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 seekable, 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.
4.9.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 provided to express the worst case distance between
random access points.
Return To Start: Seeking is only possible to beginning of the
content.
No seeking: Seeking is not possible at all.
4.9.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
is in existence.
Time Limited: The media will at least not be removed before given
wallclock time. After that time it may or may not be available
any more.
Duration limited: Each individual unit of the media will be retained
for the specified duration.
4.9.3. Content Modifications
There is also the question of how the content may change during time
for a give media resource:
Immutable: 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.
4.9.4. Supported Scale Factors
The content is often limiting the possible rates of scale that can be
supported when delivering the media. To enable the client to know
what values or ranges of scale operations that the whole content or
the current position supports a media properties attribute for this
is defined. It contains a list with the values and/or ranges that
are supported. The attribute is named "Scales". It may be updated
at any point in the content due to content consisting of spliced
pieces or content being dynamically updated by out of bands
mechanisms.
4.9.5. 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:
Immutable, Retention: unlimited or time limited.
Dynamic On-demand: Random Access: Random Access=3s, Content
Modifications: Dynamic, Retention: unlimited 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
5. RTSP Message 5. RTSP Message
RTSP is a text-based protocol and uses the ISO 10646 character set in RTSP is a text-based protocol and uses the ISO 10646 character set in
UTF-8 encoding (RFC 3629 [RFC3629]). Lines SHALL be terminated by UTF-8 encoding (RFC 3629 [RFC3629]). Lines MUST be terminated by
CRLF. CRLF.
Text-based protocols make it easier to add optional parameters in Text-based protocols make it easier to add optional parameters in
a self-describing manner. Since the number of parameters and the a self-describing manner. Since the number of parameters and the
frequency of commands is low, processing efficiency is not a frequency of commands is low, processing efficiency is not a
concern. Text-based protocols, if done carefully, also allow easy concern. Text-based protocols, if done carefully, also allow easy
implementation of research prototypes in scripting languages such implementation of research prototypes in scripting languages such
as Tcl, Visual Basic and Perl. as TCL, Visual Basic and Perl.
The ISO 10646 character set avoids tricky character set switching, The ISO 10646 character set avoids tricky character set switching,
but is invisible to the application as long as US-ASCII is being but is invisible to the application as long as US-ASCII is being
used. This is also the encoding used for RTCP [RFC3550]. ISO 8859-1 used. This is also the encoding used for RTCP [RFC3550]. ISO 8859-1
translates directly into Unicode with a high-order octet of zero. translates directly into Unicode with a high-order octet of zero.
ISO 8859-1 characters with the most-significant bit set are ISO 8859-1 characters with the most-significant bit set are
represented as 1100001x 10xxxxxx. (See RFC 3629 [RFC3629]) represented as 1100001x 10xxxxxx. (See RFC 3629 [RFC3629])
Requests contain methods, the object the method is operating upon and Requests contain methods, the object the method is operating upon and
parameters to further describe the method. Methods are idempotent parameters to further describe the method. Methods are idempotent
skipping to change at page 33, line 38 skipping to change at page 35, line 38
or no state maintenance at the media server. or no state maintenance at the media server.
5.1. Message Types 5.1. Message Types
RTSP messages consist of requests from client to server or server to RTSP messages consist of requests from client to server or server to
client and responses in the reverse direction. Request Section 7 and client and responses in the reverse direction. Request Section 7 and
Response Section 8 messages use the generic message format of RFC 822 Response Section 8 messages use the generic message format of RFC 822
[9] for transferring entities (the payload of the message). Both [9] for transferring entities (the payload of the message). Both
types of message consist of a start-line, zero or more header fields 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 (also known as "headers"), an empty line (i.e., a line with nothing
preceding the CRLF) indicating the end of the header fields, and preceding the CRLF) indicating the end of the header, and possibly a
possibly a message-body. message-body.
generic-message = start-line generic-message = start-line
*(message-header CRLF) *(message-header CRLF)
CRLF CRLF
[ message-body ] [ message-body ]
start-line = Request-Line | Status-Line start-line = Request-Line | Status-Line
In the interest of robustness, servers SHOULD ignore any empty In the interest of robustness, servers SHOULD ignore any empty
line(s) received where a Request-Line is expected. In other words, 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 if the server is reading the protocol stream at the beginning of a
message and receives a CRLF first, it should ignore the CRLF. message and receives a CRLF first, it should ignore the CRLF.
5.2. Message Headers 5.2. Message Headers
See [H4.2]. RTSP header fields (see Section 16) include general-header, request-
header, response-header, and entity-header fields.
Unknown message headers SHALL be ignored by a RTSP server or client. The order in which header fields with differing field names are
An RTSP Proxy SHALL forward unknown message headers. Message headers received is not significant. However, it is "good practice" to send
general-header fields first, followed by request-header or response-
header fields, and ending with the entity-header fields.
Multiple message-header fields with the same field-name MAY be
present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list [i.e., #(values)].
It MUST be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same
field-name are received is therefore significant to the
interpretation of the combined field value, and thus a proxy MUST NOT
change the order of these field values when a message is forwarded.
Unknown message headers MUST be ignored by a RTSP server or client.
An RTSP Proxy MUST forward unknown message headers. Message headers
defined outside of this specification that are required to be defined outside of this specification that are required to be
interpret by the RTSP agent will need to use feature tags interpret by the RTSP agent will need to use feature tags
(Section 4.7) and include it in the appropriate Require (Section 4.7) and include it in the appropriate Require
(Section 16.42) or Proxy-Require (Section 16.35) header. (Section 16.42) or Proxy-Require (Section 16.35) header.
5.3. Message Body 5.3. Message Body
See [H4.3]. The message-body (if any) of an RTSP message is used to carry further
information for a particular resource associated with the request or
response. An example for a message body is the Session Description
Protocol (SDP).
Unlike HTTP, the presence of a message-body in either a request or a The presence of a message-body in either a request or a response MUST
response MUST be signaled by the inclusion of a Content-Length header be signaled by the inclusion of a Content-Length header (see
field (see Section 16.16). Section 16.16).
The presence of a message-body in a request is signaled by the
inclusion of a Content-Length header field in the RTSP message. A
message-body MUST NOT be included in a request or response if the
specification of the particular method (see Method Definitions
(Section 13)) does not allow sending an message body. A server
SHOULD read and forward a message-body on any request; if the request
method does not include defined semantics for a message body, then
the message-body SHOULD be ignored when handling the request..
5.4. Message Length 5.4. Message Length
When a message body is included with a message, the length of that When a message body is included with a message, the length of that
body is determined by one of the following (in order of precedence): body is determined by one of the following (in order of precedence):
1. Any response message which MUST NOT include a message body (such 1. Any response message which MUST NOT include a message body (such
as the 1xx, 204, and 304 responses) is always terminated by the as the 1xx, 204, and 304 responses) is always terminated by the
first empty line after the header fields, regardless of the first empty line after the header fields, regardless of the
entity-header fields present in the message. (Note: An empty message-header fields present in the message. (Note: An empty
line is a line with nothing preceding the CRLF.) line is a line with nothing preceding the CRLF.)
2. If a Content-Length header field (Section 16.16) is present, its 2. If a Content-Length header(Section 16.16) is present, its value
value in bytes represents the length of the message-body. If in bytes represents the length of the message-body. If this
this header field is not present, a value of zero is assumed. header field is not present, a value of zero is assumed.
Unlike an HTTP message, an RTSP message MUST contain a Content-Length Unlike an HTTP message, an RTSP message MUST contain a Content-Length
header field whenever it contains a message body. Note that RTSP header whenever it contains a message body. Note that RTSP does not
does not support the HTTP/1.1 "chunked" transfer coding (see support the HTTP/1.1 "chunked" transfer coding (see [H3.6.1]).
[H3.6.1]).
Given the moderate length of presentation descriptions returned, Given the moderate length of presentation descriptions returned,
the server should always be able to determine its length, even if the server should always be able to determine its length, even if
it is generated dynamically, making the chunked transfer encoding it is generated dynamically, making the chunked transfer encoding
unnecessary. unnecessary.
6. General Header Fields 6. General Header Fields
See [H4.5], except that the Pragma, Trailer, Transfer-Encoding,
Upgrade, and Warning headers are not defined. RTSP further defines
the CSeq, Pipelined-Requests, Proxy-Supported and Timestamp headers.
The general headers are listed in Table 1: The general headers are listed in Table 1:
+--------------------+--------------------+ +--------------------+--------------------+
| Header Name | Defined in Section | | Header Name | Defined in Section |
+--------------------+--------------------+ +--------------------+--------------------+
| Cache-Control | Section 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 |
| | | | | |
| Media-Properties | Section 16.29 | | Media-Properties | Section 16.28 |
| | | | | |
| Media-Range | Section 16.30 | | Media-Range | Section 16.29 |
| | | | | |
| Pipelined-Requests | Section 16.32 | | Pipelined-Requests | Section 16.32 |
| | | | | |
| Proxy-Supported | Section 16.36 | | Proxy-Supported | Section 16.36 |
| | | | | |
| Seek-Style | Section 16.45 | | Seek-Style | Section 16.45 |
| | | | | |
| Supported | Section 16.49 | | Supported | Section 16.49 |
| | | | | |
| Timestamp | Section 16.50 | | Timestamp | Section 16.51 |
| | | | | |
| Via | Section 16.55 | | Via | Section 16.56 |
+--------------------+--------------------+ +--------------------+--------------------+
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,
the identifier of the resource, and the protocol version in use; the identifier of the resource, and the protocol version in use;
o Zero or more Header lines, that can be of the following types: o Zero or more Header lines, that can be of the following types:
general (Section 6), request (Section 7.2), or entity general (Section 6), request (Section 7.2), or message
(Section 9.1); body(Section 9.1);
o One empty line (CRLF) to indicate the end of the header section; o One empty line (CRLF) to indicate the end of the header section;
o Optionally a message body (entity), consisting of one or more o Optionally a message-body, consisting of one or more lines. The
lines. The length of the message body in bytes is indicated by length of the message body in bytes is indicated by the Content-
the Content-Length entity header. Length message header.
7.1. Request Line 7.1. Request Line
The request line provides the key information about the request: what The request line provides the key information about the request: what
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 |
+---------------+--------------------+ +---------------+--------------------+
skipping to change at page 38, line 43 skipping to change at page 41, line 43
| Accept-Encoding | Section 16.3 | | Accept-Encoding | Section 16.3 |
| | | | | |
| Accept-Language | Section 16.4 | | Accept-Language | Section 16.4 |
| | | | | |
| Authorization | Section 16.7 | | Authorization | Section 16.7 |
| | | | | |
| Bandwidth | Section 16.8 | | Bandwidth | Section 16.8 |
| | | | | |
| Blocksize | Section 16.9 | | Blocksize | Section 16.9 |
| | | | | |
| From | Section 16.23 | | From | Section 16.22 |
| | | | | |
| If-Match | Section 16.24 | | If-Match | Section 16.23 |
| | | | | |
| If-Modified-Since | Section 16.25 | | If-Modified-Since | Section 16.24 |
| | | | | |
| If-None-Match | Section 16.26 | | If-None-Match | Section 16.25 |
| | | | | |
| Notify-Reason | Section 16.31 | | Notify-Reason | Section 16.31 |
| | | | | |
| Proxy-Require | Section 16.35 | | Proxy-Require | Section 16.35 |
| | | | | |
| Range | Section 16.38 | | Range | Section 16.38 |
| | | | | |
| Terminate-Reason | Section 16.50 |
| | |
| Referer | Section 16.39 | | Referer | Section 16.39 |
| | | | | |
| Request-Status | Section 16.41 | | Request-Status | Section 16.41 |
| | | | | |
| Require | Section 16.42 | | Require | Section 16.42 |
| | | | | |
| Scale | Section 16.44 | | Scale | Section 16.44 |
| | | | | |
| Session | Section 16.48 | | Session | Section 16.48 |
| | | | | |
| Speed | Section 16.46 | | Speed | Section 16.46 |
| | | | | |
| Supported | Section 16.49 | | Supported | Section 16.49 |
| | | | | |
| Transport | Section 16.51 | | Transport | Section 16.52 |
| | | | | |
| User-Agent | Section 16.53 | | User-Agent | Section 16.54 |
+--------------------+--------------------+ +--------------------+--------------------+
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 processing of the header. actually happens. header to ensure the processing of the header.
8. Response 8. Response
[H6] applies except that HTTP-Version is replaced by RTSP-Version.
Also, RTSP defines additional status codes and does not define some
of the HTTP codes. The valid response codes and the methods they can
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. The final response is
exactly one message, and final responses are any using the response
code classes from the list; 2xx, 3xx, 4xx and 5xx classes. Only for
responses using the response code class 1xx, is it allowed to send
one or more 1xx response messages prior to the final response
message.
The valid response codes and the methods they can be used with are
listed in Table 4.
8.1. Status-Line 8.1. Status-Line
The first line of a Response message is the Status-Line, consisting The first line of a Response message is the Status-Line, consisting
of the protocol version followed by a numeric status code and the of the protocol version followed by a numeric status code and the
textual phrase associated with the status code, with each element textual phrase associated with the status code, with each element
separated by SP characters. No CR or LF is allowed except in the separated by SP characters. No CR or LF is allowed except in the
final CRLF sequence. final CRLF sequence.
<RTSP-Version> SP <Status-Code> SP <Reason-Phrase> CRLF <RTSP-Version> SP <Status-Code> SP <Reason-Phrase> CRLF
skipping to change at page 41, line 25 skipping to change at page 44, line 28
RTSP status codes are extensible. RTSP applications are not required RTSP status codes are extensible. RTSP applications are not required
to understand the meaning of all registered status codes, though such to understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST understanding is obviously desirable. However, applications MUST
understand the class of any status code, as indicated by the first understand the class of any status code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the digit, and treat any unrecognized response as being equivalent to the
x00 status code of that class, with the exception that an x00 status code of that class, with the exception that an
unrecognized response MUST NOT be cached. For example, if an unrecognized response MUST NOT be cached. For example, if an
unrecognized status code of 431 is received by the client, it can unrecognized status code of 431 is received by the client, it can
safely assume that there was something wrong with its request and safely assume that there was something wrong with its request and
treat the response as if it had received a 400 status code. In such treat the response as if it had received a 400 status code. In such
cases, user agents SHOULD present to the user the entity returned cases, user agents SHOULD present to the user the message body
with the response, since that entity is likely to include human- returned with the response, since that message body is likely to
readable information which will explain the unusual status. include human-readable information which will explain the unusual
status.
+------+----------------------------------------+-----------------+ +------+----------------------------------------+-----------------+
| Code | Reason | Method | | Code | Reason | Method |
+------+----------------------------------------+-----------------+ +------+----------------------------------------+-----------------+
| 100 | Continue | all | | 100 | Continue | all |
| | | | | | | |
| | | | | | | |
| 200 | OK | all | | 200 | OK | all |
| | | | | | | |
| | | | | | | |
| 300 | Multiple Choices | all |
| | | |
| 301 | Moved Permanently | all | | 301 | Moved Permanently | all |
| | | | | | | |
| 302 | Found | all | | 302 | Found | all |
| | | | | | | |
| 303 | See Other | all | | 304 | Not Modified | all |
| | | | | | | |
| 305 | Use Proxy | all | | 305 | Use Proxy | all |
| | | | | | | |
| | | | | | | |
| 400 | Bad Request | all | | 400 | Bad Request | all |
| | | |
| 401 | Unauthorized | all | | 401 | Unauthorized | all |
| | | |
| 402 | Payment Required | all | | 402 | Payment Required | all |
| | | | | | | |
| 403 | Forbidden | all | | 403 | Forbidden | all |
| | | | | | | |
| 404 | Not Found | all | | 404 | Not Found | all |
| | | | | | | |
| 405 | Method Not Allowed | all | | 405 | Method Not Allowed | all |
| | | | | | | |
| 406 | Not Acceptable | all | | 406 | Not Acceptable | all |
| | | | | | | |
| 407 | Proxy Authentication Required | all | | 407 | Proxy Authentication Required | all |
| | | | | | | |
| 408 | Request Timeout | all | | 408 | Request Timeout | all |
| | | | | | | |
| 410 | Gone | all | | 410 | Gone | all |
| | | | | | | |
| 411 | Length Required | all | | 411 | Length Required | all |
| | | | | | | |
| 412 | Precondition Failed | DESCRIBE, SETUP | | 412 | Precondition Failed | DESCRIBE, SETUP |
| | | | | | | |
| 413 | Request Entity Too Large | all | | 413 | Request Message Body Too Large | all |
| | | | | | | |
| 414 | Request-URI Too Long | all | | 414 | Request-URI Too Long | all |
| | | | | | | |
| 415 | Unsupported Media Type | all | | 415 | Unsupported Media Type | all |
| | | | | | | |
| 451 | Parameter Not Understood | SET_PARAMETER | | 451 | Parameter Not Understood | SET_PARAMETER |
| | | | | | | |
| 452 | reserved | n/a | | 452 | reserved | n/a |
| | | | | | | |
| 453 | Not Enough Bandwidth | SETUP | | 453 | Not Enough Bandwidth | SETUP |
skipping to change at page 43, line 36 skipping to change at page 46, line 38
| | | | | | | |
| 504 | Gateway Timeout | all | | 504 | Gateway Timeout | all |
| | | | | | | |
| 505 | RTSP Version Not Supported | all | | 505 | RTSP Version Not Supported | all |
| | | | | | | |
| 551 | Option not support | all | | 551 | Option not support | all |
+------+----------------------------------------+-----------------+ +------+----------------------------------------+-----------------+
Table 4: Status codes and their usage with RTSP methods Table 4: Status codes and their usage with RTSP methods
8.2. Response Header Fields 8.2. Response Headers
The response-header fields allow the request recipient to pass The response-header allow the request recipient to pass additional
additional information about the response which cannot be placed in information about the response which cannot be placed in the Status-
the Status-Line. These header fields give information about the Line. This header give information about the server and about
server and about further access to the resource identified by the further access to the resource identified by the Request-URI. All
Request-URI. All headers currently classified as response headers headers currently classified as response headers are listed in
are listed in Table 5. Table 5.
+------------------------+--------------------+ +------------------------+--------------------+
| Header | Defined in Section | | Header | Defined in Section |
+------------------------+--------------------+ +------------------------+--------------------+
| 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 | | MTag | Section 16.30 |
| | | | | |
| Location | Section 16.28 | | Location | Section 16.27 |
| | | | | |
| Proxy-Authenticate | Section 16.33 | | Proxy-Authenticate | Section 16.33 |
| | | | | |
| Public | Section 16.37 | | Public | Section 16.37 |
| | | | | |
| Range | Section 16.38 | | Range | Section 16.38 |
| | | | | |
| Retry-After | Section 16.40 | | Retry-After | Section 16.40 |
| | | | | |
| RTP-Info | Section 16.43 | | RTP-Info | Section 16.43 |
| | | | | |
| Scale | Section 16.44 | | Scale | Section 16.44 |
| | | | | |
| Session | Section 16.48 | | Session | Section 16.48 |
| | | | | |
| Server | Section 16.47 | | Server | Section 16.47 |
| | | | | |
| Speed | Section 16.46 | | Speed | Section 16.46 |
| | | | | |
| Transport | Section 16.51 | | Transport | Section 16.52 |
| | | | | |
| Unsupported | Section 16.52 | | Unsupported | Section 16.53 |
| | | | | |
| Vary | Section 16.54 | | Vary | Section 16.55 |
| | | | | |
| WWW-Authenticate | Section 16.56 | | WWW-Authenticate | Section 16.57 |
+------------------------+--------------------+ +------------------------+--------------------+
Table 5: The RTSP response headers Table 5: The RTSP response headers
Response-header field names can be extended reliably only in Response-headers names can be extended reliably only in combination
combination with a change in the protocol version. However the usage with a change in the protocol version. However the usage of feature-
of feature-tags in the request allows the responding party to learn tags in the request allows the responding party to learn the
the capability of the receiver of the response. New or experimental capability of the receiver of the response. New or experimental
header fields MAY be given the semantics of response-header fields if header MAY be given the semantics of response-header if all parties
all parties in the communication recognize them to be response-header in the communication recognize them to be response-header.
fields. Unrecognized header fields in responses are treated as
entity-header fields.
9. Entity Unrecognized headers in responses are treated as message-headers.
Request and Response messages MAY transfer an entity if not otherwise 9. Message Body
restricted by the request method or response status code. An entity
consists of entity-header fields and an entity-body, although some Request and Response messages MAY transfer a message body if not
responses will only include the entity-headers. otherwise restricted by the request method or response status code.
An message body consists of message-header fields and an message-
body, although some responses will only include the message-headers.
The SET_PARAMETER and GET_PARAMETER request and response, and The SET_PARAMETER and GET_PARAMETER request and response, and
DESCRIBE response MAY have an entity. All 4xx and 5xx responses MAY DESCRIBE response MAY have an message body. All 4xx and 5xx
also have an entity. responses MAY also have an message body.
In this section, both sender and recipient refer to either the client In this section, both sender and recipient refer to either the client
or the server, depending on who sends and who receives the entity. or the server, depending on who sends and who receives the message
body.
9.1. Entity Header Fields 9.1. Message Body Header Fields
Entity-header fields define meta-information about the entity-body message-header fields define meta-information about the message-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 message body header fields are listed in Table 6.
+------------------+--------------------+ +------------------+--------------------+
| Header | Defined in Section | | Header | Defined in Section |
+------------------+--------------------+ +------------------+--------------------+
| Allow | Section 16.6 | | Allow | Section 16.6 |
| | | | | |
| Content-Base | Section 16.13 | | Content-Base | Section 16.13 |
| | | | | |
| Content-Encoding | Section 16.14 | | Content-Encoding | Section 16.14 |
| | | | | |
| Content-Language | Section 16.15 | | Content-Language | Section 16.15 |
| | | | | |
| Content-Length | Section 16.16 | | Content-Length | Section 16.16 |
| | | | | |
| Content-Location | Section 16.17 | | Content-Location | Section 16.17 |
| | | | | |
| Content-Type | Section 16.18 | | Content-Type | Section 16.18 |
| | | | | |
| Expires | Section 16.22 | | Expires | Section 16.21 |
| | | | | |
| Last-Modified | Section 16.27 | | Last-Modified | Section 16.26 |
+------------------+--------------------+ +------------------+--------------------+
Table 6: The RTSP entity headers Table 6: The RTSP message body headers
The extension-header mechanism allows additional entity-header fields The extension-header mechanism allows additional message-header
to be defined without changing the protocol, but these fields cannot fields to be defined without changing the protocol, but these fields
be assumed to be recognizable by the recipient. Unrecognized header cannot be assumed to be recognizable by the recipient. Unrecognized
fields SHOULD be ignored by the recipient and forwarded by proxies. header fields SHOULD be ignored by the recipient and forwarded by
proxies.
9.2. Entity Body 9.2. Message Body
See [H7.2] with the addition that an RTSP message with an entity body RTSP message with an message body MUST include the Content-Type and
MUST include the Content-Type and Content-Length headers. Content-Length headers if a message body is included.
When an message body is included with a message, the data type of
that body is determined via the header fields Content-Type and
Content- Encoding.
Content-Type specifies the media type of the underlying data.
Content-Encoding may be used to indicate any additional content
codings applied to the data, usually for the purpose of data
compression, that are a property of the requested resource. There is
no default encoding.
The Content-Length of a message is the length of the message-body.
10. Connections 10. Connections
RTSP requests can be transmitted using the two different connection RTSP requests can be transmitted using the two different connection
scenarios listed below: scenarios listed below:
o persistent - a transport connection is used for several request/ o persistent - a transport connection is used for several request/
response transactions; response transactions;
o transient - a transport connection is used for a single request/ o transient - a transport connection is used for a single request/
response transaction. response transaction.
RFC 2326 attempted to specify an optional mechanism for transmitting RFC 2326 attempted to specify an optional mechanism for transmitting
RTSP messages in connectionless mode over a transport protocol such RTSP messages in connectionless mode over a transport protocol such
as UDP. However, it was not specified in sufficient detail to allow as UDP. However, it was not specified in sufficient detail to allow
for interoperable implementations. In an attempt to reduce for interoperable implementations. In an attempt to reduce
complexity and scope, and due to lack of interest, RTSP 2.0 does not complexity and scope, and due to lack of interest, RTSP 2.0 does not
attempt to define a mechanism for supporting RTSP over UDP or other attempt to define a mechanism for supporting RTSP over UDP or other
connectionless transport protocols. A side-effect of this is that connectionless transport protocols. A side-effect of this is that
RTSP requests SHALL NOT be sent to multicast groups since no RTSP requests MUST NOT be sent to multicast groups since no
connection can be established with a specific receiver in multicast connection can be established with a specific receiver in multicast
environments. environments.
Certain RTSP headers, such as the CSeq header (Section 16.19), which Certain RTSP headers, such as the CSeq header (Section 16.19), which
may appear to be relevant only to connectionless transport scenarios may appear to be relevant only to connectionless transport scenarios
are still retained and must be implemented according to the are still retained and must be implemented according to the
specification. In the case of CSeq, it is quite useful for matching specification. In the case of CSeq, it is quite useful for matching
responses to requests if the requests are pipelined (see Section 12). responses to requests if the requests are pipelined (see Section 12).
It is also useful in proxies for keeping track of the different It is also useful in proxies for keeping track of the different
requests when aggregating several client requests on a single TCP requests when aggregating several client requests on a single TCP
skipping to change at page 49, line 27 skipping to change at page 52, line 27
A server MUST handle both persistent and transient connections. A server MUST handle both persistent and transient connections.
Transient connections facilitate mechanisms for fault tolerance. Transient connections facilitate mechanisms for fault tolerance.
They also allow for application layer mobility. A server and They also allow for application layer mobility. A server and
client pair that support transient connections can survive the client pair that support transient connections can survive the
loss of a TCP connection; e.g., due to a NAT timeout. When the loss of a TCP connection; e.g., due to a NAT timeout. When the
client has discovered that the TCP connection has been lost, it client has discovered that the TCP connection has been lost, it
can set up a new one when there is need to communicate again. can set up a new one when there is need to communicate again.
A persistent connection MAY be used for all transactions between the A persistent connection is RECOMMENDED be used for all transactions
server and client, including messages for multiple RTSP sessions. between the server and client, including messages for multiple RTSP
However a persistent connection MAY also be closed after a few sessions. However a persistent connection MAY be closed after a few
message exchanges. For example, a client may use a persistent message exchanges. For example, a client may use a persistent
connection for the initial SETUP and PLAY message exchanges in a connection for the initial SETUP and PLAY message exchanges in a
session and then close the connection. Later, when the client wishes session and then close the connection. Later, when the client wishes
to send a new request, such as a PAUSE for the session, a new to send a new request, such as a PAUSE for the session, a new
connection would be opened. This connection may either be transient connection would be opened. This connection may either be transient
or persistent. or persistent.
An RTSP agent SHOULD NOT have more than one connection to the server An RTSP agent SHOULD NOT have more than one connection to the server
at any given point. If a client or proxy handles multiple RTSP at any given point. If a client or proxy handles multiple RTSP
sessions on the same server, it SHOULD use only one connection for sessions on the same server, it SHOULD use only one connection for
managing those sessions. managing those sessions.
This saves connection resources on the server. It also reduces This saves connection resources on the server. It also reduces
complexity by and enabling the server to maintain less state about complexity by and enabling the server to maintain less state about
its sessions and connections. its sessions and connections.
Unlike HTTP, RTSP allows a server to send requests to a client. RTSP allows a server to send requests to a client. However, this can
However, this can be supported only if a client establishes a be supported only if a client establishes a persistent connection
persistent connection with the server. In cases where a persistent with the server. In cases where a persistent connection does not
connection does not exist between a server and its client, due to the exist between a server and its client, due to the lack of a
lack of a signalling channel the server may be forced to drop an RTSP signalling channel the server may be forced to silently discard RTSP
session without notifying the client. An example of such a case is messages, and may even drop an RTSP session without notifying the
when the server desires to send a REDIRECT request for an RTSP client. An example of such a case is when the server desires to send
session to the client but is not able to do so because it cannot a REDIRECT request for an RTSP session to the client but is not able
reach the client. to do so because it cannot reach the client. A server that attempt
to send a request to a client that has no connection currently to the
server SHOULD discard the request directly, it MAY queue it for later
delivery. However, if the server queue the request it should when
adding additional requests to the queue ensure to remove older
requests that are now redundant.
Without a persistent connection between the client and the server, Without a persistent connection between the client and the server,
the media server has no reliable way of reaching the client. the media server has no reliable way of reaching the client.
Also, this is the only way that requests from a server to its Because the likely failure of server to client established
client are likely to traverse firewalls. connections the server will not even attempt establishing any
connection.
The client and server sending requests can be asynchronous events.
To avoid deadlock situations both client and server MUST be able to
send and receive requests simultaneously. As an RTSP response may be
queue up for transmission, reception or processing behind the peer
RTSP agent's own requests, all RTSP agents are required to have a
certain capability of handling outstanding messages. The issue is
that outstanding requests may timeout despite them being processed by
the peer due to the response is caught in the queue behind a number
of request that the RTSP agent is processing but that take some time
to complete. To avoid this problem an RTSP agent is recommended to
buffer incoming messages locally so that any response messages can be
processed immediately upon reception. If responses are separated
from requests and directly forwarded for processing can not only the
result be used immediately, the state associated with that
outstanding request can also be released. However, buffering a
number of requests on the receiving RTSP agent consumes resources and
enables a resource exhaustion attack on the agent. Therefore this
buffer should be limited so that an unreasonable number of requests
or total message size is not allowed to consume the receiving agents
resources. In most APIs having the receiving agent stop reading from
the TCP socket will result in TCP's window being clamped. Thus
forcing the buffering on the sending agent when the load is larger
than expected. However, as both RTSP message sizes and frequency may
be changed in the future by protocol extension an agent should be
careful against taking harsher measurements against a potential
attack. When under attack an RTSP agent can close TCP connections
and release state associated with that TCP connection.
To provide some guidance on what is reasonable the following
guidelines are given. An RTSP agent should not have more than 10
outstanding requests per RTSP session. An RTSP agent should not have
more than 10 outstanding requests that aren't related to an RTSP
session or that are requesting to create an RTSP session.
In light of the above, it is RECOMMENDED that clients use persistent In light of the above, it is RECOMMENDED that clients use persistent
connections whenever possible. A client that supports persistent connections whenever possible. A client that supports persistent
connections MAY "pipeline" its requests (see Section 12). connections MAY "pipeline" its requests (see Section 12).
10.3. Closing Connections 10.3. Closing Connections
The client MAY close a connection at any point when no outstanding The client MAY close a connection at any point when no outstanding
request/response transactions exist for any RTSP session being request/response transactions exist for any RTSP session being
managed through the connection. The server, however, SHOULD NOT managed through the connection. The server, however, SHOULD NOT
skipping to change at page 50, line 41 skipping to change at page 54, line 33
This is to ensure that the client has time to issue a SETUP for a This is to ensure that the client has time to issue a SETUP for a
new session on the existing connection after having torn the last new session on the existing connection after having torn the last
one down. 10 seconds should give the client ample opportunity get one down. 10 seconds should give the client ample opportunity get
its message to the server. its message to the server.
A server SHOULD NOT close the connection directly as a result of A server SHOULD NOT close the connection directly as a result of
responding to a request with an error code. responding to a request with an error code.
Certain error responses such as "460 Only Aggregate Operation Certain error responses such as "460 Only Aggregate Operation
Allowed" (Section 15.4.12) are used for negotiating capabilities Allowed" (Section 15.4.25) are used for negotiating capabilities
of a server with respect to content or other factors. In such of a server with respect to content or other factors. In such
cases, it is inefficient for the server to close a connection on cases, it is inefficient for the server to close a connection on
an error response. Also, such behavior would prevent an error response. Also, such behavior would prevent
implementation of advanced/special types of requests or result in implementation of advanced/special types of requests or result in
extra overhead for the client when testing for new features. On extra overhead for the client when testing for new features. On
the flip side, keeping connections open after sending an error the flip side, keeping connections open after sending an error
response poses a Denial of Service security risk (Section 21). response poses a Denial of Service security risk (Section 21).
If a server closes a connection while the client is attempting to If a server closes a connection while the client is attempting to
send a new request, the client will have to close its current send a new request, the client will have to close its current
skipping to change at page 51, line 16 skipping to change at page 55, line 9
An RTSP message should not be terminated by closing the connection. An RTSP message should not be terminated by closing the connection.
Such a message MAY be considered to be incomplete by the receiver and Such a message MAY be considered to be incomplete by the receiver and
discarded. An RTSP message is properly terminated as defined in discarded. An RTSP message is properly terminated as defined in
Section 5. Section 5.
10.4. Timing Out Connections and RTSP Messages 10.4. Timing Out Connections and RTSP Messages
Receivers of a request (responder) SHOULD respond to requests in a Receivers of a request (responder) SHOULD respond to requests in a
timely manner even when a reliable transport such as TCP is used. timely manner even when a reliable transport such as TCP is used.
Similarly, the sender of a request (requestor) SHOULD wait for a Similarly, the sender of a request (requester) SHOULD wait for a
sufficient time for a response before concluding that the responder sufficient time for a response before concluding that the responder
will not be acting upon its request. will not be acting upon its request.
A responder SHOULD respond to all requests within 5 seconds. If the A responder SHOULD respond to all requests within 5 seconds. If the
responder recognizes that processing of a request will take longer responder recognizes that processing of a request will take longer
than 5 seconds, it SHOULD send a 100 (Continue) response as soon as than 5 seconds, it SHOULD send a 100 (Continue) response as soon as
possible. It SHOULD continue sending a 100 response every 5 seconds possible. It SHOULD continue sending a 100 response every 5 seconds
thereafter until it is ready to send the final response to the thereafter until it is ready to send the final response to the
requestor. After sending a 100 response, the receiver MUST send a requester. After sending a 100 response, the receiver MUST send a
final response indicating the success or failure of the request. final response indicating the success or failure of the request.
A requestor SHOULD wait at least 10 seconds for a response before A requester SHOULD wait at least 10 seconds for a response before
concluding that the responder will not be responding to its request. concluding that the responder will not be responding to its request.
After receiving a 100 response, the requestor SHOULD continue waiting After receiving a 100 response, the requester SHOULD continue waiting
for further responses. If more than 10 seconds elapses without for further responses. If more than 10 seconds elapses without
receiving any response, the requestor MAY assume that the responder receiving any response, the requester 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 requester SHOULD wait longer than 10 seconds for a response if it
is experiencing significant transport delays on its connection to the is experiencing significant transport delays on its connection to the
responder. The requestor is capable of determining the RTT of the responder. The requester is capable of determining the RTT of the
request/response cycle using the Timestamp header (Section 16.50) in request/response cycle using the Timestamp header (Section 16.51) in
any RTSP request. any RTSP request.
10 seconds was chosen for the following reasons. It gives TCP
time to perform a couple of retransmissions, even if operating on
default values. It is short enough that users may not abandon the
process themselves. However, it should be noted that 10 seconds
can be aggressive on certain type of networks. The 5 seconds
value for 1xx messages is half the timeout giving a reasonable
change of successful delivery before timeout happens on the
requestor side.
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
reliable protocols, such as TCP, the message may take some time to reliable protocols, such as TCP, the message may take some time to
arrive safely at the receiver. To show liveness between RTSP request arrive safely at the receiver. To show liveness between RTSP request
issued to accomplish other things, the following mechanisms can be issued to accomplish other things, the following mechanisms can be
used, in descending order of preference: used, in descending order of preference:
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 MUST 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 probability client have for a network with 5 % packet loss, the probability
to fail showing liveness sign in that session within the to fail showing liveness sign in that session within the
timeout interval of 2.4*E-16. In sessions with shorter timeout timeout interval of 2.4*E-16. In sessions with shorter timeout
times, or much higher packet loss, or small RTCP bandwidths times, or much higher packet loss, or small RTCP bandwidths
SHOULD also use any of the mechanisms below. SHOULD also use any of the mechanisms below.
SET_PARAMETER: When using SET_PARAMETER for keep alive, no body SET_PARAMETER: When using SET_PARAMETER for keep alive, no body
SHOULD be included. This method is the RECOMMENDED RTSP method SHOULD be included. This method is the RECOMMENDED RTSP method
to use 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 is also usable, but it causes the server to
to perform more unnecessary processing and result in bigger 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 is that the
that the server needs to determine what capabilities that are server needs to determine the capabilities associated with the
associated with the media resource to correctly populate the media resource to correctly populate the Public and Allow
Public and Allow headers. headers.
The timeout parameter MAY be included in a SETUP response, and SHALL The timeout parameter MAY be included in a SETUP response, and MUST
NOT be included in requests. The server uses it to indicate to the NOT be included in requests. The server uses it to indicate to the
client how long the server is prepared to wait between RTSP commands client how long the server is prepared to wait between RTSP commands
or other signs of life before closing the session due to lack of or other signs of life before closing the session due to lack of
activity (see below and Appendix B). The timeout is measured in activity (see below and Appendix B). The timeout is measured in
seconds, with a default of 60 seconds. The length of the session seconds, with a default of 60 seconds. The length of the session
timeout SHALL NOT be changed in a established session. timeout MUST NOT be changed in a established session.
10.6. Use of IPv6 10.6. Use of IPv6
Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP
2.0 has been updated for explicit IPv6 support. Implementations of 2.0 has been updated for explicit IPv6 support. Implementations of
RTSP 2.0 MUST understand literal IPv6 addresses in URIs and headers. RTSP 2.0 MUST understand literal IPv6 addresses in URIs and headers.
11. Capability Handling 11. Capability Handling
This section describes the available capability handling mechanism This section describes the available capability handling mechanism
which allows RTSP to be extended. Extensions to this version of the which allows RTSP to be extended. Extensions to this version of the
protocol are basically done in two ways. First, new headers can be protocol are basically done in two ways. First, new headers can be
added. Secondly, new methods can be added. The capability handling added. Secondly, new methods can be added. The capability handling
mechanism is designed to handle both cases. mechanism is designed to handle both cases.
When a method is added, the involved parties can use the OPTIONS When a method is added, the involved parties can use the OPTIONS
method to discover wether it is supported. This is done by issuing a method to discover whether it is supported. This is done by issuing
OPTIONS request to the other party. Depending on the URI it will a OPTIONS request to the other party. Depending on the URI it will
either apply in regards to a certain media resource, the whole server either apply in regards to a certain media resource, the whole server
in general, or simply the next hop. The OPTIONS response MUST in general, or simply the next hop. The OPTIONS response MUST
contain a Public header which declares all methods supported for the contain a Public header which declares all methods supported for the
indicated resource. indicated resource.
It is not necessary to use OPTIONS to discover support of a method, It is not necessary to use OPTIONS to discover support of a method,
the client could simply try the method. If the receiver of the the client could simply try the method. If the receiver of the
request does not support the method it will respond with an error request does not support the method it will respond with an error
code indicating the the method is either not implemented (501) or code indicating the method is either not implemented (501) or does
does not apply for the resource (405). The choice between the two not apply for the resource (405). The choice between the two
discovery methods depends on the requirements of the service. discovery methods depends on the requirements of the service.
Feature-Tags are defined to handle functionality additions that are Feature-Tags are defined to handle functionality additions that are
not new methods. Each feature-tag represents a certain block of not new methods. Each feature-tag represents a certain block of
functionality. The amount of functionality that a feature-tag functionality. The amount of functionality that a feature-tag
represents can vary significantly. A feature-tag can for example represents can vary significantly. A feature-tag can for example
represent the functionality a single RTSP header provides. Another represent the functionality a single RTSP header provides. Another
feature-tag can represent much more functionality, such as the feature-tag can represent much more functionality, such as the
"play.basic" feature-tag which represents the minimal playback "play.basic" feature-tag which represents the minimal playback
implementation. implementation.
Feature-tags are used to determine wether the client, server or proxy Feature-tags are used to determine whether the client, server or
supports the functionality that is necessary to achieve the desired proxy supports the functionality that is necessary to achieve the
service. To determine support of a feature-tag, several different desired service. To determine support of a feature-tag, several
headers can be used, each explained below: different headers can be used, each explained below:
Supported: The supported header is used to determine the complete Supported: This header is used to determine the complete set of
set of functionality that both client and server have. The functionality that both client and server have. The intended
intended usage is to determine before one needs to use a usage is to determine before one needs to use a functionality
functionality that it is supported. It can be used in any that it is supported. It can be used in any method, however
method, however OPTIONS is the most suitable one as it at the OPTIONS is the most suitable one as it at the same time
same time determines all methods that are implemented. When determines all methods that are implemented. When sending a
sending a request the requestor declares all its capabilities request the requester declares all its capabilities by
by including all supported feature-tags. This results in that including all supported feature-tags. This results in that the
the receiver learns the requestors feature support. The receiver learns the requesters feature support. The receiver
receiver then includes its set of features in the response. then includes its set of features in the response.
Proxy-Supported: The Proxy-Supported header is used similar to the Proxy-Supported: This header is used similar to the Supported
Supported header, but instead of giving the supported header, but instead of giving the supported functionality of
functionality of the client or server it provides both the the client or server it provides both the requester and the
requestor and the responder a view of what functionality the responder a view of what functionality the proxy chain between
proxy chain between the two supports. Proxies are required to the two supports. Proxies are required to add this header
add this header whenever the Supported header is present, but whenever the Supported header is present, but proxies may
proxies may independently of the requestor add it. independently of the requester add it.
Require: The Require header can be included in any request where the Require: The header can be included in any request where the end-
end-point, i.e. the client or server, is required to understand point, i.e. the client or server, is required to understand the
the feature to correctly perform the request. This can, for feature to correctly perform the request. This can, for
example, be a SETUP request where the server is required to example, be a SETUP request where the server is required to
understand a certain parameter to be able to set up the media understand a certain parameter to be able to set up the media
delivery correctly. Ignoring this parameter would not have the delivery correctly. Ignoring this parameter would not have the
desired effect and is not acceptable. Therefore the end-point desired effect and is not acceptable. Therefore the end-point
receiving a request containing a Require MUST negatively receiving a request containing a Require MUST negatively
acknowledge any feature that it does not understand and not acknowledge any feature that it does not understand and not
perform the request. The response in cases where features are perform the request. The response in cases where features are
not supported are 551 (Option Not Supported). Also the not supported are 551 (Option Not Supported). Also the
features that are not supported are given in the Unsupported features that are not supported are given in the Unsupported
header in the response. header in the response.
Proxy-Require: This method has the same purpose and workings as Proxy-Require: This header has the same purpose and workings as
Require except that it only applies to proxies and not the end- Require except that it only applies to proxies and not the end-
point. Features that needs to be supported by both proxies and point. Features that needs to be supported by both proxies and
end-point needs to be included in both the Require and Proxy- end-point needs to be included in both the Require and Proxy-
Require header. Require header.
Unsupported: This header is used in a 551 error response, to Unsupported: This header is used in a 551 error response, to
indicate which feature(s) that was not supported. Such a indicate which features were not supported. Such a response is
response is only the result of the usage of the Require and/or only the result of the usage of the Require and/or Proxy-
Proxy-Require header where one or more feature where not Require header where one or more feature where not supported.
supported. This information allows the requestor to make the This information allows the requester to make the best of
best of situations as it knows which features are not situations as it knows which features are not supported.
supported.
12. Pipelining Support 12. Pipelining Support
Pipelining is a general method to improve performance of request Pipelining is a general method to improve performance of request
response protocols by allowing the requesting entity to have more response protocols by allowing the requesting entity to have more
than one request outstanding and send them over the same persistent than one request outstanding and send them over the same persistent
connection. For RTSP where the relative order of requests will connection. For RTSP where the relative order of requests will
matter it is important to maintain the order of the requests. matter it is important to maintain the order of the requests.
Because of this the the responding entity SHALL process the incoming Because of this the responding entity MUST process the incoming
requests in their sending order. The sending order can be determined requests in their sending order. The sending order can be determined
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 MUST 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.32). 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 are processed in the same RTSP session context which
which the first request creates. In other words a client can request the first request creates. In other words a client can request that
that two or more media streams are set-up and then played without two or more media streams are set-up and then played without needing
needing to wait for a single response. This speeds up the initial to wait for a single response. This speeds up the initial startup
startup time for an RTSP session with at least one RTT. 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 successful completion of one or
more prior requests the requestor must verify that all requests were more prior requests the requester 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
PLAY request can still be succesfully executed. However, not as PLAY request can still be successfully executed. However, not as
expected by the requesting client as only a single media instead of expected by the requesting client as only a single media instead of
two will be played. In this case the client can send a PAUSE 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 MUST 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 [RFC5234] 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 |
skipping to change at page 56, line 43 skipping to change at page 60, line 43
| | | | | | | | | | | |
| 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 |
| | | | | |
| | S -> C | | required | required |
+---------------+-----------+--------+--------------+---------------+ +---------------+-----------+--------+--------------+---------------+
Table 7: Overview of RTSP methods, their direction, and what objects Table 7: Overview of RTSP methods, their direction, and what objects
(P: presentation, S: stream) they operate on. Legend: R=Respond, (P: presentation, S: stream) they operate on. Legend: R=Respond,
Sd=Send, Opt: Optional, Req: Required Sd=Send, Opt: Optional, Req: Required
Note on Table 7: GET_PARAMETER is recommended, but not required. Note on Table 7: GET_PARAMETER is recommended, but not required.
For example, a fully functional server can be built to deliver For example, a fully functional server can be built to deliver
media without any parameters. SET_PARAMETER is required however media without any parameters. SET_PARAMETER is required however
due to its usage for keep-alive. PAUSE is now required due to due to its usage for keep-alive. PAUSE is now required due to
that it is the only way of getting out of the state machines play that it is the only way of getting out of the state machines play
state without terminating the whole session. state without terminating the whole session.
If an RTSP agent does not support a particular method, it MUST return If an RTSP agent does not support a particular method, it MUST return
501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD 501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD
NOT try this method again for the given agent / resource combination. NOT try this method again for the given agent / resource combination.
An RTSP proxy whos main function is to log or audit and not modify An RTSP proxy who's main function is to log or audit and not modify
transport or media handling in any way MAY forward RTSP messages with transport or media handling in any way MAY forward RTSP messages with
unknown methods. Note, the proxy stil needs to perform the minimal unknown methods. Note, the proxy still needs to perform the minimal
required processing, like adding the Via header. required processing, like adding the Via header.
13.1. OPTIONS 13.1. OPTIONS
The semantics of the RTSP OPTIONS method is equivalent to that of the The semantics of the RTSP OPTIONS method is similar to that of the
HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is
bi-directional, in that a client can request it to a server and vice bi-directional, in that a client can request it to a server and vice
versa. A client MUST implement the capability to send an OPTIONS versa. A client MUST implement the capability to send an OPTIONS
request and a server or a proxy MUST implement the capability to request and a server or a proxy MUST implement the capability to
respond to an OPTIONS request. The client, server or proxy MAY also respond to an OPTIONS request. The client, server or proxy MAY also
implement the converse of their required capability. implement the converse of their required capability.
An OPTIONS request may be issued at any time. Such a request does An OPTIONS request may be issued at any time. Such a request does
not modify the session state. However, it may prolong the session not modify the session state. However, it may prolong the session
lifespan (see below). The URI in an OPTIONS request determines the lifespan (see below). The URI in an OPTIONS request determines the
skipping to change at page 58, line 37 skipping to change at page 62, line 37
Note that some of the feature-tags in Require and Proxy-Require are Note that some of the feature-tags in Require and Proxy-Require are
fictional features. fictional features.
13.2. DESCRIBE 13.2. DESCRIBE
The DESCRIBE method is used to retrieve the description of a The DESCRIBE method is used to retrieve the description of a
presentation or media object from a server. The Request-URI of the presentation or media object from a server. The Request-URI of the
DESCRIBE request identifies the media resource of interest. The DESCRIBE request identifies the media resource of interest. The
client MAY include the Accept header in the request to list the client MAY include the Accept header in the request to list the
description formats that it understands. The server SHALL respond description formats that it understands. The server MUST respond
with a description of the requested resource and return the with a description of the requested resource and return the
description in the entity of the response. The DESCRIBE reply- description in the message body of the response. The DESCRIBE reply-
response pair constitutes the media initialization phase of RTSP. response pair constitutes the media initialization phase of RTSP.
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
skipping to change at page 60, line 23 skipping to change at page 64, line 23
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 two used for the streamed media. The SETUP method may be used in two
different cases; Create an RTSP session and change the transport different cases; Create an RTSP session and change the transport
parameters of already set up media stream. SETUP can be used in all parameters of already set up media stream. SETUP can be used in all
three states; INIT, and READY, for both purposes and in PLAY to three states; INIT, and READY, for both purposes and in PLAY to
change the transport parameters. There is also a third possibile change the transport parameters. There is also a third possible
usage for the SETUP method which is not specified in this memo: usage for the SETUP method which is not specified in this memo:
adding a media to a session. Using SETUP to add media to an existing adding a media to a session. Using SETUP to add media to an existing
session, when the session is in PLAY state, is unspecified. session, when the session is in PLAY state, is unspecified.
The Transport header, see Section 16.51, specifies the transport The Transport header, see Section 16.52, specifies the media
parameters acceptable to the client for data transmission; the transport parameters acceptable to the client for data transmission;
response will contain the transport parameters selected by the the response will contain the transport parameters selected by the
server. This allows the client to enumerate in descending order of server. This allows the client to enumerate in descending order of
preference the transport mechanisms and parameters acceptable to it, preference the transport mechanisms and parameters acceptable to it,
while the server can select the most appropriate. It is expected while the server can select the most appropriate. It is expected
that the session description format used will enable the client to that the session description format used will enable the client to
select a limited number possible configurations that are offered to select a limited number 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.
For the benefit of any intervening firewalls, a client SHALL indicate For the benefit of any intervening firewalls, a client MUST indicate
the known transport parameters, even if it has no influence over the known transport parameters, even if it has no influence over
these parameters, for example, where the server advertises a fixed these parameters, for example, where the server advertises a fixed
multicast address as destination. multicast address as destination.
Since SETUP includes all transport initialization information, Since SETUP includes all transport initialization information,
firewalls and other intermediate network devices (which need this firewalls and other intermediate network devices (which need this
information) are spared the more arduous task of parsing the information) are spared the more arduous task of parsing the
DESCRIBE response, which has been reserved for media DESCRIBE response, which has been reserved for media
initialization. initialization.
The client SHALL include the Accept-Ranges header in the request The client MUST include the Accept-Ranges header in the request
indicating all supported unit formats in the Range header. This indicating all supported unit formats in the Range header. This
allows the server to know which format it may use in future session allows the server to know which format it may use in future session
related responses, such as PLAY response without any range in the related responses, such as PLAY response without any range in the
request. If the client does not support a time format necessary for request. If the client does not support a time format necessary for
the presentation the server SHALL respond using 456 (Header Field Not the presentation the server MUST respond using 456 (Header Field Not
Valid for Resource) and include the Accept-Ranges header with the Valid for Resource) and include the Accept-Ranges header with the
range unit formats supported for the resource. range unit formats supported for the resource.
In a SETUP response the server SHALL include the Accept-Ranges header In a SETUP response the server MUST include the Accept-Ranges header
(see Section 16.5) to indicate which time formats 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 The SETUP response 200 OK MUST include the Media-Properties header
(see Section 16.29 ). The combination of the parameters of the (see Section 16.28 ). The combination of the parameters of the
Media-Properties header indicate the nature of the content present in Media-Properties header indicate the nature of the content present in
the session (see also Section 1.5). For example, a live stream with the session (see also Section 4.9). For example, a live stream with
time shifting is indicated by time shifting is indicated by
o Random Access set to Random-Access, o Random Access set to Random-Access,
o Content Modifications set to Time Progressing, o Content Modifications set to Time Progressing,
o Retention set to Time-Duration (with specific recording window o Retention set to Time-Duration (with specific recording window
time value). time value).
The SETUP response 200 OK SHALL include the Media-Range header (see The SETUP response 200 OK MUST include the Media-Range header (see
Section 16.30) if the media is Time-Progressing. Section 16.29) if the media is Time-Progressing.
A basic example for SETUP: 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
skipping to change at page 62, line 19 skipping to change at page 66, line 19
UDP (UDP per default) to be received on client port 4588 and 4589 or UDP (UDP per default) to be received on client port 4588 and 4589 or
RTP/AVP interleaved on the RTSP control channel. The server selects RTP/AVP interleaved on the RTSP control channel. The server selects
the RTP/AVP/UDP transport and adds the ports it will send and the RTP/AVP/UDP transport and adds the ports it will send and
received RTP and RTCP from, and the RTP SSRC that will be used by the received RTP and RTCP from, and the RTP SSRC that will be used by the
server. server.
The server MUST generate a session identifier in response to a The server MUST generate a session identifier in response to a
successful SETUP request, unless a SETUP request to a server includes successful SETUP request, unless a SETUP request to a server includes
a session identifier, in which case the server MUST bundle this setup a session identifier, in which case the server MUST bundle this setup
request into the existing session (aggregated session) or return request into the existing session (aggregated session) or return
error 459 (Aggregate Operation Not Allowed) (see Section 15.4.11). error 459 (Aggregate Operation Not Allowed) (see Section 15.4.24).
An Aggregate control URI MUST be used to control an aggregated An Aggregate control URI MUST be used to control an aggregated
session. This URI MUST be different from the stream control URIs of session. This URI MUST be different from the stream control URIs of
the individual media streams included in the aggregate. The the individual media streams included in the aggregate. The
Aggregate control URI is to be specified by the session description Aggregate control URI is to be specified by the session description
if the server supports aggregated control and aggregated control is if the server supports aggregated control and aggregated control is
desired for the session. However even if aggregated control is desired for the session. However even if aggregated control is
offered the client MAY chose to not set up the session in aggregated offered the client MAY chose to not set up the session in aggregated
control. If an Aggregate control URI is not specified in the session control. If an Aggregate control URI is not specified in the session
description, it is normally an indication that non-aggregated control description, it is normally an indication that non-aggregated control
should be used. The SETUP of media streams in an aggregate which has should be used. The SETUP of media streams in an aggregate which has
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 carries enough information for
aggregate control of a session, the Aggregate control URI is still aggregate control of a session, the Aggregate control URI is still
important for some methods such as SET_PARAMETER where the control important for some methods such as SET_PARAMETER where the control
URI enables the resource in question to be easily identified. The URI enables the resource in question to be easily identified. The
Aggregate control URI is also useful for proxies, enabling them to Aggregate control URI is also useful for proxies, enabling them to
route the request to the appropriate server, and for logging, route the request to the appropriate server, and for logging,
where it is useful to note the actual resource that a request was where it is useful to note the actual resource that a request was
operating on. operating on.
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
skipping to change at page 63, line 13 skipping to change at page 67, line 13
with that session's ID. with that session's ID.
o If RTP is used as a transport for the underlying media streams, an o If RTP is used as a transport for the underlying media streams, an
RTCP sender or receiver report from the client(s) for any of the RTCP sender or receiver report from the client(s) for any of the
media streams in that RTSP session. RTCP Sender Reports may for media streams in that RTSP session. RTCP Sender Reports may for
example be received in sessions where the server is invited into a example be received in sessions where the server is invited into a
conference session and is as valid for keep-alive. conference session and is as valid for keep-alive.
If a SETUP request on a session fails for any reason, the session If a SETUP request on a session fails for any reason, the session
state, as well as transport and other parameters for associated state, as well as transport and other parameters for associated
streams SHALL remain unchanged from their values as if the SETUP streams MUST remain unchanged from their values as if the SETUP
request had never been received by the server. request had never been received by the server.
13.3.1. Changing Transport Parameters 13.3.1. Changing Transport Parameters
A client MAY issue a SETUP request for a stream that is already set A client MAY issue a SETUP request for a stream that is already set
up or playing in the session to change transport parameters, which a up or playing in the session to change transport parameters, which a
server MAY allow. If it does not allow changing of parameters, it server MAY allow. If it does not allow changing of parameters, it
MUST respond with error 455 (Method Not Valid In This State). MUST respond with error 455 (Method Not Valid In This State).
Reasons to support changing transport parameters, is to allow for Reasons to support changing transport parameters, is to allow for
application layer mobility and flexibility to utilize the best application layer mobility and flexibility to utilize the best
skipping to change at page 63, line 39 skipping to change at page 67, line 39
performs a TEARDOWN of the affected media and then setting it up performs a TEARDOWN of the affected media and then setting it up
again. In aggregated session avoiding tearing down all the media at again. In aggregated session avoiding tearing down all the media at
the same time will avoid the creation of a new session. the same time will avoid the creation of a new session.
All transport parameters MAY be changed. However the primary usage All transport parameters MAY be changed. However the primary usage
expected is to either change transport protocol completely, like expected is to either change transport protocol completely, like
switching from Interleaved TCP mode to UDP or vise versa or change switching from Interleaved TCP mode to UDP or vise versa or change
delivery address. delivery address.
In a SETUP response for a request to change the transport parameters In a SETUP response for a request to change the transport parameters
while in Play state, the server SHALL include the Range to indicate while in Play state, the server MUST include the Range to indicate
from what point the new transport parameters are used. Further, if from what point the new transport parameters are used. Further, if
RTP is used for delivery, the server SHALL also include the RTP-Info RTP is used for delivery, the server MUST also include the RTP-Info
header to indicate from what timestamp and RTP sequence number the header to indicate from what timestamp and RTP sequence number the
change has taken place. If both RTP-Info and Range is included in change has taken place. If both RTP-Info and Range is included in
the response the "rtp_time" parameter and range MUST be for the the response the "rtp_time" parameter and start point in the Range
corresponding time, i.e. be used in the same way as for PLAY to header MUST be for the corresponding time, i.e. be used in the same
ensure the correct synchronization information is available. way as for PLAY to 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
This section describes the usage of the PLAY method in general, for This section describes the usage of the PLAY method in general, for
aggregated sessions, and in different usage scenarios. aggregated sessions, and in different usage scenarios.
13.4.1. General Usage 13.4.1. General Usage
The PLAY method tells the server to start sending data via the The PLAY method tells the server to start sending data via the
mechanism specified in SETUP and which part of the media should be mechanism specified in SETUP and which part of the media should be
played out. PLAY requests are valid when the session is in READY or played out. PLAY requests are valid when the session is in READY or
PLAY states. A PLAY request MUST include a Session header to PLAY states. A PLAY request MUST include a Session header to
indicate which session the request applies to. indicate which session the request applies to.
Upon receipt of the PLAY request, the server SHALL position the Upon receipt of the PLAY request, the server MUST position the normal
normal play time to the beginning of the range specified in the play time to the beginning of the range specified in the received
received Range header and delivers stream data until the end of the Range header and delivers stream data until the end of the range if
range if given, or until a new PLAY request is received, else to the given, or until a new PLAY request is received, else to the end of
end of the media is reached. To allow for precise composition the media is reached. If not Range header is present in the PLAY
multiple ranges MAY be specified in one PLAY Request. The range request the server shall play from current pause point until the end
values are valid if all given ranges are part of any media within the of media. The pause point defaults at start to the beginning of the
aggregate. If a given range value points outside of the media, the media. For media that is time-progressing and has no retention, the
response SHALL be the 457 (Invalid Range) error code. pause point will always be set equal to NPT "now", i.e. current
playback point. The pause point may also be set to a particular
The below example will first play seconds 10 through 15, then, point in the media by the PAUSE method, see Section 13.6. The pause
immediately following, seconds 20 to 25, and finally seconds 30 point for media that is currently playing is equal to the current
through the end. media position. For time-progressing media with time-limited
retention, if the pause point represents a position that is older
C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0 than what is retained by the server, the pause point will be moved to
CSeq: 835 the oldest retained.
Session: 12345678
Range: npt=10-15, npt=20-25, npt=30-
Seek-Style: RAP
User-Agent: PhonyClient/1.2
See the description of the PAUSE request for further examples. What range values is valid depends on the type of content. For
content that isn't time progressing the range value is valid if the
given range is part of any media within the aggregate. In other
words the valid media range for the aggregate is the super-set of all
of the media components in the aggregate. If a given range value
points outside of the media, the response MUST be the 457 (Invalid
Range) error code and include the Media-Range header (Section 16.29)
with the valid range for the media. For time progressing content
where the client request a start point prior to what is retained, the
start point is adjusted to the oldest retained content. For a start
point that is beyond the media front edge, i.e. beyond the current
value for "now", the server shall adjust the start value to the
current front edge. The Range headers end point value may point
beyond the current media edge. In that case the server shall deliver
media from the requested (and possibly adjusted) start point until
the provided end-point, or the end of the media is reached prior to
the specified stop point. Please note that if one simply want to
play from a particular start point until the end of media using an
Range header with an implicit stop point is recommended.
A PLAY request without a Range header is legal. It SHALL start For media with random access properties a client may express its
playing a stream from the beginning (npt=0-) unless the stream has preference on which policy for start point selection the server shall
been paused or is currently playing. If a stream has been paused via use. This is done by including the Seek-Style header (Section 16.45)
PAUSE, stream delivery resumes at the pause point. If a stream is in the PLAY request.
currently playing, the new PLAY begins at the current stream
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.
A client desiring to play the media from the beginning MUST send a A client desiring to play the media from the beginning MUST send a
PLAY request with a Range header pointing at the beginning, e.g. PLAY request with a Range header pointing at the beginning, e.g.
npt=0-. If a PLAY request is received without a Range header when 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 media delivery has stopped at the end, the server SHOULD respond with
a 457 "Invalid Range" error response. In that response the current a 457 "Invalid Range" error response. In that response the current
pause point in a Range header SHALL be included. pause point in a Range header MUST be included.
All range specifiers in this specification allow for ranges with All range specifiers in this specification allow for ranges with
unspecified begin times (e.g. "npt=-30"). When used in a PLAY implicit start point (e.g. "npt=-30"). When used in a PLAY request,
request, the server treats this as a request to start/resume playback the server treats this as a request to start/resume playback from the
from the current pause point, ending at the end time specified in the current pause point, ending at the end time specified in the Range
Range header. If the pause point is located later than the given end header. If the pause point is located later than the given end
value, a 457 (Invalid Range) response SHALL be given. value, a 457 (Invalid Range) response MUST be given.
Server MUST include a "Range" header in any PLAY response. The The below example will play seconds 10 through 25. It also request
response MUST use the same format as the request's range header the server to deliver media from the first Random Access Point prior
contained. If no Range header was in the request, the format used in to the indicated start point.
any previous PLAY request within the session SHOULD be used. If no
format has been indicated in a previous request the server MAY use C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0
any time format supported by the media and indicated in the Accept- CSeq: 835
Ranges header in the SETUP respone. It is RECOMMENDED that NPT is Session: 12345678
used if supported by the media. Range: npt=10-25
Seek-Style: RAP
User-Agent: PhonyClient/1.2
Server MUST include a "Range" header in any PLAY response, even if no
Range header was present in the request. The response MUST use the
same format as the request's range header contained. If no Range
header was in the request, the format used in any previous PLAY
request within the session SHOULD be used. If no format has been
indicated in a previous request the server MAY use any time format
supported by the media and indicated in the Accept-Ranges header in
the SETUP response. It is RECOMMENDED that NPT is used if supported
by the media.
For any error response to a PLAY request, the server's response For any error response to a PLAY request, the server's response
depends on the current session state. If the session is in ready depends on the current session state. If the session is in ready
state, the current pause-point is returned. For time-progressing state, the current pause-point is returned using Range header with
content where the pause-point moves with real-time due to limited the pause point as the explicit start-point and an implicit end-
retention, the current resume point is returned. For sessions in point. For time-progressing content where the pause-point moves with
playing state, the current playout point and the remaining parts of real-time due to limited retention, the current pause point is
the range request is returned. returned. For sessions in playing state, the current playout point
and the remaining parts of the range request is returned. For any
media with retention longer than 0 seconds the currently valid Media-
Range header shall also be included in the response.
A PLAY response MAY include a header(s) carrying synchronization A PLAY response MAY include a header(s) carrying synchronization
information. As the information necessary is dependent on the media information. As the information necessary is dependent on the media
transport format, further rules specifying the header and its usage transport format, further rules specifying the header and its usage
is needed. For RTP the RTP-Info header is specified, see is needed. For RTP the RTP-Info header is specified, see
Section 16.43, and used in the following example. Section 16.43, and used in the following example.
Here is a simple example for a single audio stream where the client Here is a simple example for a single audio stream where the client
requests the media starting from 3.52 seconds and to the end. The requests the media starting from 3.52 seconds and to the end. The
server sends a 200 OK response with the actual play time (equal to server sends a 200 OK response with the actual play time which is 10
the requested in this case) and the RTP-Info header that contains the m prior (3.51) and the RTP-Info header that contains the necessary
necessary parameters for the RTP stack. parameters for the RTP stack.
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=3.52- Range: npt=3.52-
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: 836 CSeq: 836
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=3.52-324.39 Range: npt=3.51-324.39
Seek-Style: First-Prior
RTP-Info:url="rtsp://example.com/audio" RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545 ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTP Packet TS=2345962545 => NPT=3.52 S->C: RTP Packet TS=2345962545 => NPT=3.51
Duration=4.15 seconds Duration=0.16 seconds
For media with random-acces properties, the server MUST reply with The server reply with the actual start point that will be delivered.
the actual range that will be played back, i.e. for which duration This may differ from the requested range if alignment of the
any media (having content at this time) is delivered. This may requested range to valid frame boundaries is required for the media
differ from the requested range if alignment of the requested range source. Note that some media streams in an aggregate may need to be
to valid frame boundaries is required for the media source. Note delivered from even earlier points. Also, some media format have a
that some media streams in an aggregate may need to be delivered from very long duration per individual data unit, therefore it might be
even earlier points. Also, some media format have a very long necessary for the client to parse the data unit, and select where to
duration per individual data unit, therefore it might be necessary start. The server shall also indicate which policy it uses for
for the client to parse the data unit, and select where to start. selecting the actual start point by including a Seek-Style header.
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 In the following example the client receives the first media packet
that stretches all the way up and past the requested playtime. Thus, 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 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.
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=7.05- User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 836 CSeq: 836
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=3.52- Range: npt=3.52-
skipping to change at page 67, line 15 skipping to change at page 71, line 17
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=7.05- User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 836 CSeq: 836
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=3.52- Range: npt=3.52-
Seek-Style: First-Prior
RTP-Info:url="rtsp://example.com/audio" RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545 ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTP Packet TS=2345962545 => NPT=3.52 S->C: RTP Packet TS=2345962545 => NPT=3.52
Duration=4.15 seconds Duration=4.15 seconds
After playing the desired range, the presentation does NOT transition After playing the desired range, the presentation does NOT 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, MUST replace the current PLAY action with the new one requested, i.e.
i.e. being handle the same as the request was received in ready being handle the same as the request was received in ready state. In
state. In the case the first time range in Range header has a open the case the range in Range header has a implicit start time
start time (-endtime), the server SHALL continue to play from where (-endtime), the server MUST continue to play from where it currently
it currently was until the specified end point. This is useful to was until the specified end point. This is useful to change end at
change ongoing playback to play another sequence, or end at another another point than in the previous request.
point than in the previous request.
The following example plays the whole presentation starting at SMPTE The following example plays the whole presentation starting at SMPTE
time code 0:10:20 until the end of the clip. Note: The RTP-Info time code 0:10:20 until the end of the clip. Note: The RTP-Info
headers has been broken into several lines 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: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: smpte=0:10:22-0:15:45 Range: smpte=0:10:22-0:15:45
Seek-Style: Next
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: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server:PhonyServer 1.0 Server:PhonyServer 1.0
Range: clock=19961108T142300Z-19961108T143520Z Range: clock=19961108T142300Z-19961108T143520Z
Seek-Style: Next
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
13.4.2. Aggregated Sessions 13.4.2. Aggregated Sessions
PLAY requests can operate on sessions controlling a single media and PLAY requests can operate on sessions controlling a single media and
on aggregated sessions controlling multiple media. on aggregated sessions controlling multiple media.
In an aggregated session the PLAY request MUST contain an aggregated In an aggregated session the PLAY request MUST contain an aggregated
control URI. A server SHALL responde with error 460 (Only Aggregate control URI. A server MUST response with error 460 (Only Aggregate
Operation Allowed) if the client PLAY Request-URI is for one of the Operation Allowed) if the client PLAY Request-URI is for one of the
media. The media in an aggregate SHALL be played in sync. If a media. The media in an aggregate MUST be played in sync. If a
client wants individual control of the media it needs to use separate client wants individual control of the media it needs to use separate
RTSP sessions for each media. RTSP sessions for each media.
For aggregated sessions where the initial SETUP request (creating a For aggregated sessions where the initial SETUP request (creating a
session) is followed by one or more additional SETUP request, a PLAY session) is followed by one or more additional SETUP request, a PLAY
request MAY be pipelined after those additional SETUP requests request MAY be pipelined after those additional SETUP requests
without awaiting their responses. This procedure can reduce the without awaiting their responses. This procedure can reduce the
delay from start of session establishment until media play-out has delay from start of session establishment until media play-out has
started with one round trip time. However an client needs to be started with one round trip time. However, a client needs to be
aware that using this procedure will result in the playout of the aware that using this procedure will result in the playout of the
server state established at the time of processing the PLAY, i.e., 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 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 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 of the prior requests. However a client easily determine this based
on the responses from those requests. In case of failure the client on the responses from those requests. In case of failure the client
can halt the media playout using PAUSE and try to establish the can halt the media playout using PAUSE and try to establish the
intended state again before issuing another PLAY request. intended state again before issuing another PLAY request.
13.4.3. Updating current PLAY Requests 13.4.3. Updating current PLAY Requests
Clients can issue PLAY request while the stream is In PLAYING state Clients can issue PLAY request while the stream is in PLAYING state
and thus updating their request. The possibility to replace a and thus updating their request.
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
removed and multiple ranges can be used to achieve a similar
functionality in combination with the possibility to replace
previous play messages.
o The use of PLAY for keep-alive signaling, i.e. PLAY request
without a range header in PLAY state, has also been deprecated.
Instead a client can use, SET_PARAMETER (recommended) or OPTIONS
(allowed) for keep alive.
The important difference compared to a PLAY request in ready state is The important difference compared to a PLAY request in ready state is
the handling of the current playpoint and how the range header in the handling of the current playpoint and how the range header in
request is constructed. The session is actively playing media and request is constructed. The session is actively playing media and
the playpoint will be moving making the exact time a request will the playpoint will be moving making the exact time a request will
take action is hard to predict. Depending on how the PLAY header take action is hard to predict. Depending on how the PLAY header
appears two different cases exist: total replacement or continuation. appears two different cases exist: total replacement or continuation.
A total replacement is signalled by having the first range A total replacement is signalled by having the first range
specification have an explicit start value, e.g. npt=45- or specification have an explicit start value, e.g. npt=45- or
npt=45-60, in which case the server stops playout at the current npt=45-60, in which case the server stops playout at the current
playout point and then starts delivering media according to the Range playout point and then starts delivering media according to the Range
header. This is equivalent to having the client first send a PAUSE header. This is equivalent to having the client first send a PAUSE
and then a new play request that isn't based on the pause point. In and then a new play request that isn't based on the pause point. In
the case of continuation the first range specifier has an open start the case of continuation the first range specifier has an implicit
point and a explict stop value (Z), e.g. npt=-60, which indicate that start point and a explicit stop value (Z), e.g. npt=-60, which
it SHALL convert the range specifier being played prior to this PLAY indicate that it MUST convert the range specifier being played prior
request (X to Y) into (X to Z) and continue as this was the request to this PLAY request (X to Y) into (X to Z) and continue as this was
originally played. For both total replacement and continuation the the request originally played.
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 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). play ranges 10 to 15. If the new PLAY request arrives at the server
If the new PLAY request arrives at the server 4 seconds after the 4 seconds after the previous one, it will take effect while the
previous one, it will take effect while the server plays the first server still plays the first range (10-15). Thus changing the
range (10-15). Thus changing the behavior of this range to continue behavior of this range to continue to play to 25 seconds, i.e. the
to play to 25 seconds, i.e. the equivalent single request would be equivalent single request would be PLAY with range: npt=10-25.
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
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: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=10-15, npt=13-20 Range: npt=10-15
Seek-Style: Next
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921, ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792482193 ssrc=789DAF12:seq=57654;rtptime=2792482193
Session: 12345678 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: Thu, 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
Seek-Style: Next
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934239921, ssrc=0D12F123:seq=5712;rtptime=934239921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792842193 ssrc=789DAF12:seq=57654;rtptime=2792842193
Session: 12345678 Session: 12345678
13.4.4. Playing On-Demand Media 13.4.4. Playing On-Demand Media
On-demand media is indicated by the content of the Media-Properties On-demand media is indicated by the content of the Media-Properties
header in the SETUP response by (see also Section 16.29): header in the SETUP response by (see also Section 16.28):
o Random-Access property is set to Random Acces; o Random-Access property is set to Random Access;
o Content Modifications set to unmutable; o Content Modifications set to Immutable;
o Retetion set Unlimited or Time-Limited. o Retention set Unlimited or Time-Limited.
Playing on-demand media follows the general usage as described in Playing on-demand media follows the general usage as described in
Section 13.4.1. Section 13.4.1.
13.4.5. Playing Dynamic On-Demand Media 13.4.5. Playing Dynamic On-Demand Media
Dynamic on-demand media is indicated by the content of the 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): Properties header in the SETUP response by (see also Section 16.28):
o Random-Access set to Random Access; o Random-Access set to Random Access;
o Content Modifications set to dynamic; o Content Modifications set to dynamic;
o Retetion set unlimited or Time-Limited. o Retention set Unlimited or Time-Limited.
Playing on-demand media follows the general usage as described in Playing on-demand media follows the general usage as described in
Section 13.4.1 as long as the media has not been changed. 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 There are ways for the client to get informed about changed of media
resources in play state, if the resource was changed. The client resources in play state, if the resource was changed. The client
will receive a PLAY_NOTIFY request with Notify-Reason header set to 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 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- value of the Media-Range to decide further actions, if the Media-
Range header is present in the PLAY_NOTIFY request. The second way 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 is that the client issues a GET_PARAMETER request without a body but
including a Media-Range header. The 200 OK response SHALL include including a Media-Range header. The 200 OK response MUST include the
the current Media-Range header (see Section 16.30). current Media-Range header (see Section 16.29).
13.4.6. Playing Live Media 13.4.6. Playing Live Media
Live media is indicated by the content of the Media-Properties header Live media is indicated by the content of the Media-Properties header
in the SETUP response by (see also Section 16.29): in the SETUP response by (see also Section 16.28):
o Random-Access set to no-seeking; o Random-Access set to no-seeking;
o Content Modifications set to Time-Progressing; o Content Modifications set to Time-Progressing;
o Retetion with Time-Duration set to 0.0. o Retention with Time-Duration set to 0.0.
For live media, the SETUP response 200 OK SHALL include the Media- For live media, the SETUP response 200 OK MUST include the Media-
Range header (see Section 16.30). Range header (see Section 16.29).
A client MAY send PLAY requests without the Range header, if the A client MAY send PLAY requests without the Range header, if the
request include the Range header it SHALL use a symbolic value request include the Range header it MUST use a symbolic value
representing "now". For NPT that range specification is "npt=now-". representing "now". For NPT that range specification is "npt=now-".
The server SHALL include the Range header in the response and it MUST The server MUST include the Range header in the response and it MUST
indicate a explict time value and not a symbolic value. In other indicate an explicit time value and not a symbolic value. In other
words npt=now- is not a valid to use in the respone. Instead the words npt=now- is not a valid to use in the response. Instead the
time since session start is recommended expressed as an open time since session start is recommended expressed as an open
interval, e.g. "npt=96.23-". An absolute time value (clock) for the interval, e.g. "npt=96.23-". An absolute time value (clock) for the
corresponding time MAY be given, i.e. "clock=20030213T143205Z-". The corresponding time MAY be given, i.e. "clock=20030213T143205Z-". The
UTC clock format SHOULD only be used if client has shown support for UTC clock format can only be used if client has shown support for it
it. using the Accept-Ranges header.
13.4.7. Playing Live with Recording 13.4.7. Playing Live with Recording
Certain media server may offer recording services of live sessions to Certain media server may offer recording services of live sessions to
their clients. This recording would normally be from the begining of their clients. This recording would normally be from the beginning
the media session. Clients can randomly access the media between now of the media session. Clients can randomly access the media between
and the begining of the media session. This live media with now and the beginning of the media session. This live media with
recording is indicated by the content of the Media-Properties header recording is indicated by the content of the Media-Properties header
in the SETUP response by (see also Section 16.29): in the SETUP response by (see also Section 16.28):
o Random-Access set to random-access; o Random-Access set to random-access;
o Content Modifications set to Time-Progressing; o Content Modifications set to Time-Progressing;
o Retetion set to Time-limited or Unlimited o Retention set to Time-limited or Unlimited
The SETUP response 200 OK SHALL include the Media-Range header (see The SETUP response 200 OK MUST include the Media-Range header (see
Section 16.30) for this type of media. For live media with recording Section 16.29) for this type of media. For live media with recording
the Range header indicates the current playback time in the media and the Range header indicates the current playback time in the media and
the Media Range indicates the currently available media window around the Media-Range header indicates the currently available media window
the current time. This window can cover recorded content in the past around the current time. This window can cover recorded content in
(seen from current time in the media) or recorded content in the the past (seen from current time in the media) or recorded content in
future (seen from current time in the media). The server adjusts the the future (seen from current time in the media). The server adjusts
play point to the requested border of the window, if the client the play point to the requested border of the window, if the client
requests a play point that is located outside the recording windows, 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 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, range in the recording. The considerations in Section 13.5.3 apply,
if a client requests playback at Scale (Section 16.44) values other if a client requests playback at Scale (Section 16.44) values other
than 1.0 (Normal playback rate) while playing live media with than 1.0 (Normal playback rate) while playing live media with
recording. recording.
13.4.8. Playing Live with Time-Shift 13.4.8. Playing Live with Time-Shift
Certain media server may offer time-shift services to their clients. Certain media server may offer time-shift services to their clients.
This time shift records a fixed interval in the past, i.e., a sliding This time shift records a fixed interval in the past, i.e., a sliding
window recording mechanism, but not past this interval. Clients can window recording mechanism, but not past this interval. Clients can
randomly access the media between now and the interval. This live randomly access the media between now and the interval. This live
media with recording is indicated by the content of the Media- media with recording is indicated by the content of the Media-
Properties header in the SETUP response by (see also Section 16.29): Properties header in the SETUP response by (see also Section 16.28):
o Random-Access set to random-access; o Random-Access set to random-access;
o Content Modifications set to Time-Progressing; o Content Modifications set to Time-Progressing;
o Retention set to Time-Duration and a value indicating the
recording interval (>0).
o Retetion set to Time-Duration and a value indicating the recording The SETUP response 200 OK MUST include the Media-Range header (see
interval (>0). Section 16.29) for this type of media. For live media with recording
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 the Range header indicates the current time in the media and the
Media Range indicates a window around the current time. This window Media Range indicates a window around the current time. This window
can cover recorded content in the past (seen from current time in the 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 media) or recorded content in the future (seen from current time in
the media). The server adjusts the play point to the requested the media). The server adjusts the play point to the requested
border of the window, if the client requests a play point that is 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 located outside the recording windows, e.g., if requested too far in
the past, the server selects the oldest range in the recording. The the past, the server selects the oldest range in the recording. The
considerations in Section 13.5.3 apply, if a client requests playback 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) at Scale (Section 16.44) values other than 1.0 (Normal playback rate)
while playing live media with time-shift. while playing live media with time-shift.
13.5. PLAY_NOTIFY 13.5. PLAY_NOTIFY
The PLAY_NOTIFY method is issued by a server to inform a client about The PLAY_NOTIFY method is issued by a server to inform a client about
an ansynchronous event for a session in play state. The Session an asynchronously event for a session in play state. The Session
header MUST be presented in a PLAY_NOTIFY request and indicates the header MUST be presented in a PLAY_NOTIFY request and indicates the
scope of the request. Sending of PLAY_NOTIFY requests requires a scope of the request. Sending of PLAY_NOTIFY requests requires a
persistent connection between server and client, otherwise there is persistent connection between server and client, otherwise there is
no way for the server to send this request method to the client. no way for the server to send this request method to the client.
PLAY_NOTIFY requests have an end-to-end (i.e. server to client) PLAY_NOTIFY requests have an end-to-end (i.e. server to client)
scope, as they carry the Session header, and apply only to the given scope, as they carry the Session header, and apply only to the given
session. The client SHOULD immediately return a response to the session. The client SHOULD immediately return a response to the
server. server.
PLAY_NOTIFY requests MAY be used with a message body, depending on PLAY_NOTIFY requests MAY be used with a message body, depending on
the value of the Notify-Reason header. It is described in the the value of the Notify-Reason header. It is described in the
particular section for each Notify-Reason if a message body is used. particular section for each Notify-Reason if a message body is used.
However, currently there is no Notify-Reason that allows using a However, currently there is no Notify-Reason that allows using a
message body. There is the need to obey some limitations, when message body. There is in this case a need to obey some limitations
adding new Notify-Reasons that intend to use a message body: The when adding new Notify-Reasons that intend to use a message body: The
server can send any type of message body, but it is not ensured that server can send any type of message body, but it is not ensured that
the client can understand the received message body. This is related the client can understand the received message body. This is related
to DESCRIBE (seeSection 13.2 ), but there the client can state its to DESCRIBE (seeSection 13.2 ), but in this particular case the
acceptable message bodies by using the Accept header. In case of client can state its acceptable message bodies by using the Accept
PLAY_NOTIFY, the server does not know which message bodies are header. In the case of PLAY_NOTIFY, the server does not know which
understood by the client. message bodies are understood by the client.
The Notify-Reason header (see Section 16.31) specifies the reason why The Notify-Reason header (see Section 16.31) specifies the reason why
the server sends the PLAY_NOTIFY request. This is extensible and new the server sends the PLAY_NOTIFY request. This is extensible and new
reasons MAY be added in the future. In case the client does not reasons MAY be added in the future. In case the client does not
understand the reason for the notification it SHALL respond with an understand the reason for the notification it MUST respond with an
465 (Notification Reason Unknown) (Section 15.4.17) error code. 465 (Notification Reason Unknown) (Section 15.4.30) error code.
Servers can send PLAY_NOTIFY with these types: Servers can send PLAY_NOTIFY with these types:
o end-of-stream (see Section 13.5.1); o end-of-stream (see Section 13.5.1);
o media-properties-update (see Section 13.5.2); o media-properties-update (see Section 13.5.2);
o and scale-change (see Section 13.5.3). o scale-change (see Section 13.5.3).
13.5.1. End-of-Stream 13.5.1. End-of-Stream
A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream
indicates the end of the media streams has been reached or will be in indicates the completion or near completion of the PLAY request and
the near future for the given session aggregate. The request SHALL the ending delivery of the media stream(s). The request MUST NOT be
NOT be issued unless the server is in the playing state. The end of issued unless the server is in the playing state. The end of the
the media stream delivery notification may be for either succesful media stream delivery notification may be used to indicate either a
completion of the PLAY request currently being served or indicate successful completion of the PLAY request currently being served, or
some error resulting in failure to complete the request. The to indicate some error resulting in failure to complete the request.
Request-Status header (Section 16.41) SHALL be included to indicate The Request-Status header (Section 16.41) MUST be included to
which request the notification is for and its completion status. The indicate which request the notification is for and its completion
message response status codes (Section 8.1.1) are used to indicate status. The message response status codes (Section 8.1.1) are used
how the PLAY request concluded. In case a PLAY_NOTIFY was issues to indicate how the PLAY request concluded. The sender of a
prior to the actual completion and some error occured resulting in PALY_NOTIFY can issue an updated PALY_NOTIFY, in the case of a
that the previosuly sent was in error a new Notification MUST be sent PLAY_NOTIFY sent with wrong information. For instance, a PLAY_NOTIFY
including the correct status for the completion and all additional was issued before reaching the end-of-stream, but some error occurred
information. resulting in that the previously sent PLAY_NOTIFY contained a wrong
time when the stream will end. In this case a new PLAY_NOTIFY 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 PLAY_NOTIFY requests with Notify-Reason header set to end-of-stream
MUST include a Range header. The Range header indicates the point in MUST include a Range header and the Scale header if the scale value
the stream or streams where delivery was/are ending with the is not 1. The Range header indicates the point in the stream or
timescale that has been used by the client in the PLAY request being streams where delivery is ending with the timescale that was used by
fulfilled. For normal play time it is not alllowed to use "now" as the server in the PLAY response for the request being fulfilled. The
server do know the real ending time of the media stream and now server MUST NOT use the "now" constant in the Range header; it MUST
carries no information to determine what has/will be delivered. When use the actual numeric end position in the proper timescale. When
end-of-stream notifications are issued prior to having sent the last 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 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, beyond the current time in the media being received by the client,
e.g., npt=-15, if npt is currently at 14.2 seconds. e.g., npt=-15, if npt is currently at 14.2 seconds. The Scale header
is to be included so that it is evident if the media time scale is
moving backwards and/or have a non-default pace.
If RTP is used as media transport, a RTP-Info header MUST be If RTP is used as media transport, a RTP-Info header MUST be
included, and the RTP-Info header MUST indicate the last sequence included, and the RTP-Info header MUST indicate the last sequence
number in the seq parameter. number in the seq parameter.
A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream
MUST NOT carry a message body. MUST NOT carry a message body.
This example request notifies the client about a future end-of-stream This example request notifies the client about a future end-of-stream
event: event:
skipping to change at page 75, line 22 skipping to change at page 79, line 28
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 854 CSeq: 854
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
13.5.2. Media-Properties-Update 13.5.2. Media-Properties-Update
A PLAY_NOTIFY request with Notify-Reason header set to media- A PLAY_NOTIFY request with Notify-Reason header set to media-
properties-update indicates an update of the media properties for the properties-update indicates an update of the media properties for the
given session (see Section 16.29) and/or the available media range given session (see Section 16.28) and/or the available media range
that can be played as indicated by Media-Range (Section 16.30). that can be played as indicated by Media-Range (Section 16.29).
PLAY_NOTIFY requests with Notify-Reason header set to media- PLAY_NOTIFY requests with Notify-Reason header set to media-
properties-update MUST include a Media-Properties and Date header and properties-update MUST include a Media-Properties and Date header and
SHOULD include a Media-Range header. SHOULD include a Media-Range header.
This notification SHALL be sent for media that are time-progressing This notification MUST be sent for media that are time-progressing
every time a event happens that changes the basis for making every time an event happens that changes the basis for making
estimations on how the media range progress. In addition it is estimations on how the media range progress. In addition it is
RECOMMENDED that the server sends these notification every 5 minutes RECOMMENDED that the server sends these notifications every 5 minutes
for time-progressing content to ensure the long term stability of the for time-progressing content to ensure the long term stability of the
client estimation and allowing for clock skew detection by the client estimation and allowing for clock skew detection by the
client. Requests for the just mentioned reasons SHALL include Media- client. Requests for the just mentioned reasons MUST include Media-
Range header to provide current Media duration and the Range header Range header to provide current Media duration and the Range header
to indicate the current playing point and any remaining parts of the to indicate the current playing point and any remaining parts of the
requsted range. requested range.
The recommendation for sending updates every 5 minutes is due to
any clock skew issues. In 5 minutes the clock skew should not
become too significant as this is not used for media playback and
synchronization, only for determining which content is available
to the user.
A PLAY_NOTIFY request with Notify-Reason header set to media- A PLAY_NOTIFY request with Notify-Reason header set to media-
properties-update MUST NOT carry a message body. properties-update MUST NOT carry a message body.
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
Date: Tue, 14 Apr 2008 15:48:06 GMT Date: Tue, 14 Apr 2008 15:48:06 GMT
CSeq: 854 CSeq: 854
Notify-Reason: media-properties-update Notify-Reason: media-properties-update
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
Media-Properties: Time-Progressing, Media-Properties: Time-Progressing,
Time-Limited=20080415T153919.36Z, Random-Access=5.0 Time-Limited=20080415T153919.36Z, Random-Access=5.0
Media-Range: npt=0-1:37:21.394 Media-Range: npt=0-1:37:21.394
Range: npt=1:15:49.873- Range: npt=1:15:49.873-
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 854 CSeq: 854
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
13.5.3. Scale-Change 13.5.3. Scale-Change
When a client request playback at Scale (Section 16.44) values other The server may be forced to change the rate, when a client request
than 1.0 (Normal playback rate) then the server may be forced to playback at Scale (Section 16.44) values other than 1.0 (normal
changed the rate. For time progressing media with some retention, playback rate). For time progressing media with some retention, i.e.
i.e. the server stores already sent content, a client requesting to the server stores already sent content, a client requesting to play
play with Scale values larger than 1 may catch up with front end of with Scale values larger than 1 may catch up with the front end of
the media. The server will be unable to continue provide content at the media. The server will then be unable to continue to provide
Scale larger than 1 as content only made available by the server at with content at Scale larger than 1 as content is only made available
Scale=1. Another case is when Scale < 1 and the media retention is by the server at Scale=1. Another case is when Scale < 1 and the
time_duration limited. In this case the playback point can reach the media retention is time-duration limited. In this case the playback
the oldest media unit available, and further playback at this scale point can reach the oldest media unit available, and further playback
becomes impossible as there will be no media available. To avoid at this scale becomes impossible as there will be no media available.
having the client loose any media, the scale will need to be adjusted To avoid having the client loose any media, the scale will need to be
to the same rate which the media is removed from the storage buffer, adjusted to the same rate which the media is removed from the storage
commonly scale=1.0. buffer, commonly scale = 1.0.
Another case is when the content itself consist of spliced pieces or
is dynamically updated. In these cases the server may be required to
change from one supported scale value (different than Scale=1.0) to
another. In this case the server will pick the closest value and
inform the client of what it has picked. In these case the media
properties will also be sent updating the supported Scale values.
This enables a client to adjust the used Scale value.
To minimize impact on playback in any of the above cases the server To minimize impact on playback in any of the above cases the server
SHALL modify the playback properties and set Scale to a supportable MUST modify the playback properties and set Scale to a supportable
value (commonly 1.0) and continue delivery the media. When doing value and continue delivery the media. When doing this modification
this modification it MUST send a PLAY_NOTIFY message with the Notify- it MUST send a PLAY_NOTIFY message with the Notify-Reason header set
Reason header set to "Scale-Change". The request SHALL contain a to "scale-change". The request MUST contain a Range header with the
Range header with the media time where the change took effect, a media time where the change took effect, a Scale header with the new
Scale header with the new value in use, Session header with the ID value in use, Session header with the ID for the session it applies
for the session it applies to and a Date header with the server wall to and a Date header with the server wallclock time of the change.
clock time of the change. For time progressing content also the For time progressing content also the Media-Range and the Media-
Media-Range and the Media-Properties at this point in time SHALL be Properties at this point in time MUST be included. The Media-
included. Properties header MUST be included if the scale change was due to the
content changing what scale values that is supported.
For media streams being delivered using RTP also a RTP-Info header For media streams being delivered using RTP also a RTP-Info header
SHALL be included. It MUST contain the rtptime parameter with a MUST be included. It MUST contain the rtptime parameter with a value
value corresponding to the point of change in that media and corresponding to the point of change in that media and optionally
optionally the sequence number. also the sequence number.
A PLAY_NOTIFY request with Notify-Reason header set to "Scale-Change" A PLAY_NOTIFY request with Notify-Reason header set to "Scale-Change"
MUST NOT carry a message body. MUST NOT carry a message body.
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
Date: Tue, 14 Apr 2008 15:48:06 GMT Date: Tue, 14 Apr 2008 15:48:06 GMT
CSeq: 854 CSeq: 854
Notify-Reason: scale-change Notify-Reason: scale-change
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
Media-Properties: Time-Progressing, Media-Properties: Time-Progressing,
skipping to change at page 77, line 32 skipping to change at page 81, line 40
CSeq: 854 CSeq: 854
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
13.6. PAUSE 13.6. PAUSE
The PAUSE request causes the stream delivery to immediately be The PAUSE request causes the stream delivery to immediately be
interrupted (halted). A PAUSE request MUST be done either with the interrupted (halted). A PAUSE request MUST be done either with the
aggregated control URI for aggregated sessions, resulting in all aggregated control URI for aggregated sessions, resulting in all
media being halted, or the media URI for non-aggregated sessions. media being halted, or the media URI for non-aggregated sessions.
Any attempt to do muting of a single media with an PAUSE request in Any attempt to do muting of a single media with an PAUSE request in
an aggregated session SHALL be responded with error 460 (Only an aggregated session MUST be responded with error 460 (Only
Aggregate Operation Allowed). After resuming playback, Aggregate Operation Allowed). After resuming playback,
synchronization of the tracks MUST be maintained. Any server synchronization of the tracks MUST be maintained. Any server
resources are kept, though servers MAY close the session and free resources are kept, though servers MAY close the session and free
resources after being paused for the duration specified with the resources after being paused for the duration specified with the
timeout parameter of the Session header in the SETUP message. timeout parameter of the Session header in the SETUP message.
Example: Example:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
skipping to change at page 78, line 6 skipping to change at page 82, line 19
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 834 CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Range: npt=45.76- 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 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 MUST be returned to the
client by adding a Range header with what remains unplayed of the client by adding a Range header with what remains unplayed of the
PLAY request's ranges, i.e. including all the remaining ranges part PLAY request's range. For media with random access properties, if
of multiple range specification. For media with random access one desires to resume playing a ranged request, one simply includes
properties If one desires to resume playing a ranged request, one the Range header from the PAUSE response and include the Seek-Style
simply includes the Range header from the PAUSE response. Any play- header with the Next policy in the PLAY request. For media that is
request including symbolic values, such as the NPT timescale's "now" time-progressing and has retention duration=0 the follow-up PLAY
MUST be resolved into the actual stream position where the pause request to start media delivery again, will need to use "npt=now-"
point is. For example a Play request with a range specification of and not the answer in the pause-response.
"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: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=10-30 Range: npt=10-30
Seek-Style: First-Prior
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921, ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=4FAD8726:seq=57654;rtptime=2792482193 ssrc=4FAD8726:seq=57654;rtptime=2792482193
Session: 12345678 Session: 12345678
After 11 seconds, i.e. at 21 seconds into the presentation: After 11 seconds, i.e. at 21 seconds into the presentation:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
skipping to change at page 79, line 34 skipping to change at page 84, line 29
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.7. TEARDOWN 13.7. TEARDOWN
13.7.1. Client to Server
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 MUST 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
done in any state (Ready, and Play). A successful request SHALL done in any state (Ready, and Play). A successful request MUST
result in that media delivery is immediately halted and the session result in that media delivery is immediately halted and the session
state is destroyed. This SHALL be indicated through the lack of a state is destroyed. This MUST be indicated through the lack of a
Session header in the response. Session header in the response.
A TEARDOWN using a media URI in an aggregated session MAY only be A TEARDOWN using a media URI in an aggregated session MAY only be
done in Ready state. Such a request only removes the indicated media done in Ready state. Such a request only removes the indicated media
stream and associated resources from the session. This may result in stream and associated resources from the session. This may result in
that a session returns to non-aggregated control, due to that it only that a session returns to non-aggregated control, due to that it only
contains a single media after the requests completion. A session contains a single media after the requests completion. A session
that will exist after the processing of the TEARDOWN request SHALL in that will exist after the processing of the TEARDOWN request MUST in
the response to that TEARDOWN request contain a Session header. Thus the response to that TEARDOWN request contain a Session header. Thus
the presence of the Session header indicates to the receiver of the the presence of the Session header indicates to the receiver of the
response if the session is still existing or has been removed. response if the session is still existing or has been removed.
Example: Example:
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 892 CSeq: 892
Session: 12345678 Session: 12345678
User-Agent: PhonyClient/1.2 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.2. Server to Client
The server can send TEARDOWN requests in the server to client
direction to indicate that the server has been forced to terminate
the ongoing session. This may happen for several reasons such as,
server maintenance without available backup, or session have been
inactive for extended periods of time. The reason is provided in the
Terminate-Reason header (Section 16.50).
When a RTSP client has maintained a RTSP session that otherwise is
inactive for an extended period of time the server may reclaim the
resources. That is done by issuing a REDIRECT request with the
Terminate-Reason set to "Session-Timeout". This MAY be done when the
client has been inactive in the RTSP session for more than one
Session Timeout period (Section 16.48). However, the server is
RECOMMENDED to not perform this operation until an extended period of
inactivity has passed. The time period is considered extended when
it is 10 times the Session Timeout period. Consideration of the
application of the server and its content should be performed when
configuring what is considered as extended periods of time.
In case the server needs to stop provide service to the established
sessions and their is no server to point at in a REDIRECT request
TEARDOWN shall be used to terminate the session. This method can
also be used when non-recoverable internal errors have happened and
the server has no other option then to terminate the sessions.
The TEARDOWN request is normally done on the session aggregate
control URI and MUST include the following headers; Session and
Terminate-Reason headers. The request only applies to the session
identified in the Session header. The server may include a message
to the client's user with the "user-msg" parameter.
The TEARDOWN request may alternatively be done on the wild card URI *
and without any session header. The scope of such a request is
limited to the next-hop (i.e. the RTSP agent in direct communication
with the server) and applies, as well, to the control connection
between the next-hop RTSP agent and the server. This request
indicates that all sessions and pending requests being managed via
the control connection are terminated. Any intervening proxies
SHOULD do all of the following in the order listed:
1. respond to the TEARDOWN request
2. disconnect the control channel from the requesting server
3. pass the TEARDOWN request to each applicable client (typically
those clients with an active session or an unanswered request)
Note: The proxy is responsible for accepting TEARDOWN responses
from its clients; these responses MUST NOT be passed on to either
the original server or the redirected server.
13.8. GET_PARAMETER 13.8. GET_PARAMETER
The GET_PARAMETER request retrieves the value of any specified The GET_PARAMETER request retrieves the value of any specified
parameter or parameters for a presentation or stream specified in the parameter or parameters for a presentation or stream specified in the
URI. If the Session header is present in a request, the value of a URI. If the Session header is present in a request, the value of a
parameter MUST be retrieved in the specified session context. There parameter MUST be retrieved in the specified session context. There
exist two ways of specifying the parameters to retrive. The first is are two ways of specifying the parameters to be retrieved. The first
by including headers that has been defined such that you can use them is by including headers which have been defined such that you can use
for this purpose. Header for this purpose should allow empty, or them for this purpose. Header for this purpose should allow empty,
stripped value parts to avoid having to specify bogus data when or stripped value parts to avoid having to specify bogus data when
indicating the desire to retrive a value. The succesful completion indicating the desire to retrieve a value. The successful completion
of the request should also be evident from any filled out values in 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 the response. The Media-Range header (Section 16.29) is one such
header. The other is to specify a body (entity) that lists the header. The other is to specify a message body that lists the
parameter(s) that are desirable to retrieve. The Content-Type header parameter(s) that are desirable to retrieve. The Content-Type header
(Section 16.18) is used to specify which format the entity has. (Section 16.18) is used to specify which format the message body has.
The method MAY also be used without a body (entity) or any header The headers that MAY be used for retrieving their current value using
that request parameters for keep-alive purpose. Any request that is GET_PARAMETER are:
o Accept-Ranges
o Media-Range
o Media-Properties
o Range
o RTP-Info
The method MAY also be used without a message body or any header that
request parameters for keep-alive purpose. Any request that is
successful, i.e., a 200 OK response is received, then the keep-alive successful, i.e., a 200 OK response is received, then the keep-alive
timer has been updated. Any non-required header present in such a timer has been updated. Any non-required header present in such a
request may or may not been processed. Normaly the presence of request may or may not been processed. Normally the presence of
filled out values in the header will be indication that the header filled out values in the header will be indication that the header
has been processed. However, for cases when this is difficult to has been processed. However, for cases when this is difficult to
determine, it is recommended to use a feature-tag and the Require determine, it is recommended to use a feature-tag and the Require
header. Due to this reason it is usually easier if any parameters to header. Due to this reason it is usually easier if any parameters to
be retrieved are sent in the body, rather than using any header. be retrieved are sent in the body, rather than using any header.
Parameters specified within the body of the message must all be Parameters specified within the body of the message must all be
understood by the request receiving agent. If one or more parameters understood by the request receiving agent. If one or more parameters
are not understood a 451 (Parameter Not Understood) SHALL be sent are not understood a 451 (Parameter Not Understood) MUST be sent
including a body listing these parameters that wasn't understood. If including a body listing these parameters that wasn't understood. If
all parameters are understood their value is filled in and returned all parameters are understood their value is filled in and returned
in the response message body. 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
skipping to change at page 81, line 32 skipping to change at page 87, line 46
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
13.9. SET_PARAMETER 13.9. SET_PARAMETER
This method requests to set the value of a parameter or a set of This method requests to set the value of a parameter or a set of
parameters for a presentation or stream specified by the URI. The parameters for a presentation or stream specified by the URI. The
method MAY also be used without a body (entity). It is the method MAY also be used without a message body. 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
the Require header. Due to this reason it is RECOMMENDED that any the Require header. Due to this reason it is RECOMMENDED that any
parameters are sent in the body, rather than using any header. parameters are sent in the body, rather than using any header.
A request is RECOMMENDED to only contain a single parameter to allow A request is RECOMMENDED to only contain a single parameter to allow
the client to determine why a particular request failed. If the the client to determine why a particular request failed. If the
request contains several parameters, the server MUST only act on the request contains several parameters, the server MUST only act on the
request if all of the parameters can be set successfully. A server request if all of the parameters can be set successfully. A server
MUST allow a parameter to be set repeatedly to the same value, but it MUST allow a parameter to be set repeatedly to the same value, but it
MAY disallow changing parameter values. If the receiver of the MAY disallow changing parameter values. If the receiver of the
request does not understand or cannot locate a parameter, error 451 request does not understand or cannot locate a parameter, error 451
(Parameter Not Understood) SHALL be used. In the case a parameter is (Parameter Not Understood) MUST be used. In the case a parameter is
not allowed to change, the error code is 458 (Parameter Is Read- not allowed to change, the error code is 458 (Parameter Is Read-
Only). The response body SHALL contain only the parameters that have Only). The response body MUST contain only the parameters that have
errors. Otherwise no body SHALL be returned. errors. Otherwise no body MUST 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 82, line 38 skipping to change at page 89, line 7
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
13.10. REDIRECT 13.10. 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 the
required to connect to another server location to access the resource service provided will be terminated and where a corresponding service
indicated by the Request-URI. The presence of the Session header in can provided instead. This happens for different reasons. One is
a REDIRECT request indicates the scope of the request, and determines that the server is being administrated such that it must stop
the specific semantics of the request. providing service. Thus the client is required to connect to another
server location to access the resource indicated by the Request-URI.
The REDIRECT request SHALL contain a Terminate-Reason header
(Section 16.50) to inform the