draft-ietf-mmusic-rfc2326bis-22.txt   draft-ietf-mmusic-rfc2326bis-23.txt 
MMUSIC Working Group H. Schulzrinne MMUSIC Working Group H. Schulzrinne
Internet-Draft Columbia University Internet-Draft Columbia University
Obsoletes: RFC 2326 A. Rao Obsoletes: 2326 (if approved) A. Rao
(if approved) Cisco Intended status: Standards Track Cisco
Intended status: Standards Track R. Lanphier Expires: September 9, 2010 R. Lanphier
Expires: January 14, 2010
M. Westerlund M. Westerlund
Ericsson AB Ericsson AB
M. Stiemerling (Ed.) M. Stiemerling (Ed.)
NEC NEC
July 13, 2009 March 8, 2010
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-22 draft-ietf-mmusic-rfc2326bis-23
Abstract
This memorandum defines RTSP version 2.0 which obsoletes RTSP version
1.0 which is defined in RFC 2326.
The Real Time Streaming Protocol, or RTSP, is an application-level
protocol for setup and control of the delivery of data with real-time
properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and
video. Sources of data can include both live data feeds and stored
clips. This protocol is intended to control multiple data delivery
sessions, provide a means for choosing delivery channels such as UDP,
multicast UDP and TCP, and provide a means for choosing delivery
mechanisms based upon RTP (RFC 3550).
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
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 January 14, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This memorandum defines RTSP version 2.0 which obsoletes RTSP version described in the BSD License.
1.0 which is defined in RFC 2326.
The Real Time Streaming Protocol, or RTSP, is an application-level This document may contain material from IETF Documents or IETF
protocol for setup and control of the delivery of data with real-time Contributions published or made publicly available before November
properties. RTSP provides an extensible framework to enable 10, 2008. The person(s) controlling the copyright in some of this
controlled, on-demand delivery of real-time data, such as audio and material may not have granted the IETF Trust the right to allow
video. Sources of data can include both live data feeds and stored modifications of such material outside the IETF Standards Process.
clips. This protocol is intended to control multiple data delivery Without obtaining an adequate license from the person(s) controlling
sessions, provide a means for choosing delivery channels such as UDP, the copyright in such materials, this document may not be modified
multicast UDP and TCP, and provide a means for choosing delivery outside the IETF Standards Process, and derivative works of it may
mechanisms based upon RTP (RFC 3550). 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 10
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11
2.1. Content Description . . . . . . . . . . . . . . . . . . 12 2.1. Presentation Description . . . . . . . . . . . . . . . . 11
2.2. Session Establishment . . . . . . . . . . . . . . . . . 13 2.2. Session Establishment . . . . . . . . . . . . . . . . . 12
2.3. Media Delivery Control . . . . . . . . . . . . . . . . . 14 2.3. Media Delivery Control . . . . . . . . . . . . . . . . . 13
2.4. Session Parameter Manipulations . . . . . . . . . . . . 16 2.4. Session Parameter Manipulations . . . . . . . . . . . . 15
2.5. Media Delivery . . . . . . . . . . . . . . . . . . . . . 16 2.5. Media Delivery . . . . . . . . . . . . . . . . . . . . . 15
2.5.1. Media Delivery Manipulations . . . . . . . . . . . . 17 2.5.1. Media Delivery Manipulations . . . . . . . . . . . . 16
2.6. Session Maintenance and Termination . . . . . . . . . . 19 2.6. Session Maintenance and Termination . . . . . . . . . . 18
2.7. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 20 2.7. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 19
3. Document Conventions . . . . . . . . . . . . . . . . . . . . 22 3. Document Conventions . . . . . . . . . . . . . . . . . . . . 21
3.1. Notational Conventions . . . . . . . . . . . . . . . . . 22 3.1. Notational Conventions . . . . . . . . . . . . . . . . . 21
3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 22 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 21
4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 26 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 25
4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 26 4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 25
4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 26 4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 25
4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 28 4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 27
4.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . 28 4.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . 27
4.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 29 4.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 28
4.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . 30 4.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . 29
4.7. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 30 4.7. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 29
4.8. Message Body Tags . . . . . . . . . . . . . . . . . . . 30 4.8. Message Body Tags . . . . . . . . . . . . . . . . . . . 29
4.9. Media Properties . . . . . . . . . . . . . . . . . . . . 31 4.9. Media Properties . . . . . . . . . . . . . . . . . . . . 30
4.9.1. Random Access and Seeking . . . . . . . . . . . . . 32 4.9.1. Random Access and Seeking . . . . . . . . . . . . . 31
4.9.2. Retention . . . . . . . . . . . . . . . . . . . . . 32 4.9.2. Retention . . . . . . . . . . . . . . . . . . . . . 31
4.9.3. Content Modifications . . . . . . . . . . . . . . . 32 4.9.3. Content Modifications . . . . . . . . . . . . . . . 32
4.9.4. Supported Scale Factors . . . . . . . . . . . . . . 33 4.9.4. Supported Scale Factors . . . . . . . . . . . . . . 32
4.9.5. Mapping to the Attributes . . . . . . . . . . . . . 33 4.9.5. Mapping to the Attributes . . . . . . . . . . . . . 32
5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 34 5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 34 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 34
5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 35 5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 35
5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 35 5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 35
5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 36 5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 36
6. General Header Fields . . . . . . . . . . . . . . . . . . . . 37 6. General Header Fields . . . . . . . . . . . . . . . . . . . . 37
7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 38 7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 38
7.2. Request Header Fields . . . . . . . . . . . . . . . . . 40 7.2. Request Header Fields . . . . . . . . . . . . . . . . . 40
8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 42 8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 42 8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 42
8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 42 8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 42
8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 45 8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 45
9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 48 9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 47
9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 48 9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 47
9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 49 9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 48
10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 50 10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.1. Reliability and Acknowledgements . . . . . . . . . . . . 50 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 49
10.2. Using Connections . . . . . . . . . . . . . . . . . . . 51 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 50
10.3. Closing Connections . . . . . . . . . . . . . . . . . . 53 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 52
10.4. Timing Out Connections and RTSP Messages . . . . . . . . 54 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 53
10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 54 10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 53
10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 55 10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 54
11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 56 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 55
12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 58 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 57
13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 59 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 58
13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 60 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 59
13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 61 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 60
13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 63 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 62
13.3.1. Changing Transport Parameters . . . . . . . . . . . 66 13.3.1. Changing Transport Parameters . . . . . . . . . . . 65
13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 67 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 66
13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 67 13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 66
13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 71 13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 71
13.4.3. Updating current PLAY Requests . . . . . . . . . . . 72 13.4.3. Updating current PLAY Requests . . . . . . . . . . . 72
13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 73 13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 73
13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 74 13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 74
13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 74 13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 74
13.4.7. Playing Live with Recording . . . . . . . . . . . . 75 13.4.7. Playing Live with Recording . . . . . . . . . . . . 75
13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 75 13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 75
13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 76 13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 76
13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 77 13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 77
13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 78 13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 78
skipping to change at page 6, line 11 skipping to change at page 5, line 43
15.4.33. 472 Failure to establish secure connection . . . . . 101 15.4.33. 472 Failure to establish secure connection . . . . . 101
15.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 101 15.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 101
15.5.1. 500 Internal Server Error . . . . . . . . . . . . . 101 15.5.1. 500 Internal Server Error . . . . . . . . . . . . . 101
15.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 101 15.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 101
15.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 101 15.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 101
15.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 101 15.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 101
15.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 102 15.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 102
15.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 102 15.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 102
15.5.7. 551 Option not supported . . . . . . . . . . . . . . 102 15.5.7. 551 Option not supported . . . . . . . . . . . . . . 102
16. Header Field Definitions . . . . . . . . . . . . . . . . . . 103 16. Header Field Definitions . . . . . . . . . . . . . . . . . . 103
16.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 112 16.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 113
16.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 113 16.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 113
16.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 113 16.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 114
16.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 114 16.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 115
16.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 115 16.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 116
16.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 116 16.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 116
16.7. Authorization . . . . . . . . . . . . . . . . . . . . . 116 16.7. Authorization . . . . . . . . . . . . . . . . . . . . . 116
16.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 117 16.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 117
16.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 117 16.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 117
16.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 117 16.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 118
16.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 120 16.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 120
16.12. Connection-Credentials . . . . . . . . . . . . . . . . . 120 16.12. Connection-Credentials . . . . . . . . . . . . . . . . . 121
16.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 121 16.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 122
16.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 121 16.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 122
16.15. Content-Language . . . . . . . . . . . . . . . . . . . . 122 16.15. Content-Language . . . . . . . . . . . . . . . . . . . . 123
16.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 123 16.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 123
16.17. Content-Location . . . . . . . . . . . . . . . . . . . . 123 16.17. Content-Location . . . . . . . . . . . . . . . . . . . . 124
16.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 123 16.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 124
16.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 124 16.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 124
16.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 124 16.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 125
16.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 125 16.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 126
16.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 126 16.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 127
16.23. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 126 16.23. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 127
16.24. If-Modified-Since . . . . . . . . . . . . . . . . . . . 127 16.24. If-Modified-Since . . . . . . . . . . . . . . . . . . . 127
16.25. If-None-Match . . . . . . . . . . . . . . . . . . . . . 127 16.25. If-None-Match . . . . . . . . . . . . . . . . . . . . . 128
16.26. Last-Modified . . . . . . . . . . . . . . . . . . . . . 128 16.26. Last-Modified . . . . . . . . . . . . . . . . . . . . . 129
16.27. Location . . . . . . . . . . . . . . . . . . . . . . . . 128 16.27. Location . . . . . . . . . . . . . . . . . . . . . . . . 129
16.28. Media-Properties . . . . . . . . . . . . . . . . . . . . 129 16.28. Media-Properties . . . . . . . . . . . . . . . . . . . . 129
16.29. Media-Range . . . . . . . . . . . . . . . . . . . . . . 131 16.29. Media-Range . . . . . . . . . . . . . . . . . . . . . . 131
16.30. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 131 16.30. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 132
16.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 132 16.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 132
16.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 132 16.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 133
16.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 133 16.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 134
16.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 133 16.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 134
16.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 134 16.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 134
16.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 134 16.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 135
16.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 135 16.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 136
16.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 136 16.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 136
16.39. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 137 16.39. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 138
16.40. Retry-After . . . . . . . . . . . . . . . . . . . . . . 138 16.40. Request-Status . . . . . . . . . . . . . . . . . . . . . 139
16.41. Request-Status . . . . . . . . . . . . . . . . . . . . . 138 16.41. Require . . . . . . . . . . . . . . . . . . . . . . . . 139
16.42. Require . . . . . . . . . . . . . . . . . . . . . . . . 138 16.42. Retry-After . . . . . . . . . . . . . . . . . . . . . . 140
16.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 139 16.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 140
16.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 142 16.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 143
16.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 143 16.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 144
16.46. Server . . . . . . . . . . . . . . . . . . . . . . . . . 144 16.46. Server . . . . . . . . . . . . . . . . . . . . . . . . . 145
16.47. Session . . . . . . . . . . . . . . . . . . . . . . . . 144 16.47. Session . . . . . . . . . . . . . . . . . . . . . . . . 146
16.48. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 145 16.48. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 147
16.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 146 16.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 148
16.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 147 16.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 148
16.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 147 16.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 149
16.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 147 16.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 149
16.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 154 16.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 156
16.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 154 16.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 156
16.55. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 155 16.55. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 157
16.56. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 156 16.56. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 157
16.57. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 156 16.57. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 158
17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
17.1. Proxies and Protocol Extensions . . . . . . . . . . . . 158
18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
18.1. Validation Model (HTTP) . . . . . . . . . . . . . . . . 161
18.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 162
18.1.2. Message Body Tag Cache Validators . . . . . . . . . 162
18.1.3. Weak and Strong Validators . . . . . . . . . . . . . 162
18.1.4. Rules for When to Use Entity Tags and
Last-Modified Dates . . . . . . . . . . . . . . . . 165
18.1.5. Non-validating Conditionals . . . . . . . . . . . . 166
18.2. Invalidation After Updates or Deletions (HTTP) . . . . . 166
19. Security Framework . . . . . . . . . . . . . . . . . . . . . 168
19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 168
19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 168
19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 169
19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 170
19.3.2. User approved TLS procedure . . . . . . . . . . . . 171
20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 173
20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 175
20.2.1. Generic Protocol elements . . . . . . . . . . . . . 175
20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 178
20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 182
20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 191
21. Security Considerations . . . . . . . . . . . . . . . . . . . 192
21.1. Remote denial of Service Attack . . . . . . . . . . . . 194
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 196
22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 196
22.1.1. Description . . . . . . . . . . . . . . . . . . . . 196
22.1.2. Registering New Feature-tags with IANA . . . . . . . 197
22.1.3. Registered entries . . . . . . . . . . . . . . . . . 197
22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 197
22.2.1. Description . . . . . . . . . . . . . . . . . . . . 197
22.2.2. Registering New Methods with IANA . . . . . . . . . 197
22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 198
22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 198
22.3.1. Description . . . . . . . . . . . . . . . . . . . . 198
22.3.2. Registering New Status Codes with IANA . . . . . . . 198
22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 198
22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 198
22.4.1. Description . . . . . . . . . . . . . . . . . . . . 198
22.4.2. Registering New Headers with IANA . . . . . . . . . 199
22.4.3. Registered entries . . . . . . . . . . . . . . . . . 199
22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 200
22.5.1. Accept-Credentials policies . . . . . . . . . . . . 200
22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 200
22.6. Cache-Control Cache Directive Extensions . . . . . . . 201
22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 202
22.7.1. Description . . . . . . . . . . . . . . . . . . . . 202
22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 202
22.7.3. Registered Values . . . . . . . . . . . . . . . . . 202
22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 202
22.8.1. Description . . . . . . . . . . . . . . . . . . . . 202
22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 203
22.8.3. Registered Values . . . . . . . . . . . . . . . . . 203
22.9. Range header formats . . . . . . . . . . . . . . . . . . 203
22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 204
22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 204
22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 204
22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 204
22.11.1. Description . . . . . . . . . . . . . . . . . . . . 204
22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 204
22.11.3. Registered Values . . . . . . . . . . . . . . . . . 205
22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 205
22.12.1. Description . . . . . . . . . . . . . . . . . . . . 205
22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 205
22.12.3. Registered Values . . . . . . . . . . . . . . . . . 205
22.13. Transport Header Registries . . . . . . . . . . . . . . 206
22.13.1. Transport Protocol Specification . . . . . . . . . . 206
22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 207
22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 207
22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 208
22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 208
22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 209
22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 210
22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 211
22.16. Media Type Registration for text/parameters . . . . . . 211
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 213
23.1. Normative References . . . . . . . . . . . . . . . . . . 213
23.2. Informative References . . . . . . . . . . . . . . . . . 215
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 217 17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 217 17.1. Proxies and Protocol Extensions . . . . . . . . . . . . 160
A.2. Media on Demand using Pipelining . . . . . . . . . . . . 220 17.2. Multiplexing and Demultiplexing of Messages . . . . . . 161
A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 223 18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
A.4. Single Stream Container Files . . . . . . . . . . . . . 227 18.1. Validation Model . . . . . . . . . . . . . . . . . . . . 162
A.5. Live Media Presentation Using Multicast . . . . . . . . 229 18.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 164
A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 230 18.1.2. Message Body Tag Cache Validators . . . . . . . . . 164
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 232 18.1.3. Weak and Strong Validators . . . . . . . . . . . . . 164
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 232 18.1.4. Rules for When to Use Message Body Tags and
B.2. State variables . . . . . . . . . . . . . . . . . . . . 232 Last-Modified Dates . . . . . . . . . . . . . . . . 166
B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 232 18.1.5. Non-validating Conditionals . . . . . . . . . . . . 168
B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 233 18.2. Invalidation After Updates or Deletions . . . . . . . . 168
Appendix C. Media Transport Alternatives . . . . . . . . . . . . 238 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 170
C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 238 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 170
C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 238 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 170
C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 238 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 171
C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 239 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 172
C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 240 19.3.2. User approved TLS procedure . . . . . . . . . . . . 173
C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 240 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 240 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 176
C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 241 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 178
C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 242 20.2.1. Generic Protocol elements . . . . . . . . . . . . . 178
C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 242 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 181
C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 246 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 185
C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 250 20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 194
C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 252 21. Security Considerations . . . . . . . . . . . . . . . . . . . 195
C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 252 21.1. Remote denial of Service Attack . . . . . . . . . . . . 197
C.7. Maintaining NPT synchronization with RTP timestamps . . 252 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 199
C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 252 22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 199
C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 252 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 199
22.1.2. Registering New Feature-tags with IANA . . . . . . . 200
22.1.3. Registered entries . . . . . . . . . . . . . . . . . 200
22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 200
22.2.1. Description . . . . . . . . . . . . . . . . . . . . 200
22.2.2. Registering New Methods with IANA . . . . . . . . . 201
22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 201
22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 201
22.3.1. Description . . . . . . . . . . . . . . . . . . . . 201
22.3.2. Registering New Status Codes with IANA . . . . . . . 202
22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 202
22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 202
22.4.1. Description . . . . . . . . . . . . . . . . . . . . 202
22.4.2. Registering New Headers with IANA . . . . . . . . . 202
22.4.3. Registered entries . . . . . . . . . . . . . . . . . 203
22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 203
22.5.1. Accept-Credentials policies . . . . . . . . . . . . 203
22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 204
22.6. Cache-Control Cache Directive Extensions . . . . . . . . 204
22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 205
22.7.1. Description . . . . . . . . . . . . . . . . . . . . 205
22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 205
22.7.3. Registered Values . . . . . . . . . . . . . . . . . 206
22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 206
22.8.1. Description . . . . . . . . . . . . . . . . . . . . 206
22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 206
22.8.3. Registered Values . . . . . . . . . . . . . . . . . 207
22.9. Range header formats . . . . . . . . . . . . . . . . . . 207
22.9.1. Description . . . . . . . . . . . . . . . . . . . . 207
22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 207
22.9.3. Registered Values . . . . . . . . . . . . . . . . . 207
22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 208
22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 208
22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 208
22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 208
22.11.1. Description . . . . . . . . . . . . . . . . . . . . 208
22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 209
22.11.3. Registered Values . . . . . . . . . . . . . . . . . 209
22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 209
22.12.1. Description . . . . . . . . . . . . . . . . . . . . 209
22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 209
22.12.3. Registered Values . . . . . . . . . . . . . . . . . 210
22.13. Transport Header Registries . . . . . . . . . . . . . . 210
22.13.1. Transport Protocol Specification . . . . . . . . . . 210
22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 211
22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 212
22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 212
22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 212
22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 213
22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 214
22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 215
22.16. Media Type Registration for text/parameters . . . . . . 216
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 218
23.1. Normative References . . . . . . . . . . . . . . . . . . 218
23.2. Informative References . . . . . . . . . . . . . . . . . 220
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 223
A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 223
A.2. Media on Demand using Pipelining . . . . . . . . . . . . 227
A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 229
A.4. Single Stream Container Files . . . . . . . . . . . . . 233
A.5. Live Media Presentation Using Multicast . . . . . . . . 235
A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 236
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 238
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 238
B.2. State variables . . . . . . . . . . . . . . . . . . . . 238
B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 238
B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 239
Appendix C. Media Transport Alternatives . . . . . . . . . . . . 245
C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 245
C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 245
C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 245
C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 246
C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 247
C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 247
C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 247
C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 248
C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 249
C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 249
C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 253
C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 257
C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 259
C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 259
C.7. Maintaining NPT synchronization with RTP timestamps . . 259
C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 259
C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 259
C.10. Usage of SSRCs and the RTCP BYE Message During an C.10. Usage of SSRCs and the RTCP BYE Message During an
RTSP Session . . . . . . . . . . . . . . . . . . . . . . 252 RTSP Session . . . . . . . . . . . . . . . . . . . . . . 259
C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 253 C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 260
Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 254 Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 261
D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 254 D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 261
D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 254 D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 261
D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 255 D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 262
D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 256 D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 263
D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 256 D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 263
D.1.5. Directionality of media stream . . . . . . . . . . . 256 D.1.5. Directionality of media stream . . . . . . . . . . . 263
D.1.6. Range of Presentation . . . . . . . . . . . . . . . 257 D.1.6. Range of Presentation . . . . . . . . . . . . . . . 264
D.1.7. Time of Availability . . . . . . . . . . . . . . . . 258 D.1.7. Time of Availability . . . . . . . . . . . . . . . . 265
D.1.8. Connection Information . . . . . . . . . . . . . . . 258 D.1.8. Connection Information . . . . . . . . . . . . . . . 265
D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 258 D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 265
D.2. Aggregate Control Not Available . . . . . . . . . . . . 259 D.2. Aggregate Control Not Available . . . . . . . . . . . . 266
D.3. Aggregate Control Available . . . . . . . . . . . . . . 259 D.3. Aggregate Control Available . . . . . . . . . . . . . . 266
D.4. RTSP external SDP delivery . . . . . . . . . . . . . . . 260 D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 267
Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 262 D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 268
E.1. On-demand Playback of Stored Content . . . . . . . . . . 262 Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 269
E.2. Unicast Distribution of Live Content . . . . . . . . . . 263 E.1. On-demand Playback of Stored Content . . . . . . . . . . 269
E.3. On-demand Playback using Multicast . . . . . . . . . . . 264 E.2. Unicast Distribution of Live Content . . . . . . . . . . 270
E.4. Inviting an RTSP server into a conference . . . . . . . 264 E.3. On-demand Playback using Multicast . . . . . . . . . . . 271
E.5. Live Content using Multicast . . . . . . . . . . . . . . 265 E.4. Inviting an RTSP server into a conference . . . . . . . 271
Appendix F. Text format for Parameters . . . . . . . . . . . . . 267 E.5. Live Content using Multicast . . . . . . . . . . . . . . 272
Appendix G. Requirements for Unreliable Transport of RTSP . . . 268 Appendix F. Text format for Parameters . . . . . . . . . . . . . 274
Appendix H. Backwards Compatibility Considerations . . . . . . . 270 Appendix G. Requirements for Unreliable Transport of RTSP . . . 275
H.1. Play Request in Play mode . . . . . . . . . . . . . . . 270 Appendix H. Backwards Compatibility Considerations . . . . . . . 277
H.2. Using Persistent Connections . . . . . . . . . . . . . . 270 H.1. Play Request in Play mode . . . . . . . . . . . . . . . 277
Appendix I. Open Issues . . . . . . . . . . . . . . . . . . . . 271 H.2. Using Persistent Connections . . . . . . . . . . . . . . 277
Appendix J. Changes . . . . . . . . . . . . . . . . . . . . . . 272 Appendix I. Open Issues . . . . . . . . . . . . . . . . . . . . 278
Appendix K. Acknowledgements . . . . . . . . . . . . . . . . . . 279 Appendix J. Changes . . . . . . . . . . . . . . . . . . . . . . 279
K.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 279 J.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 279
Appendix L. RFC Editor Consideration . . . . . . . . . . . . . . 281 J.2. Detailed List of Changes . . . . . . . . . . . . . . . . 280
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 282 Appendix K. Acknowledgements . . . . . . . . . . . . . . . . . . 287
K.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 287
Appendix L. RFC Editor Consideration . . . . . . . . . . . . . . 289
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 290
1. Introduction 1. Introduction
This memo defines version 2.0 of the Real Time Streaming Protocol This memo defines version 2.0 of the Real Time Streaming Protocol
(RTSP 2.0). RTSP 2.0 is an application-level protocol for setup and (RTSP 2.0). RTSP 2.0 is an application-level protocol for setup and
control over the delivery of data with real-time properties, control over the delivery of data with real-time properties,
typically streaming media. Streaming media is, for instance, video typically streaming media. Streaming media is, for instance, video
on demand or audio live streaming. Put simply, RTSP acts as a on demand or audio live streaming. Put simply, RTSP acts as a
"network remote control" for multimedia servers, as you know it from "network remote control" for multimedia servers, as you know it from
your TV set. your TV set.
skipping to change at page 11, line 44 skipping to change at page 11, line 44
state; changed behavior of the extensibility model and its mechanism; state; changed behavior of the extensibility model and its mechanism;
the change of syntax for some headers. The summary is that there are the change of syntax for some headers. The summary is that there are
so many small details that changing version become necessary to so many small details that changing version become necessary to
enable clarification and consistent behavior. enable clarification and consistent behavior.
This document is structured in the way that it begins with an This document is structured in the way that it begins with an
overview of the protocol operations and its functions in an informal overview of the protocol operations and its functions in an informal
way. Then a set of definitions of used terms and document way. Then a set of definitions of used terms and document
conventions is introduced. Then comes the actual protocol conventions is introduced. Then comes the actual protocol
specification. In the appendix some functionality that isn't core specification. In the appendix some functionality that isn't core
RTSP defined, but still important to enable some usage, like RTP and RTSP defined, but still important to enable some usage, like RTP
SDP usage with RTSP. This is followed by a number of informational Appendix C and SDP usage with RTSP Appendix D, making these two
appendixes mandatory. This is followed by a number of informational
parts discussing the changes, use cases, different considerations or parts discussing the changes, use cases, different considerations or
motivations. motivations.
2. Protocol Overview 2. Protocol Overview
This section provides a informative overview of the different This section provides a informative overview of the different
mechanisms in the RTSP 2.0 protocol, to give the reader a high level mechanisms in the RTSP 2.0 protocol, to give the reader a high level
understanding before getting into all the different details. In case understanding before getting into all the different details. In case
of conflict with this description and the later sections, the later of conflict with this description and the later sections, the later
sections take precedence. For more information about considered use sections take precedence. For more information about considered use
skipping to change at page 12, line 37 skipping to change at page 12, line 37
RTSP headers. This part is ended by two consecutive carriage return RTSP headers. This part is ended by two consecutive carriage return
line feed (CRLF) character pairs. The message body if present line feed (CRLF) character pairs. The message body if present
follows the two CRLF and the bodies length are described by a message follows the two CRLF and the bodies length are described by a message
header. RTSP responses are similar, but start with a response line header. RTSP responses are similar, but start with a response line
with protocol and version, followed by a status code and a reason with protocol and version, followed by a status code and a reason
phrase. RTSP messages are sent over a reliable transport protocol phrase. RTSP messages are sent over a reliable transport protocol
between the client and server. RTSP 2.0 requires clients and servers between the client and server. RTSP 2.0 requires clients and servers
to implement TCP, and TLS over TCP, as mandatory transports for RTSP to implement TCP, and TLS over TCP, as mandatory transports for RTSP
messages. messages.
2.1. Content Description 2.1. Presentation Description
RTSP exists to provide access to multi-media content, but tries to be RTSP exists to provide access to multi-media presentations and
agnostic to the media type or the actual media delivery protocol that content, but tries to be agnostic to the media type or the actual
is used. To enable a client to implement a complete system, an RTSP- media delivery protocol that is used. To enable a client to
external mechanism for describing the content and the delivery implement a complete system, an RTSP-external mechanism for
protocol(s) is used. RTSP assumes that this description is either describing the presentation and the delivery protocol(s) is used.
delivered completely out of bands or as a data object in the response RTSP assumes that this description is either delivered completely out
to a client's request using the DESCRIBE method (Section 13.2). of bands or as a data object in the response to a client's request
using the DESCRIBE method (Section 13.2).
Parameters that commonly have to be included in the Content Parameters that commonly have to be included in the Content
Description are the following: Description are the following:
o Number of media streams o Number of media streams
o The resource identifier for each media stream/resource that is to o The resource identifier for each media stream/resource that is to
be controlled by RTSP be controlled by RTSP
o The protocol that each media stream is to be delivered over o The protocol that each media stream is to be delivered over
skipping to change at page 13, line 26 skipping to change at page 13, line 26
RTSP uses its own URI schemes ("rtsp" and "rtsps") to reference media RTSP uses its own URI schemes ("rtsp" and "rtsps") to reference media
resources and aggregates under common control. resources and aggregates under common control.
This specification describes in Appendix D how one uses SDP [RFC4566] This specification describes in Appendix D how one uses SDP [RFC4566]
for Content Description for Content Description
2.2. Session Establishment 2.2. Session Establishment
The RTSP client can request the establishment of an RTSP session The RTSP client can request the establishment of an RTSP session
after having used the content description to determine which media after having used the presentation description to determine which
streams are available, and also which media delivery protocol is used media streams are available, and also which media delivery protocol
and their particular resource identifiers. The RTSP session is a is used and their particular resource identifiers. The RTSP session
common context between the client and the server that consist of one is a common context between the client and the server that consist of
or more media resource that is to be under common media delivery one or more media resource that is to be under common media delivery
control. control.
The client creates an RTSP session by sending an request using the 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 SETUP method (Section 13.3) to the server. In the SETUP request the
client also includes all the transport parameter necessary to enable client also includes all the transport parameter necessary to enable
the media delivery protocol to function in the "Transport" header the media delivery protocol to function in the "Transport" header
(Section 16.52). This includes parameters that are pre-established (Section 16.52). This includes parameters that are pre-established
by the content description but necessary for any middlebox to by the presentation description but necessary for any middlebox to
correctly handle the media delivery protocols. The Transport header correctly handle the media delivery protocols. The Transport header
in a request may contain multiple alternatives for media delivery in in a request may contain multiple alternatives for media delivery in
a prioritized list, which the server can select from. These a prioritized list, which the server can select from. These
alternatives are typically based on information in the content alternatives are typically based on information in the content
description. description.
The server determines if the media resource is available upon The server determines if the media resource is available upon
receiving a SETUP request and if any of the transport parameter receiving a SETUP request and if any of the transport parameter
specifications are acceptable. If that is successful, an RTSP specifications are acceptable. If that is successful, an RTSP
session context is created and the relevant parameters and state is session context is created and the relevant parameters and state is
skipping to change at page 15, line 35 skipping to change at page 15, line 35
requested point and indicate that in its PLAY response. If 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 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 which the server stopped will be reported back in the response. The
client can later resume by a PLAY request without a range header. client can later resume by a PLAY request without a range header.
When the server is about to completed the PLAY request by delivering 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 the end of the content or the requested range the server will send a
PLAY_NOTIFY request indicating this. PLAY_NOTIFY request indicating this.
When playing live content with no extra functions, such as recording, When playing live content with no extra functions, such as recording,
the client will receive the live media from the server after having the client will receive the live media from the server after having
sent a PLAY request. Seeking in such content is not working as the sent a PLAY request. Seeking in such content is not possible as the
server does not store it, but only forwards it from the source of 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 session. Thus delivery continues until the client sends a PAUSE
request, tears down the session, or the content ends. request, tears down the session, or the content ends.
For live sessions that are being recorded the client will need to For live sessions that are being recorded the client will need to
keep track of how the recording progresses. Upon session keep track of how the recording progresses. Upon session
establishment the client will learn the current duration of the establishment the client will learn the current duration of the
recording from the Media-Range header. As the recording is ongoing recording from the Media-Range header. As the recording is ongoing
the content grows in direct relation to the passed time. Therefore, the content grows in direct relation to the passed time. Therefore,
each server's response to a PLAY request will contain the current each server's response to a PLAY request will contain the current
skipping to change at page 24, line 12 skipping to change at page 24, line 12
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. A message is either a Request or a Response. transport. A message is either a Request or a Response.
Message Body: The information transferred as the payload of a Message Body: The information transferred as the payload of a
message (Request and response). A message body consists of meta- message (Request and response). A message body consists of meta-
information in the form of message-header and content in the form information in the form of message-headers and content in the form
of an message-body, as described in Section 9. of an message-body, as described in Section 9.
Non-Aggregated Control: Control of a single media stream. Non-Aggregated Control: Control of a single media stream.
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
skipping to change at page 24, line 47 skipping to change at page 24, line 47
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 common context; it
is created, maintained and destroyed by the server. It is is created, maintained and destroyed on client's request. 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 labeled with
with a session identifier at that time. The session exists until a session identifier at that time. The session exists until timed
timed out by the server or explicitly removed by a TEARDOWN out by the server or explicitly removed by a TEARDOWN request. An
request. An RTSP session is a stateful entity; an RTSP server RTSP session is a stateful entity; an RTSP server maintains an
maintains an explicit session state machine (see Appendix A) where explicit session state machine (see Appendix A) where most state
most state transitions are triggered by client requests. The transitions are triggered by client requests. The existence of a
existence of a session implies the existence of state about the session implies the existence of state about the session's media
session's media streams and their respective transport mechanisms. streams and their respective transport mechanisms. A given
A given session can have one or more media streams associated with session can have one or more media streams associated with it. An
it. An RTSP server uses the session to aggregate control over RTSP server uses the session to aggregate control over multiple
multiple media streams. media streams.
Origin Server: The server on which a given resource resides.
Transport initialization: The negotiation of transport information Transport initialization: The negotiation of transport information
(e.g., port numbers, transport protocols) between the client and (e.g., port numbers, transport protocols) between the client and
the server. the server.
URI: Universal Resource Identifier, see [RFC3986]. The URIs used in URI: Universal Resource Identifier, see [RFC3986]. The URIs used in
RTSP are generally URLs as they give a location for the resource. RTSP are generally URLs as they give a location for the resource.
As URLs are a subset of URIs, they will be referred to as URIs to As URLs are a subset of URIs, they will be referred to as URIs to
cover also the cases when an RTSP URI would not be an URL. cover also the cases when an RTSP URI would not be an URL.
skipping to change at page 26, line 36 skipping to change at page 26, line 36
and minor numbers MUST be treated as separate integers and that each and minor numbers MUST be treated as separate integers and that each
MAY be incremented higher than a single digit. Thus, RTSP/2.4 is a MAY be incremented higher than a single digit. Thus, RTSP/2.4 is a
lower version than RTSP/2.13, which in turn is lower than RTSP/12.3. lower version than RTSP/2.13, which in turn is lower than RTSP/12.3.
Leading zeros MUST be ignored by recipients and MUST NOT be sent. Leading zeros 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 schemes "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 unspecified
transport of the RTSP messages over unreliable transport (UDP). The transport of the RTSP messages over unreliable transport (UDP in RTSP
syntax of "rtsp" and "rtsps" URIs has been changed from RTSP 1.0. 1.0). The details of the 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 MUST 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
skipping to change at page 28, line 34 skipping to change at page 28, line 40
scheme in the URI. scheme in the URI.
4.3. Session Identifiers 4.3. Session Identifiers
Session identifiers are strings of length 8-128 characters. A Session identifiers are strings of length 8-128 characters. A
session identifier MUST be chosen cryptographically random (see session identifier MUST be chosen cryptographically random (see
[RFC4086]) . It is RECOMMENDED that it contains 128 bits of entropy, [RFC4086]) . It is RECOMMENDED that it contains 128 bits of entropy,
i.e. approximately 22 characters from a high quality generator. (see i.e. approximately 22 characters from a high quality generator. (see
Section 21.) However, note that the session identifier does not Section 21.) However, note that the session identifier does not
provide any security against session hijacking unless it is kept provide any security against session hijacking unless it is kept
confidential between client, server and trusted proxies. confidential by the client, server and trusted proxies.
4.4. SMPTE Relative Timestamps 4.4. SMPTE Relative Timestamps
A SMPTE relative timestamp expresses time relative to the start of A SMPTE relative timestamp expresses time relative to the start of
the clip. Relative timestamps are expressed as SMPTE time codes for the clip. Relative timestamps are expressed as SMPTE time codes for
frame-level access accuracy. The time code has the format frame-level access accuracy. The time code has the format
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
skipping to change at page 30, line 10 skipping to change at page 30, line 16
notation for consumption by human readers. The "now" constant notation for consumption by human readers. The "now" constant
allows clients to request to receive the live feed rather than the allows clients to request to receive the live feed rather than the
stored or time-delayed version. This is needed since neither stored or time-delayed version. This is needed since neither
absolute time nor zero time are appropriate for this case. absolute time nor zero time are appropriate for this case.
4.6. Absolute Time 4.6. Absolute Time
Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps, Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps,
using UTC (GMT). Fractions of a second may be indicated. using UTC (GMT). Fractions of a second may be indicated.
Example for November 8, 1996 at 14h37 and 20 and a quarter seconds Example for November 8, 1996 at 14h 37 min and 20 and a quarter
UTC: seconds UTC:
19961108T143720.25Z 19961108T143720.25Z
4.7. Feature-Tags 4.7. Feature-Tags
Feature-tags are unique identifiers used to designate features in Feature-tags are unique identifiers used to designate features in
RTSP. These tags are used in Require (Section 16.42), Proxy-Require RTSP. These tags are used in Require (Section 16.41), Proxy-Require
(Section 16.35), Proxy-Supported (Section 16.36), and Unsupported (Section 16.35), Proxy-Supported (Section 16.36), and Unsupported
(Section 16.53) 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
skipping to change at page 30, line 52 skipping to change at page 31, line 10
A message body tag MUST be unique across all versions of all message A message body tag MUST be unique across all versions of all message
bodies associated with a particular resource. A given message body bodies associated with a particular resource. A given message body
tag value MAY be used for message body obtained by requests on tag value MAY be used for message body obtained by requests on
different URIs. The use of the same message body tag value in different URIs. The use of the same message body tag value in
conjunction with message bodies obtained by requests on different conjunction with message bodies obtained by requests on different
URIs does not imply the equivalence of those message bodies URIs does not imply the equivalence of those message bodies
Message body tags are used in RTSP to make some methods conditional. Message body tags are used in RTSP to make some methods conditional.
The methods are made conditional through the inclusion of headers, The methods are made conditional through the inclusion of headers,
see Section 16.23 and Section 16.25. Note that RTSP message body see "If-Match" (Section 16.23) and "If-None-Match" (Section 16.25).
tags apply to the complete presentation; i.e., both the session Note that RTSP message body tags apply to the complete presentation;
description and the individual media streams. Thus message body tags i.e., both the presentation description and the individual media
can be used to verify at setup time after a redirect that the same streams. Thus message body tags can be used to verify at setup time
session description applies to the media at the new location using after a redirect that the same session description applies to the
the If-Match header. media at the new location using the If-Match header.
4.9. Media Properties 4.9. Media Properties
When an RTSP server handles media, it is important to consider the When an RTSP server handles media, it is important to consider the
different properties a media instance for delivery and playback can different properties a media instance for delivery and playback can
have. This specification considers the below listed media properties have. This specification considers the below listed media properties
in its protocol operations. They are derived from the differences in its protocol operations. They are derived from the differences
between a number of supported usages. between a number of supported usages.
On-demand: Media that has a fixed (given) duration that doesn't On-demand: Media that has a fixed (given) duration that doesn't
change during the life time of the RTSP session and is known at change during the life time of the RTSP session and is known at
the time of the creation of the session. It is expected that the the time of the creation of the session. It is expected that the
content of the media will not change, even if the representation, content of the media will not change, even if the representation,
i.e encoding, quality, etc, may change. Generally one can seek, i.e encoding, quality, etc, may change. Generally one can seek,
i.e. request any range, within the media. i.e. request any range, within the media.
Dynamic On-demand: This is a variation of the on-demand case where Dynamic On-demand: This is a variation of the on-demand case where
external methods are used to manipulate the actual content of the external methods are used to manipulate the actual content of the
media setup for the RTSP session. The main example is a content media setup for the RTSP session. The main example is a content
defined by a playlist-specified. defined by a playlist.
Live: Live media represents a progressing content stream (such as Live: Live media represents a progressing content stream (such as
broadcast TV) where the duration may or may not be known. It is broadcast TV) where the duration may or may not be known. It is
not seekable, only the content presently being delivered can be not seekable, only the content presently being delivered can be
accessed. accessed.
Live with Recording: A Live stream that is combined with a server Live with Recording: A Live stream that is combined with a server
side capability to store and retain the content of the live side capability to store and retain the content of the live
session for random access delivery within the part of the already session for random access delivery within the part of the already
recorded content. The actual behavior of the media stream is very recorded content. The actual behavior of the media stream is very
skipping to change at page 32, line 9 skipping to change at page 32, line 14
forwards while data is made available and content that is older forwards while data is made available and content that is older
than a limit will be discarded. than a limit will be discarded.
To cover the above usages, the following media properties with To cover the above usages, the following media properties with
appropriate values are specified: appropriate values are specified:
4.9.1. Random Access and Seeking 4.9.1. Random Access and Seeking
Random Access is about the possibility to specify and get media Random Access is about the possibility to specify and get media
delivered from any point inside the content, an operation called delivered from any point inside the content, an operation called
seeking. This possiblity is signalled using Seek-Style which can seeking. This possibility is signaled using Seek-Style which can
take the following different values: take the following different values:
Random Access: The media are seekable to any out of a large number Random Access: The media are seekable to any out of a large number
of points within the media. Due to media encoding limitations, a of points within the media. Due to media encoding limitations, a
particular point may not be reachable, but seeking to a point particular point may not be reachable, but seeking to a point
close by is enabled. A floating point number of seconds may be close by is enabled. A floating point number of seconds may be
provided to express the worst case distance between random access provided to express the worst case distance between random access
points. points.
Conditional Random Access: Based on the above Random Access but
intended to handle a case where the distance in the media between
random access points are large and where small seek forward using
Random Access would move the client further away then the current
point.
Return To Start: Seeking is only possible to beginning of the Return To Start: Seeking is only possible to beginning of the
content. content.
No seeking: Seeking is not possible at all. No seeking: Seeking is not possible at all.
4.9.2. Retention 4.9.2. Retention
Media may have different retention policy in place that affect the Media may have different retention policy in place that affect the
operation on the media. The following different media retention operation on the media. The following different media retention
policies are envisioned and taken into consideration where policies are envisioned and taken into consideration where
skipping to change at page 34, line 8 skipping to change at page 35, line 8
Live: Random Access: No seeking, Content Modifications: Time Live: Random Access: No seeking, Content Modifications: Time
Progressing, Retention: Duration limited=0.0s Progressing, Retention: Duration limited=0.0s
Live with Recording: Random Access: Random Access=3s, Content Live with Recording: Random Access: Random Access=3s, Content
Modifications: Time Progressing, Retention: Duration limited=2H 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 MUST 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
skipping to change at page 34, line 33 skipping to change at page 35, line 32
represented as 1100001x 10xxxxxx. (See RFC 3629 [RFC3629]) represented as 1100001x 10xxxxxx. (See RFC 3629 [RFC3629])
Requests contain methods, the object the method is operating upon and Requests contain methods, the object the method is operating upon and
parameters to further describe the method. Methods are idempotent parameters to further describe the method. Methods are idempotent
unless otherwise noted. Methods are also designed to require little unless otherwise noted. Methods are also designed to require little
or no state maintenance at the media server. or no state maintenance at the media server.
5.1. Message Types 5.1. Message Types
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 ( client, and responses in the reverse direction. Request Section 7
(Section 7) ) and Response (Section 8) messages uses a format based and Response Section 8 messages uses a format based on the generic
on the generic message format of RFC 0822 [RFC0822] for transferring message format of RFC 0822 [RFC0822] for transferring bodies (the
bodies (the payload of the message). Both types of message consist payload of the message). Both types of message consist of a start-
of a start-line, zero or more header fields (also known as line, zero or more header fields (also known as "headers"), an empty
"headers"), an empty line (i.e., a line with nothing preceding the line (i.e., a line with nothing preceding the CRLF) indicating the
CRLF) indicating the end of the header, and possibly the data of the end of the header, and possibly the data of the message-body.
message-body.
generic-message = start-line generic-message = start-line
*(message-header CRLF) *(message-header CRLF)
CRLF CRLF
[ message-body-data ] [ message-body-data ]
start-line = Request-Line | Status-Line start-line = Request-Line | Status-Line
In the interest of robustness, servers SHOULD ignore any empty In the interest of robustness, servers MUST ignore any empty line(s)
line(s) received where a Request-Line is expected. In other words, received where a Request-Line is expected. In other words, if the
if the server is reading the protocol stream at the beginning of a server is reading the protocol stream at the beginning of a message
message and receives a CRLF first, it should ignore the CRLF. and receives a CRLF first, it should ignore the CRLF.
5.2. Message Headers 5.2. Message Headers
RTSP header fields (see Section 16) include general-header, request- RTSP header fields (see Section 16) include general-header, request-
header, response-header, and entity-header fields. header, response-header, and Message-body header fields.
The order in which header fields with differing field names are The order in which header fields with differing field names are
received is not significant. However, it is "good practice" to send received is not significant. However, it is "good practice" to send
general-header fields first, followed by request-header or response- general-header fields first, followed by request-header or response-
header fields, and ending with the entity-header fields. header fields, and ending with the Message-body header fields.
Multiple message-header fields with the same field-name MAY be 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 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)]. header field is defined as a comma-separated list. It MUST be
It MUST be possible to combine the multiple header fields into one possible to combine the multiple header fields into one "field-name:
"field-name: field-value" pair, without changing the semantics of the field-value" pair, without changing the semantics of the message, by
message, by appending each subsequent field-value to the first, each appending each subsequent field-value to the first, each separated by
separated by a comma. The order in which header fields with the same a comma. The order in which header fields with the same field-name
field-name are received is therefore significant to the are received is therefore significant to the interpretation of the
interpretation of the combined field value, and thus a proxy MUST NOT combined field value, and thus a proxy MUST NOT change the order of
change the order of these field values when a message is forwarded. these field values when a message is forwarded.
Unknown message headers MUST be ignored by a RTSP server or client. Unknown message headers MUST be ignored (skipping over the header to
An RTSP Proxy MUST forward unknown message headers. Message headers the next protocol element, and not causing an error) by a RTSP server
defined outside of this specification that are required to be or client. An RTSP Proxy MUST forward unknown message headers.
interpret by the RTSP agent will need to use feature tags Message headers defined outside of this specification that are
(Section 4.7) and include it in the appropriate Require required to be interpret by the RTSP agent will need to use feature
(Section 16.42) or Proxy-Require (Section 16.35) header. tags (Section 4.7) and include it in the appropriate Require
(Section 16.41) or Proxy-Require (Section 16.35) header.
5.3. Message Body 5.3. Message Body
The message-body (if any) of an RTSP message is used to carry further The message-body (if any) of an RTSP message is used to carry further
information for a particular resource associated with the request or information for a particular resource associated with the request or
response. An example for a message body is the Session Description response. An example for a message body is the Session Description
Protocol (SDP). Protocol (SDP).
The presence of a message-body in either a request or a response MUST The presence of a message-body in either a request or a response MUST
be signaled by the inclusion of a Content-Length header (see be signaled by the inclusion of a Content-Length header (see
Section 16.16). Section 16.16).
The presence of a message-body in a request is signaled by the 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 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 message-body MUST NOT be included in a request or response if the
specification of the particular method (see Method Definitions specification of the particular method (see Method Definitions
(Section 13)) does not allow sending a message body. A server SHOULD (Section 13)) does not allow sending a message body.
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
message-header fields present in the message. (Note: An empty message-header fields present in the message. (Note: An empty
skipping to change at page 37, line 7 skipping to change at page 38, line 7
header whenever it contains a message body. Note that RTSP does not header whenever it contains a message body. Note that RTSP does not
support the HTTP/1.1 "chunked" transfer coding (see [H3.6.1]). support the HTTP/1.1 "chunked" transfer coding (see [H3.6.1]).
Given the moderate length of presentation descriptions returned, Given the moderate length of presentation descriptions returned,
the server should always be able to determine its length, even if the server should always be able to determine its length, even if
it is generated dynamically, making the chunked transfer encoding it is generated dynamically, making the chunked transfer encoding
unnecessary. unnecessary.
6. General Header Fields 6. General Header Fields
The general headers are listed in Table 1: General headers are headers that may be used in both request and
responses. The general headers are listed in Table 1:
+--------------------+--------------------+ +--------------------+--------------------+
| Header Name | Defined in Section | | Header Name | Defined in Section |
+--------------------+--------------------+ +--------------------+--------------------+
| Accept-Ranges | Section 16.5 |
| | |
| 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.28 | | Media-Properties | Section 16.28 |
| | | | | |
| Media-Range | Section 16.29 | | 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 |
| | | | | |
| RTP-Info | Section 16.43 |
| | |
| Seek-Style | Section 16.45 | | Seek-Style | Section 16.45 |
| | | | | |
| Supported | Section 16.49 | | Supported | Section 16.49 |
| | | | | |
| Timestamp | Section 16.51 | | Timestamp | Section 16.51 |
| | | | | |
| Via | Section 16.56 | | Via | Section 16.56 |
+--------------------+--------------------+ +--------------------+--------------------+
Table 1: The general headers used in RTSP Table 1: The general headers used in RTSP
skipping to change at page 39, line 40 skipping to change at page 40, line 40
The syntax of the RTSP request line is the following: The syntax of the RTSP request line is the following:
<Method> <Request-URI> <RTSP-Version> CRLF <Method> <Request-URI> <RTSP-Version> CRLF
Note: This syntax cannot be freely changed in future versions of Note: This syntax cannot be freely changed in future versions of
RTSP. This line needs to remain parsable by older RTSP RTSP. This line needs to remain parsable by older RTSP
implementations since it indicates the RTSP version of the message. implementations since it indicates the RTSP version of the message.
In contrast to HTTP/1.1 [RFC2616], RTSP requests identify the In contrast to HTTP/1.1 [RFC2616], RTSP requests identify the
resource through an absolute RTSP URI (scheme, host, and port) (see resource through an absolute RTSP URI (including scheme, host, and
Section 4.2) rather than just the absolute path. port) (see Section 4.2) rather than just the absolute path.
HTTP/1.1 requires servers to understand the absolute URI, but HTTP/1.1 requires servers to understand the absolute URI, but
clients are supposed to use the Host request header. This is clients are supposed to use the Host request header. This is
purely needed for backward-compatibility with HTTP/1.0 servers, a purely needed for backward-compatibility with HTTP/1.0 servers, a
consideration that does not apply to RTSP. consideration that does not apply to RTSP.
An asterisk "*" can be used instead of an absolute URI in the An asterisk "*" can be used instead of an absolute URI in the
Request-URI part to indicate that the request does not apply to a Request-URI part to indicate that the request does not apply to a
particular resource, but to the server or proxy itself, and is only particular resource, but to the server or proxy itself, and is only
allowed when the request method does not necessarily apply to a allowed when the request method does not necessarily apply to a
skipping to change at page 41, line 12 skipping to change at page 42, line 12
| 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 | | Terminate-Reason | Section 16.50 |
| | | | | |
| Referrer | Section 16.39 | | Referrer | Section 16.39 |
| | | | | |
| Request-Status | Section 16.41 | | Request-Status | Section 16.40 |
| | | | | |
| Require | Section 16.42 | | Require | Section 16.41 |
| | | | | |
| Scale | Section 16.44 | | Scale | Section 16.44 |
| | | | | |
| Session | Section 16.47 | | Session | Section 16.47 |
| | | | | |
| Speed | Section 16.48 | | Speed | Section 16.48 |
| | | | | |
| Supported | Section 16.49 | | Supported | Section 16.49 |
| | | | | |
| Transport | Section 16.52 | | Transport | Section 16.52 |
skipping to change at page 43, line 14 skipping to change at page 44, line 14
5xx: Server Error - The server failed to fulfill an apparently valid 5xx: Server Error - The server failed to fulfill an apparently valid
request request
The individual values of the numeric status codes defined for The individual values of the numeric status codes defined for
RTSP/2.0, and an example set of corresponding Reason-Phrases, are RTSP/2.0, and an example set of corresponding Reason-Phrases, are
presented in Table 4. The reason phrases listed here are only presented in Table 4. The reason phrases listed here are only
recommended; they may be replaced by local equivalents without recommended; they may be replaced by local equivalents without
affecting the protocol. Note that RTSP adopts most HTTP/1.1 affecting the protocol. Note that RTSP adopts most HTTP/1.1
[RFC2616] status codes and adds RTSP-specific status codes starting [RFC2616] status codes and adds RTSP-specific status codes starting
at x50 to avoid conflicts with newly defined HTTP status codes. at x50 to avoid conflicts with future HTTP status codes that are
desirable to import into RTSP.
RTSP status codes are extensible. RTSP applications are not required RTSP status codes are extensible. RTSP applications are not required
to understand the meaning of all registered status codes, though such to understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST understanding is obviously desirable. However, applications MUST
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
skipping to change at page 43, line 52 skipping to change at page 45, line 4
| 302 | Found | all | | 302 | Found | all |
| | | | | | | |
| 304 | Not Modified | 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 |
| | | | | | | |
skipping to change at page 46, line 8 skipping to change at page 47, line 8
The response-header allow the request recipient to pass additional The response-header allow the request recipient to pass additional
information about the response which cannot be placed in the Status- information about the response which cannot be placed in the Status-
Line. This header give information about the server and about Line. This header give information about the server and about
further access to the resource identified by the Request-URI. All further access to the resource identified by the Request-URI. All
headers currently classified as response headers are listed in headers currently classified as response headers are listed in
Table 5. Table 5.
+------------------------+--------------------+ +------------------------+--------------------+
| Header | Defined in Section | | Header | Defined in Section |
+------------------------+--------------------+ +------------------------+--------------------+
| Accept-Credentials | Section 16.2 |
| | |
| Accept-Ranges | Section 16.5 |
| | |
| Connection-Credentials | Section 16.12 | | Connection-Credentials | Section 16.12 |
| | | | | |
| MTag | Section 16.30 | | MTag | Section 16.30 |
| | | | | |
| Location | Section 16.27 | | 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.42 |
| | |
| RTP-Info | Section 16.43 |
| | | | | |
| Scale | Section 16.44 | | Scale | Section 16.44 |
| | | | | |
| Session | Section 16.47 | | Session | Section 16.47 |
| | | | | |
| Server | Section 16.46 | | Server | Section 16.46 |
| | | | | |
| Speed | Section 16.48 | | Speed | Section 16.48 |
| | | | | |
| Transport | Section 16.52 | | Transport | Section 16.52 |
skipping to change at page 49, line 4 skipping to change at page 49, line 4
| Expires | Section 16.21 | | Expires | Section 16.21 |
| | | | | |
| Last-Modified | Section 16.26 | | Last-Modified | Section 16.26 |
+------------------+--------------------+ +------------------+--------------------+
Table 6: The RTSP message-body headers Table 6: The RTSP message-body headers
The extension-header mechanism allows additional message-header The extension-header mechanism allows additional message-header
fields to be defined without changing the protocol, but these fields fields to be defined without changing the protocol, but these fields
cannot be assumed to be recognizable by the recipient. Unrecognized cannot be assumed to be recognizable by the recipient. Unrecognized
header fields SHOULD be ignored by the recipient and forwarded by header fields MUST be ignored by the recipient and forwarded by
proxies. proxies.
9.2. Message Body 9.2. Message Body
RTSP message with an message body MUST include the Content-Type and RTSP message with an message body MUST include the Content-Type and
Content-Length headers. When a message body is included with a Content-Length headers. When a message body is included with a
message, the data type of that content data is determined via the message, the data type of that content data is determined via the
header fields Content-Type and Content-Encoding. header fields Content-Type and Content-Encoding.
Content-Type specifies the media type of the underlying data. Content-Type specifies the media type of the underlying data.
skipping to change at page 51, line 16 skipping to change at page 51, line 16
Lack of acknowledgement of an RTSP request should be handled within Lack of acknowledgement of an RTSP request should be handled within
the constraints of the connection timeout considerations described the constraints of the connection timeout considerations described
below (Section 10.4). below (Section 10.4).
10.2. Using Connections 10.2. Using Connections
A TCP transport can be used for both persistent connections (for A TCP transport can be used for both persistent connections (for
several message exchanges) and transient connections (for a single several message exchanges) and transient connections (for a single
message exchange). Implementations of this specification MUST message exchange). Implementations of this specification MUST
support RTSP over TCP. The scheme of the RTSP URI (Section 4.2) support RTSP over TCP. The scheme of the RTSP URI (Section 4.2)
indicates the default port that the server will listen on. indicates the default port that the server will listen on if the port
is not explicitly given.
A server MUST handle both persistent and transient connections. A server MUST handle both persistent and transient connections.
Transient connections facilitate mechanisms for fault tolerance. Transient connections facilitate mechanisms for fault tolerance.
They also allow for application layer mobility. A server and They also allow for application layer mobility. A server and
client pair that support transient connections can survive the client pair that support transient connections can survive the
loss of a TCP connection; e.g., due to a NAT timeout. When the loss of a TCP connection; e.g., due to a NAT timeout. When the
client has discovered that the TCP connection has been lost, it client has discovered that the TCP connection has been lost, it
can set up a new one when there is need to communicate again. can set up a new one when there is need to communicate again.
skipping to change at page 51, line 49 skipping to change at page 51, line 50
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.
RTSP allows a server to send requests to a client. However, this can RTSP allows a server to send requests to a client. However, this can
be supported only if a client establishes a persistent connection be supported only if a client establishes a persistent connection
with the server. In cases where a persistent connection does not with the server. In cases where a persistent connection does not
exist between a server and its client, due to the lack of a exist between a server and its client, due to the lack of a signaling
signalling channel the server may be forced to silently discard RTSP channel the server may be forced to silently discard RTSP messages,
messages, and may even drop an RTSP session without notifying the and may even drop an RTSP session without notifying the client. An
client. An example of such a case is when the server desires to send example of such a case is when the server desires to send a REDIRECT
a REDIRECT request for an RTSP session to the client but is not able request for an RTSP session to the client but is not able to do so
to do so because it cannot reach the client. A server that attempt because it cannot reach the client. A server that attempt to send a
to send a request to a client that has no connection currently to the request to a client that has no connection currently to the server
server SHOULD discard the request directly, it MAY queue it for later SHOULD discard the request directly, it MAY queue it for later
delivery. However, if the server queue the request it should when delivery. However, if the server queue the request it should when
adding additional requests to the queue ensure to remove older adding additional requests to the queue ensure to remove older
requests that are now redundant. 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.
Because the likely failure of server to client established Because the likely failure of server to client established
connections the server will not even attempt establishing any connections the server will not even attempt establishing any
connection. connection.
skipping to change at page 54, line 41 skipping to change at page 54, line 41
request/response cycle using the Timestamp header (Section 16.51) 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 10 seconds was chosen for the following reasons. It gives TCP
time to perform a couple of retransmissions, even if operating on time to perform a couple of retransmissions, even if operating on
default values. It is short enough that users may not abandon the default values. It is short enough that users may not abandon the
process themselves. However, it should be noted that 10 seconds process themselves. However, it should be noted that 10 seconds
can be aggressive on certain type of networks. The 5 seconds can be aggressive on certain type of networks. The 5 seconds
value for 1xx messages is half the timeout giving a reasonable value for 1xx messages is half the timeout giving a reasonable
change of successful delivery before timeout happens on the change of successful delivery before timeout happens on the
requestor side. requester 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
skipping to change at page 55, line 27 skipping to change at page 55, line 27
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.
GET_PARAMETER: When using GET_PARAMETER for keep alive, no body
SHOULD be included.
OPTIONS: This method is also usable, but it causes the server to OPTIONS: This method is also usable, but it causes the server to
perform more unnecessary processing and result in bigger perform more unnecessary processing and result in bigger
responses than necessary for the task. The reason is that the responses than necessary for the task. The reason is that the
server needs to determine the capabilities associated with the server needs to determine the capabilities associated with the
media resource to correctly populate the Public and Allow media resource to correctly populate the Public and Allow
headers. headers.
The timeout parameter MAY be included in a SETUP response, and MUST 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
skipping to change at page 58, line 8 skipping to change at page 58, line 8
Unsupported: This header is used in a 551 error response, to Unsupported: This header is used in a 551 error response, to
indicate which features were not supported. Such a response is indicate which features were not supported. Such a response is
only the result of the usage of the Require and/or Proxy- only the result of the usage of the Require and/or Proxy-
Require header where one or more feature where not supported. Require header where one or more feature where not supported.
This information allows the requester to make the best of This information allows the requester to make the best of
situations as it knows which features are not supported. situations as it knows which features are not supported.
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 agent to have more than
than one request outstanding and send them over the same persistent one request outstanding and send them over the same persistent
connection. For RTSP, where the relative order of requests will connection. For RTSP, where the relative order of requests will
matter, it is important to maintain the order of the requests. matter, it is important to maintain the order of the requests.
Because of this, the responding entity MUST process the incoming Because of this, the responding agent MUST process the incoming
requests in their sending order. The sending order can be determined requests in their sending order. The sending order can be determined
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 MUST 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 agent. The responses MUST be sent in the order
order the requests was processed. 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 delivery to be pipelined after each other. This is media delivery 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 are processed in the same RTSP session context which more requests are processed in the same RTSP session context which
the first request creates. In other words, a client can request that the first request creates. In other words, a client can request that
two or more media streams are set-up and then played without needing two or more media streams are set-up and then played without needing
to wait for a single response. This speeds up the initial startup to wait for a single response. This speeds up the initial startup
skipping to change at page 59, line 14 skipping to change at page 59, line 14
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 MUST 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 |
| | | | | | | | | | | |
| | S -> C | | | | | | S -> C | P,S | optional | optional |
| | | | | | | | | | | |
| OPTIONS | C -> S | P,S | R=Req, | Sd=Req, R=Opt | | OPTIONS | C -> S | P,S | required | required |
| | | | Sd=Opt | | | | | | | |
| | | | | | | | S -> C | P,S | optional | optional |
| | S -> C | | | | | | | | | |
| | | | | | | PAUSE | C -> S | P,S | required | required |
| PAUSE | C -> S | P,S | required | required | | | | | | |
| | | | | | | PLAY | C -> S | P,S | required | required |
| PLAY | C -> S | P,S | required | required | | | | | | |
| | | | | | | PLAY_NOTIFY | S -> C | P,S | required | required |
| PLAY_NOTIFY | S -> C | P,S | required | required | | | | | | |
| | | | | | | REDIRECT | S -> C | P,S | optional | required |
| REDIRECT | S -> C | P,S | optional | required | | | | | | |
| | | | | | | SETUP | C -> S | S | required | required |
| SETUP | C -> S | S | required | required | | | | | | |
| | | | | | | SET_PARAMETER | C -> S | P,S | required | optional |
| SET_PARAMETER | C -> S | P,S | required | optional | | | | | | |
| | | | | | | | S -> C | P,S | optional | optional |
| | S -> C | | | | | | | | | |
| | | | | | | TEARDOWN | C -> S | P,S | required | required |
| TEARDOWN | C -> S | P,S | required | required | | | | | | |
| | | | | | | | S -> C | | 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
skipping to change at page 61, line 8 skipping to change at page 61, line 8
included in the response to enumerate the set of methods that are included in the response to enumerate the set of methods that are
allowed for that resource unless the set of methods completely allowed for that resource unless the set of methods completely
matches the set in the Public header. If the given resource is not matches the set in the Public header. If the given resource is not
available, the RTSP agent SHOULD return an appropriate response code available, the RTSP agent SHOULD return an appropriate response code
such as 3rr or 4xx. The Supported header MAY be included in the such as 3rr or 4xx. The Supported header MAY be included in the
request to query the set of features that are supported by the request to query the set of features that are supported by the
responding RTSP agent. responding RTSP agent.
The OPTIONS method can be used to keep an RTSP session alive. The OPTIONS method can be used to keep an RTSP session alive.
However, it is not the preferred means of session keep-alive However, it is not the preferred means of session keep-alive
signalling, see Section 16.47. An OPTIONS request intended for signaling, see Section 16.47. An OPTIONS request intended for
keeping alive an RTSP session MUST include the Session header with keeping alive an RTSP session MUST include the Session header with
the associated session ID. Such a request SHOULD also use the media the associated session ID. Such a request SHOULD also use the media
or the aggregated control URI as the Request-URI. or the aggregated control URI as the Request-URI.
Example: Example:
C->S: OPTIONS * RTSP/2.0 C->S: OPTIONS rtsp://server.example.com RTSP/2.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Require:
Proxy-Require: gzipped-messages Proxy-Require: gzipped-messages
Supported: play.basic Supported: play.basic
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS
Supported: play.basic, implicit-play, gzipped-messages Supported: play.basic, setup.rtp.rtcp.mux, play.scale
Server: PhonyServer/1.1 Server: PhonyServer/1.1
Note that some of the feature-tags in Require and Proxy-Require are Note that some of the feature-tags in Supported 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 MUST 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
skipping to change at page 63, line 8 skipping to change at page 63, line 8
done via the DESCRIBE method. There are three ways that an RTSP done via the DESCRIBE method. There are three ways that an RTSP
client may receive initialization information: client may receive initialization information:
o via an RTSP DESCRIBE request o via an RTSP DESCRIBE request
o via some other protocol (HTTP, email attachment, etc.) o via some other protocol (HTTP, email attachment, etc.)
o via some form of user interface o via some form of user interface
If a client obtains a valid description from an alternate source, the If a client obtains a valid description from an alternate source, the
client MAY use this description for initialization purposes without client MAY use this description for initialization purposes without
issuing a DESCRIBE request for the same media. issuing a DESCRIBE request for the same media. The client should use
any MTag to either validate the presentation description or make the
session establishment conditional on being valid.
It is RECOMMENDED that minimal servers support the DESCRIBE method, It is RECOMMENDED that minimal servers support the DESCRIBE method,
and highly recommended that minimal clients support the ability to and highly recommended that minimal clients support the ability to
act as "helper applications" that accept a media initialization file act as "helper applications" that accept a media initialization file
from a user interface, and/or other means that are appropriate to the from a user interface, and/or other means that are appropriate to the
operating environment of the clients. operating environment of the clients.
13.3. SETUP 13.3. SETUP
The SETUP request for an URI specifies the transport mechanism to be The SETUP request for an URI specifies the transport mechanism to be
skipping to change at page 64, line 47 skipping to change at page 65, line 18
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, UTC Accept-Ranges: NPT, UTC
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 302 CSeq: 302
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1 Server: PhonyServer 1.1
Session: 47112344;timeout=60 Session: 47112344;timeout=60
Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/ Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/
"192.0.2.53:4589"; src_addr="192.0.2.241:6256"/ "192.0.2.53:4589"; src_addr="198.51.100.241:6256"/
"192.0.2.241:6257"; ssrc=2A3F93ED "198.51.100.241:6257"; ssrc=2A3F93ED
Accept-Ranges: NPT Accept-Ranges: NPT
Media-Properties: Random-Access=3.2, Time-Progressing, Media-Properties: Random-Access=3.2, Time-Progressing,
Time-Duration=3600.0 Time-Duration=3600.0
Media-Range: npt=0-2893.23 Media-Range: npt=0-2893.23
In the above example the client wants to create an RTSP session In the above example the client wants to create an RTSP session
containing the media resource "rtsp://example.com/foo/bar/baz.rm". containing the media resource "rtsp://example.com/foo/bar/baz.rm".
The transport parameters acceptable to the client is either RTP/AVP/ The transport parameters acceptable to the client is either RTP/AVP/
UDP (UDP per default) to be received on client port 4588 and 4589 or UDP (UDP per default) to be received on client port 4588 and 4589 at
RTP/AVP interleaved on the RTSP control channel. The server selects the address the RTSP setup connection comes from or RTP/AVP
the RTP/AVP/UDP transport and adds the ports it will send and interleaved on the RTSP control channel. The server selects the RTP/
AVP/UDP transport and adds the address and 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 or an Pipelined-Requests header referencing an
request into the existing session (aggregated session) or return existing session context, in which case the server MUST bundle this
error 459 (Aggregate Operation Not Allowed) (see Section 15.4.24). setup request into the existing session (aggregated session) or
An Aggregate control URI MUST be used to control an aggregated return error 459 (Aggregate Operation Not Allowed) (see
session. This URI MUST be different from the stream control URIs of Section 15.4.24). An Aggregate control URI MUST be used to control
the individual media streams included in the aggregate. The an aggregated session. This URI MUST be different from the stream
Aggregate control URI is to be specified by the session description control URIs of the individual media streams included in the
if the server supports aggregated control and aggregated control is aggregate. The Aggregate control URI is to be specified by the
desired for the session. However, even if aggregated control is session description if the server supports aggregated control and
offered the client MAY chose to not set up the session in aggregated aggregated control is desired for the session. However, even if
control. If an Aggregate control URI is not specified in the session aggregated control is offered the client MAY chose to not set up the
description, it is normally an indication that non-aggregated control session in aggregated control. If an Aggregate control URI is not
should be used. The SETUP of media streams in an aggregate which has specified in the session description, it is normally an indication
not been given an aggregated control URI is unspecified. that non-aggregated control should be used. The SETUP of media
streams in an aggregate which has not been given an aggregated
control URI is unspecified.
While the session ID sometimes carries 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
has not demonstrated liveness signs from the client(s) within a has not demonstrated liveness signs from the client(s) within a
certain timeout period. The default timeout value is 60 seconds; the certain timeout period. The default timeout value is 60 seconds; the
server MAY set this to a different value and indicate so in the server MAY set this to a different value and indicate so in the
timeout field of the Session header in the SETUP response. For timeout field of the Session header in the SETUP response. For
further discussion see Section 16.47. Signs of liveness for an RTSP further discussion see Section 16.47. Signs of liveness for an RTSP
session are: session are:
o Any RTSP request from a client(s) which includes a Session header o Any RTSP request from a client which includes a Session header
with that session's ID. with that session's ID.
o If RTP is used as a transport for the underlying media streams, an o If RTP is used as a transport for the underlying media streams, an
RTCP sender or receiver report from the client(s) for any of the RTCP sender or receiver report from the client(s) for any of the
media streams in that RTSP session. RTCP Sender Reports may for media streams in that RTSP session. RTCP Sender Reports may for
example be received in sessions where the server is invited into a example be received in sessions where the server is invited into a
conference session and is as valid for keep-alive. conference session and is as valid for keep-alive.
If a SETUP request on a session fails for any reason, the session If a SETUP request on a session fails for any reason, the session
state, as well as transport and other parameters for associated state, as well as transport and other parameters for associated
skipping to change at page 68, line 15 skipping to change at page 68, line 35
want to play from a particular start point until the end of media want to play from a particular start point until the end of media
using an Range header with an implicit stop point is recommended. using an Range header with an implicit stop point is recommended.
If a client request starting playing media at the end-point either If a client request starting playing media at the end-point either
explicitly with a Range header or implicit by having a pause point explicitly with a Range header or implicit by having a pause point
that is at the end of the media, a 457 (Invalid Range) error MUST be that is at the end of the media, a 457 (Invalid Range) error MUST be
sent and include the Media-Range header (Section 16.29). Below is sent and include the Media-Range header (Section 16.29). Below is
specified that the Range header also must be included, and will in specified that the Range header also must be included, and will in
the case of Ready-State carry the pause point. Note that this also the case of Ready-State carry the pause point. Note that this also
applies if the pause point or requested start point is at the applies if the pause point or requested start point is at the
begining of the media and a Scale header (Section 16.44) is included beginning of the media and a Scale header (Section 16.44) is included
with a negative value (playing backwards). with a negative value (playing backwards).
For media with random access properties a client may express its For media with random access properties a client may express its
preference on which policy for start point selection the server shall preference on which policy for start point selection the server shall
use. This is done by including the Seek-Style header (Section 16.45) use. This is done by including the Seek-Style header (Section 16.45)
in the PLAY request. in the PLAY request. The Seek-Style applied will effect the content
of the Range header as it will be adjusted to indicate from what
point the media actually is delivered.
A client desiring to play the media from the beginning MUST send a A client desiring to play the media from the beginning MUST send a
PLAY request with a Range header pointing at the beginning, e.g. PLAY request with a Range header pointing at the beginning, e.g.
npt=0-. If a PLAY request is received without a Range header and npt=0-. If a PLAY request is received without a Range header and
media delivery has stopped at the end, the server SHOULD respond with media delivery has stopped at the end, the server SHOULD respond with
a 457 "Invalid Range" error response. In that response, the current a 457 "Invalid Range" error response. In that response, the current
pause point MUST be included in a Range header. pause point MUST be included in a Range header.
All range specifiers in this specification allow for ranges with All range specifiers in this specification allow for ranges with
implicit start point (e.g. "npt=-30"). When used in a PLAY request, implicit start point (e.g. "npt=-30"). When used in a PLAY request,
skipping to change at page 69, line 7 skipping to change at page 69, line 30
Seek-Style: RAP Seek-Style: RAP
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Servers MUST include a "Range" header in any PLAY response, even if Servers MUST include a "Range" header in any PLAY response, even if
no Range header was present in the request. The response MUST use no Range header was present in the request. The response MUST use
the same format as the request's range header contained. If no Range the same format as the request's range header contained. If no Range
header was in the request, the format used in any previous PLAY header was in the request, the format used in any previous PLAY
request within the session SHOULD be used. If no format has been request within the session SHOULD be used. If no format has been
indicated in a previous request the server MAY use any time format indicated in a previous request the server MAY use any time format
supported by the media and indicated in the Accept-Ranges header in supported by the media and indicated in the Accept-Ranges header in
the SETUP response. It is RECOMMENDED that NPT is used if supported the SETUP request. It is RECOMMENDED that NPT is used if supported
by the media. by the media.
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 using Range header with state, the current pause-point is returned using Range header with
the pause point as the explicit start-point and an implicit end- the pause point as the explicit start-point and an implicit end-
point. For time-progressing content where the pause-point moves with point. For time-progressing content where the pause-point moves with
real-time due to limited retention, the current pause point is real-time due to limited retention, the current pause point is
returned. For sessions in playing state, the current playout point returned. For sessions in playing state, the current playout point
and the remaining parts of the range request is returned. For any and the remaining parts of the range request is returned. For any
media with retention longer than 0 seconds the currently valid Media- media with retention longer than 0 seconds the currently valid Media-
Range header shall also be included in the response. 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 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 are 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 which is 10 server sends a 200 OK response with the actual play time which is 10
ms prior (3.51) and the RTP-Info header that contains the necessary ms prior (3.51) and the RTP-Info header that contains the 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
skipping to change at page 71, line 14 skipping to change at page 71, line 48
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
Session: 12345678
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 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
Session: 12345678
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: clock=19961108T142300Z-19961108T143520Z Range: clock=19961108T142300Z-19961108T143520Z
Seek-Style: Next 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.
skipping to change at page 72, line 26 skipping to change at page 73, line 16
Clients can issue PLAY requests while the stream is in PLAYING state Clients can issue PLAY requests while the stream is in PLAYING state
and thus updating their request. and thus updating their request.
The important difference compared to a PLAY request in ready state is The important difference compared to a PLAY request in ready state is
the handling of the current play point and how the range header in the handling of the current play point and how the range header in
request is constructed. The session is actively playing media and request is constructed. The session is actively playing media and
the play point will be moving making the exact time a request will the play point 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 signaled by having the first range
specification have an explicit start value, e.g. npt=45- or specification have an explicit start value, e.g. npt=45- or
npt=45-60, in which case the server stops playout at the current npt=45-60, in which case the server stops playout at the current
playout point and then starts delivering media according to the Range playout point and then starts delivering media according to the Range
header. This is equivalent to having the client first send a PAUSE header. This is equivalent to having the client first send a PAUSE
and then a new play request that isn't based on the pause point. In and then a new play request that isn't based on the pause point. In
the case of continuation the first range specifier has an implicit the case of continuation the first range specifier has an implicit
start point and a explicit stop value (Z), e.g. npt=-60, which start point and a explicit stop value (Z), e.g. npt=-60, which
indicate that it MUST convert the range specifier being played prior indicate that it MUST convert the range specifier being played prior
to this PLAY request (X to Y) into (X to Z) and continue as this was to this PLAY request (X to Y) into (X to Z) and continue as this was
the request originally played. If the stop point is beyond the the request originally played. If the stop point is beyond the
current delivery point, the server SHALL immediatly pause delivery. current delivery point, the server SHALL immediately pause delivery.
As the request has been completed succesfully it shall be responded As the request has been completed successfully it shall be responded
with 200 ok. A PLAY-Notify with end-of-stream is also sent to with 200 OK. A PLAY-Notify with end-of-stream is also sent to
indicate the actual stop point. The pause point is set to requested indicate the actual stop point. The pause point is set to requested
stop point. stop point.
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. If the new PLAY request arrives at the server play ranges 10 to 15. If the new PLAY request arrives at the server
4 seconds after the previous one, it will take effect while the 4 seconds after the previous one, it will take effect while the
server still plays the first range (10-15). Thus changing the server still plays the first range (10-15). Thus changing the
behavior of this range to continue to play to 25 seconds, i.e. the behavior of this range to continue to play to 25 seconds, i.e. the
equivalent single request would be PLAY with range: npt=10-25. equivalent single request would be PLAY with range: npt=10-25.
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
Range: npt=10-15 Range: npt=10-15
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 834 CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: 12345678
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=10-15 Range: npt=10-15
Seek-Style: Next 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
Session: 12345678
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=14-25 Range: npt=14-25
Seek-Style: Next 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
skipping to change at page 74, line 20 skipping to change at page 75, line 23
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 Retention 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 changes of media There are two ways for the client to get informed about changes of
resources in play state. The client will receive a PLAY_NOTIFY media resources in play state. The client will receive a PLAY_NOTIFY
request with Notify-Reason header set to media-properties-update (see request with Notify-Reason header set to media-properties-update (see
Section 13.5.2. The client can use the value of the Media-Range to Section 13.5.2. The client can use the value of the Media-Range to
decide further actions, if the Media-Range header is present in the decide further actions, if the Media-Range header is present in the
PLAY_NOTIFY request. The second way is that the client issues a PLAY_NOTIFY request. The second way is that the client issues a
GET_PARAMETER request without a body but including a Media-Range GET_PARAMETER request without a body but including a Media-Range
header. The 200 OK response MUST include the current Media-Range header. The 200 OK response MUST include the current Media-Range
header (see Section 16.29). header (see Section 16.29).
13.4.6. Playing Live Media 13.4.6. Playing Live Media
skipping to change at page 75, line 36 skipping to change at page 76, line 39
the media and the Media-Range header indicates the currently the media and the Media-Range header indicates the currently
available media window around the current time. This window can available media window around the current time. This window can
cover recorded content in the past (seen from current time in the 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 delivery point to the requested the media). The server adjusts the delivery point to the requested
border of the window, if the client requests a delivery point that is border of the window, if the client requests a delivery point that is
located outside the recording windows, e.g., if requested to far in located outside the recording windows, e.g., if requested to 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 delivery considerations in Section 13.5.3 apply, if a client requests delivery
with Scale (Section 16.44) values other than 1.0 (Normal playback with Scale (Section 16.44) values other than 1.0 (Normal playback
rate) while deliverying live media with recording. rate) while delivering live media with 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.28): Properties header in the SETUP response by (see also Section 16.28):
skipping to change at page 77, line 22 skipping to change at page 78, line 24
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 completion or near completion of the PLAY request and indicates the completion or near completion of the PLAY request and
the ending delivery of the media stream(s). The request MUST NOT be the ending delivery of the media stream(s). The request MUST NOT be
issued unless the server is in the playing state. The end of the issued unless the server is in the playing state. The end of the
media stream delivery notification may be used to indicate either a media stream delivery notification may be used to indicate either a
successful completion of the PLAY request currently being served, or successful completion of the PLAY request currently being served, or
to indicate some error resulting in failure to complete the request. to indicate some error resulting in failure to complete the request.
The Request-Status header (Section 16.41) MUST be included to The Request-Status header (Section 16.40) MUST be included to
indicate which request the notification is for and its completion indicate which request the notification is for and its completion
status. The message response status codes (Section 8.1.1) are used status. The message response status codes (Section 8.1.1) are used
to indicate how the PLAY request concluded. The sender of a to indicate how the PLAY request concluded. The sender of a
PALY_NOTIFY can issue an updated PALY_NOTIFY, in the case of a PLAY_NOTIFY can issue an updated PLAY_NOTIFY, in the case of a
PLAY_NOTIFY sent with wrong information. For instance, a PLAY_NOTIFY PLAY_NOTIFY sent with wrong information. For instance, a PLAY_NOTIFY
was issued before reaching the end-of-stream, but some error occurred was issued before reaching the end-of-stream, but some error occurred
resulting in that the previously sent PLAY_NOTIFY contained a wrong 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 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 be sent including the correct status for the completion and all
additional information. 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 and the Scale header if the scale value MUST include a Range header and the Scale header if the scale value
is not 1. The Range header indicates the point in the stream or is not 1. The Range header indicates the point in the stream or
skipping to change at page 78, line 19 skipping to change at page 79, line 20
event: event:
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 854 CSeq: 854
Notify-Reason: end-of-stream Notify-Reason: end-of-stream
Request-Status: cseq=853 status=200 reason="OK" Request-Status: cseq=853 status=200 reason="OK"
Range: npt=-145 Range: npt=-145
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
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
Date: Mon, 08 Mar 2010 13:37:16 GMT
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
Session: uZ3ci0K+Ld-M
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.28) 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.29). 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.
skipping to change at page 79, line 18 skipping to change at page 80, line 22
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
Session: uZ3ci0K+Ld-M
13.5.3. Scale-Change 13.5.3. Scale-Change
The server may be forced to change the rate, when a client request The server may be forced to change the rate, when a client request
delivery using a Scale (Section 16.44) value other than 1.0 (normal delivery using a Scale (Section 16.44) value other than 1.0 (normal
playback rate). For time progressing media with some retention, i.e. playback rate). For time progressing media with some retention, i.e.
the server stores already sent content, a client requesting to play the server stores already sent content, a client requesting to play
with Scale values larger than 1 may catch up with the front end of with Scale values larger than 1 may catch up with the front end of
the media. The server will then be unable to continue to provide the media. The server will then be unable to continue to provide
with content at Scale larger than 1 as content is only made available with content at Scale larger than 1 as content is only made available
skipping to change at page 80, line 32 skipping to change at page 81, line 38
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:37:21.394- Range: npt=1:37:21.394-
Scale: 1 Scale: 1
RTP-Info: url="rtsp://example.com/fizzle/foo/audio" RTP-Info: url="rtsp://example.com/fizzle/foo/audio"
ssrc=0D12F123:rtptime=2345962545 ssrc=0D12F123:rtptime=2345962545
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
Session: uZ3ci0K+Ld-M
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 MUST 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
Session: 12345678 Session: 12345678
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 834 CSeq: 834
Date: 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-75.00
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 resume from the pause point and play until media end. Range header resume from the pause point and play until media end.
The pause point after any PAUSE request MUST 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 range. For media with random access properties, if PLAY request's range. For media with random access properties, if
skipping to change at page 84, line 28 skipping to change at page 85, line 28
The server can send TEARDOWN requests in the 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 direction to indicate that the server has been forced to terminate
the ongoing session. This may happen for several reasons, such as the ongoing session. This may happen for several reasons, such as
server maintenance without available backup, or that the session has server maintenance without available backup, or that the session has
been inactive for extended periods of time. The reason is provided been inactive for extended periods of time. The reason is provided
in the Terminate-Reason header (Section 16.50). in the Terminate-Reason header (Section 16.50).
When a RTSP client has maintained a RTSP session that otherwise is When a RTSP client has maintained a RTSP session that otherwise is
inactive for an extended period of time the server may reclaim the inactive for an extended period of time the server may reclaim the
resources. That is done by issuing a REDIRECT request with the resources. That is done by issuing a TEARDOWN request with the
Terminate-Reason set to "Session-Timeout". This MAY be done when the Terminate-Reason set to "Session-Timeout". This MAY be done when the
client has been inactive in the RTSP session for more than one client has been inactive in the RTSP session for more than one
Session Timeout period (Section 16.47). However, the server is Session Timeout period (Section 16.47). However, the server is
RECOMMENDED to not perform this operation until an extended period of RECOMMENDED to not perform this operation until an extended period of
inactivity has passed. The time period is considered extended when inactivity has passed. The time period is considered extended when
it is 10 times the Session Timeout period. Consideration of the it is 10 times the Session Timeout period. Consideration of the
application of the server and its content should be performed when application of the server and its content should be performed when
configuring what is considered as extended periods of time. configuring what is considered as extended periods of time.
In case the server needs to stop providing service to the established In case the server needs to stop providing service to the established
skipping to change at page 85, line 20 skipping to change at page 86, line 20
1. respond to the TEARDOWN request 1. respond to the TEARDOWN request
2. disconnect the control channel from the requesting server 2. disconnect the control channel from the requesting server
3. pass the TEARDOWN request to each applicable client (typically 3. pass the TEARDOWN request to each applicable client (typically
those clients with an active session or an unanswered request) those clients with an active session or an unanswered request)
Note: The proxy is responsible for accepting TEARDOWN responses Note: The proxy is responsible for accepting TEARDOWN responses
from its clients; these responses MUST NOT be passed on to either from its clients; these responses MUST NOT be passed on to either
the original server or the redirected server. the original server or the target server in the redirect.
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
are two ways of specifying the parameters to be retrieved. The first are two ways of specifying the parameters to be retrieved. The first
is by including headers which have been defined such that you can use is by including headers which have been defined such that you can use
them for this purpose. Headers for this purpose should allow empty, them for this purpose. Headers for this purpose should allow empty,
skipping to change at page 86, line 28 skipping to change at page 87, line 28
understood by the request receiving agent. If one or more parameters understood by the request receiving agent. If one or more parameters
are not understood a 451 (Parameter Not Understood) MUST be sent are not understood a 451 (Parameter Not Understood) MUST be sent
including a body listing these parameters that 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 User-Agent: PhonyClient/1.2
Session: 12345678 Session: 12345678
Content-Length: 26 Content-Length: 26
User-Agent: PhonyClient/1.2 Content-Type: text/parameters
packets_received packets_received
jitter jitter
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 431 CSeq: 431
Session: 12345678 Session: 12345678
Server: PhonyServer/1.1
Date: Mon, 08 Mar 2010 13:43:23 GMT
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
skipping to change at page 87, line 41 skipping to change at page 89, line 8
sense to allow the setting of several parameters if an atomic sense to allow the setting of several parameters if an atomic
setting is desirable. Imagine device control where the client setting is desirable. Imagine device control where the client
does not want the camera to pan unless it can also tilt to the does not want the camera to pan unless it can also tilt to the
right angle at the same time. right angle at the same time.
Example: Example:
C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 421 CSeq: 421
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: iixT43KLc
Date: Mon, 08 Mar 2010 14:45:04 GMT
Content-length: 20 Content-length: 20
Content-type: text/parameters Content-type: text/parameters
barparam: barstuff barparam: barstuff
S->C: RTSP/2.0 451 Parameter Not Understood S->C: RTSP/2.0 451 Parameter Not Understood
CSeq: 421 CSeq: 421
Session: iixT43KLc
Server: PhonyServer 1.0
Date: Mon, 08 Mar 2010 14:44:56 GMT
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 the The REDIRECT method is issued by a server to inform a client that the
service provided will be terminated and where a corresponding service service provided will be terminated and where a corresponding service
can be provided instead. This happens for different reasons. One is can be provided instead. This happens for different reasons. One is
skipping to change at page 89, line 19 skipping to change at page 90, line 40
the original server or the redirected server. the original server or the redirected server.
When the server lacks any alternative server and needs to terminate a When the server lacks any alternative server and needs to terminate a
session or all sessions the TEARDOWN request SHALL be used instead. session or all sessions the TEARDOWN request SHALL be used instead.
When no Terminate-Reason "time" parameter are included in a REDIRECT When no Terminate-Reason "time" parameter are included in a REDIRECT
request, the client SHALL perform the redirection immediately and request, the client SHALL perform the redirection immediately and
return a response to the server. The server shall consider the return a response to the server. The server shall consider the
session as terminated and can free any associated state after it session as terminated and can free any associated state after it
receives the successful (2xx) response. The server MAY close the receives the successful (2xx) response. The server MAY close the
signalling connection upon receiving the response and the client signaling connection upon receiving the response and the client
SHOULD close the signalling connection after sending the 2xx SHOULD close the signaling connection after sending the 2xx response.
response. The exception to this is when the client has several The exception to this is when the client has several sessions on the
sessions on the server being managed by the given signalling server being managed by the given signaling connection. In this
connection. In this case, the client SHOULD close the connection case, the client SHOULD close the connection when it has received and
when it has received and responded to REDIRECT requests for all the responded to REDIRECT requests for all the sessions managed by the
sessions managed by the signalling connection. signaling connection.
The Terminate-Reason header "time" parameter MAY be used to indicate The Terminate-Reason header "time" parameter MAY be used to indicate
the wallclock time by when the redirection MUST have take place. To the wallclock time by when the redirection MUST have take place. To
allow a client to determine that redirect time without being time allow a client to determine that redirect time without being time
synchronized with the server, the server MUST include a Date header synchronized with the server, the server MUST include a Date header
in the request. The client should have before the redirection time- in the request. The client should have before the redirection time-
line terminated the session and close the control connection. The line terminated the session and close the control connection. The
server MAY simple cease to provide service when the deadline time has server MAY simple cease to provide service when the deadline time has
been reached, or it may issue TEARDOWN requests to the remaining been reached, or it may issue TEARDOWN requests to the remaining
sessions. sessions.
The differentiation of REDIRECT requests with and without range
header is to allow for clear and explicit state handling. As the
state in the server needs to be kept until the point of
redirection, the handling becomes more clear if the client is
required to TEARDOWN the session at the redirect point.
If the REDIRECT request times out following the rules in Section 10.4 If the REDIRECT request times out following the rules in Section 10.4
the server MAY terminate the session or transport connection that the server MAY terminate the session or transport connection that
would be redirected by the request. This is a safeguard against would be redirected by the request. This is a safeguard against
misbehaving clients that refuses to respond to a REDIRECT request. misbehaving clients that refuses to respond to a REDIRECT request.
That should not provide any benefit. That should not provide any benefit.
After a REDIRECT request has been processed, a client that wants to After a REDIRECT request has been processed, a client that wants to
continue to send or receive media for the resource identified by the continue to send or receive media for the resource identified by the
Request-URI will have to establish a new session with the designated Request-URI will have to establish a new session with the designated
host. If the URI given in the Location header is a valid resource host. If the URI given in the Location header is a valid resource
skipping to change at page 91, line 4 skipping to change at page 91, line 45
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 732 CSeq: 732
Location: rtsp://s2.example.com:8001 Location: rtsp://s2.example.com:8001
Terminate-Reason: Server-Admin ;time=19960213T143205Z Terminate-Reason: Server-Admin ;time=19960213T143205Z
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
Date: Thu, 13 Feb 1996 14:30:43 GMT Date: Thu, 13 Feb 1996 14:30:43 GMT
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 732 CSeq: 732
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: uZ3ci0K+Ld-M
14. Embedded (Interleaved) Binary Data 14. Embedded (Interleaved) Binary Data
In order to fulfill certain requirements on the network side, e.g. in In order to fulfill certain requirements on the network side, e.g. in
conjunction with network address translators that block RTP traffic conjunction with network address translators that block RTP traffic
over UDP, it may be necessary to interleave RTSP messages and media over UDP, it may be necessary to interleave RTSP messages and media
stream data. This interleaving should generally be avoided unless stream data. This interleaving should generally be avoided unless
necessary since it complicates client and server operation and necessary since it complicates client and server operation and
imposes additional overhead. Also, head of line blocking may cause imposes additional overhead. Also, head of line blocking may cause
problems. Interleaved binary data SHOULD only be used if RTSP is problems. Interleaved binary data SHOULD only be used if RTSP is
skipping to change at page 92, line 27 skipping to change at page 93, line 27
Media-Properties: Random-Access=0.2, Unmutable, Unlimited Media-Properties: Random-Access=0.2, Unmutable, Unlimited
C->S: PLAY rtsp://example.com/bar.file RTSP/2.0 C->S: PLAY rtsp://example.com/bar.file RTSP/2.0
CSeq: 3 CSeq: 3
Session: 12345678 Session: 12345678
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Session: 12345678 Session: 12345678
Date: Thu, 05 Jun 1997 18:59:15 GMT Date: Thu, 05 Jun 1997 18:57:19 GMT
RTP-Info: url="rtsp://example.com/bar.file" RTP-Info: url="rtsp://example.com/bar.file"
ssrc=0D12F123:seq=232433;rtptime=972948234 ssrc=0D12F123:seq=232433;rtptime=972948234
Range: npt=0-56.8 Range: npt=0-56.8
Seek-Style: RAP Seek-Style: RAP
S->C: $005{2 byte length}{"length" bytes data, w/RTP header} S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
S->C: $005{2 byte length}{"length" bytes data, w/RTP header} S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
S->C: $006{2 byte length}{"length" bytes RTCP packet} S->C: $006{2 byte length}{"length" bytes RTCP packet}
15. Status Code Definitions 15. Status Code Definitions
skipping to change at page 94, line 44 skipping to change at page 95, line 44
Transport: RTP/AVP/TCP;unicast;interleaved=0-1 Transport: RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 302 Try Other Server S->C: RTSP/2.0 302 Try Other Server
CSeq: 2 CSeq: 2
Location: rtsp://s2.example.com:8001/fizzle/foo Location: rtsp://s2.example.com:8001/fizzle/foo
15.3.3. 303 See Other 15.3.3. 303 See Other
This status code MUST NOT be used in RTSP. However, it was allowed This status code MUST NOT be used in RTSP 2.0. However, it was
to use in RTSP 1.0 (RFC 2326). allowed to use in RTSP 1.0 (RFC 2326).
15.3.4. 304 Not Modified 15.3.4. 304 Not Modified
If the client has performed a conditional DESCRIBE or SETUP (see If the client has performed a conditional DESCRIBE or SETUP (see
Section 16.24) and the requested resource has not been modified, the Section 16.24) and the requested resource has not been modified, the
server SHOULD send a 304 response. This response MUST NOT contain a server SHOULD send a 304 response. This response MUST NOT contain a
message-body. message-body.
The response MUST include the following header fields: The response MUST include the following header fields:
skipping to change at page 95, line 51 skipping to change at page 96, line 51
The request requires user authentication. The response MUST include The request requires user authentication. The response MUST include
a WWW-Authenticate header (Section 16.57) field containing a a WWW-Authenticate header (Section 16.57) field containing a
challenge applicable to the requested resource. The client MAY challenge applicable to the requested resource. The client MAY
repeat the request with a suitable Authorization header field. If repeat the request with a suitable Authorization header field. If
the request already included Authorization credentials, then the 401 the request already included Authorization credentials, then the 401
response indicates that authorization has been refused for those response indicates that authorization has been refused for those
credentials. If the 401 response contains the same challenge as the credentials. If the 401 response contains the same challenge as the
prior response, and the user agent has already attempted prior response, and the user agent has already attempted
authentication at least once, then the user SHOULD be presented the authentication at least once, then the user SHOULD be presented the
entity that was given in the response, since that entity might message body that was given in the response, since that message body
include relevant diagnostic information. HTTP access authentication might include relevant diagnostic information. HTTP access
is explained in [RFC2617]. authentication is explained in [RFC2617].
15.4.3. 402 Payment Required 15.4.3. 402 Payment Required
This code is reserved for future use. This code is reserved for future use.
15.4.4. 403 Forbidden 15.4.4. 403 Forbidden
The server understood the request, but is refusing to fulfill it. The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated. Authorization will not help and the request SHOULD NOT be repeated.
If the server wishes to make public why the request has not been If the server wishes to make public why the request has not been
fulfilled, it SHOULD describe the reason for the refusal in the fulfilled, it SHOULD describe the reason for the refusal in the
entity. If the server does not wish to make this information message body. If the server does not wish to make this information
available to the client, the status code 404 (Not Found) can be used available to the client, the status code 404 (Not Found) can be used
instead. instead.
15.4.5. 404 Not Found 15.4.5. 404 Not Found
The server has not found anything matching the Request-URI. No The server has not found anything matching the Request-URI. No
indication is given of whether the condition is temporary or indication is given of whether the condition is temporary or
permanent. The 410 (Gone) status code SHOULD be used if the server permanent. The 410 (Gone) status code SHOULD be used if the server
knows, through some internally configurable mechanism, that an old knows, through some internally configurable mechanism, that an old
resource is permanently unavailable and has no forwarding address. resource is permanently unavailable and has no forwarding address.
skipping to change at page 96, line 43 skipping to change at page 97, line 43
The method specified in the request is not allowed for the resource The method specified in the request is not allowed for the resource
identified by the Request-URI. The response MUST include an Allow identified by the Request-URI. The response MUST include an Allow
header containing a list of valid methods for the requested resource. header containing a list of valid methods for the requested resource.
This status code is also to be used if a request attempts to use a This status code is also to be used if a request attempts to use a
method not indicated during SETUP. method not indicated during SETUP.
15.4.7. 406 Not Acceptable 15.4.7. 406 Not Acceptable
The resource identified by the request is only capable of generating The resource identified by the request is only capable of generating
response entities which have content characteristics not acceptable response message bodies which have content characteristics not
according to the accept headers sent in the request. acceptable according to the accept headers sent in the request.
The response SHOULD include an message body containing a list of The response SHOULD include an message body containing a list of
available entity characteristics and location(s) from which the user available message body characteristics and location(s) from which the
or user agent can choose the one most appropriate. The entity format user or user agent can choose the one most appropriate. The message
is specified by the media type given in the Content-Type header body format is specified by the media type given in the Content-Type
field. Depending upon the format and the capabilities of the user header field. Depending upon the format and the capabilities of the
agent, selection of the most appropriate choice MAY be performed user agent, selection of the most appropriate choice MAY be performed
automatically. However, this specification does not define any automatically. However, this specification does not define any
standard for such automatic selection. standard for such automatic selection.
If the response could be unacceptable, a user agent SHOULD If the response could be unacceptable, a user agent SHOULD
temporarily stop receipt of more data and query the user for a temporarily stop receipt of more data and query the user for a
decision on further actions. decision on further actions.
15.4.8. 407 Proxy Authentication Required 15.4.8. 407 Proxy Authentication Required
This code is similar to 401 (Unauthorized) (Section 15.4.2), but This code is similar to 401 (Unauthorized) (Section 15.4.2), but
skipping to change at page 98, line 38 skipping to change at page 99, line 38
condition is only likely to occur when a client has used a request condition is only likely to occur when a client has used a request
with long query information, when the client has descended into a URI with long query information, when the client has descended into a URI
"black hole" of redirection (e.g., a redirected URI prefix that "black hole" of redirection (e.g., a redirected URI prefix that
points to a suffix of itself), or when the server is under attack by points to a suffix of itself), or when the server is under attack by
a client attempting to exploit security holes present in some servers a client attempting to exploit security holes present in some servers
using fixed-length buffers for reading or manipulating the Request- using fixed-length buffers for reading or manipulating the Request-
URI. URI.
15.4.15. 415 Unsupported Media Type 15.4.15. 415 Unsupported Media Type
The server is refusing to service the request because the entity of The server is refusing to service the request because the message
the request is in a format not supported by the requested resource body of the request is in a format not supported by the requested
for the requested method. resource for the requested method.
15.4.16. 451 Parameter Not Understood 15.4.16. 451 Parameter Not Understood
The recipient of the request does not support one or more parameters The recipient of the request does not support one or more parameters
contained in the request. When returning this error message the contained in the request. When returning this error message the
sender SHOULD return a message body containing the offending sender SHOULD return a message body containing the offending
parameter(s). parameter(s).
15.4.17. 452 reserved 15.4.17. 452 reserved
skipping to change at page 100, line 27 skipping to change at page 101, line 27
15.4.28. 463 Destination Prohibited 15.4.28. 463 Destination Prohibited
The data transmission channel was not established because the server The data transmission channel was not established because the server
prohibited access to the client address. This error is most likely prohibited access to the client address. This error is most likely
the result of a client attempt to redirect media traffic to another the result of a client attempt to redirect media traffic to another
destination with a dest_addr parameter in the Transport header. destination with a dest_addr parameter in the Transport header.
15.4.29. 464 Data Transport Not Ready Yet 15.4.29. 464 Data Transport Not Ready Yet
The data transmission channel to the media destination is not yet The data transmission channel to the media destination is not yet
ready for carrying data. However, the responding entity still ready for carrying data. However, the responding agent still expects
expects that the data transmission channel will be established at that the data transmission channel will be established at some point
this point in time. Note, however, that this may result in a in time. Note, however, that this may result in a permanent failure
permanent failure like 462 "Destination Unreachable". like 462 "Destination Unreachable".
An example when this error may occur is in the case a client sends a An example when this error may occur is in the case a client sends a
PLAY request to a server prior to ensuring that the TCP connections PLAY request to a server prior to ensuring that the TCP connections
negotiated for carrying media data was successful established (In negotiated for carrying media data was successful established (In
violation of this specification). The server would use this error violation of this specification). The server would use this error
code to indicate that the requested action could not be performed due code to indicate that the requested action could not be performed due
to the failure of completing the connection establishment. to the failure of completing the connection establishment.
15.4.30. 465 Notification Reason Unknown 15.4.30. 465 Notification Reason Unknown
skipping to change at page 101, line 21 skipping to change at page 102, line 21
15.4.33. 472 Failure to establish secure connection 15.4.33. 472 Failure to establish secure connection
A proxy fails to establish a secure connection to the next hop RTSP A proxy fails to establish a secure connection to the next hop RTSP
agent. This is primarily caused by a fatal failure at the TLS agent. This is primarily caused by a fatal failure at the TLS
handshake, for example due to server not accepting any cipher suits. handshake, for example due to server not accepting any cipher suits.
15.5. Server Error 5xx 15.5. Server Error 5xx
Response status codes beginning with the digit "5" indicate cases in Response status codes beginning with the digit "5" indicate cases in
which the server is aware that it has erred or is incapable of which the server is aware that it has erred or is incapable of
performing the request The server SHOULD include an entity containing performing the request The server SHOULD include an message body
an explanation of the error situation, and whether it is a temporary containing an explanation of the error situation, and whether it is a
or permanent condition. User agents SHOULD display any included temporary or permanent condition. User agents SHOULD display any
entity to the user. These response codes are applicable to any included message body to the user. These response codes are
request method. applicable to any request method.
15.5.1. 500 Internal Server Error 15.5.1. 500 Internal Server Error
The server encountered an unexpected condition which prevented it The server encountered an unexpected condition which prevented it
from fulfilling the request. from fulfilling the request.
15.5.2. 501 Not Implemented 15.5.2. 501 Not Implemented
The server does not support the functionality required to fulfill the The server does not support the functionality required to fulfill the
request. This is the appropriate response when the server does not request. This is the appropriate response when the server does not
skipping to change at page 103, line 16 skipping to change at page 104, line 16
+---------------+----------------+--------+---------+------+ +---------------+----------------+--------+---------+------+
| method | direction | object | acronym | Body | | method | direction | object | acronym | Body |
+---------------+----------------+--------+---------+------+ +---------------+----------------+--------+---------+------+
| DESCRIBE | C -> S | P,S | DES | r | | DESCRIBE | C -> S | P,S | DES | r |
| | | | | | | | | | | |
| GET_PARAMETER | C -> S, S -> C | P,S | GPR | R,r | | GET_PARAMETER | C -> S, S -> C | P,S | GPR | R,r |
| | | | | | | | | | | |
| OPTIONS | C -> S, S -> C | P,S | OPT | | | OPTIONS | C -> S, S -> C | P,S | OPT | |
| | | | | | | | | | | |
| | S -> C | | | |
| | | | | |
| PAUSE | C -> S | P,S | PSE | | | PAUSE | C -> S | P,S | PSE | |
| | | | | | | | | | | |
| PLAY | C -> S | P,S | PLY | | | PLAY | C -> S | P,S | PLY | |
| | | | | | | | | | | |
| PLAY_NOTIFY | S -> C | P,S | PNY | R | | PLAY_NOTIFY | S -> C | P,S | PNY | R |
| | | | | | | | | | | |
| REDIRECT | S -> C | P,S | RDR | | | REDIRECT | S -> C | P,S | RDR | |
| | | | | | | | | | | |
| SETUP | C -> S | S | STP | | | SETUP | C -> S | S | STP | |
| | | | | | | | | | | |
skipping to change at page 105, line 7 skipping to change at page 106, line 7
details. details.
-: The header field is not applicable. -: The header field is not applicable.
"Optional" means that a Client/Server MAY include the header field in "Optional" means that a Client/Server MAY include the header field in
a request or response. The Client/Server behavior when receiving a request or response. The Client/Server behavior when receiving
such headers varies, for some it may ignore the header field, in such headers varies, for some it may ignore the header field, in
other case it is request to process the header. This is regulated by other case it is request to process the header. This is regulated by
the method and header descriptions. Example of headers that require the method and header descriptions. Example of headers that require
processing are the Require and Proxy-Require header fields discussed processing are the Require and Proxy-Require header fields discussed
in Section 16.42 and Section 16.35. A "mandatory" header field MUST in Section 16.41 and Section 16.35. A "mandatory" header field MUST
be present in a request, and MUST be understood by the Client/Server be present in a request, and MUST be understood by the Client/Server
receiving the request. A mandatory response header field MUST be receiving the request. A mandatory response header field MUST be
present in the response, and the header field MUST be understood by present in the response, and the header field MUST be understood by
the Client/Server processing the response. "Not applicable" means the Client/Server processing the response. "Not applicable" means
that the header field MUST NOT be present in a request. If one is that the header field MUST NOT be present in a request. If one is
placed in a request by mistake, it MUST be ignored by the Client/ placed in a request by mistake, it MUST be ignored by the Client/
Server receiving the request. Similarly, a header field labeled "not Server receiving the request. Similarly, a header field labeled "not
applicable" for a response means that the Client/Server MUST NOT applicable" for a response means that the Client/Server MUST NOT
place the header field in the response, and the Client/Server MUST place the header field in the response, and the Client/Server MUST
ignore the header field in the response. ignore the header field in the response.
An RTSP agent MUST ignore extension headers that are not understood. An RTSP agent MUST ignore extension headers that are not understood.
The From and Location header fields contain an URI. If the URI The From and Location header fields contain an URI. If the URI
contains a comma, or semicolon, the URI MUST be enclosed in double contains a comma, or semicolon, the URI MUST be enclosed in double
quotes ("). Any URI parameters are contained within these quotes. quotes ("). Any URI parameters are contained within these quotes.
If the URI is not enclosed in double quotas, any semicolon- delimited If the URI is not enclosed in double quotas, any semicolon- delimited
parameters are header-parameters, not URI parameters. parameters are header-parameters, not URI parameters.
+----------------+------+-----+-----+-----+------+-----+------+-----+ +------------------+-------+-----+----+-----+-----+-----+-----+-----+
| Header | Wher | Pro | DES | OPT | SETU | PLA | PAUS | TRD | | Header | Where | Pro | DE | OPT | STP | PLY | PSE | TRD |
| | e | xy | | | P | Y | E | | | | | xy | S | | | | | |
+----------------+------+-----+-----+-----+------+-----+------+-----+ +------------------+-------+-----+----+-----+-----+-----+-----+-----+
| Accept | R | | o | - | - | - | - | - | | Accept | R | | o | - | - | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Accept-Credent | R | r | o | o | o | o | o | o | | Accept-Credentia | R | rm | o | o | o | o | o | o |
| ials | | | | | | | | | | ls | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Accept-Encodin | R | r | o | - | - | - | - | - | | Accept-Encoding | R | r | o | - | - | - | - | - |
| g | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Accept-Language | R | r | o | - | - | - | - | - |
| Accept-Languag | R | r | o | - | - | - | - | - | | | | | | | | | | |
| e | | | | | | | | | | Accept-Ranges | R | r | - | - | m | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Accept-Ranges | R | r | - | - | m | - | - | - | | Accept-Ranges | r | r | - | - | m | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Accept-Ranges | r | r | - | - | o | - | - | - | | Accept-Ranges | 456 | r | - | - | - | m | - | - |
| | | | | | | | | | | | | | | | | | | |
| Accept-Ranges | 456 | r | - | - | - | o | - | - | | Allow | r | am | c | c | c | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Allow | r | am | c | c | c | - | - | - | | Allow | 405 | am | m | m | m | m | m | m |
| | | | | | | | | | | | | | | | | | | |
| Allow | 405 | am | m | m | m | m | m | m | | Authorization | R | | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Authorization | R | | o | o | o | o | o | o | | Bandwidth | R | | o | o | o | o | - | - |
| | | | | | | | | | | | | | | | | | | |
| Bandwidth | R | | o | o | o | o | - | - | | Blocksize | R | | o | - | o | o | - | - |
| | | | | | | | | | | | | | | | | | | |
| Blocksize | R | | o | - | o | o | - | - | | Cache-Control | | r | o | - | o | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Cache-Control | | r | o | - | o | - | - | - | | Connection | | ad | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Connection | | | o | o | o | o | o | o | | Connection-Crede | 470,4 | ar | o | o | o | o | o | o |
| | | | | | | | | | | ntials | 07 | | | | | | | |
| Connection-Cre | 470, | ar | o | o | o | o | o | o | | | | | | | | | | |
| dentials | 407 | | | | | | | | | Content-Base | r | | o | - | - | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Content-Base | r | | o | - | - | - | - | - | | Content-Base | 4xx,5 | | o | o | o | o | o | o |
| | | | | | | | | | | | xx | | | | | | | |
| Content-Base | 4xx, | | o | o | o | o | o | o | | | | | | | | | | |
| | 5xx | | | | | | | | | Content-Encoding | R | r | - | - | - | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Content-Encodi | R | r | - | - | - | - | - | - | | Content-Encoding | r | r | o | - | - | - | - | - |
| ng | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Content-Encoding | 4xx,5 | r | o | o | o | o | o | o |
| Content-Encodi | r | r | o | - | - | - | - | - | | | xx | | | | | | | |
| ng | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Content-Language | R | r | - | - | - | - | - | - |
| Content-Encodi | 4xx, | r | o | o | o | o | o | o | | | | | | | | | | |
| ng | 5xx | | | | | | | | | Content-Language | r | r | o | - | - | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Content-Langua | R | r | - | - | - | - | - | - | | Content-Language | 4xx,5 | r | o | o | o | o | o | o |
| ge | | | | | | | | | | | xx | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Content-Langua | r | r | o | - | - | - | - | - | | Content-Length | r | r | * | - | - | - | - | - |
| ge | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Content-Length | 4xx,5 | r | * | * | * | * | * | * |
| Content-Langua | 4xx, | r | o | o | o | o | o | o | | | xx | | | | | | | |
| ge | 5xx | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Content-Location | r | r | o | - | - | - | - | - |
| Content-Length | r | r | * | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Content-Location | 4xx,5 | r | o | o | o | o | o | o |
| Content-Length | 4xx, | r | * | * | * | * | * | * | | | xx | | | | | | | |
| | 5xx | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Content-Type | r | r | * | - | - | - | - | - |
| Content-Locati | r | | o | - | - | - | - | - | | | | | | | | | | |
| on | | | | | | | | | | Content-Type | 4xx,5 | ar | * | * | * | * | * | * |
| | | | | | | | | | | | xx | | | | | | | |
| Content-Locati | 4xx, | | o | o | o | o | o | o | | | | | | | | | | |
| on | 5xx | | | | | | | | | CSeq | Rc | rm | m | m | m | m | m | m |
| | | | | | | | | | | | | | | | | | | |
| Content-Type | r | | * | - | - | - | - | - | | Date | | am | o/ | o/* | o/* | o/* | o/* | o/* |
| Content-Type | 4xx, | | * | * | * | * | * | * | | | | | * | | | | | |
| | 5xx | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Expires | r | r | o | - | - | - | - | - |
| CSeq | Rc | rm | m | m | m | m | m | m | | | | | | | | | | |
| | | | | | | | | | | From | R | r | o | o | o | o | o | o |
| Date | | am | o | o | o | o | o | o | | | | | | | | | | |
| | | | | | | | | | | If-Match | R | r | - | - | o | - | - | - |
| MTag | r | r | o | - | o | - | - | - | | | | | | | | | | |
| | | | | | | | | | | If-Modified-Sinc | R | r | o | - | o | - | - | - |
| Expires | r | r | o | - | - | - | - | - | | e | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| From | R | r | o | o | o | o | o | o | | If-None-Match | R | r | o | - | o | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| If-Match | R | r | - | - | o | - | - | - | | Last-Modified | r | r | o | - | o | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| If-Modified-Si | R | r | o | - | o | - | - | - | | Location | 3rr | | o | o | o | o | o | o |
| nce | | | | | | | | | +------------------+-------+-----+----+-----+-----+-----+-----+-----+
| | | | | | | | | |
| If-None-Match | R | r | o | - | - | - | - | - |
| | | | | | | | | |
| Last-Modified | r | r | o | - | - | - | - | - |
| | | | | | | | | |
| Location | 3rr | | o | o | o | o | o | o |
+----------------+------+-----+-----+-----+------+-----+------+-----+
Table 9: Overview of RTSP header fields (A-L) related to methods Table 9: Overview of RTSP header fields (A-L) related to methods
DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.
+--------------+-------+------+----+----+------+------+-------+-----+ +---------------+--------+------+-----+-----+-----+-----+-----+-----+
| Header | Where | Prox | DE | OP | SETU | PLAY | PAUSE | TRD | | Header | Where | Prox | DES | OPT | STP | PLY | PSE | TRD |
| | | y | S | T | P | | | | | | | y | | | | | | |
+--------------+-------+------+----+----+------+------+-------+-----+ +---------------+--------+------+-----+-----+-----+-----+-----+-----+
| Media- | | | - | - | r | r | r | - | | Media- | | | - | - | m | m | m | - |
| Properties | | | | | | | | | | Properties | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Media-Range | | | - | - | r | r | r | - | | Media-Range | | | - | - | m | m | m | - |
| | | | | | | | | | | | | | | | | | | |
| Pipelined- | | amdr | - | o | o | o | o | o | | MTag | r | r | o | - | o | - | - | - |
| Requests | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Pipelined- | | amdr | - | o | o | o | o | o |
| Proxy- | 407 | amr | m | m | m | m | m | m | | Requests | | | | | | | | |
| Authenticate | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Proxy- | 407 | amr | m | m | m | m | m | m |
| Proxy- | R | rd | o | o | o | o | o | o | | Authenticate | | | | | | | | |
| Authorizatio | | | | | | | | | | | | | | | | | | |
| n | | | | | | | | | | Proxy- | R | rd | o | o | o | o | o | o |
| | | | | | | | | | | Authorization | | | | | | | | |
| Proxy- | R | ar | o | o | o | o | o | o | | | | | | | | | | |
| Require | | | | | | | | | | Proxy- | R | ar | o | o | o | o | o | o |
| | | | | | | | | | | Require | | | | | | | | |
| Proxy- | r | r | c | c | c | c | c | c | | | | | | | | | | |
| Require | | | | | | | | | | Proxy- | r | r | c | c | c | c | c | c |
| | | | | | | | | | | Require | | | | | | | | |
| Proxy- | R | amr | c | c | c | c | c | c | | | | | | | | | | |
| Supported | | | | | | | | | | Proxy- | R | amr | c | c | c | c | c | c |
| | | | | | | | | | | Supported | | | | | | | | |
| Proxy- | r | | c | c | c | c | c | c | | | | | | | | | | |
| Supported | | | | | | | | | | Proxy- | r | | c | c | c | c | c | c |
| | | | | | | | | | | Supported | | | | | | | | |
| Public | r | admr | - | m | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Public | r | amr | - | m | - | - | - | - |
| Public | 501 | admr | m | m | m | m | m | m | | | | | | | | | | |
| | | | | | | | | | | Public | 501 | amr | m | m | m | m | m | m |
| Range | R | | - | - | - | o | - | - | | | | | | | | | | |
| | | | | | | | | | | Range | R | | - | - | - | o | - | - |
| Range | r | | - | - | c | m | m | - | | | | | | | | | | |
| | | | | | | | | | | Range | r | | - | - | c | m | m | - |
| Terminate-Re | R | r | - | - | - | - | - | - | | | | | | | | | | |
| ason | | | | | | | | | | Terminate-Rea | R | r | - | - | - | - | - | - |
| | | | | | | | | | | son | | | | | | | | |
| Referrer | R | | o | o | o | o | o | o | | | | | | | | | | |
| | | | | | | | | | | Referrer | R | | o | o | o | o | o | o |
| Request- | R | | - | - | - | - | - | - | | | | | | | | | | |
| Status | | | | | | | | | | Request- | R | | - | - | - | - | - | - |
| | | | | | | | | | | Status | | | | | | | | |
| Require | R | | o | o | o | o | o | o | | | | | | | | | | |
| | | | | | | | | | | Require | R | | o | o | o | o | o | o |
| Retry-After | 3rr,5 | | o | o | o | - | - | - | | | | | | | | | | |
| | 03 | | | | | | | | | Retry-After | 3rr,50 | | o | o | o | o | o | - |
| | | | | | | | | | | | 3 | | | | | | | |
| Retry-After | 413 | | o | o | o | o | o | o | | | | | | | | | | |
| | | | | | | | | | | Retry-After | 413 | | o | - | - | - | - | - |
| RTP-Info | r | | - | - | c | c | - | - | | | | | | | | | | |
| | | | | | | | | | | RTP-Info | r | | - | - | c | c | - | - |
| Scale | | | - | - | - | o | - | - | | | | | | | | | | |
| | | | | | | | | | | Scale | R | r | - | - | - | o | - | - |
| Seek-Style | R | | - | - | - | o | - | - | | | | | | | | | | |
| | | | | | | | | | | Scale | r | amr | - | - | - | c | - | - |
| Seek-Style | r | | - | - | - | m | - | - | | | | | | | | | | |
| | | | | | | | | | | Seek-Style | R | | - | - | - | o | - | - |
| Session | R | r | - | o | o | m | m | m | | | | | | | | | | |
| | | | | | | | | | | Seek-Style | r | | - | - | - | m | - | - |
| Session | r | r | - | c | m | m | m | o | | | | | | | | | | |
| | | | | | | | | | | Server | R | r | - | o | - | - | - | o |
| Server | R | r | - | o | - | - | - | - | | | | | | | | | | |
| Server | r | r | o | o | o | o | o | o | | Server | r | r | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Speed | | | - | - | - | o | - | - | | Session | R | r | - | o | o | m | m | m |
| | | | | | | | | | | | | | | | | | | |
| Supported | R | amr | o | o | o | o | o | o | | Session | r | r | - | c | m | m | m | o |
| | | | | | | | | | | | | | | | | | | |
| Supported | r | amr | c | c | c | c | c | c | | Speed | R | admr | - | - | - | o | - | - |
| | | | | | | | | | | Speed | r | admr | - | - | - | c | - | - |
| Timestamp | R | admr | o | o | o | o | o | o | | | | | | | | | | |
| | | | | | | | | | | Supported | R | amr | o | o | o | o | o | o |
| Timestamp | c | admr | m | m | m | m | m | m | | | | | | | | | | |
| | | | | | | | | | | Supported | r | amr | c | c | c | c | c | c |
| Transport | | amr | - | - | m | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Timestamp | R | admr | o | o | o | o | o | o |
| Unsupported | r | | c | c | c | c | c | c | | | | | | | | | | |
| | | | | | | | | | | Timestamp | c | admr | m | m | m | m | m | m |
| User-Agent | R | | m* | m* | m* | m* | m* | m* | | | | | | | | | | |
| | | | | | | | | | | Transport | | mr | - | - | m | - | - | - |
| Vary | r | | c | c | c | c | c | c | | | | | | | | | | |
| | | | | | | | | | | Unsupported | r | | c | c | c | c | c | c |
| Via | R | amr | o | o | o | o | o | o | | | | | | | | | | |
| | | | | | | | | | | User-Agent | R | | m* | m* | m* | m* | m* | m* |
| Via | c | dr | m | m | m | m | m | m | | | | | | | | | | |
| | | | | | | | | | | Vary | r | | c | c | c | c | c | c |
| WWW- | 401 | | m | m | m | m | m | m | | | | | | | | | | |
| Authenticate | | | | | | | | | | Via | R | amr | o | o | o | o | o | o |
+--------------+-------+------+----+----+------+------+-------+-----+ | | | | | | | | | |
| Via | c | dr | m | m | m | m | m | m |
| | | | | | | | | |
| WWW- | 401 | | m | m | m | m | m | m |
| Authenticate | | | | | | | | |
+---------------+--------+------+-----+-----+-----+-----+-----+-----+
Table 10: Overview of RTSP header fields (P-W) related to methods Table 10: Overview of RTSP header fields (P-W) related to methods
DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.
+------------------------+---------+-------+-----+-----+-----+-----+ +------------------------+---------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY | | Header | Where | Proxy | GPR | SPR | RDR | PNY |
+------------------------+---------+-------+-----+-----+-----+-----+ +------------------------+---------+-------+-----+-----+-----+-----+
| Accept-Credentials | R | r | o | o | o | - | | Accept | R | arm | o | o | - | - |
| | | | | | | |
| Accept-Credentials | R | rm | o | o | o | - |
| | | | | | | |
| Accept-Ranges | | rm | o | - | - | - |
| | | | | | | | | | | | | | | |
| Allow | 405 | amr | m | m | m | - | | Allow | 405 | amr | m | m | m | - |
| | | | | | | | | | | | | | | |
| Authorization | R | | o | o | o | - | | Authorization | R | | o | o | o | - |
| | | | | | | | | | | | | | | |
| Bandwidth | R | | - | o | - | - | | Bandwidth | R | | - | o | - | - |
| | | | | | | | | | | | | | | |
| Blocksize | R | | - | o | - | - | | Blocksize | R | | - | o | - | - |
| | | | | | | | | | | | | | | |
| Connection | | | o | o | o | - | | Connection | | | o | o | o | o |
| | | | | | | |
| Cache-Control | | r | o | o | - | - |
| | | | | | | | | | | | | | | |
| Connection-Credentials | 470,407 | ar | o | o | o | - | | Connection-Credentials | 470,407 | ar | o | o | o | - |
| | | | | | | | | | | | | | | |
| Content-Base | R | | o | o | - | - | | Content-Base | R | | o | o | - | - |
| | | | | | | | | | | | | | | |
| Content-Base | r | | o | o | - | - | | Content-Base | r | | o | o | - | - |
| | | | | | | | | | | | | | | |
| Content-Base | 4xx,5xx | | o | o | o | - | | Content-Base | 4xx,5xx | | o | o | o | o |
| | | | | | | | | | | | | | | |
| Content-Encoding | R | r | o | o | - | - | | Content-Encoding | R | r | o | o | - | - |
| | | | | | | | | | | | | | | |
| Content-Encoding | r | r | o | o | - | - | | Content-Encoding | r | r | o | o | - | - |
| | | | | | | | | | | | | | | |
| Content-Encoding | 4xx,5xx | r | o | o | o | - | | Content-Encoding | 4xx,5xx | r | o | o | o | o |
| | | | | | | | | | | | | | | |
| Content-Language | R | r | o | o | - | - | | Content-Language | R | r | o | o | - | - |
| | | | | | | | | | | | | | | |
| Content-Language | r | r | o | o | - | - | | Content-Language | r | r | o | o | - | - |
| | | | | | | | | | | | | | | |
| Content-Language | 4xx,5xx | r | o | o | o | - | | Content-Language | 4xx,5xx | r | o | o | o | o |
| | | | | | | | | | | | | | | |
| Content-Length | R | r | * | * | - | - | | Content-Length | R | r | * | * | - | - |
| | | | | | | | | | | | | | | |
| Content-Length | r | r | * | * | - | - | | Content-Length | r | r | * | * | - | - |
| | | | | | | | | | | | | | | |
| Content-Length | 4xx,5xx | r | * | * | * | - | | Content-Length | 4xx,5xx | r | * | * | * | * |
| | | | | | | | | | | | | | | |
| Content-Location | R | | o | o | - | - | | Content-Location | R | | o | o | - | - |
| | | | | | | | | | | | | | | |
| Content-Location | r | | o | o | - | - | | Content-Location | r | | o | o | - | - |
| | | | | | | | | | | | | | | |
| Content-Location | 4xx,5xx | | o | o | o | - | | Content-Location | 4xx,5xx | | o | o | o | o |
| | | | | | | | | | | | | | | |
| Content-Type | R | | * | * | - | - | | Content-Type | R | | * | * | - | - |
| | | | | | | | | | | | | | | |
| Content-Type | r | | * | * | - | - | | Content-Type | r | | * | * | - | - |
| | | | | | | | | | | | | | | |
| Content-Type | 4xx | | * | * | * | - | | Content-Type | 4xx,5xx | | * | * | * | * |
| | | | | | | | | | | | | | | |
| CSeq | R,c | mr | m | m | m | m | | CSeq | R,c | mr | m | m | m | m |
| | | | | | | | | | | | | | | |
| Date | R | a | o | o | m | - | | Date | R | a | o | o | m | o |
| | | | | | | | | | | | | | | |
| Date | r | am | o | o | o | - | | Date | r | am | o | o | o | o |
| | | | | | | |
| If-Modified-Since | R | am | o | - | - | - |
| | | | | | | |
| If-None-Match | R | am | o | - | - | - |
| | | | | | | | | | | | | | | |
| From | R | r | o | o | o | - | | From | R | r | o | o | o | - |
| | | | | | | | | | | | | | | |
| Last-Modified | R | r | - | - | - | - | | Last-Modified | R | r | - | - | - | - |
| | | | | | | | | | | | | | | |
| Last-Modified | r | r | o | - | - | - | | Last-Modified | r | r | o | - | - | - |
| | | | | | | | | | | | | | | |
| Location | 3rr | | o | o | o | - | | Location | 3rr | | o | o | o | - |
| | | | | | | | | | | | | | | |
| Location | R | | - | - | m | - | | Location | R | | - | - | m | - |
| | | | | | | | | | | | | | | |
| Media-Properties | | | - | - | - | | | Media-Properties | R | amr | o | - | - | c |
| | | | | | | |
| Media-Properties | r | mr | c | - | - | - |
| | | | | | | | | | | | | | | |
| Media-Range | R | | o | - | - | c | | Media-Range | R | | o | - | - | c |
| | | | | | | | | | | | | | | |
| Media-Range | r | | c | - | - | - | | Media-Range | r | | c | - | - | - |
| | | | | | | | | | | | | | | |
| Notify-Reason | R | | - | - | - | m | | Notify-Reason | R | | - | - | - | m |
| | | | | | | | | | | | | | | |
| Pipelined-Requests | | amdr | o | o | o | - | | Pipelined-Requests | R | amdr | o | o | - | - |
| | | | | | | | | | | | | | | |
| Proxy-Authenticate | 407 | amr | m | m | m | - | | Proxy-Authenticate | 407 | amr | m | m | m | - |
| | | | | | | | | | | | | | | |
| Proxy-Authorization | R | rd | o | o | o | - | | Proxy-Authorization | R | rd | o | o | o | - |
| | | | | | | | | | | | | | | |
| Proxy-Require | R | ar | o | o | o | - | | Proxy-Require | R | ar | o | o | o | - |
| | | | | | | | | | | | | | | |
| Proxy-Require | r | r | c | c | c | - | | Proxy-Require | r | r | c | c | c | - |
| | | | | | | | | | | | | | | |
| Proxy-Supported | R | amr | c | c | c | - | | Proxy-Supported | R | amr | c | c | c | - |
| | | | | | | | | | | | | | | |
| Proxy-Supported | r | | c | c | c | - | | Proxy-Supported | r | | c | c | c | - |
| | | | | | | | | | | | | | | |
| Public | 501 | admr | m | m | m | - | | Public | 501 | admr | m | m | m | - |
+------------------------+---------+-------+-----+-----+-----+-----+ +------------------------+---------+-------+-----+-----+-----+-----+
Table 11: Overview of RTSP header fields (A-P) related to methods Table 11: Overview of RTSP header fields (A-P) related to methods
GET_PARAMETER, SET_PARAMETER, PLAY_NOTIFY, and REDIRECT. GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY.
+------------------+-------------+-------+-----+-----+-----+-----+ +------------------+---------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY | | Header | Where | Proxy | GPR | SPR | RDR | PNY |
+------------------+-------------+-------+-----+-----+-----+-----+ +------------------+---------+-------+-----+-----+-----+-----+
| Range | R | | o | - | o | m | | Range | R | | o | - | o | m |
| | | | | | | | | | | | | | | |
| Terminate-Reason | R | r | - | - | m | - | | Referrer | R | | o | o | o | - |
| | | | | | | | | Request-Status | R | | - | - | - | c |
| Referrer | R | | o | o | o | - | | | | | | | | |
| | | | | | | | | Require | R | r | o | o | o | - |
| Request-Status | R | | - | - | - | m | | | | | | | | |
| | | | | | | | | Retry-After | 3rr,503 | | o | o | - | - |
| Require | R | r | o | o | o | - | | | | | | | | |
| | | | | | | | | Retry-After | 413 | | o | o | - | - |
| Retry-After | 3rr,413,503 | | o | o | - | - | | | | | | | | |
| | | | | | | | | RTP-Info | R | r | o | - | - | C |
| Retry-After | 413 | | o | o | o | o | | | | | | | | |
| Scale | | | - | - | - | c | | RTP-Info | r | r | c | - | - | - |
| | | | | | | | | | | | | | | |
| Seek-Style | | | - | - | - | - | | Scale | | | - | - | - | c |
| | | | | | | | | | | | | | | |
| Session | R | r | o | o | o | m | | Seek-Style | | | - | - | - | - |
| | | | | | | | | | | | | | | |
| Session | r | r | c | c | o | m | | Session | R | r | o | o | o | m |
| | | | | | | | | | | | | | | |
| Server | R | r | o | o | o | - | | Session | r | r | c | c | o | m |
| | | | | | | | | | | | | | | |
| Server | r | r | o | o | - | - | | Server | R | r | o | o | o | o |
| | | | | | | | | | | | | | | |
| Speed | | | - | - | - | - | | Server | r | r | o | o | - | - |
| | | | | | | | | | | | | | | |
| Supported | R | adrm | o | o | o | - | | Speed | | | - | - | - | - |
| | | | | | | | | | | | | | | |
| Supported | r | adrm | c | c | c | - | | Supported | R | adrm | o | o | o | - |
| | | | | | | | | | | | | | | |
| Timestamp | R | adrm | o | o | o | - | | Supported | r | adrm | c | c | c | - |
| | | | | | | | | | | | | | | |
| Timestamp | c | adrm | m | m | m | - | | Terminate-Reason | R | r | - | - | m | - |
| | | | | | | | | | | | | | | |
| Unsupported | r | arm | c | c | c | - | | Timestamp | R | adrm | o | o | o | - |
| | | | | | | | | | | | | | | |
| User-Agent | R | r | m* | m* | - | - | | Timestamp | c | adrm | m | m | m | - |
| | | | | | | | | | | | | | | |
| User-Agent | r | r | - | - | m* | - | | Unsupported | r | arm | c | c | c | - |
| | | | | | | | | | | | | | | |
| Vary | r | | c | c | - | - | | User-Agent | R | r | m* | m* | - | - |
| | | | | | | | | | | | | | | |
| Via | R | amr | o | o | o | - | | User-Agent | r | r | m* | m* | m* | m* |
| | | | | | | | | | | | | | | |
| Via | c | dr | m | m | m | - | | Vary | r | | c | c | - | - |
| | | | | | | | | | | | | | | |
| WWW-Authenticate | 401 | | m | m | m | - | | Via | R | amr | o | o | o | - |
+------------------+-------------+-------+-----+-----+-----+-----+ | | | | | | | |
| Via | c | dr | m | m | m | - |
| | | | | | | |
| WWW-Authenticate | 401 | | m | m | m | - |
+------------------+---------+-------+-----+-----+-----+-----+
Table 12: Overview of RTSP header fields (R-W) related to methods Table 12: Overview of RTSP header fields (R-W) related to methods
GET_PARAMETER, SET_PARAMETER, PLAY_NOTIFY, and REDIRECT. GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY.
16.1. Accept 16.1. Accept
The Accept request-header field can be used to specify certain The Accept request-header field can be used to specify certain
presentation description content types which are acceptable for the presentation description and parameter media types [RFC4288] which
response. are acceptable for the response to DESCRIBE and GET_PARAMETER
requests.
See Section 20.2.3 for the syntax. See Section 20.2.3 for the syntax.
Example of use: Example of use:
Accept: application/example ;q=1.0, application/sdp Accept: application/example ;q=1.0, application/sdp
16.2. Accept-Credentials 16.2. Accept-Credentials
The Accept-Credentials header is a request header used to indicate to The Accept-Credentials header is a request header used to indicate to
any trusted intermediary how to handle further secured connections to any trusted intermediary how to handle further secured connections to
skipping to change at page 113, line 25 skipping to change at page 114, line 39
In a request the header MUST contain the method (User, Proxy, or Any) In a request the header MUST contain the method (User, Proxy, or Any)
for approving credentials selected by the requester. The method MUST for approving credentials selected by the requester. The method MUST
NOT be changed by any proxy, unless it is "proxy" when a proxy MAY NOT be changed by any proxy, unless it is "proxy" when a proxy MAY
change it to "user" to take the role of user approving each further change it to "user" to take the role of user approving each further
hop. If the method is "User" the header contains zero or more of hop. If the method is "User" the header contains zero or more of
credentials that the client accepts. The header may contain zero credentials that the client accepts. The header may contain zero
credentials in the first RTSP request to a RTSP server when using the credentials in the first RTSP request to a RTSP server when using the
"User" method. This as the client has not yet received any "User" method. This as the client has not yet received any
credentials to accept. Each credential MUST consist of one URI credentials to accept. Each credential MUST consist of one URI
identifying the proxy or server, the hash algorithm identifier, and identifying the proxy or server, the hash algorithm identifier, and
the hash over that entity's DER encoded certificate [RFC5280] in the hash over that agent's DER encoded certificate [RFC5280] in
Base64 [RFC4648]. All RTSP clients and proxies MUST implement the Base64 [RFC4648]. All RTSP clients and proxies MUST implement the
SHA-256[FIPS-pub-180-2] algorithm for computation of the hash of the SHA-256[FIPS-pub-180-2] algorithm for computation of the hash of the
DER encoded certificate. The SHA-256 algorithm is identified by the DER encoded certificate. The SHA-256 algorithm is identified by the
token "sha-256". token "sha-256".
The intention with allowing for other hash algorithms is to enable The intention with allowing for other hash algorithms is to enable
the future retirement of algorithms that are not implemented the future retirement of algorithms that are not implemented
somewhere else than here. Thus the definition of future algorithms somewhere else than here. Thus the definition of future algorithms
for this purpose is intended to be extremely limited. A feature tag for this purpose is intended to be extremely limited. A feature tag
can be used to ensure that support for the replacement algorithm can be used to ensure that support for the replacement algorithm
exist. exist.
Example: Example:
Accept-Credentials:User Accept-Credentials:User
"rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=, "rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=,
"rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M= "rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M=
16.3. Accept-Encoding 16.3. Accept-Encoding
The Accept-Encoding request-header field is similar to Accept, but The Accept-Encoding request-header field is similar to Accept, but
restricts the content-codings that are acceptable in the response. restricts the content-codings, i.e. transformation codings of the
message body like gzip compression, that are acceptable in the
response.
A server tests whether a content-coding is acceptable, according to A server tests whether a content-coding is acceptable, according to
an Accept-Encoding field, using these rules: an Accept-Encoding field, using these rules:
1. If the content-coding is one of the content-codings listed in the 1. If the content-coding is one of the content-codings listed in the
Accept-Encoding field, then it is acceptable, unless it is Accept-Encoding field, then it is acceptable, unless it is
accompanied by a qvalue of 0. (As defined in section 3.9, a accompanied by a qvalue of 0. (As defined in section 3.9, a
qvalue of 0 means "not acceptable.") qvalue of 0 means "not acceptable.")
2. The special "*" symbol in an Accept-Encoding field matches any 2. The special "*" symbol in an Accept-Encoding field matches any
available content-coding not explicitly listed in the header available content-coding not explicitly listed in the header
field. field.
3. If multiple content-codings are acceptable, then the acceptable 3. If multiple content-codings are acceptable, then the acceptable
content-coding with the highest non-zero qvalue is preferred. content-coding with the highest non-zero qvalue is preferred.
4. The "identity" content-coding is always acceptable, unless 4. The "identity" content-coding is always acceptable, i.e. no
specifically refused because the Accept-Encoding field includes transformation at all, unless specifically refused because the
"identity;q=0", or because the field includes "*;q=0" and does Accept-Encoding field includes "identity;q=0", or because the
not explicitly include the "identity" content-coding. If the field includes "*;q=0" and does not explicitly include the
Accept-Encoding field-value is empty, then only the "identity" "identity" content-coding. If the Accept-Encoding field-value is
encoding is acceptable. empty, then only the "identity" encoding is acceptable.
If an Accept-Encoding field is present in a request, and if the If an Accept-Encoding field is present in a request, and if the
server cannot send a response which is acceptable according to the server cannot send a response which is acceptable according to the
Accept-Encoding header, then the server SHOULD send an error response Accept-Encoding header, then the server SHOULD send an error response
with the 406 (Not Acceptable) status code. with the 406 (Not Acceptable) status code.
If no Accept-Encoding field is present in a request, the server MAY If no Accept-Encoding field is present in a request, the server MAY
assume that the client will accept any content coding. In this case, assume that the client will accept any content coding. In this case,
if "identity" is one of the available content-codings, then the if "identity" is one of the available content-codings, then the
server SHOULD use the "identity" content-coding, unless it has server SHOULD use the "identity" content-coding, unless it has
skipping to change at page 114, line 48 skipping to change at page 116, line 17
The Accept-Language request-header field is similar to Accept, but The Accept-Language request-header field is similar to Accept, but
restricts the set of natural languages that are preferred as a restricts the set of natural languages that are preferred as a
response to the request. Note that the language specified applies to response to the request. Note that the language specified applies to
the presentation description and any reason phrases, but not the the presentation description and any reason phrases, but not the
media content. media content.
A language tag identifies a natural language spoken, written, or A language tag identifies a natural language spoken, written, or
otherwise conveyed by human beings for communication of information otherwise conveyed by human beings for communication of information
to other human beings. Computer languages are explicitly excluded. to other human beings. Computer languages are explicitly excluded.
The syntax and registry of RTSP 2.0 language tags is the same as that The syntax and registry of RTSP 2.0 language tags is the same as that
defined by [RFC4646]. defined by [RFC5646].
Each language-range MAY be given an associated quality value which Each language-range MAY be given an associated quality value which
represents an estimate of the user's preference for the languages represents an estimate of the user's preference for the languages
specified by that range. The quality value defaults to "q=1". For specified by that range. The quality value defaults to "q=1". For
example: example:
Accept-Language: da, en-gb;q=0.8, en;q=0.7 Accept-Language: da, en-gb;q=0.8, en;q=0.7
would mean: "I prefer Danish, but will accept British English and would mean: "I prefer Danish, but will accept British English and
other types of English." A language-range matches a language-tag if other types of English." A language-range matches a language-tag if
skipping to change at page 115, line 34 skipping to change at page 117, line 7
Language field is the quality value of the longest language-range in Language field is the quality value of the longest language-range in
the field that matches the language-tag. If no language-range in the the field that matches the language-tag. If no language-range in the
field matches the tag, the language quality factor assigned is 0. If field matches the tag, the language quality factor assigned is 0. If
no Accept-Language header is present in the request, the server no Accept-Language header is present in the request, the server
SHOULD assume that all languages are equally acceptable. If an SHOULD assume that all languages are equally acceptable. If an
Accept-Language header is present, then all languages which are Accept-Language header is present, then all languages which are
assigned a quality factor greater than 0 are acceptable. assigned a quality factor greater than 0 are acceptable.
16.5. Accept-Ranges 16.5. Accept-Ranges
The Accept-Ranges request and response-header field allows indication The Accept-Ranges general-header field allows indication of the
of the format supported in the Range header. The client MUST include format supported in the Range header. The client MUST include the
the header in SETUP requests to indicate which formats it support to header in SETUP requests to indicate which formats it support to
receive in PLAY and PAUSE responses, and REDIRECT requests. The receive in PLAY and PAUSE responses, and REDIRECT requests. The
server MUST include the header in SETUP and 456 error responses to server MUST include the header in SETUP and 456 error responses to
indicate the formats supported for the resource indicated by the indicate the formats supported for the resource indicated by the
request URI. The header MAY be included in GET_PARAMETER request and request URI. The header MAY be included in GET_PARAMETER request and
response pairs. The GET_PARAMETER request MUST contain a Session response pairs. The GET_PARAMETER request MUST contain a Session
header to identify the session context the request are related to. header to identify the session context the request are related to.
The requester and responder will indicate their capabilities The requester and responder will indicate their capabilities
regarding Range formats respectively. regarding Range formats respectively.
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
The syntax is defined in Section 20.2.3. The syntax is defined in Section 20.2.3.
16.6. Allow 16.6. Allow
The Allow message-header field lists the methods supported by the The Allow message-header field lists the methods supported by the
resource identified by the Request-URI. The purpose of this field is resource identified by the Request-URI. The purpose of this field is
to strictly inform the recipient of valid methods associated with the to strictly inform the recipient of valid methods associated with the
resource. An Allow header field MUST be present in a 405 (Method Not resource. An Allow header field MUST be present in a 405 (Method Not
skipping to change at page 116, line 24 skipping to change at page 117, line 42
The Allow MUST also be included in SETUP and DESCRIBE responses, if The Allow MUST also be included in SETUP and DESCRIBE responses, if
the methods allowed for the resource is different than the minimal the methods allowed for the resource is different than the minimal
implementation set. implementation set.
Example of use: Example of use:
Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE
16.7. Authorization 16.7. Authorization
An RTSP client that wishes to authenticate itself with a server, An RTSP client that wishes to authenticate itself with a server using
usually, but not necessarily, after receiving a 401 response, does so authentication mechanism from HTTP [RFC2617] , usually, but not
by including an Authorization request-header field with the request. necessarily, after receiving a 401 response, does so by including an
The Authorization field value consists of credentials containing the Authorization request-header field with the request. The
Authorization field value consists of credentials containing the
authentication information of the user agent for the realm of the authentication information of the user agent for the realm of the
resource being requested. resource being requested.
If a request is authenticated and a realm specified, the same If a request is authenticated and a realm specified, the same
credentials SHOULD be valid for all other requests within this realm credentials SHOULD be valid for all other requests within this realm
(assuming that the authentication scheme itself does not require (assuming that the authentication scheme itself does not require
otherwise, such as credentials that vary according to a challenge otherwise, such as credentials that vary according to a challenge
value or using synchronized clocks). value or using synchronized clocks).
When a shared cache (see Section 18) receives a request containing an When a shared cache (see Section 18) receives a request containing an
skipping to change at page 117, line 47 skipping to change at page 119, line 18
The Cache-Control general-header field is used to specify directives The Cache-Control general-header field is used to specify directives
that MUST be obeyed by all caching mechanisms along the request/ that MUST be obeyed by all caching mechanisms along the request/
response chain. response chain.
Cache directives MUST be passed through by a proxy or gateway Cache directives MUST be passed through by a proxy or gateway
application, regardless of their significance to that application, application, regardless of their significance to that application,
since the directives may be applicable to all recipients along the since the directives may be applicable to all recipients along the
request/response chain. It is not possible to specify a cache- request/response chain. It is not possible to specify a cache-
directive for a specific cache. directive for a specific cache.
Cache-Control should only be specified in a SETUP request and its Cache-Control should only be specified in a DESCRIBE, GET_PARAMETER,
response. Note: Cache-Control does not govern the caching of SET_PARAMETER and SETUP request and its response. Note: Cache-
responses as for HTTP, instead it applies to the media stream Control does not govern only the caching of responses as for HTTP,
identified by the SETUP request. The RTSP requests are generally not instead it also applies to the media stream identified by the SETUP
cacheable, for further information see Section 18. Below is the request. The RTSP requests are generally not cacheable, for further
description of the cache directives that can be included in the information see Section 18. Below is the description of the cache
Cache-Control header. directives that can be included in the Cache-Control header.
no-cache: Indicates that the media stream MUST NOT be cached no-cache: Indicates that the media stream MUST NOT be cached
anywhere. This allows an origin server to prevent caching even anywhere. This allows an origin server to prevent caching even
by caches that have been configured to return stale responses by caches that have been configured to return stale responses
to client requests. Note, there is no security function to client requests. Note, there is no security function
enforcing that the content can't be cached. enforcing that the content can't be cached.
public: Indicates that the media stream is cacheable by any cache. public: Indicates that the media stream is cacheable by any cache.
private: Indicates that the media stream is intended for a single private: Indicates that the media stream is intended for a single
skipping to change at page 119, line 45 skipping to change at page 121, line 17
client has supplied its own validator in the request, the client has supplied its own validator in the request, the
supplied validator might differ from the validator currently supplied validator might differ from the validator currently
stored with the cache entry. In this case, the cache MAY use stored with the cache entry. In this case, the cache MAY use
either validator in making its own request without affecting either validator in making its own request without affecting
semantic transparency. semantic transparency.
However, the choice of validator might affect performance. The best However, the choice of validator might affect performance. The best
approach is for the intermediate cache to use its own validator when approach is for the intermediate cache to use its own validator when
making its request. If the server replies with 304 (Not Modified), making its request. If the server replies with 304 (Not Modified),
then the cache can return its now validated copy to the client with a then the cache can return its now validated copy to the client with a
200 (OK) response. If the server replies with a new entity and cache 200 (OK) response. If the server replies with a new message body and
validator, however, the intermediate cache can compare the returned cache validator, however, the intermediate cache can compare the
validator with the one provided in the client's request, using the returned validator with the one provided in the client's request,
strong comparison function. If the client's validator is equal to using the strong comparison function. If the client's validator is
the origin server's, then the intermediate cache simply returns 304 equal to the origin server's, then the intermediate cache simply
(Not Modified). Otherwise, it returns the new entity with a 200 (OK) returns 304 (Not Modified). Otherwise, it returns the new message
response. body with a 200 (OK) response.
16.11. Connection 16.11. Connection
The Connection general-header field allows the sender to specify The Connection general-header field allows the sender to specify
options that are desired for that particular connection and MUST NOT options that are desired for that particular connection and MUST NOT
be communicated by proxies over further connections. be communicated by proxies over further connections.
RTSP 2.0 proxies MUST parse the Connection header field before a RTSP 2.0 proxies MUST parse the Connection header field before a
message is forwarded and, for each connection-token in this field, message is forwarded and, for each connection-token in this field,
remove any header field(s) from the message with the same name as the remove any header field(s) from the message with the same name as the
connection-token. Connection options are signaled by the presence of connection-token. Connection options are signaled by the presence of
a connection-token in the Connection header field, not by any a connection-token in the Connection header field, not by any
corresponding additional header field(s), since the additional header corresponding additional header field(s), since the additional header
field may not be sent if there are no parameters associated with that field may not be sent if there are no parameters associated with that
connection option. connection option.
Message headers listed in the Connection header MUST NOT include end- Message headers listed in the Connection header MUST NOT include end-
to-end headers, such as Cache-Control. to-end headers, such as Cache-Control.
RTSP 2.0 defines the "close" connection option for the sender to
signal that the connection will be closed after completion of the
response. For example, Connection: close in either the request or
the response header fields indicates that the connection SHOULD NOT
be considered `persistent' (Section 10.2) after the current request/
response is complete.
The use of the connection option "close" in RTSP messages SHOULD be The use of the connection option "close" in RTSP messages SHOULD be
limited to error messages when the server is unable to recover and limited to error messages when the server is unable to recover and
therefore see it necessary to close the connection. The reason is therefore see it necessary to close the connection. The reason is
that the client has the choice of continuing using a connection that the client has the choice of continuing using a connection
indefinitely, as long as it sends valid messages. indefinitely, as long as it sends valid messages.
16.12. Connection-Credentials 16.12. Connection-Credentials
The Connection-Credentials response header is used to carry the chain The Connection-Credentials response header is used to carry the chain
of credentials of any next hop that need to be approved by the of credentials of any next hop that need to be approved by the
skipping to change at page 121, line 49 skipping to change at page 123, line 31
16.14. Content-Encoding 16.14. Content-Encoding
The Content-Encoding header field is used as a modifier to the media- The Content-Encoding header field is used as a modifier to the media-
type. When present, its value indicates what additional content type. When present, its value indicates what additional content
codings have been applied to the message body, and thus what decoding codings have been applied to the message body, and thus what decoding
mechanisms must be applied in order to obtain the media-type mechanisms must be applied in order to obtain the media-type
referenced by the Content-Type header field. Content-Encoding is referenced by the Content-Type header field. Content-Encoding is
primarily used to allow a document to be compressed without losing primarily used to allow a document to be compressed without losing
the identity of its underlying media type. the identity of its underlying media type.
The content-coding is a characteristic of the entity identified by The content-coding is a characteristic of the message body identified
the Request-URI. Typically, the message body is stored with this by the Request-URI. Typically, the message body is stored with this
encoding and is only decoded before rendering or analogous usage. encoding and is only decoded before rendering or analogous usage.
However, a non-transparent proxy MAY modify the content-coding if the However, a non-transparent proxy MAY modify the content-coding if the
new coding is known to be acceptable to the recipient, unless the new coding is known to be acceptable to the recipient, unless the
"no-transform" cache-control directive is present in the message. "no-transform" cache-control directive is present in the message.
If the content-coding of an message body is not "identity", then the If the content-coding of an message body is not "identity", then the
response MUST include a Content-Encoding entity-header that lists the response MUST include a Content-Encoding Message-body header that
non-identity content-coding(s) used. lists the non-identity content-coding(s) used.
If the content-coding of an message body in a request message is not If the content-coding of an message body in a request message is not
acceptable to the origin server, the server SHOULD respond with a acceptable to the origin server, the server SHOULD respond with a
status code of 415 (Unsupported Media Type). status code of 415 (Unsupported Media Type).
If multiple encodings have been applied to a message body, the If multiple encodings have been applied to a message body, the
content codings MUST be listed in the order in which they were content codings MUST be listed in the order in which they were
applied. Additional information about the encoding parameters MAY be applied, first to last from left to right. Additional information
provided by other header fields not defined by this specification. about the encoding parameters MAY be provided by other header fields
not defined by this specification.
16.15. Content-Language 16.15. Content-Language
The Content-Language header field describes the natural language(s) The Content-Language header field describes the natural language(s)
of the intended audience for the enclosed message body. Note that of the intended audience for the enclosed message body. Note that
this might not be equivalent to all the languages used within the this might not be equivalent to all the languages used within the
message body. message body.
Language tags are mentioned in Section 16.4. The primary purpose of Language tags are mentioned in Section 16.4. The primary purpose of
Content-Language is to allow a user to identify and differentiate Content-Language is to allow a user to identify and differentiate
skipping to change at page 122, line 49 skipping to change at page 124, line 32
sender does not consider it to be specific to any natural language, sender does not consider it to be specific to any natural language,
or that the sender does not know for which language it is intended. or that the sender does not know for which language it is intended.
Multiple languages MAY be listed for content that is intended for Multiple languages MAY be listed for content that is intended for
multiple audiences. For example, a rendition of the "Treaty of multiple audiences. For example, a rendition of the "Treaty of
Waitangi," presented simultaneously in the original Maori and English Waitangi," presented simultaneously in the original Maori and English
versions, would call for versions, would call for
Content-Language: mi, en Content-Language: mi, en
However, just because multiple languages are present within an entity However, just because multiple languages are present within an
does not mean that it is intended for multiple linguistic audiences. message body does not mean that it is intended for multiple
An example would be a beginner's language primer, such as "A First linguistic audiences. An example would be a beginner's language
Lesson in Latin," which is clearly intended to be used by an English- primer, such as "A First Lesson in Latin," which is clearly intended
literate audience. In this case, the Content-Language would properly to be used by an English-literate audience. In this case, the
only include "en". Content-Language would properly only include "en".
Content-Language MAY be applied to any media type -- it is not Content-Language MAY be applied to any media type -- it is not
limited to textual documents. limited to textual documents.
16.16. Content-Length 16.16. Content-Length
The Content-Length general-header field contains the length of the The Content-Length general-header field contains the length of the
message body of the RTSP message (i.e. after the double CRLF message body of the RTSP message (i.e. after the double CRLF
following the last header). Unlike HTTP, it MUST be included in all following the last header). Unlike HTTP, it MUST be included in all
messages that carry a message body beyond the header portion of the messages that carry a message body beyond the header portion of the
RTSP message. If it is missing, a default value of zero is assumed. RTSP message. If it is missing, a default value of zero is assumed.
Any Content-Length greater than or equal to zero is a valid value. Any Content-Length greater than or equal to zero is a valid value.
16.17. Content-Location 16.17. Content-Location
The Content-Location header field MAY be used to supply the resource The Content-Location header field MAY be used to supply the resource
location for the entity enclosed in the message when that entity is location for the message body enclosed in the message when that body
accessible from a location separate from the requested resource's is accessible from a location separate from the requested resource's
URI. A server SHOULD provide a Content-Location for the variant URI. A server SHOULD provide a Content-Location for the variant
corresponding to the response entity; especially in the case where a corresponding to the response message body; especially in the case
resource has multiple entities associated with it, and those entities where a resource has multiple variants associated with it, and those
actually have separate locations by which they might be individually entities actually have separate locations by which they might be
accessed, the server SHOULD provide a Content-Location for the individually accessed, the server SHOULD provide a Content-Location
particular variant which is returned. for the particular variant which is returned.
The Content-Location value is not a replacement for the original The Content-Location value is not a replacement for the original
requested URI; it is only a statement of the location of the resource requested URI; it is only a statement of the location of the resource
corresponding to this particular entity at the time of the request. corresponding to this particular variant at the time of the request.
Future requests MAY specify the Content-Location URI as the request- Future requests MAY specify the Content-Location URI as the request
URI if the desire is to identify the source of that particular URI if the desire is to identify the source of that particular
entity. variant.
A cache cannot assume that an entity with a Content-Location A cache cannot assume that an message body with a Content-Location
different from the URI used to retrieve it can be used to respond to different from the URI used to retrieve it can be used to respond to
later requests on that Content-Location URI. However, the Content- later requests on that Content-Location URI. However, the Content-
Location can be used to differentiate between multiple entities Location can be used to differentiate between multiple variants
retrieved from a single requested resource. retrieved from a single requested resource.
If the Content-Location is a relative URI, the relative URI is If the Content-Location is a relative URI, the relative URI is
interpreted relative to the Request-URI. interpreted relative to the Request-URI.
16.18. Content-Type 16.18. Content-Type
The Content-Type header indicates the media type of the message body The Content-Type header indicates the media type of the message body
sent to the recipient. Note that the content types suitable for RTSP sent to the recipient. Note that the content types suitable for RTSP
are likely to be restricted in practice to presentation descriptions are likely to be restricted in practice to presentation descriptions
skipping to change at page 124, line 23 skipping to change at page 126, line 8
number as the original (i.e. the sequence number is not incremented number as the original (i.e. the sequence number is not incremented
for retransmissions of the same request). For each new RTSP request for retransmissions of the same request). For each new RTSP request
the CSeq value MUST be incremented by one. The initial sequence the CSeq value MUST be incremented by one. The initial sequence
number MAY be any number, however, it is RECOMMENDED to start at 0. number MAY be any number, however, it is RECOMMENDED to start at 0.
Each sequence number series is unique between each requester and Each sequence number series is unique between each requester and
responder, i.e. the client has one series for its request to a server responder, i.e. the client has one series for its request to a server
and the server has another when sending request to the client. Each and the server has another when sending request to the client. Each
requester and responder is identified with its network address. requester and responder is identified with its network address.
Proxies that aggregate several sessions on the same transport will Proxies that aggregate several sessions on the same transport will
regularly need to renumber the CSeq header field in requests and have to ensure that the requests sent towards a particular server
responses to fulfill the rules for the header. have a joint sequence number space, i.e., they will regularly need to
renumber the CSeq header field in requests (from proxy to server) and
responses (from server to proxy) to fulfill the rules for the header.
The proxy MUST increase the CSeq by one for each request it
transmits, without regard of different sessions.
Example: Example:
CSeq: 239 CSeq: 239
16.20. Date 16.20. Date
The Date header field represents the date and time at which the The Date header field represents the date and time at which the
message was originated. The inclusion of the Date header in RTSP message was originated. The inclusion of the Date header in RTSP
message follows these rules: message follows these rules:
skipping to change at page 125, line 18 skipping to change at page 127, line 7
recipient . An RTSP implementation without a clock MUST NOT cache recipient . An RTSP implementation without a clock MUST NOT cache
responses without revalidating them on every use. An RTSP cache, responses without revalidating them on every use. An RTSP cache,
especially a shared cache, SHOULD use a mechanism, such as NTP, to especially a shared cache, SHOULD use a mechanism, such as NTP, to
synchronize its clock with a reliable external standard. synchronize its clock with a reliable external standard.
The RTSP-date sent in a Date header SHOULD NOT represent a date and The RTSP-date sent in a Date header SHOULD NOT represent a date and
time subsequent to the generation of the message. It SHOULD time subsequent to the generation of the message. It SHOULD
represent the best available approximation of the date and time of represent the best available approximation of the date and time of
message generation, unless the implementation has no means of message generation, unless the implementation has no means of
generating a reasonably accurate date and time. In theory, the date generating a reasonably accurate date and time. In theory, the date
ought to represent the moment just before the entity is generated. ought to represent the moment just before the message body is
In practice, the date can be generated at any time during the message generated. In practice, the date can be generated at any time during
origination without affecting its semantic value. the message origination without affecting its semantic value.
16.21. Expires 16.21. Expires
The Expires message-header field gives a date and time after which The Expires message-header field gives a date and time after which
the description or media-stream should be considered stale. The the description or media-stream should be considered stale. The
interpretation depends on the method: interpretation depends on the method:
DESCRIBE response: The Expires header indicates a date and time DESCRIBE response: The Expires header indicates a date and time
after which the presentation description (body) SHOULD be after which the presentation description (body) SHOULD be
considered stale. considered stale.
skipping to change at page 125, line 45 skipping to change at page 127, line 34
A stale cache entry may not normally be returned by a cache (either a A stale cache entry may not normally be returned by a cache (either a
proxy cache or an user agent cache) unless it is first validated with proxy cache or an user agent cache) unless it is first validated with
the origin server (or with an intermediate cache that has a fresh the origin server (or with an intermediate cache that has a fresh
copy of the message body). See Section 18 for further discussion of copy of the message body). See Section 18 for further discussion of
the expiration model. the expiration model.
The presence of an Expires field does not imply that the original The presence of an Expires field does not imply that the original
resource will change or cease to exist at, before, or after that resource will change or cease to exist at, before, or after that
time. time.
The format is an absolute date and time as defined by RTSP-date: The format is an absolute date and time as defined by RTSP-date. An
example of its use is
An example of its use is
Expires: Thu, 01 Dec 1994 16:00:00 GMT Expires: Thu, 01 Dec 1994 16:00:00 GMT
RTSP/2.0 clients and caches MUST treat other invalid date formats, RTSP/2.0 clients and caches MUST treat other invalid date formats,
especially including the value "0", as having occurred in the past especially including the value "0", as having occurred in the past
(i.e., already expired). (i.e., already expired).
To mark a response as "already expired," an origin server should use To mark a response as "already expired," an origin server should use
an Expires date that is equal to the Date header value. To mark a an Expires date that is equal to the Date header value. To mark a
response as "never expires," an origin server SHOULD use an Expires response as "never expires," an origin server SHOULD use an Expires
date approximately one year from the time the response is sent. date approximately one year from the time the response is sent.
skipping to change at page 126, line 42 skipping to change at page 128, line 34
used. used.
The client SHOULD NOT send the From header field without the user's The client SHOULD NOT send the From header field without the user's
approval, as it might conflict with the user's privacy interests or approval, as it might conflict with the user's privacy interests or
their site's security policy. It is strongly recommended that the their site's security policy. It is strongly recommended that the
user be able to disable, enable, and modify the value of this field user be able to disable, enable, and modify the value of this field
at any time prior to a request. at any time prior to a request.
16.23. If-Match 16.23. If-Match
See [H14.24].
The If-Match request-header field is especially useful for ensuring The If-Match request-header field is especially useful for ensuring
the integrity of the presentation description, in both the case where the integrity of the presentation description, in both the case where
it is fetched via means external to RTSP (such as HTTP), or in the it is fetched via means external to RTSP (such as HTTP), or in the
case where the server implementation is guaranteeing the integrity of case where the server implementation is guaranteeing the integrity of
the description between the time of the DESCRIBE message and the the description between the time of the DESCRIBE message and the
SETUP message. By including the MTag given in or with the session SETUP message. By including the MTag given in or with the session
description in a SETUP request, the client ensures that resources set description in a in a If-Match header part of the SETUP request, the
up are matching the description. A SETUP request for which the MTag client ensures that resources set up are matching the description. A
validation check fails, MUST response using 412 (Precondition SETUP request with the If-Match header for which the MTag validation
Failed). check fails, MUST response using 412 (Precondition Failed).
This validation check is also very useful if a session has been This validation check is also very useful if a session has been
redirected from one server to another. redirected from one server to another.
16.24. If-Modified-Since 16.24. If-Modified-Since
The If-Modified-Since request-header field is used with the DESCRIBE The If-Modified-Since request-header field is used with the DESCRIBE
and SETUP methods to make them conditional. If the requested variant and SETUP methods to make them conditional. If the requested variant
has not been modified since the time specified in this field, a has not been modified since the time specified in this field, a
description will not be returned from the server (DESCRIBE) or a description will not be returned from the server (DESCRIBE) or a
skipping to change at page 127, line 34 skipping to change at page 129, line 23
This request header can be used with one or several message body tags This request header can be used with one or several message body tags
to make DESCRIBE requests conditional. A client that has one or more to make DESCRIBE requests conditional. A client that has one or more
message bodies previously obtained from the resource, can verify that message bodies previously obtained from the resource, can verify that
none of those entities is current by including a list of their none of those entities is current by including a list of their
associated message body tags in the If-None-Match header field. The associated message body tags in the If-None-Match header field. The
purpose of this feature is to allow efficient updates of cached purpose of this feature is to allow efficient updates of cached
information with a minimum amount of transaction overhead. As a information with a minimum amount of transaction overhead. As a
special case, the value "*" matches any current entity of the special case, the value "*" matches any current entity of the
resource. resource.
If any of the message body tags match the message body tag of the if any of the message body tags match the message body tag of the
message body that would have been returned in the response to a message body that would have been returned in the response to a
similar DESCRIBE request (without the If-None-Match header) on that similar DESCRIBE request (without the If-None-Match header) on that
resource, or if "*" is given and any current entity exists for that resource, or if "*" is given and any current entity exists for that
resource, then the server MUST NOT perform the requested method, resource, then the server MUST NOT perform the requested method,
unless required to do so because the resource's modification date unless required to do so because the resource's modification date
fails to match that supplied in an If-Modified-Since header field in fails to match that supplied in an If-Modified-Since header field in
the request. Instead, if the request method was DESCRIBE, the server the request. Instead, if the request method was DESCRIBE, the server
SHOULD respond with a 304 (Not Modified) response, including the SHOULD respond with a 304 (Not Modified) response, including the
cache-related header fields (particularly MTag) of one of the message cache-related header fields (particularly MTag) of one of the message
bodies that matched. For all other request methods, the server MUST bodies that matched. For all other request methods, the server MUST
skipping to change at page 128, line 14 skipping to change at page 129, line 51
exist, but MUST also ignore any If-Modified-Since header field(s) in exist, but MUST also ignore any If-Modified-Since header field(s) in
the request. That is, if no message body tags match, then the server the request. That is, if no message body tags match, then the server
MUST NOT return a 304 (Not Modified) response. MUST NOT return a 304 (Not Modified) response.
If the request would, without the If-None-Match header field, result If the request would, without the If-None-Match header field, result
in anything other than a 2xx or 304 status, then the If-None-Match in anything other than a 2xx or 304 status, then the If-None-Match
header MUST be ignored. (See Section 18.1.4 for a discussion of header MUST be ignored. (See Section 18.1.4 for a discussion of
server behavior when both If-Modified-Since and If-None-Match appear server behavior when both If-Modified-Since and If-None-Match appear
in the same request.) in the same request.)
The meaning of "If-None-Match: *" is that the method MUST NOT be
performed if the representation selected by the origin server (or by
a cache, possibly using the Vary mechanism, see Section 16.55)
exists, and SHOULD be performed if the representation does not exist.
This feature is intended to be useful in preventing races between PUT
operations.
The result of a request having both an If-None-Match header field and The result of a request having both an If-None-Match header field and
either an If-Match or an If-Unmodified-Since header fields is an If-Match header field is unspecified and MUST be considered an
undefined by this specification. illegal request.
16.26. Last-Modified 16.26. Last-Modified
The Last-Modified message-header field indicates the date and time at The Last-Modified message-header field indicates the date and time at
which the origin server believes the presentation description or which the origin server believes the presentation description or
media stream was last modified. For the method DESCRIBE, the header media stream was last modified. For the method DESCRIBE, the header
field indicates the last modification date and time of the field indicates the last modification date and time of the
description, for SETUP that of the media stream. description, for SETUP that of the media stream.
An origin server MUST NOT send a Last-Modified date which is later An origin server MUST NOT send a Last-Modified date which is later
than the server's time of message origination. In such cases, where than the server's time of message origination. In such cases, where
the resource's last modification would indicate some time in the the resource's last modification would indicate some time in the
future, the server MUST replace that date with the message future, the server MUST replace that date with the message
origination date. origination date.
An origin server SHOULD obtain the Last-Modified value of the entity An origin server SHOULD obtain the Last-Modified value of the message
as close as possible to the time that it generates the Date value of body as close as possible to the time that it generates the Date
its response. This allows a recipient to make an accurate assessment value of its response. This allows a recipient to make an accurate
of the entity's modification time, especially if the entity changes assessment of the message body's modification time, especially if the
near the time that the response is generated. message body changes near the time that the response is generated.
RTSP servers SHOULD send Last-Modified whenever feasible. RTSP servers SHOULD send Last-Modified whenever feasible.
16.27. Location 16.27. Location
The Location response-header field is used to redirect the recipient The Location response-header field is used to redirect the recipient
to a location other than the Request-URI for completion of the to a location other than the Request-URI for completion of the
request or identification of a new resource. For 3xx responses, the request or identification of a new resource. For 3xx responses, the
location SHOULD indicate the server's preferred URI for automatic location SHOULD indicate the server's preferred URI for automatic
redirection to the resource. The field value consists of a single redirection to the resource. The field value consists of a single
absolute URI. absolute URI.
Note: The Content-Location header field (Section 16.17) differs from Note: The Content-Location header field (Section 16.17) differs from
Location in that the Content-Location identifies the original Location in that the Content-Location identifies the original
location of the entity enclosed in the request. It is therefore location of the message body enclosed in the request. It is
possible for a response to contain header fields for both Location therefore possible for a response to contain header fields for both
and Content-Location. Also, see Section 18.2 for cache requirements Location and Content-Location. Also, see Section 18.2 for cache
of some methods. requirements of some methods.
16.28. Media-Properties 16.28. Media-Properties
This general header is used in SETUP response or PLAY_NOTIFY requests This general header is used in SETUP response or PLAY_NOTIFY requests
to indicate the media's properties that currently are applicable to to indicate the media's properties that currently are applicable to
the RTSP session. PLAY_NOTIFY MAY be used to modify these properties the RTSP session. PLAY_NOTIFY MAY be used to modify these properties
at any point. However, the client SHOULD have received the update at any point. However, the client SHOULD have received the update
prior to that any action related to the new media properties take prior to that any action related to the new media properties take
affect. For aggregated sessions, the Media-Properties header will be effect. For aggregated sessions, the Media-Properties header will be
returned in each SETUP response. The header received in the latest returned in each SETUP response. The header received in the latest
response is the one that applies on the whole session from this point response is the one that applies on the whole session from this point
until any future update. The header MAY be included without value in until any future update. The header MAY be included without value in
GET_PARAMETER requests to the server with a Session header included GET_PARAMETER requests to the server with a Session header included
to query the current Media-Properties for the session. The responder to query the current Media-Properties for the session. The responder
MUST include the current session's media properties. MUST include the current session's media properties.
The media properties expressed by this header is the one applicable The media properties expressed by this header is the one applicable
to all media in the RTSP session. For aggregated sessions, the to all media in the RTSP session. For aggregated sessions, the
header expressed the combined media-properties. As a result header expressed the combined media-properties. As a result
skipping to change at page 130, line 16 skipping to change at page 131, line 42
Random-Access: Indicates that random access is possible. May Random-Access: Indicates that random access is possible. May
optionally include a floating point value in seconds indicating optionally include a floating point value in seconds indicating
the longest duration between any two random access points in the longest duration between any two random access points in
the media. the media.
Begining-Only: Seeking is limited to the beginning only. Begining-Only: Seeking is limited to the beginning only.
No-Seeking: No seeking is possible. No-Seeking: No seeking is possible.
Content Modifications Content Modifications:
Immutable: The content will not be changed during the life-time Immutable: The content will not be changed during the life-time
of the RTSP session. of the RTSP session.
Dynamic: The content may be changed based on external methods or Dynamic: The content may be changed based on external methods or
triggers triggers
Time-Progressing The media accessible progress as wallclock time Time-Progressing The media accessible progress as wallclock time
progresses. progresses.
Retention Retention:
Unlimited: Content will be retained for the duration of the life- Unlimited: Content will be retained for the duration of the life-
time of the RTSP session. time of the RTSP session.
Time-Limited: Content will be retained at least until the Time-Limited: Content will be retained at least until the
specified wallclock time. The time must be provided in the specified wallclock time. The time must be provided in the
absolute time format specified in Section Section 4.6. absolute time format specified in Section 4.6.
Time-Duration Each individual media unit is retained for at least Time-Duration Each individual media unit is retained for at least
the specified time duration. This definition allows for the specified time duration. This definition allows for
retaining data with a time based sliding window. The time retaining data with a time based sliding window. The time
duration is expressed as floating point number in seconds. 0.0 duration is expressed as floating point number in seconds. 0.0
is a valid value as this indicates that no data is retained in is a valid value as this indicates that no data is retained in
a time-progressing session. a time-progressing session.
Supported Scale: Supported Scale:
Scales: A quoted comma separated list of one or more decimal Scales: A quoted comma separated list of one or more decimal
values or ranges of scale values supported by the content in values or ranges of scale values supported by the content in
arbitary order. A range has a start and stop value separated arbitrary order. A range has a start and stop value separated
by a colon. A range indicates that the content supports fine by a colon. A range indicates that the content supports fine
grained selection of scale values. Fine grained allows for grained selection of scale values. Fine grained allows for
steps at least as small as one tenth of a scale value. steps at least as small as one tenth of a scale value.
Negative values are supported. The value 0 have no meaning and Negative values are supported. The value 0 have no meaning and
must not be used. must not be used.
Examples of this header for on-demand content and a live stream Examples of this header for on-demand content and a live stream
without recording are: without recording are:
On-demand: On-demand:
skipping to change at page 131, line 43 skipping to change at page 133, line 24
For media that has the Time-Progressing property, the Media-Range For media that has the Time-Progressing property, the Media-Range
values will only be valid for the particular point in time when it values will only be valid for the particular point in time when it
was issued. As wallclock progresses so will also the media range. was issued. As wallclock progresses so will also the media range.
However, it shall be assumed that media time progress in direct However, it shall be assumed that media time progress in direct
relationship to wallclock time (with the exception of clock skew) so relationship to wallclock time (with the exception of clock skew) so
that a reasonably accurate estimation of the media range can be that a reasonably accurate estimation of the media range can be
calculated. calculated.
16.30. MTag 16.30. MTag
The MTag response header MAY be included in DESCRIBE or SETUP The MTag response header MAY be included in DESCRIBE, GET_PARAMETER
responses. The message body tags (Section 4.8) returned in a or SETUP responses. The message body tags (Section 4.8) returned in
DESCRIBE response, and the one in SETUP refers to the presentation, a DESCRIBE response, and the one in SETUP refers to the presentation,
i.e. both the returned session description and the media stream. i.e. both the returned session description and the media stream.
This allows for verification that one has the right session This allows for verification that one has the right session
description to a media resource at the time of the SETUP request. description to a media resource at the time of the SETUP request.
However, it has the disadvantage that a change in any of the parts However, it has the disadvantage that a change in any of the parts
results in invalidation of all the parts. results in invalidation of all the parts.
If the MTag is provided both inside the message body, e.g. within the If the MTag is provided both inside the message body, e.g. within the
"a=mtag" attribute in SDP, and in the response message, then both "a=mtag" attribute in SDP, and in the response message, then both
tags MUST be identical. It is RECOMMENDED that the MTag is primarily tags MUST be identical. It is RECOMMENDED that the MTag is primarily
given in the RTSP response message, to ensure that caches can use the given in the RTSP response message, to ensure that caches can use the
skipping to change at page 132, line 29 skipping to change at page 134, line 12
It indicates the reason why the server has sent the asynchronous It indicates the reason why the server has sent the asynchronous
PLAY_NOTIFY request (see Section 13.5). PLAY_NOTIFY request (see Section 13.5).
16.32. Pipelined-Requests 16.32. Pipelined-Requests
The Pipelined-Requests general header is used to indicate that a The Pipelined-Requests general header is used to indicate that a
request is to be executed in the context created by a previous request is to be executed in the context created by a previous
request(s). The primary usage of this header is to allow pipelining request(s). The primary usage of this header is to allow pipelining
of SETUP requests so that any additional SETUP request after the of SETUP requests so that any additional SETUP request after the
first one does not need to wait for the session ID to be sent back to first one does not need to wait for the session ID to be sent back to
the requesting entity. The header contains a unique identifier that the requesting agent. The header contains a unique identifier that
is scoped by the persistent connection used to send the requests. is scoped by the persistent connection used to send the requests.
Upon receiving a request with the Pipelined-Requests the responding Upon receiving a request with the Pipelined-Requests the responding
entity MUST look up if there exist a binding between this Pipelined- agent MUST look up if there exist a binding between this Pipelined-
Requests identifier for the current persistent connection and an RTSP Requests identifier for the current persistent connection and an RTSP
session ID. If that exists then the received request is processed session ID. If that exists then the received request is processed
the same way as if it did contain the Session header with the looked the same way as if it did contain the Session header with the looked
up session ID. If there doesn't exist a mapping and no Session up session ID. If there doesn't exist a mapping and no Session
header is included in the request, the responding entity MUST create header is included in the request, the responding agent MUST create a
a binding upon the successful completion of a session creating binding upon the successful completion of a session creating request,
request, i.e. SETUP. If the request failed to create an RTSP i.e. SETUP. If the request failed to create an RTSP session no
session no binding MUST be created. In case the request contains binding MUST be created. In case the request contains both a Session
both a Session header and the Pipelined-Requests header the header and the Pipelined-Requests header the Pipelined-Requests MUST
Pipelined-Requests MUST be ignored. be ignored.
Note: Based on the above definition at least the first request Note: Based on the above definition at least the first request
containing a new unique Pipelined-Requests will be required to be a containing a new unique Pipelined-Requests will be required to be a
SETUP request (unless the protocol is extended with new methods of SETUP request (unless the protocol is extended with new methods of
creating a session). After that first one, additional SETUP requests creating a session). After that first one, additional SETUP requests
or request of any type using the RTSP session context may include the or request of any type using the RTSP session context may include the
Pipelined-Requests header. Pipelined-Requests header.
When responding to any request that contained the Pipelined-Requests When responding to any request that contained the Pipelined-Requests
header the server MUST include also the Session header when a binding header the server MUST include also the Session header when a binding
to a session context exist. A RTSP agent that knows the session ID to a session context exist. A RTSP agent that knows the session ID
SHOULD NOT use the Pipelined-Requests header in any request and only SHOULD NOT use the Pipelined-Requests header in any request and only
use the Session header. This as the Session identifier is persistent use the Session header. This as the Session identifier is persistent
across transport contexts, like TCP connections, which the Pipelined- across transport contexts, like TCP connections, which the Pipelined-
Requests identifier is not. Requests identifier is not.
It is the RTSP agent sending the request with a Pipelined-Requests It is the RTSP agent sending the request with a Pipelined-Requests
header that has the responsibility for using a unique and previously header that has the responsibility for using a unique and previously
unused identifier within the the transport context. Currently only unused identifier within the transport context. Currently only TCP
TCP connection is defined as such transport context. A server MUST connection is defined as such transport context. A server MUST
delete the Pipelined-Requests identifier and its binding to a session delete the Pipelined-Requests identifier and its binding to a session
upon the termination of that session. RTSP agents are RECOMMENDED to upon the termination of that session. RTSP agents are RECOMMENDED to
despite the previous mandate to no reuse identifiers to allow for despite the previous mandate to not reuse identifiers to allow for
better error handling and logging. better error handling and logging.
RTSP Proxies may need to translate Pipelined-Requests identifier RTSP Proxies may need to translate Pipelined-Requests identifier
values from incoming request to outgoing to allow for aggregation of values from incoming request to outgoing to allow for aggregation of
requests onto a persistent connection. requests onto a persistent connection.
16.33. Proxy-Authenticate 16.33. Proxy-Authenticate
The Proxy-Authenticate response-header field MUST be included as part The Proxy-Authenticate response-header field MUST be included as part
of a 407 (Proxy Authentication Required) response. The field value of a 407 (Proxy Authentication Required) response. The field value
consists of a challenge that indicates the authentication scheme and consists of a challenge that indicates the authentication scheme and
parameters applicable to the proxy for this Request-URI. parameters applicable to the proxy for this Request-URI.
The HTTP access authentication process is described in [RFC2617]. The HTTP access authentication process is described in [RFC2617].
Unlike WWW-Authenticate, the Proxy-Authenticate header field applies Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
only to the current connection and SHOULD NOT be passed on to only to the current connection and SHOULD NOT be passed on to
downstream clients. However, an intermediate proxy might need to downstream agents. However, an intermediate proxy might need to
obtain its own credentials by requesting them from the downstream obtain its own credentials by requesting them from the downstream
client, which in some circumstances will appear as if the proxy is agent, which in some circumstances will appear as if the proxy is
forwarding the Proxy-Authenticate header field. forwarding the Proxy-Authenticate header field.
16.34. Proxy-Authorization 16.34. Proxy-Authorization
The Proxy-Authorization request-header field allows the client to The Proxy-Authorization request-header field allows the client to
identify itself (or its user) to a proxy which requires identify itself (or its user) to a proxy which requires
authentication. The Proxy-Authorization field value consists of authentication. The Proxy-Authorization field value consists of
credentials containing the authentication information of the user credentials containing the authentication information of the user
agent for the proxy and/or realm of the resource being requested. agent for the proxy and/or realm of the resource being requested.
skipping to change at page 134, line 22 skipping to change at page 136, line 5
The Proxy-Require request-header field is used to indicate proxy- The Proxy-Require request-header field is used to indicate proxy-
sensitive features that MUST be supported by the proxy. Any Proxy- sensitive features that MUST be supported by the proxy. Any Proxy-
Require header features that are not supported by the proxy MUST be Require header features that are not supported by the proxy MUST be
negatively acknowledged by the proxy to the client using the negatively acknowledged by the proxy to the client using the
Unsupported header. The proxy MUST use the 551 (Option Not Unsupported header. The proxy MUST use the 551 (Option Not
Supported) status code in the response. Any feature-tag included in Supported) status code in the response. Any feature-tag included in
the Proxy-Require does not apply to the end-point (server or client). the Proxy-Require does not apply to the end-point (server or client).
To ensure that a feature is supported by both proxies and servers the To ensure that a feature is supported by both proxies and servers the
tag needs to be included in also a Require header. tag needs to be included in also a Require header.
See Section 16.42 for more details on the mechanics of this message See Section 16.41 for more details on the mechanics of this message
and a usage example. See discussion in the proxies section and a usage example. See discussion in the proxies section
(Section 17.1) about when to consider that a feature requires proxy (Section 17.1) about when to consider that a feature requires proxy
support. support.
Example of use: Example of use:
Proxy-Require: play.basic Proxy-Require: play.basic
16.36. Proxy-Supported 16.36. Proxy-Supported
The Proxy-Supported header field enumerates all the extensions The Proxy-Supported header field enumerates all the extensions
skipping to change at page 138, line 14 skipping to change at page 139, line 42
request-header allows a server to generate lists of back-links to request-header allows a server to generate lists of back-links to
resources for interest, logging, optimized caching, etc. It also resources for interest, logging, optimized caching, etc. It also
allows obsolete or mistyped links to be traced for maintenance. The allows obsolete or mistyped links to be traced for maintenance. The
Referrer field MUST NOT be sent if the Request-URI was obtained from Referrer field MUST NOT be sent if the Request-URI was obtained from
a source that does not have its own URI, such as input from the user a source that does not have its own URI, such as input from the user
keyboard. keyboard.
If the field value is a relative URI, it SHOULD be interpreted If the field value is a relative URI, it SHOULD be interpreted
relative to the Request-URI. The URI MUST NOT include a fragment. relative to the Request-URI. The URI MUST NOT include a fragment.
See [H15.1.3] for security considerations on Referrer. Because the source of a link might be private information or might
reveal an otherwise private information source, it is strongly
16.40. Retry-After recommended that the user be able to select whether or not the
Referrer field is sent. For example, a streaming client could have a
The Retry-After response-header field can be used with a 503 (Service toggle switch for openly/anonymously, which would respectively
Unavailable) response to indicate how long the service is expected to enable/disable the sending of Referee and From information.
be unavailable to the requesting client. This field MAY also be used
with any 3xx (Redirection) response to indicate the minimum time the
user-agent is asked wait before issuing the redirected request. The
value of this field can be either an RTSP-date or an integer number
of seconds (in decimal) after the time of the response.
Example:
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
In the latter example, the delay is 2 minutes. Clients SHOULD NOT include a Referee header field in a (non-secure)
RTSP request if the referring page was transferred with a secure
protocol.
16.41. Request-Status 16.40. Request-Status
This request header is used to indicate the end result for requests This request header is used to indicate the end result for requests
that takes time to complete, such a PLAY (Section 13.4). It is sent that takes time to complete, such a PLAY (Section 13.4). It is sent
in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report
how the PLAY request concluded, either in success or in failure. The how the PLAY request concluded, either in success or in failure. The
header carries a reference to the request it reports on using the header carries a reference to the request it reports on using the
CSeq number for the session indicated by the Session header in the CSeq number for the session indicated by the Session header in the
request. It provides both a numerical status code (according to request. It provides both a numerical status code (according to
Section 8.1.1) and a human readable reason phrase. Section 8.1.1) and a human readable reason phrase.
Example: Example:
Request-Status: cseq=63 status=500 reason="Media data unavailable" Request-Status: cseq=63 status=500 reason="Media data unavailable"
16.42. Require 16.41. Require
The Require request-header field is used by clients or servers to The Require request-header field is used by clients or servers to
ensure that the other end-point supports features that are required ensure that the other end-point supports features that are required
in respect to this request. It can also be used to query if the in respect to this request. It can also be used to query if the
other end-point supports certain features, however, the use of the other end-point supports certain features, however, the use of the
Supported (Section 16.49) is much more effective in this purpose. Supported (Section 16.49) is much more effective in this purpose.
The server MUST respond to this header by using the Unsupported The server MUST respond to this header by using the Unsupported
header to negatively acknowledge those feature-tags which are NOT header to negatively acknowledge those feature-tags which are NOT
supported. The response MUST use the error code 551 (Option Not supported. The response MUST use the error code 551 (Option Not
Supported). This header does not apply to proxies, for the same Supported). This header does not apply to proxies, for the same
skipping to change at page 139, line 48 skipping to change at page 141, line 28
immutable property of "funky-feature" and thus should not be immutable property of "funky-feature" and thus should not be
transmitted with every exchange. transmitted with every exchange.
Proxies and other intermediary devices MUST ignore this header. If a Proxies and other intermediary devices MUST ignore this header. If a
particular extension requires that intermediate devices support it, particular extension requires that intermediate devices support it,
the extension should be tagged in the Proxy-Require field instead the extension should be tagged in the Proxy-Require field instead
(see Section 16.35). See discussion in the proxies section (see Section 16.35). See discussion in the proxies section
(Section 17.1) about when to consider that a feature requires proxy (Section 17.1) about when to consider that a feature requires proxy
support. support.
16.42. Retry-After
The Retry-After response-header field can be used with a 503 (Service
Unavailable) response to indicate how long the service is expected to
be unavailable to the requesting client. This field MAY also be used
with any 3xx (Redirection) response to indicate the minimum time the
user-agent is asked wait before issuing the redirected request. The
value of this field can be either an RTSP-date or an integer number
of seconds (in decimal) after the time of the response.
Example:
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
In the latter example, the delay is 2 minutes.
16.43. RTP-Info 16.43. RTP-Info
The RTP-Info response-header field is used to set RTP-specific The RTP-Info general field is used to set RTP-specific parameters in
parameters in the PLAY response. For streams using RTP as transport the PLAY and GET_PARAMETER responses or a PLAY_NOTIFY and
protocol the RTP-Info header SHOULD be part of a 200 response to GET_PARAMETER requests. For streams using RTP as transport protocol
PLAY. the RTP-Info header SHOULD be part of a 200 response to PLAY.
The exclusion of the RTP-Info in a PLAY response for RTP The exclusion of the RTP-Info in a PLAY response for RTP
transported media will result in that a client needs to transported media will result in that a client needs to
synchronize the media streams using RTCP. This may have negative synchronize the media streams using RTCP. This may have negative
impact as the RTCP can be lost, and does not need to be impact as the RTCP can be lost, and does not need to be
particularly timely in their arrival. Also functionality as particularly timely in their arrival. Also functionality as
informing the client from which packet a seek has occurred is informing the client from which packet a seek has occurred is
affected. affected.
The RTP-Info MAY be included in SETUP responses to provide The RTP-Info MAY be included in SETUP responses to provide
synchronization information when changing transport parameters, see synchronization information when changing transport parameters, see
Section 13.3. The RTP-Info header and the Range header MAY be Section 13.3. The RTP-Info header and the Range header MAY be
included in a GET_PARAMETER request from client to server without any included in a GET_PARAMETER request from client to server without any
values to request the current playback point and corresponding.RTP values to request the current playback point and corresponding. RTP
synchronization information. When the RTP-Info header is included in synchronization information. When the RTP-Info header is included in
a Request also the Range header MUST be included (Note, Range header a Request also the Range header MUST be included (Note, Range header
only MAY be used). The server respons SHALL include both the Range only MAY be used). The server response SHALL include both the Range
header and the RTP-Info header. If the session is in playing state, header and the RTP-Info header. If the session is in playing state,
then the value of the Range header SHALL be filled in with the then the value of the Range header SHALL be filled in with the
current playback point and with the corresponding RTP-Info values. current playback point and with the corresponding RTP-Info values.
If the server is another state, no values are included in the RTP- If the server is another state, no values are included in the RTP-
Info header. Info header. The header is included in PLAY_NOTIFY requests with the
Notify-Reason of end-of-stream to provide RTP information about the
end of the stream.
The header can carry the following parameters: The header can carry the following parameters:
url: Indicates the stream URI which for which the following RTP url: Indicates the stream URI which for which the following RTP
parameters correspond, this URI MUST be the same used in the parameters correspond, this URI MUST be the same used in the
SETUP request for this media stream. Any relative URI MUST use SETUP request for this media stream. Any relative URI MUST use
the Request-URI as base URI. This parameter MUST be present. the Request-URI as base URI. This parameter MUST be present.
ssrc: The Synchronization source (SSRC) that the RTP timestamp and ssrc: The Synchronization source (SSRC) that the RTP timestamp and
sequence number provide applies to. This parameter MUST be sequence number provide applies to. This parameter MUST be
skipping to change at page 142, line 25 skipping to change at page 144, line 25
certain media transports this may require certain considerations to certain media transports this may require certain considerations to
work consistent, see Appendix C.1 for description on how RTP handles work consistent, see Appendix C.1 for description on how RTP handles
this. this.
The transmitted data rate SHOULD NOT be changed by selection of a The transmitted data rate SHOULD NOT be changed by selection of a
different scale value. The resulting bit-rate should be reasonably different scale value. The resulting bit-rate should be reasonably
close to the nominal bit-rate of the content for Scale = 1. The close to the nominal bit-rate of the content for Scale = 1. The
server has to actively manipulate the data when needed to meet the server has to actively manipulate the data when needed to meet the
bitrate constraints. Implementation of scale changes depends on the bitrate constraints. Implementation of scale changes depends on the
server and media type. For video, a server may, for example, deliver server and media type. For video, a server may, for example, deliver
only key frames or selected key frames. For audio, it may time-scale only key frames or selected frames. For audio, it may time-scale the
the audio while preserving pitch or, less desirably, deliver audio while preserving pitch or, less desirably, deliver fragments of
fragments of audio, or completely mute the audio. audio, or completely mute the audio.
The server and content may restrict the range of scale values that it The server and content may restrict the range of scale values that it
supports. The supported values are indicated by the Media-Properties supports. The supported values are indicated by the Media-Properties
header (Section 16.28). The client SHOULD only indicate values header (Section 16.28). The client SHOULD only indicate values
indicated to be supported. However, as the values may change as the indicated to be supported. However, as the values may change as the
content progresses a requested value may no longer be valid when the content progresses a requested value may no longer be valid when the
request arrives. Thus, a non-supported value in a request does not request arrives. Thus, a non-supported value in a request does not
generate an error, only forces the server to choose the closest generate an error, only forces the server to choose the closest
value. The response MUST always contain the actual scale value value. The response MUST always contain the actual scale value
chosen by the server. chosen by the server.
skipping to change at page 143, line 21 skipping to change at page 145, line 21
have a strong preference. To express this preference and provide the have a strong preference. To express this preference and provide the
client with information on how the server actually acted on that client with information on how the server actually acted on that
preference the Seek-Style header is defined. preference the Seek-Style header is defined.
Seek-Style is a general header that MAY be included in any PLAY Seek-Style is a general header that MAY be included in any PLAY
request to indicate the client's preference for any media stream that request to indicate the client's preference for any media stream that
has random access properties. The server MUST always include the has random access properties. The server MUST always include the
header in any PLAY response for media with random access properties header in any PLAY response for media with random access properties
to indicate what policy was applied. A Server that receives a to indicate what policy was applied. A Server that receives a
unknown Seek-Style policy MUST ignore it and select the server unknown Seek-Style policy MUST ignore it and select the server
default policy. default policy. A Client receiving an unknown policy MUST ignore it
and use the Range header and any media synchronization information as
basis to figure out what the server did.
This specification defines the following seek policies that may be This specification defines the following seek policies that may be
requested: requested:
RAP: Random Access Point (RAP) is the behavior of requesting the RAP: Random Access Point (RAP) is the behavior of requesting the
server to locate the closest previous random access point that server to locate the closest previous random access point that
exist in the media aggregate and deliver from that. By requesting exist in the media aggregate and deliver from that. By requesting
a RAP media quality will be the best possible as all media will be a RAP media quality will be the best possible as all media will be
delivered from a point where full media state can be established delivered from a point where full media state can be established
in the media decoder. in the media decoder.
CoRAP: Conditional Random Access Point (CoRAP) is a variant of the
above RAP behavior. It is conditioned on that there exist a
Random Access Point closer to the requested start point than the
current pause point. This policy assumes that the media state
existing prior to the pause is usable if delivery is continued.
If the client or server knows that this is not the fact the RAP
policy should be used. In other words in most cases when the
client requests a start point prior to the current pause point a
valid decoding dependency chain from the media delivered prior to
the pause and to the requested media unit will not exist. This
policy is primarily intended for cases where there are larger
distance between the random access points in the media. If the
server searched to a random access point the server MUST return
the CoRAP policy in the Seek-Style header and adjust the Range
header to reflect the position of the picked RAP. In case the
random access point is further away and the server selects to
continue from the current pause point it MUST include the "Next"
policy in the Seek-Style header and adjust the Range header start
point to the current pause point.
First-Prior: The first-prior policy will start delivery with the First-Prior: The first-prior policy will start delivery with the
media unit that has a playout time first prior to the requested media unit that has a playout time first prior to the requested
time. For discrete media that would only include media units that time. For discrete media that would only include media units that
would still be rendered at the request time. For continuous media would still be rendered at the request time. For continuous media
that is media that will be render during the requested start time that is media that will be render during the requested start time
of the range. of the range.
Next: The next media units after the provided start time of the Next: The next media units after the provided start time of the
range. For continuous framed media that would mean the first next range. For continuous framed media that would mean the first next
frame after the provided time. For discrete media the first unit frame after the provided time. For discrete media the first unit
skipping to change at page 145, line 37 skipping to change at page 148, line 12
response timeout becomes a significant part of the session response timeout becomes a significant part of the session
timeout. 60 seconds also allows for reasonably rapid recovery of timeout. 60 seconds also allows for reasonably rapid recovery of
committed server resources in case of client failure. committed server resources in case of client failure.
16.48. Speed 16.48. Speed
The Speed request-header field requests the server to deliver The Speed request-header field requests the server to deliver
specific amounts of nominal media time per unit of delivery time, specific amounts of nominal media time per unit of delivery time,
contingent on the server's ability and desire to serve the media contingent on the server's ability and desire to serve the media
stream at the given speed. The client requests the delivery speed to stream at the given speed. The client requests the delivery speed to
be within a given range with an upper and lower bound. The server be within a given range with an lower and upper bound. The server
SHALL deliver at the highest possible speed within the range, but not SHALL deliver at the highest possible speed within the range, but not
faster than the upper-bound, for which the underlying network path faster than the upper-bound, for which the underlying network path
can support the resulting transport data rates. As long as any speed can support the resulting transport data rates. As long as any speed
value within the given range can be provided the server SHALL NOT value within the given range can be provided the server SHALL NOT
modify the media quality. Only if the server is unable to delivery modify the media quality. Only if the server is unable to delivery
media at the speed value provided by the lower bound shall it reduce media at the speed value provided by the lower bound shall it reduce
the media quality. the media quality.
Implementation of the Speed functionality by the server is OPTIONAL. Implementation of the Speed functionality by the server is OPTIONAL.
The server can indicate its support through a feature-tag, The server can indicate its support through a feature-tag,
skipping to change at page 146, line 31 skipping to change at page 149, line 9
beforehand (by means other than RTSP), and therefore re-negotiation beforehand (by means other than RTSP), and therefore re-negotiation
may be necessary. To perform Speed operations the server needs to may be necessary. To perform Speed operations the server needs to
ensure that the network path can support the resulting bit-rate. ensure that the network path can support the resulting bit-rate.
Thus the media transport needs to support feedback so that the server Thus the media transport needs to support feedback so that the server
can react and adapt to the available bitrate. can react and adapt to the available bitrate.
16.49. Supported 16.49. Supported
The Supported header enumerates all the extensions supported by the The Supported header enumerates all the extensions supported by the
client or server using feature tags. The header carries the client or server using feature tags. The header carries the
extensions supported by the message sending entity. The Supported extensions supported by the message sending client or server. The
header MAY be included in any request. When present in a request, Supported header MAY be included in any request. When present in a
the receiver MUST respond with its corresponding Supported header. request, the receiver MUST respond with its corresponding Supported
Note that the supported headers is also included in 4xx and 5xx header. Note that the supported headers is also included in 4xx and
responses. 5xx responses.
The Supported header contains a list of feature-tags, described in The Supported header contains a list of feature-tags, described in
Section 4.7, that are understood by the client or server. Section 4.7, that are understood by the client or server.
Example: Example:
C->S: OPTIONS rtsp://example.com/ RTSP/2.0 C->S: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech Supported: foo, bar, blech
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
skipping to change at page 147, line 39 skipping to change at page 150, line 15
user-msg: An UTF-8 text string with a message from the server to the user-msg: An UTF-8 text string with a message from the server to the
user. This message SHOULD be displayed to the user. user. This message SHOULD be displayed to the user.
16.51. Timestamp 16.51. Timestamp
The Timestamp general-header describes when the agent sent the The Timestamp general-header describes when the agent sent the
request. The value of the timestamp is of significance only to the request. The value of the timestamp is of significance only to the
agent and may use any timescale. The responding agent MUST echo the agent and may use any timescale. The responding agent MUST echo the
exact same value and MAY, if it has accurate information about this, exact same value and MAY, if it has accurate information about this,
add a floating point number indicating the number of seconds that has add a floating point number indicating the number of seconds that has
elapsed since it has received the request. The timestamp is used by elapsed since it has received the request. The timestamp can be used
the agent to compute the round-trip time to the responding agent so by the agent to compute the round-trip time to the responding agent
that it can adjust the timeout value for retransmissions. It also so that it can adjust the timeout value for retransmissions when
resolves retransmission ambiguities for unreliable transport of RTSP. running over a unreliable protocol. It also resolves retransmission
ambiguities for unreliable transport of RTSP.
16.52. Transport 16.52. Transport
The Transport request and response header indicates which transport The Transport request and response header indicates which transport
protocol is to be used and configures its parameters such as protocol is to be used and configures its parameters such as
destination address, compression, multicast time-to-live and destination address, compression, multicast time-to-live and
destination port for a single stream. It sets those values not destination port for a single stream. It sets those values not
already determined by a presentation description. already determined by a presentation description.
A Transport request header MAY contain a list of transport options A Transport request header MAY contain a list of transport options
skipping to change at page 149, line 11 skipping to change at page 151, line 36
There are two different methods for how to specify where the media There are two different methods for how to specify where the media
should be delivered for unicast transport: should be delivered for unicast transport:
dest_addr: The presence of this parameter and its values indicates dest_addr: The presence of this parameter and its values indicates
the destination address or addresses (host address and port the destination address or addresses (host address and port
pairs for IP flows) necessary for the media transport. pairs for IP flows) necessary for the media transport.
No dest_addr: The lack of the dest_addr parameter indicates that the No dest_addr: The lack of the dest_addr parameter indicates that the
server MUST send media to same address for which the RTSP server MUST send media to same address for which the RTSP
messages originates. Does not work for transports requiring messages originates.
explicitly given destination ports.
The choice of method for indicating where the media is to be The choice of method for indicating where the media is to be
delivered depends on the use case. In some case the only allowed delivered depends on the use case. In some case the only allowed
method will be to use no explicit address indication and have the method will be to use no explicit address indication and have the
server deliver media to the source of the RTSP messages. server deliver media to the source of the RTSP messages.
For Multicast there is several methods for specifying addresses but For Multicast there is several methods for specifying addresses but
they are different in how they work compared with unicast: they are different in how they work compared with unicast:
dest_addr with client picked address: The address and relevant dest_addr with client picked address: The address and relevant
skipping to change at page 150, line 17 skipping to change at page 152, line 42
stream. The layers are sent to consecutive addresses starting stream. The layers are sent to consecutive addresses starting
at the dest_addr address. If the parameter is not included, it at the dest_addr address. If the parameter is not included, it
defaults to a single layer. defaults to a single layer.
dest_addr: A general destination address parameter that can contain dest_addr: A general destination address parameter that can contain
one or more address specifications. Each combination of one or more address specifications. Each combination of
Protocol/Profile/Lower Transport needs to have the format and Protocol/Profile/Lower Transport needs to have the format and
interpretation of its address specification defined. For RTP/ interpretation of its address specification defined. For RTP/
AVP/UDP and RTP/AVP/TCP, the address specification is a tuple AVP/UDP and RTP/AVP/TCP, the address specification is a tuple
containing a host address and port. Note, only a single containing a host address and port. Note, only a single
destination entity per transport spec is intended. The usage destination parameter per transport spec is intended. The
of multiple destination to distribute a single media to usage of multiple destination to distribute a single media to
multiple entities is unspecified. multiple entities is unspecified.
The client originating the RTSP request MAY specify the The client originating the RTSP request MAY specify the
destination address of the stream recipient with the host destination address of the stream recipient with the host
address part of the tuple. When the destination address is address part of the tuple. When the destination address is
specified, the recipient may be a different party than the specified, the recipient may be a different party than the
originator of the request. To avoid becoming the unwitting originator of the request. To avoid becoming the unwitting
perpetrator of a remote-controlled denial-of-service attack, a perpetrator of a remote-controlled denial-of-service attack, a
server MUST perform security checks (see Section 21.1) and server MUST perform security checks (see Section 21.1) and
SHOULD log such attempts before allowing the client to direct a SHOULD log such attempts before allowing the client to direct a
skipping to change at page 151, line 24 skipping to change at page 154, line 6
which address and port to send so called "binding packets" from which address and port to send so called "binding packets" from
the receiver to the sender, thus creating a address binding in the receiver to the sender, thus creating a address binding in
the NAT that the sender to receiver packet flow can use. the NAT that the sender to receiver packet flow can use.
This information may also be available through SDP. This information may also be available through SDP.
However, since this is more a feature of transport than However, since this is more a feature of transport than
media initialization, the authoritative source for this media initialization, the authoritative source for this
information should be in the SETUP response. information should be in the SETUP response.
mode: The mode parameter indicates the methods to be supported for mode: The mode parameter indicates the methods to be supported for
this session. Valid values are "PLAY" and "RECORD". If not this session. Currently defined valid values are "PLAY". If
provided, the default is "PLAY". The "RECORD" value was not provided, the default is "PLAY". The "RECORD" value was
defined in RFC 2326 and is in this specification unspecified defined in RFC 2326 and is in this specification unspecified
but reserved. but reserved. RECORD and other values may be specified in the
future.
interleaved: The interleaved parameter implies mixing the media interleaved: The interleaved parameter implies mixing the media
stream with the control stream in whatever protocol is being stream with the control stream in whatever protocol is being
used by the control stream, using the mechanism defined in used by the control stream, using the mechanism defined in
Section 14. The argument provides the channel number to be Section 14. The argument provides the channel number to be
used in the $ statement and MUST be present. This parameter used in the $ statement and MUST be present. This parameter
MAY be specified as a interval, e.g., interleaved=4-5 in cases MAY be specified as a interval, e.g., interleaved=4-5 in cases
where the transport choice for the media stream requires it, where the transport choice for the media stream requires it,
e.g. for RTP with RTCP. The channel number given in the e.g. for RTP with RTCP. The channel number given in the
request are only a guidance from the client to the server on request are only a guidance from the client to the server on
skipping to change at page 153, line 46 skipping to change at page 156, line 30
"connection", the server response MUST assign a value of "connection", the server response MUST assign a value of
"existing" or "new" to "connection" on the Transport line, at "existing" or "new" to "connection" on the Transport line, at
its discretion. its discretion.
The default value of "connection" is "existing", for all SETUP The default value of "connection" is "existing", for all SETUP
requests (initial and subsequent). requests (initial and subsequent).
RTCP-mux: Use to negotiate the usage of RTP and RTCP multiplexing RTCP-mux: Use to negotiate the usage of RTP and RTCP multiplexing
[I-D.ietf-avt-rtp-and-rtcp-mux] on a single underlying [I-D.ietf-avt-rtp-and-rtcp-mux] on a single underlying
transport stream. The presence of this parameter in a SETUP transport stream. The presence of this parameter in a SETUP
request indicates the clients support and desire to use RTP and request indicates the clients support and requires the server
RTCP multiplexing. The client MAY still include two transport to use RTP and RTCP multiplexing. The client SHALL only
streams in the Transport header specification to handle cases include one transport stream in the Transport header
if RTP and RTCP multiplexing is not supported by the server. specification. To provide the server with a choice between
If the server supports the usage of RTP and RTCP multiplexing using RTP/RTCP multiplexing or not, two different transport
it SHALL include this parameter in the response and strip down header specifications must be included.
the transport address negotiation to a single src_addr and
dest_addr. If the server does not support RTP and RTCP
multiplexing is removes this parameter from the transport
specification in response and treat the specification as if the
parameter was not included.
The combination of transport protocol, profile and lower transport The combination of transport protocol, profile and lower transport
needs to be defined. A number of combinations are defined in the needs to be defined. A number of combinations are defined in the
Appendix C. Appendix C.
Below is a usage example, showing a client advertising the capability Below is a usage example, showing a client advertising the capability
to handle multicast or unicast, preferring multicast. Since this is to handle multicast or unicast, preferring multicast. Since this is
a unicast-only stream, the server responds with the proper transport a unicast-only stream, the server responds with the proper transport
parameters for unicast. parameters for unicast.
skipping to change at page 154, line 40 skipping to change at page 157, line 27
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
"192.0.2.5:3457";src_addr="192.0.2.224:6256"/ "192.0.2.5:3457";src_addr="192.0.2.224:6256"/
"192.0.2.224:6257";mode="PLAY" "192.0.2.224:6257";mode="PLAY"
Accept-Ranges: NPT Accept-Ranges: NPT
Media-Properties: Random-Access=0.6, Dynamic, Media-Properties: Random-Access=0.6, Dynamic,
Time-Limited=20081128T165900 Time-Limited=20081128T165900
16.53. Unsupported 16.53. Unsupported
The Unsupported response-header lists the features not supported by The Unsupported response-header lists the features not supported by
the server. In the case where the feature was specified via the the responding RTSP agent. In the case where the feature was
Proxy-Require field (Section 16.35), if there is a proxy on the path specified via the Proxy-Require field (Section 16.35), if there is a
between the client and the server, the proxy MUST send a response proxy on the path between the client and the server, the proxy MUST
message with a status code of 551 (Option Not Supported). The send a response message with a status code of 551 (Option Not
request MUST NOT be forwarded. Supported). The request MUST NOT be forwarded.
See Section 16.42 for a usage example. See Section 16.41 for a usage example.
16.54. User-Agent 16.54. User-Agent
The User-Agent request-header field contains information about the The User-Agent request-header field contains information about the
user agent originating the request. This is for statistical user agent originating the request. This is for statistical
purposes, the tracing of protocol violations, and automated purposes, the tracing of protocol violations, and automated
recognition of user agents for the sake of tailoring responses to recognition of user agents for the sake of tailoring responses to
avoid particular user agent limitations. User agents SHOULD include avoid particular user agent limitations. User agents SHOULD include
this field with requests. The field can contain multiple product this field with requests. The field can contain multiple product
tokens and comments identifying the agent and any subproducts which tokens and comments identifying the agent and any subproducts which
skipping to change at page 160, line 5 skipping to change at page 162, line 25
Non-modifying: The audit proxy is special in that it do not modify Non-modifying: The audit proxy is special in that it do not modify
the messages in other ways than to insert the Via header. That the messages in other ways than to insert the Via header. That
makes it possible for this type to forward RTSP message that makes it possible for this type to forward RTSP message that
contains different type of unknown methods, headers or header contains different type of unknown methods, headers or header
parameters. parameters.
Based on the above classification, one should evaluate if the new Based on the above classification, one should evaluate if the new
functionality requires the Transport modifying type of proxies to functionality requires the Transport modifying type of proxies to
understand it or not. understand it or not.
17.2. Multiplexing and Demultiplexing of Messages
RTSP proxies may have to multiplex multiple RTSP sessions from their
clients towards RTSP servers. This requires that RTSP requests from
multiple clients are multiplexed onto a common connection for
requests outgoing to a RTSP server and on the way back the responses
are demultiplexed from the server to per client responses. On the
protocol level this requires that request and response messages are
handled in both ways, requiring that there is a mechanism to
correlated what request/response pair exchanged between proxy and
server is mapped to what client (or client request).
This multiplexing of requests and demultiplexing of responses is done
by using the CSeq header field (see Section 16.19). The proxy has to
rewrite the CSeq in requests to the server and responses from the
server and remember what CSeq is mapped to what client.
18. Caching 18. Caching
In HTTP, response-request pairs are cached. RTSP differs In HTTP, response-request pairs are cached. RTSP differs
significantly in that respect. Responses are not cacheable, with the significantly in that respect. Responses are not cacheable, with the
exception of the presentation description returned by DESCRIBE. exception of the presentation description returned by DESCRIBE.
(Since the responses for anything but DESCRIBE and GET_PARAMETER do (Since the responses for anything but DESCRIBE and GET_PARAMETER do
not return any data, caching is not really an issue for these not return any data, caching is not really an issue for these
requests.) However, it is desirable for the continuous media data, requests.) However, it is desirable for the continuous media data,
typically delivered out-of-band with respect to RTSP, to be cached, typically delivered out-of-band with respect to RTSP, to be cached,
as well as the session description. as well as the session description.
skipping to change at page 160, line 32 skipping to change at page 163, line 32
appropriate and forwards the request to the origin server. appropriate and forwards the request to the origin server.
Subsequent control commands such as PLAY or PAUSE then pass the proxy Subsequent control commands such as PLAY or PAUSE then pass the proxy
unmodified. The proxy delivers the continuous media data to the unmodified. The proxy delivers the continuous media data to the
client, while possibly making a local copy for later reuse. The client, while possibly making a local copy for later reuse. The
exact allowed behavior of the cache is given by the cache-response exact allowed behavior of the cache is given by the cache-response
directives described in Section 16.10. A cache MUST answer any directives described in Section 16.10. A cache MUST answer any
DESCRIBE requests if it is currently serving the stream to the DESCRIBE requests if it is currently serving the stream to the
requester, as it is possible that low-level details of the stream requester, as it is possible that low-level details of the stream
description may have changed on the origin-server. description may have changed on the origin-server.
Note that an RTSP cache, unlike the HTTP cache, is of the "cut- Note that an RTSP cache, is of the "cut-through" variety. Rather
through" variety. Rather than retrieving the whole resource from the than retrieving the whole resource from the origin server, the cache
origin server, the cache simply copies the streaming data as it simply copies the streaming data as it passes by on its way to the
passes by on its way to the client. Thus, it does not introduce client. Thus, it does not introduce additional latency.
additional latency.
To the client, an RTSP proxy cache appears like a regular media To the client, an RTSP proxy cache appears like a regular media
server, to the media origin server like a client. Just as an HTTP server, to the media origin server like a client. Just as an HTTP
cache has to store the content type, content language, and so on for cache has to store the content type, content language, and so on for
the objects it caches, a media cache has to store the presentation the objects it caches, a media cache has to store the presentation
description. Typically, a cache eliminates all transport-references description. Typically, a cache eliminates all transport-references
(that is, e.g. multicast information) from the presentation (that is, e.g. multicast information) from the presentation
description, since these are independent of the data delivery from description, since these are independent of the data delivery from
the cache to the client. Information on the encodings remains the the cache to the client. Information on the encodings remains the
same. If the cache is able to translate the cached media data, it same. If the cache is able to translate the cached media data, it
would create a new presentation description with all the encoding would create a new presentation description with all the encoding
possibilities it can offer. possibilities it can offer.
18.1. Validation Model (HTTP) 18.1. Validation Model
When a cache has a stale entry that it would like to use as a When a cache has a stale entry that it would like to use as a
response to a client's request, it first has to check with the origin response to a client's request, it first has to check with the origin
server (or possibly an intermediate cache with a fresh response) to server (or possibly an intermediate cache with a fresh response) to
see if its cached entry is still usable. We call this "validating" see if its cached entry is still usable. We call this "validating"
the cache entry. Since we do not want to have to pay the overhead of the cache entry. Since we do not want to have to pay the overhead of
retransmitting the full response if the cached entry is good, and we retransmitting the full response if the cached entry is good, and we
do not want to pay the overhead of an extra round trip if the cached do not want to pay the overhead of an extra round trip if the cached
entry is invalid, the RTSP protocol supports the use of conditional entry is invalid, the RTSP protocol supports the use of conditional
methods. methods.
The key protocol features for supporting conditional methods are The key protocol features for supporting conditional methods are
those concerned with "cache validators." When an origin server those concerned with "cache validators." When an origin server
generates a full response, it attaches some sort of validator to it, generates a full response, it attaches some sort of validator to it,
which is kept with the cache entry. When a client (user agent or which is kept with the cache entry. When a client (user agent or
proxy cache) makes a conditional request for a resource for which it proxy cache) makes a conditional request for a resource for which it
has a cache entry, it includes the associated validator in the has a cache entry, it includes the associated validator in the
request. request.
The server then checks that validator against the current validator The server then checks that validator against the current validator
for the entity, and, if they match (see Section 18.1.3), it responds for the requested resource, and, if they match (see Section 18.1.3),
with a special status code (usually, 304 (Not Modified)) and no it responds with a special status code (usually, 304 (Not Modified))
message body. Otherwise, it returns a full response (including and no message body. Otherwise, it returns a full response
message body). Thus, we avoid transmitting the full response if the (including message body). Thus, we avoid transmitting the full
validator matches, and we avoid an extra round trip if it does not response if the validator matches, and we avoid an extra round trip
match. if it does not match.
In RTSP, a conditional request looks exactly the same as a normal In RTSP, a conditional request looks exactly the same as a normal
request for the same resource, except that it carries a special request for the same resource, except that it carries a special
header (which includes the validator) that implicitly turns the header (which includes the validator) that implicitly turns the
method (usually DESCRIBE) into a conditional. method (usually DESCRIBE or SETUP) into a conditional.
The protocol includes both positive and negative senses of cache- The protocol includes both positive and negative senses of cache-
validating conditions. That is, it is possible to request either validating conditions. That is, it is possible to request either
that a method be performed if and only if a validator matches or if that a method be performed if and only if a validator matches or if
and only if no validators match. and only if no validators match.
Note: a response that lacks a validator may still be cached, and Note: a response that lacks a validator may still be cached, and
served from cache until it expires, unless this is explicitly served from cache until it expires, unless this is explicitly
prohibited by a cache-control directive (see Section 16.10). prohibited by a cache-control directive (see Section 16.10).
However, a cache cannot do a conditional retrieval if it does not However, a cache cannot do a conditional retrieval if it does not
have a validator for the entity, which means it will not be have a validator for the resource, which means it will not be
refreshable after it expires. refreshable after it expires.
Media streams that are being adapted based on the transport capacity
between the server and the cache makes caching more difficult. A
server needs to consider how it views caching of media streams that
it adapts and potentially instruct any caches to not cache such
streams.
18.1.1. Last-Modified Dates 18.1.1. Last-Modified Dates
The Last-Modified header (Section 16.26) value is often used as a The Last-Modified header (Section 16.26) value is often used as a
cache validator. In simple terms, a cache entry is considered to be cache validator. In simple terms, a cache entry is considered to be
valid if the entity has not been modified since the Last-Modified valid if the content has not been modified since the Last-Modified
value. value.
18.1.2. Message Body Tag Cache Validators 18.1.2. Message Body Tag Cache Validators
The MTag response-header field value, an message body tag, provides The MTag response-header field value, an message body tag, provides
for an "opaque" cache validator. This might allow more reliable for an "opaque" cache validator. This might allow more reliable
validation in situations where it is inconvenient to store validation in situations where it is inconvenient to store
modification dates, where the one-second resolution of RTSP-date modification dates, where the one-second resolution of RTSP-date
values is not sufficient, or where the origin server wishes to avoid values is not sufficient, or where the origin server wishes to avoid
certain paradoxes that might arise from the use of modification certain paradoxes that might arise from the use of modification
skipping to change at page 163, line 13 skipping to change at page 166, line 13
equivalent entities. equivalent entities.
Note: One example of a strong validator is an integer that is Note: One example of a strong validator is an integer that is
incremented in stable storage every time an entity is changed. incremented in stable storage every time an entity is changed.
An entity's modification time, if represented with one-second An entity's modification time, if represented with one-second
resolution, could be a weak validator, since it is possible that resolution, could be a weak validator, since it is possible that
the resource might be modified twice during a single second. the resource might be modified twice during a single second.
Support for weak validators is optional. However, weak validators Support for weak validators is optional. However, weak validators
allow for more efficient caching of equivalent objects; for allow for more efficient caching of equivalent objects.
example, a hit counter on a site is probably good enough if it is
updated every few days or weeks, and any value during that period
is likely "good enough" to be equivalent.
A "use" of a validator is either when a client generates a request A "use" of a validator is either when a client generates a request
and includes the validator in a validating header field, or when a and includes the validator in a validating header field, or when a
server compares two validators. server compares two validators.
Strong validators are usable in any context. Weak validators are Strong validators are usable in any context. Weak validators are
only usable in contexts that do not depend on exact equality of an only usable in contexts that do not depend on exact equality of an
entity. For example, either kind is usable for a conditional entity. For example, either kind is usable for a conditional
DESCRIBE of a full entity. However, only a strong validator is DESCRIBE of a full entity. However, only a strong validator is
usable for a sub-range retrieval, since otherwise the client might usable for a sub-range retrieval, since otherwise the client might
skipping to change at page 165, line 5 skipping to change at page 167, line 47
Modified values are generated from different clocks, or at somewhat Modified values are generated from different clocks, or at somewhat
different times during the preparation of the response. An different times during the preparation of the response. An
implementation MAY use a value larger than 60 seconds, if it is implementation MAY use a value larger than 60 seconds, if it is
believed that 60 seconds is too short. believed that 60 seconds is too short.
If a client wishes to perform a sub-range retrieval on a value for If a client wishes to perform a sub-range retrieval on a value for
which it has only a Last-Modified time and no opaque validator, it which it has only a Last-Modified time and no opaque validator, it
MAY do this only if the Last-Modified time is strong in the sense MAY do this only if the Last-Modified time is strong in the sense
described here. described here.
18.1.4. Rules for When to Use Entity Tags and Last-Modified Dates 18.1.4. Rules for When to Use Message Body Tags and Last-Modified Dates
We adopt a set of rules and recommendations for origin servers, We adopt a set of rules and recommendations for origin servers,
clients, and caches regarding when various validator types ought to clients, and caches regarding when various validator types ought to
be used, and for what purposes. be used, and for what purposes.
RTSP origin servers: RTSP origin servers:
o SHOULD send an message body tag validator unless it is not o SHOULD send an message body tag validator unless it is not
feasible to generate one. feasible to generate one.
skipping to change at page 166, line 31 skipping to change at page 169, line 24
18.1.5. Non-validating Conditionals 18.1.5. Non-validating Conditionals
The principle behind message body tags is that only the service The principle behind message body tags is that only the service
author knows the semantics of a resource well enough to select an author knows the semantics of a resource well enough to select an
appropriate cache validation mechanism, and the specification of any appropriate cache validation mechanism, and the specification of any
validator comparison function more complex than byte-equality would validator comparison function more complex than byte-equality would
open up a can of worms. Thus, comparisons of any other headers are open up a can of worms. Thus, comparisons of any other headers are
never used for purposes of validating a cache entry. never used for purposes of validating a cache entry.
18.2. Invalidation After Updates or Deletions (HTTP) 18.2. Invalidation After Updates or Deletions
The effect of certain methods performed on a resource at the origin The effect of certain methods performed on a resource at the origin
server might cause one or more existing cache entries to become non- server might cause one or more existing cache entries to become non-
transparently invalid. That is, although they might continue to be transparently invalid. That is, although they might continue to be
"fresh," they do not accurately reflect what the origin server would "fresh," they do not accurately reflect what the origin server would
return for a new request on that resource. return for a new request on that resource.
There is no way for the RTSP protocol to guarantee that all such There is no way for the RTSP protocol to guarantee that all such
cache entries are marked invalid. For example, the request that cache entries are marked invalid. For example, the request that
caused the change at the origin server might not have gone through caused the change at the origin server might not have gone through
the proxy where a cache entry is stored. However, several rules help the proxy where a cache entry is stored. However, several rules help
reduce the likelihood of erroneous behavior. reduce the likelihood of erroneous behavior.
In this section, the phrase "invalidate an entity" means that the In this section, the phrase "invalidate an entity" means that the
cache will either remove all instances of that entity from its cache will either remove all instances of that entity from its
storage, or will mark these as "invalid" and in need of a mandatory storage, or will mark these as "invalid" and in need of a mandatory
revalidation before they can be returned in response to a subsequent revalidation before they can be returned in response to a subsequent
request. request.
Some HTTP methods MUST cause a cache to invalidate an entity. This Some RTSP methods MUST cause a cache to invalidate an entity. This
is either the entity referred to by the Request-URI, or by the is either the entity referred to by the Request-URI, or by the
Location or Content-Location headers (if present). These methods Location or Content-Location headers (if present). These methods
are: are:
o DESCRIBE o DESCRIBE
o SETUP o SETUP
In order to prevent denial of service attacks, an invalidation based In order to prevent denial of service attacks, an invalidation based
on the URI in a Location or Content-Location header MUST only be on the URI in a Location or Content-Location header MUST only be
performed if the host part is the same as in the Request-URI. performed if the host part is the same as in the Request-URI.
A cache that passes through requests for methods it does not A cache that passes through requests for methods it does not
understand SHOULD invalidate any entities referred to by the Request- understand SHOULD invalidate any entities referred to by the Request-
URI. URI.
skipping to change at page 168, line 9 skipping to change at page 171, line 9
performed if the host part is the same as in the Request-URI. performed if the host part is the same as in the Request-URI.
A cache that passes through requests for methods it does not A cache that passes through requests for methods it does not
understand SHOULD invalidate any entities referred to by the Request- understand SHOULD invalidate any entities referred to by the Request-
URI. URI.
19. Security Framework 19. Security Framework
The RTSP security framework consists of two high level components: The RTSP security framework consists of two high level components:
the pure authentication mechanisms based on HTTP authentication, and the pure authentication mechanisms based on HTTP authentication, and
the transport protection based on TLS, which is independent of RTSP. the message transport protection based on TLS, which is independent
Because of the similarity in syntax and usage between RTSP servers of RTSP. Because of the similarity in syntax and usage between RTSP
and HTTP servers, the security for HTTP is re-used to a large extent. servers and HTTP servers, the security for HTTP is re-used to a large
extent.
19.1. RTSP and HTTP Authentication 19.1. RTSP and HTTP Authentication
RTSP and HTTP share common authentication schemes, and thus follow RTSP and HTTP share common authentication schemes, and thus follow
the same usage guidelines as specified in[RFC2617] and also in [H15]. the same usage guidelines as specified in[RFC2617] and also in [H15].
Servers SHOULD implement both basic and digest [RFC2617] Servers SHOULD implement both basic and digest [RFC2617]
authentication. Client MUST implement both basic and digest authentication. Client MUST implement both basic and digest
authentication [RFC2617] so that Server who requires the client to authentication [RFC2617] so that Server who requires the client to
authenticate can trust that the capability is present. authenticate can trust that the capability is present.
skipping to change at page 170, line 15 skipping to change at page 173, line 17
The problem is that for a proxy accepted by the client, the proxy The problem is that for a proxy accepted by the client, the proxy
needs to be provided information on which grounds it should accept needs to be provided information on which grounds it should accept
the next-hop certificate. Both the proxy and the user may have rules the next-hop certificate. Both the proxy and the user may have rules
for this, and the user have the possibility to select the desired for this, and the user have the possibility to select the desired
behavior. To handle this case, the Accept-Credentials header (See behavior. To handle this case, the Accept-Credentials header (See
Section 16.2) is used, where the client can force the proxy/proxies Section 16.2) is used, where the client can force the proxy/proxies
to relay back the chain of certificates used to authenticate any to relay back the chain of certificates used to authenticate any
intermediate proxies as well as the server. Given the assumption intermediate proxies as well as the server. Given the assumption
that the proxies are viewed as