draft-ietf-mmusic-rfc2326bis-20.txt   draft-ietf-mmusic-rfc2326bis-21.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: RFC 2326 A. Rao
(if approved) Cisco (if approved) Cisco
Intended status: Standards Track R. Lanphier Intended status: Standards Track R. Lanphier
Expires: September 10, 2009 Expires: December 21, 2009
M. Westerlund M. Westerlund
Ericsson AB Ericsson AB
M. Stiemerling (Ed.) M. Stiemerling (Ed.)
NEC NEC
March 9, 2009 June 19, 2009
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-20 draft-ietf-mmusic-rfc2326bis-21
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. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 September 10, 2009. This Internet-Draft will expire on December 21, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 27 skipping to change at page 3, line 27
multicast UDP and TCP, and provide a means for choosing delivery multicast UDP and TCP, and provide a means for choosing delivery
mechanisms based upon RTP (RFC 3550). mechanisms based upon RTP (RFC 3550).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1. Notes on Copyright . . . . . . . . . . . . . . . . . . . 11 1.1. Notes on Copyright . . . . . . . . . . . . . . . . . . . 11
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 13 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 13
2.1. Content Description . . . . . . . . . . . . . . . . . . 13 2.1. Content Description . . . . . . . . . . . . . . . . . . 13
2.2. Session Establishment . . . . . . . . . . . . . . . . . 14 2.2. Session Establishment . . . . . . . . . . . . . . . . . 14
2.3. Playback Control . . . . . . . . . . . . . . . . . . . . 15 2.3. Media Delivery Control . . . . . . . . . . . . . . . . . 15
2.4. Session Parameter Manipulations . . . . . . . . . . . . 17 2.4. Session Parameter Manipulations . . . . . . . . . . . . 17
2.5. Media Delivery . . . . . . . . . . . . . . . . . . . . . 17 2.5. Media Delivery . . . . . . . . . . . . . . . . . . . . . 17
2.5.1. Media Delivery Manipulations . . . . . . . . . . . . 18 2.5.1. Media Delivery Manipulations . . . . . . . . . . . . 18
2.6. Session Maintenance and Termination . . . . . . . . . . 20 2.6. Session Maintenance and Termination . . . . . . . . . . 20
2.7. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 21 2.7. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 21
3. Document Conventions . . . . . . . . . . . . . . . . . . . . 23 3. Document Conventions . . . . . . . . . . . . . . . . . . . . 23
3.1. Notational Conventions . . . . . . . . . . . . . . . . . 23 3.1. Notational Conventions . . . . . . . . . . . . . . . . . 23
3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 23 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 23
4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 27 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 27
4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 27 4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 27
4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 27 4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 27
4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 29 4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 29
4.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . 29 4.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . 29
4.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 30 4.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 30
4.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . 31 4.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . 31
4.7. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 31 4.7. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 31
4.8. Message Body Tags . . . . . . . . . . . . . . . . . . . 31 4.8. Message Body Tags . . . . . . . . . . . . . . . . . . . 31
4.9. Media Properties . . . . . . . . . . . . . . . . . . . . 32 4.9. Media Properties . . . . . . . . . . . . . . . . . . . . 32
4.9.1. Random Access . . . . . . . . . . . . . . . . . . . 33 4.9.1. Random Access . . . . . . . . . . . . . . . . . . . 33
4.9.2. Retention . . . . . . . . . . . . . . . . . . . . . 33 4.9.2. Retention . . . . . . . . . . . . . . . . . . . . . 33
4.9.3. Content Modifications . . . . . . . . . . . . . . . 33 4.9.3. Content Modifications . . . . . . . . . . . . . . . 33
4.9.4. Supported Scale Factors . . . . . . . . . . . . . . 34 4.9.4. Supported Scale Factors . . . . . . . . . . . . . . 34
4.9.5. Mapping to the Attributes . . . . . . . . . . . . . 34 4.9.5. Mapping to the Attributes . . . . . . . . . . . . . 34
5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 35 5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 35 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 35
5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 36 5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 36
skipping to change at page 6, line 38 skipping to change at page 6, line 38
16.17. Content-Location . . . . . . . . . . . . . . . . . . . . 124 16.17. Content-Location . . . . . . . . . . . . . . . . . . . . 124
16.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 124 16.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 124
16.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 125 16.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 125
16.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 125 16.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 125
16.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 126 16.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 126
16.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 127 16.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 127
16.23. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 127 16.23. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 127
16.24. If-Modified-Since . . . . . . . . . . . . . . . . . . . 128 16.24. If-Modified-Since . . . . . . . . . . . . . . . . . . . 128
16.25. If-None-Match . . . . . . . . . . . . . . . . . . . . . 128 16.25. If-None-Match . . . . . . . . . . . . . . . . . . . . . 128
16.26. Last-Modified . . . . . . . . . . . . . . . . . . . . . 129 16.26. Last-Modified . . . . . . . . . . . . . . . . . . . . . 129
16.27. Location . . . . . . . . . . . . . . . . . . . . . . . . 130 16.27. Location . . . . . . . . . . . . . . . . . . . . . . . . 129
16.28. Media-Properties . . . . . . . . . . . . . . . . . . . . 130 16.28. Media-Properties . . . . . . . . . . . . . . . . . . . . 130
16.29. Media-Range . . . . . . . . . . . . . . . . . . . . . . 132 16.29. Media-Range . . . . . . . . . . . . . . . . . . . . . . 132
16.30. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 132 16.30. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 132
16.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 133 16.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 133
16.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 133 16.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 133
16.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 134 16.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 134
16.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 134 16.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 134
16.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 135 16.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 135
16.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 135 16.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 135
16.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 136 16.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 136
skipping to change at page 7, line 19 skipping to change at page 7, line 19
16.46. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 145 16.46. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 145
16.47. Server . . . . . . . . . . . . . . . . . . . . . . . . . 145 16.47. Server . . . . . . . . . . . . . . . . . . . . . . . . . 145
16.48. Session . . . . . . . . . . . . . . . . . . . . . . . . 146 16.48. Session . . . . . . . . . . . . . . . . . . . . . . . . 146
16.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 147 16.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 147
16.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 147 16.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 147
16.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 148 16.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 148
16.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 148 16.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 148
16.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 155 16.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 155
16.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 155 16.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 155
16.55. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 156 16.55. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 156
16.56. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 157 16.56. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 156
16.57. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 157 16.57. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 157
17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
17.1. Proxies and Protocol Extensions . . . . . . . . . . . . 159 17.1. Proxies and Protocol Extensions . . . . . . . . . . . . 159
18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
18.1. Validation Model (HTTP) . . . . . . . . . . . . . . . . 162 18.1. Validation Model (HTTP) . . . . . . . . . . . . . . . . 162
18.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 163 18.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 163
18.1.2. Message Body Tag Cache Validators . . . . . . . . . 163 18.1.2. Message Body Tag Cache Validators . . . . . . . . . 163
18.1.3. Weak and Strong Validators . . . . . . . . . . . . . 163 18.1.3. Weak and Strong Validators . . . . . . . . . . . . . 163
18.1.4. Rules for When to Use Entity Tags and 18.1.4. Rules for When to Use Entity Tags and
Last-Modified Dates . . . . . . . . . . . . . . . . 166 Last-Modified Dates . . . . . . . . . . . . . . . . 166
18.1.5. Non-validating Conditionals . . . . . . . . . . . . 167 18.1.5. Non-validating Conditionals . . . . . . . . . . . . 167
18.2. Invalidation After Updates or Deletions (HTTP) . . . . . 167 18.2. Invalidation After Updates or Deletions (HTTP) . . . . . 167
19. Security Framework . . . . . . . . . . . . . . . . . . . . . 169 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 169
19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 169 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 169
19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 169 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 169
19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 170 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 170
19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 171 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 171
19.3.2. User approved TLS procedure . . . . . . . . . . . . 172 19.3.2. User approved TLS procedure . . . . . . . . . . . . 172
20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 175 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 174
20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 177 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 176
20.2.1. Generic Protocol elements . . . . . . . . . . . . . 177 20.2.1. Generic Protocol elements . . . . . . . . . . . . . 176
20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 180 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 179
20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 184 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 183
20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 193 20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 192
21. Security Considerations . . . . . . . . . . . . . . . . . . . 194 21. Security Considerations . . . . . . . . . . . . . . . . . . . 193
21.1. Remote denial of Service Attack . . . . . . . . . . . . 196 21.1. Remote denial of Service Attack . . . . . . . . . . . . 195
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 198 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 197
22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 198 22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 197
22.1.1. Description . . . . . . . . . . . . . . . . . . . . 198 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 197
22.1.2. Registering New Feature-tags with IANA . . . . . . . 199 22.1.2. Registering New Feature-tags with IANA . . . . . . . 198
22.1.3. Registered entries . . . . . . . . . . . . . . . . . 199 22.1.3. Registered entries . . . . . . . . . . . . . . . . . 198
22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 199 22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 198
22.2.1. Description . . . . . . . . . . . . . . . . . . . . 199 22.2.1. Description . . . . . . . . . . . . . . . . . . . . 198
22.2.2. Registering New Methods with IANA . . . . . . . . . 199 22.2.2. Registering New Methods with IANA . . . . . . . . . 198
22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 200 22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 199
22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 200 22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 199
22.3.1. Description . . . . . . . . . . . . . . . . . . . . 200 22.3.1. Description . . . . . . . . . . . . . . . . . . . . 199
22.3.2. Registering New Status Codes with IANA . . . . . . . 200 22.3.2. Registering New Status Codes with IANA . . . . . . . 199
22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 200 22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 199
22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 200 22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 199
22.4.1. Description . . . . . . . . . . . . . . . . . . . . 200 22.4.1. Description . . . . . . . . . . . . . . . . . . . . 199
22.4.2. Registering New Headers with IANA . . . . . . . . . 201 22.4.2. Registering New Headers with IANA . . . . . . . . . 200
22.4.3. Registered entries . . . . . . . . . . . . . . . . . 201 22.4.3. Registered entries . . . . . . . . . . . . . . . . . 200
22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 202 22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 201
22.5.1. Accept-Credentials policies . . . . . . . . . . . . 202 22.5.1. Accept-Credentials policies . . . . . . . . . . . . 201
22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 202 22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 201
22.6. Cache-Control Cache Directive Extensions . . . . . . . 203 22.6. Cache-Control Cache Directive Extensions . . . . . . . 202
22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 203 22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 202
22.7.1. Description . . . . . . . . . . . . . . . . . . . . 204 22.7.1. Description . . . . . . . . . . . . . . . . . . . . 203
22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 204 22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 203
22.7.3. Registered Values . . . . . . . . . . . . . . . . . 204 22.7.3. Registered Values . . . . . . . . . . . . . . . . . 203
22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 204 22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 203
22.8.1. Description . . . . . . . . . . . . . . . . . . . . 204 22.8.1. Description . . . . . . . . . . . . . . . . . . . . 203
22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 204 22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 203
22.8.3. Registered Values . . . . . . . . . . . . . . . . . 205 22.8.3. Registered Values . . . . . . . . . . . . . . . . . 204
22.9. Range header formats . . . . . . . . . . . . . . . . . . 205 22.9. Range header formats . . . . . . . . . . . . . . . . . . 204
22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 205 22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 204
22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 205 22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 204
22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 206 22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 205
22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 206 22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 205
22.11.1. Description . . . . . . . . . . . . . . . . . . . . 206 22.11.1. Description . . . . . . . . . . . . . . . . . . . . 205
22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 206 22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 205
22.11.3. Registered Values . . . . . . . . . . . . . . . . . 206 22.11.3. Registered Values . . . . . . . . . . . . . . . . . 205
22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 207 22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 206
22.12.1. Description . . . . . . . . . . . . . . . . . . . . 207 22.12.1. Description . . . . . . . . . . . . . . . . . . . . 206
22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 207 22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 206
22.12.3. Registered Values . . . . . . . . . . . . . . . . . 207 22.12.3. Registered Values . . . . . . . . . . . . . . . . . 206
22.13. Transport Header Registries . . . . . . . . . . . . . . 207 22.13. Transport Header Registries . . . . . . . . . . . . . . 206
22.13.1. Transport Protocol Specification . . . . . . . . . . 208 22.13.1. Transport Protocol Specification . . . . . . . . . . 207
22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 209 22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 208
22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 209 22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 208
22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 210 22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 209
22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 210 22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 209
22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 211 22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 210
22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 212 22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 211
22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 212 22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 211
22.16. Media Type Registration for text/parameters . . . . . . 213 22.16. Media Type Registration for text/parameters . . . . . . 212
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 215 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 214
23.1. Normative References . . . . . . . . . . . . . . . . . . 215 23.1. Normative References . . . . . . . . . . . . . . . . . . 214
23.2. Informative References . . . . . . . . . . . . . . . . . 217 23.2. Informative References . . . . . . . . . . . . . . . . . 216
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 219 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 218
A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 219 A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 218
A.2. Media on Demand using Pipelining . . . . . . . . . . . . 222 A.2. Media on Demand using Pipelining . . . . . . . . . . . . 221
A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 225 A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 224
A.4. Single Stream Container Files . . . . . . . . . . . . . 229 A.4. Single Stream Container Files . . . . . . . . . . . . . 228
A.5. Live Media Presentation Using Multicast . . . . . . . . 231 A.5. Live Media Presentation Using Multicast . . . . . . . . 230
A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 232 A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 231
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 234 Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 233
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 234 B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 233
B.2. State variables . . . . . . . . . . . . . . . . . . . . 234 B.2. State variables . . . . . . . . . . . . . . . . . . . . 233
B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 234 B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 233
B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 235 B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 234
Appendix C. Media Transport Alternatives . . . . . . . . . . . . 240 Appendix C. Media Transport Alternatives . . . . . . . . . . . . 239
C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 240 C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 239
C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 240 C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 239
C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 240 C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 239
C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 241 C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 240
C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 242 C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 241
C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 242 C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 241
C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 242 C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 241
C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 243 C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 242
C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 244 C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 243
C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 244 C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 243
C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 248 C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 247
C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 251 C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 251
C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 253 C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 253
C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 253 C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 253
C.7. Maintaining NPT synchronization with RTP timestamps . . 254 C.7. Maintaining NPT synchronization with RTP timestamps . . 253
C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 254 C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 253
C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 254 C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 253
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 . . . . . . . . . . . . . . . . . . . . . . 254 RTSP Session . . . . . . . . . . . . . . . . . . . . . . 253
C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 255 C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 254
Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 256 Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 255
D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 256 D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 255
D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 256 D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 255
D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 257 D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 256
D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 258 D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 257
D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 258 D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 257
D.1.5. Directionality of media stream . . . . . . . . . . . 258 D.1.5. Directionality of media stream . . . . . . . . . . . 257
D.1.6. Range of Presentation . . . . . . . . . . . . . . . 259 D.1.6. Range of Presentation . . . . . . . . . . . . . . . 258
D.1.7. Time of Availability . . . . . . . . . . . . . . . . 260 D.1.7. Time of Availability . . . . . . . . . . . . . . . . 259
D.1.8. Connection Information . . . . . . . . . . . . . . . 260 D.1.8. Connection Information . . . . . . . . . . . . . . . 259
D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 260 D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 259
D.2. Aggregate Control Not Available . . . . . . . . . . . . 261 D.2. Aggregate Control Not Available . . . . . . . . . . . . 260
D.3. Aggregate Control Available . . . . . . . . . . . . . . 261 D.3. Aggregate Control Available . . . . . . . . . . . . . . 260
D.4. RTSP external SDP delivery . . . . . . . . . . . . . . . 262 D.4. RTSP external SDP delivery . . . . . . . . . . . . . . . 261
Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 264 Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 263
E.1. On-demand Playback of Stored Content . . . . . . . . . . 264 E.1. On-demand Playback of Stored Content . . . . . . . . . . 263
E.2. Unicast Distribution of Live Content . . . . . . . . . . 265 E.2. Unicast Distribution of Live Content . . . . . . . . . . 264
E.3. On-demand Playback using Multicast . . . . . . . . . . . 266 E.3. On-demand Playback using Multicast . . . . . . . . . . . 265
E.4. Inviting an RTSP server into a conference . . . . . . . 266 E.4. Inviting an RTSP server into a conference . . . . . . . 265
E.5. Live Content using Multicast . . . . . . . . . . . . . . 267 E.5. Live Content using Multicast . . . . . . . . . . . . . . 266
Appendix F. Text format for Parameters . . . . . . . . . . . . . 269 Appendix F. Text format for Parameters . . . . . . . . . . . . . 268
Appendix G. Requirements for Unreliable Transport of RTSP . . . 270 Appendix G. Requirements for Unreliable Transport of RTSP . . . 269
Appendix H. Backwards Compatibility Considerations . . . . . . . 272 Appendix H. Backwards Compatibility Considerations . . . . . . . 271
H.1. Play Request in Play mode . . . . . . . . . . . . . . . 272 H.1. Play Request in Play mode . . . . . . . . . . . . . . . 271
H.2. Using Persistent Connections . . . . . . . . . . . . . . 272 H.2. Using Persistent Connections . . . . . . . . . . . . . . 271
Appendix I. Open Issues . . . . . . . . . . . . . . . . . . . . 273 Appendix I. Open Issues . . . . . . . . . . . . . . . . . . . . 272
Appendix J. Changes . . . . . . . . . . . . . . . . . . . . . . 274 Appendix J. Changes . . . . . . . . . . . . . . . . . . . . . . 273
Appendix K. Acknowledgements . . . . . . . . . . . . . . . . . . 281 Appendix K. Acknowledgements . . . . . . . . . . . . . . . . . . 280
K.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 281 K.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 280
Appendix L. RFC Editor Consideration . . . . . . . . . . . . . . 283 Appendix L. RFC Editor Consideration . . . . . . . . . . . . . . 282
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 284 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 283
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.
The protocol operates between RTSP 2.0 clients and servers, but also The protocol operates between RTSP 2.0 clients and servers, but also
supports the usage of proxies placed between clients and servers. supports the usage of proxies placed between clients and servers.
Clients can request information about streaming media from servers, Clients can request information about streaming media from servers,
by asking for a description of the media or use media description by asking for a description of the media or use media description
provided externally. Then establish the media delivery protocol to provided externally. Then the media delivery protocol is used to
be used for the media streams described by the media description. establish the media streams described by the media description.
Clients can then request to play out the media, pause it, or stop it Clients can then request to play out the media, pause it, or stop it
completely, as known from a regular TV remote control. The requested completely, as known from a regular DVD player remote control. The
media can consist of multiple audio and video streams that are requested media can consist of multiple audio and video streams that
delivered as a time-synchronized streams from servers to clients. are delivered as a time-synchronized streams from servers to clients.
RTSP 2.0 is an replacement of RTSP 1.0 [RFC2326] that obsoletes that RTSP 2.0 is an replacement of RTSP 1.0 [RFC2326] that obsoletes that
specification. This protocol is based on RTSP 1.0 but not backwards specification. This protocol is based on RTSP 1.0 but not backwards
compatible other than in the basic version negotiation mechanism. compatible other than in the basic version negotiation mechanism.
The changes are documented in Appendix J. There are many reasons why The changes are documented in Appendix J. There are many reasons why
RTSP 2.0 can't be backwards compatible with RTSP 1.0 but some of the RTSP 2.0 can't be backwards compatible with RTSP 1.0 but some of the
main ones are; that most header that needed to be extensible didn't main ones are; that most header that needed to be extensible did not
define the allowed syntax preventing safe deployment of extensions; define the allowed syntax preventing safe deployment of extensions;
the changed behavior of the PLAY method when received in playing the changed behavior of the PLAY method when received in playing
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 is 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 and
SDP usage with RTSP. This is followed by a number of informational SDP usage with RTSP. This is followed by a number of informational
skipping to change at page 13, line 8 skipping to change at page 13, line 8
Furthermore, this memo does contain text that has been copied and Furthermore, this memo does contain text that has been copied and
modified from [RFC2616]. Older versions of this memo solely linked modified from [RFC2616]. Older versions of this memo solely linked
to the particular places. Linking to the HTTP/1.1 specification was to the particular places. Linking to the HTTP/1.1 specification was
not appropriate anymore, as the text was not fitting to RTSP 2.0 not appropriate anymore, as the text was not fitting to RTSP 2.0
needs and had to be adapted. Thus text copied from HTTP/1.1 is still needs and had to be adapted. Thus text copied from HTTP/1.1 is still
under copyright prior to [RFC5378]. under copyright prior to [RFC5378].
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. This to enable 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
cases for RTSP see Appendix E. cases for RTSP see Appendix E.
RTSP 2.0 is a bi-directional request and response protocol that first RTSP 2.0 is a bi-directional request and response protocol that first
establish a context including content resources (the media) and then establish a context including content resources (the media) and then
controls the delivery of these content resources from the server to controls the delivery of these content resources from the server to
the client. RTSP has 3 fundamental parts of interest, Session the client. RTSP has three fundamental parts of interest: Session
Establishment, Playback Control and its extensibility model, that is Establishment, Playback Control, and an extensibility model described
described below. It is also is based on some assumptions on existing below. The protocol is based on some assumptions on existing
functionality that also will be touched upon to provide a complete functionality to provide a complete solution for client controlled
solution for client controlled real-time media delivery. real-time media delivery.
RTSP uses text based messages that may contain a binary message body. RTSP uses text-based messages, requests and responses, that may
The RTSP messages starts with a method line that identify the method, contain a binary message body. An RTSP request starts with a method
the protocol and version and the resource to act on. Following the line that identifies the method, the protocol and version and the
method line follows a number of RTSP headers. This part is ended by resource to act on. Following the method line follows a number of
two consecutive control line feed (CRLF) character pairs. The RTSP headers. This part is ended by two consecutive carriage return
message body if present follows the two CRLF and the bodies length line feed (CRLF) character pairs. The message body if present
are described by a message header. RTSP messages are sent over a follows the two CRLF and the bodies length are described by a message
reliable transport protocol between client and server. RTSP 2.0 header. RTSP responses are similar, but start with a response line
requires clients and servers to implement TCP and TLS over TCP as with protocol and version, followed by a status code and a reason
mandatory transport for RTSP messages. phrase. RTSP messages are sent over a reliable transport protocol
between the client and server. RTSP 2.0 requires clients and servers
to implement TCP, and TLS over TCP, as mandatory transports for RTSP
messages.
2.1. Content Description 2.1. Content Description
RTSP exist to provide access to multi-media content, however it tries RTSP exists to provide access to multi-media content, but tries to be
to be agnostic to the media type or the actual media delivery agnostic to the media type or the actual media delivery protocol that
protocol that is used. To enable a client to implement a complete is used. To enable a client to implement a complete system, an RTSP-
system, an RTSP external mechanism for describing the content and the external mechanism for describing the content and the delivery
delivery protocol(s) is used. RTSP assumes that this either protocol(s) is used. RTSP assumes that this description is either
delivered completely out of bands or can be delivered as single data delivered completely out of bands or as a data object in the response
object upon the clients request using the DESCRIBE method to a client's request using the DESCRIBE method (Section 13.2).
(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
o Transport protocol parameters that are not negotiated or varies o Transport protocol parameters that are not negotiated or varies
with each client with each client
o Media encoding information enabling client to correctly decode it o Media encoding information enabling client to correctly decode it
upon reception upon reception
o An aggregate control resource identifier o An aggregate control resource identifier
skipping to change at page 14, line 33 skipping to change at page 14, line 36
after having used the content description to determine which media after having used the content description to determine which media
streams are available, and also which media delivery protocol is used streams are available, and also which media delivery protocol is used
and their particular resource identifiers. The RTSP session is a and their particular resource identifiers. The RTSP session is a
common context between the client and the server that consist of one common context between the client and the server that consist of one
or more media resource that is to be under common playback control. or more media resource that is to be under common playback 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 are pre-established by the (Section 16.52). This includes parameters that are pre-established
content description but necessary for any middlebox to correctly by the content description but necessary for any middlebox to
handle the media delivery protocol. The Transport header in a correctly handle the media delivery protocols. The Transport header
request may contain multiple alternatives for media delivery to in a request may contain multiple alternatives for media delivery in
enable the server to select what is preferred some an prioritized a prioritized list, which the server can select from. These
list. However, RTSP builds on that the client can select a small alternatives are typically based on information in the content
number of alternatives based on the content description. description.
The server will determine 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
stored. An identifier is created for the RTSP session and included stored. An identifier is created for the RTSP session and included
in the response in the Session header (Section 16.48). The SETUP in the response in the Session header (Section 16.48). The SETUP
response message includes a Transport header that specifies which of response includes a Transport header that specifies which of the
the alternatives that are selected and any parameters which the alternatives that have been selected and relevant parameters.
server is required to fill in.
A SETUP request that references an existing RTSP session but A SETUP request that references an existing RTSP session but
identifies a new media resource is a request to add that media identifies a new media resource is a request to add that media
resource under common control with the already present media resource under common control with the already present media
resources in an aggregated session. A client can expect this to work resources in an aggregated session. A client can expect this to work
for all media resources under RTSP control within a multi-media for all media resources under RTSP control within a multi-media
content. However, aggregating resources from different content are content. However, aggregating resources from different content are
likely to be refused by the server. The RTSP session as aggregate is likely to be refused by the server. The RTSP session as aggregate is
referenced by the aggregate control URI, even if the RTSP session referenced by the aggregate control URI, even if the RTSP session
only contains a single media. only contains a single media.
To avoid an extra round trip in the session establishment of To avoid an extra round trip in the session establishment of
aggregated RTSP sessions, RTSP 2.0 supports pipelined requests. The aggregated RTSP sessions, RTSP 2.0 supports pipelined requests, i.e.,
client uses client selected identifier in the Pipelined-Requests the client can send multiple requests back to back without waiting
header to instruct the server to bind multiple requests together as first for the completion of any of them. The client uses client
if they included the session identifier. selected identifier in the Pipelined-Requests header to instruct the
server to bind multiple requests together as if they included the
session identifier.
The SETUP response also provides additional information about the The SETUP response also provides additional information about the
established sessions in couple of different headers. The Media- established sessions in a couple of different headers. The Media-
Properties header include a number of properties that apply for the Properties header include a number of properties that apply for the
aggregate that is valuable when doing playback control and aggregate that is valuable when doing playback control and
configuring user interface. The Accept-Ranges header inform the configuring user interface. The Accept-Ranges header inform the
client about which range formats that the server supports with these client about which range formats that the server supports with these
media resources. The Media-Range header inform the client about the media resources. The Media-Range header inform the client about the
time range of the media currently available. time range of the media currently available.
2.3. Playback Control 2.3. Media Delivery Control
Having established an RTSP session one can start controlling the After having established an RTSP session, the client can start
media playback. The basic operations are very simple starting media controlling the media delivery. The basic operations are Start by
delivery using the PLAY method (Section 13.4) or halt it by the PAUSE using the PLAY method (Section 13.4) and Halt by using the PAUSE
method (Section 13.6). PLAY also allows for positioning where in the method (Section 13.6). PLAY also allows for choosing the starting
media the server should deliver from if the media support such media position from which the server should deliver the media. The
operation. The positioning is done using the Range header positioning is done using the Range header (Section 16.38) that
(Section 16.38) that support several different time formats, Normal supports several different time formats: Normal Play Time
Play Time (Section 4.5), SMPTE Timestamps (Section 4.4) or absolute (Section 4.5), SMPTE Timestamps (Section 4.4) and absolute time
time (Section 4.6). The Range header does also allow the client to (Section 4.6). The Range header does further allow the client to
specify a position where playback should end, thus allowing a specify a position where delivery should end, thus allowing a
specific interval to be played back. specific interval to be delivered.
The support for positioning/searching within a content depends on the The support for positioning/searching within a content depends on the
contents media properties. Content exist in a number of different content's media properties. Content exists in a number of different
types, like on-demand, live, and live content being recorded. Even types, such as: on-demand, live, and live with simultaneous
within these categories there are differences in how the content is recording. Even within these categories there are differences in how
generated and distributed that affects how it can be accessed for the content is generated and distributed, which affect how it can be
playback. The properties applicable for the RTSP session are accessed for playback. The properties applicable for the RTSP
provided by the server in the SETUP response using the Media- session are provided by the server in the SETUP response using the
Properties header (Section 16.28). These are expressed using one or Media-Properties header (Section 16.28). These are expressed using
several attributes that are independent such as, Random Access that one or several independent attributes. A first attribute is Random
express if positioning can happen at all or if only limited to Access, which expresses if positioning can be done, and with what
rewinding from start, and if possible what granularity that can be granularity. Another aspect is whether the content will change
expected. Another aspect possible to express if the content will during the lifetime of the session. While on-demand content will
change during the lifetime of the session. While on-demand content provided in its completeness from the beginning, a live stream being
will provided in its completeness from the beginning, a live stream recorded results in that the length of the accessible content grows
being recorded while one watches it results in the content growing in as the session goes on. There also exist content that is dynamically
duration as the session goes on. There also exist content that is built by another protocol than RTSP and thus also changes in steps
dynamically built by another protocol than RTSP and thus also changes during the session, but maybe not continuously. Furthermore, when
in steps during the session but not continuously. When content is content is recorded, there are cases where not the complete content
recorded there are cases where not the complete content is maintained is maintained, but, for example, only the last hour. All these
only the last hour for example. All of these properties results in properties result in the need for mechanisms that will be discussed
the need for mechanisms that will be discussed below. below.
When the client access on-demand content that is possible to perform When the client accesses on-demand content, that is possible to
random access in the client can issue the PLAY request for any point perform random access in, the client can issue the PLAY request for
in the content between the start and the end. The server will any point in the content between the start and the end. The server
deliver media from the closest random access point prior to the will deliver media from the closest random access point prior to the
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 media from the server after having sent a the client will receive the live media from the server after having
PLAY request that is what happens now. Seeking in such content is sent a PLAY request. Seeking in such content is not working as the
not working as the server does not store it, but only forwards it server does not store it, but only forwards it from the source of the
from the source of the session. Thus delivery continues until the session. Thus delivery continues until the client sends a PAUSE
client sends a PAUSE request, tears down the session or the content request, tears down the session, or the content ends.
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 progress. Upon session establishment keep track of how the recording progresses. Upon session
the client will learn the current duration of the recording from the establishment the client will learn the current duration of the
Media-Range header. As the recording is ongoing the content grows in recording from the Media-Range header. As the recording is ongoing
direct relation to the passed time. Therefore, each server's the content grows in direct relation to the passed time. Therefore,
response to a PLAY request will contain the current Media-Range each server's response to a PLAY request will contain the current
header. The server should also send regularly every 5 minutes the Media-Range header. The server should also send regularly every 5
current media range in a PLAY_NOTIFY request. If the live minutes the current media range in a PLAY_NOTIFY request. If the
transmission ends the Server must send a PLAY_NOTIFY request with the live transmission ends, the server must send a PLAY_NOTIFY request
updated Media-Properties indicating that the content stopped being a with the updated Media-Properties indicating that the content stopped
recorded live session and instead become a on-demand content. The being a recorded live session and instead become a on-demand content.
request also contains the final media range. While the live delivery The request also contains the final media range. While the live
continues the client can request to play what is delivered just now delivery continues the client can request to play what is delivered
by using the NPT timescale symbol "now", or it can request a specific just now by using the NPT timescale symbol "now", or it can request a
point in the available content by an explicit range request for that specific point in the available content by an explicit range request
point. If the requested point is outside of the available interval for that point. If the requested point is outside of the available
the server will adjust the position to the closest available point, interval the server will adjust the position to the closest available
i.e., either at the beginning or the end. point, i.e., either at the beginning or the end.
A special case of recording is where the recording is not retained A special case of recording is, where the recording is not retained
longer than a specific time period, thus as the live delivery longer than a specific time period, thus as the live delivery
continues the client can access any media within a moving window that continues the client can access any media within a moving window that
covers for example "now" to "now" minus 1 hour. A client that pause covers for example "now" to "now" minus 1 hour. A client that pauses
on a specific point within the content may not retrieve the content on a specific point within the content may not be able to retrieve
anymore, if the client waits long enough before resuming the pause the content anymore. If the client waits too long before resuming
point, as the content may no longer be available. In this case the the pause point, the content may no longer be available. In this
pause point will adjusted to the end of the available media. case the pause point will be adjusted to the end of the available
media.
2.4. Session Parameter Manipulations 2.4. Session Parameter Manipulations
A session may have additional state or functionality that effects how A session may have additional state or functionality that effects how
the server or client treats the session, content, how it functions, the server or client treats the session, content, how it functions,
or feedback on how well the session works. Such extensions are not or feedback on how well the session works. Such extensions are not
defined in this specification, but may be done in various extensions. defined in this specification, but may be done in various extensions.
RTSP has two methods used to retrieve parameter values or to set them RTSP has two methods for retrieving and setting parameter values on
on either the client or the server: GET_PARAMETER (Section 13.8) or either the client or the server: GET_PARAMETER (Section 13.8) and
SET_PARAMETER (Section 13.9). These methods are carrying the SET_PARAMETER (Section 13.9). These methods carry the parameters in
parameters in a message body of the appropriate format. One can also a message body of the appropriate format. One can also headers to
use certain type of headers to query state with the GET_PARAMETER query state with the GET_PARAMETER method. As an example, clients
method. As an example clients needing to know the current Media- needing to know the current Media-Range for a time-progressing
Range for a time-progressing session can use the GET_PARAMETER method session can use the GET_PARAMETER method and include the media-range.
and include the media-range. Also synchronization information using Furthermore, synchronization information can be requested by using a
the combination of RTP-Info and Range can be requested. combination of RTP-Info and Range.
RTSP 2.0 does not have a strong mechanism for providing negotiation RTSP 2.0 does not have a strong mechanism for providing negotiation
of which headers or parameters and their formats that can be used. of which headers, or parameters and their formats, that can be used.
The protocol will indicate headers or parameters that it doesn't However, responses will indicate request headers or parameters that
support if tried. But determination a priori of what is available are not supported. A priori determination of what features are
needs to be done through out-of-band mechanism, like in the session available needs to be done through out-of-band mechanisms, like the
description, or through the usage of feature tags (Section 4.7). session description, or through the usage of feature tags
(Section 4.7).
2.5. Media Delivery 2.5. Media Delivery
The delivery of media to the RTSP client is done with a protocol The delivery of media to the RTSP client is done with a protocol
outside of RTSP and this protocol is determined during the session outside of RTSP and this protocol is determined during the session
establishment. This document specifies how media is delivered with establishment. This document specifies how media is delivered with
RTP over UDP, TCP or the RTSP control connection. Additional RTP over UDP, TCP or the RTSP control connection. Additional
protocols may be specified in the future based on demand. protocols may be specified in the future based on demand.
The usage of RTP as media delivery protocol does requires some The usage of RTP as media delivery protocol requires some additional
additional information to function well. The PLAY responses contains information to function well. The PLAY responses contains
synchronization information to enable reliable and timely deliver of synchronization information to enable reliable and timely deliver of
how a client should synchronize different sources in the different how a client should synchronize different sources in the different
RTP sessions. It also provides a mapping between RTP timestamps and RTP sessions. It also provides a mapping between RTP timestamps and
the content time scale. When the server is notifying the client the content time scale. When the server is notifying the client
about the end of the PLAY request using the PLAY_NOTIFY, the request about the end of the media delivery requested using PLAY, it sends a
include information about which the last RTP packets are for each PLAY_NOTIFY request to the client. The PLAY_NOTIFY request includes
stream. Thus enabling correct handling of the buffer drainage at the information about the last RTP sequence numbers for each stream, and
end. thus enables correct handling of the buffer drainage at the end.
2.5.1. Media Delivery Manipulations 2.5.1. Media Delivery Manipulations
The basic playback functionality of RTSP is to request content for a The basic playback functionality of RTSP is to request content for a
particular range to be delivered to the client in a pace that enables particular range to be delivered to the client in a pace that enables
playback as intended by the creator. However, RTSP can also playback as intended by the creator. However, RTSP can also
manipulate how this delivery is done to the client in two ways. manipulate how this delivery is done to the client in two ways.
Scale: The ratio of media content time delivered per unit playback Scale: The ratio of media content time delivered per unit playback
time. time.
Speed: The ratio of playback time delivered per unit of wallclock Speed: The ratio of playback time delivered per unit of wallclock
time. time.
So both affects the media delivery per time unit. However, they are Both affect the media delivery per time unit. However, they
manipulating two independent time scales and the effects are possible manipulate two independent time scales and the effects are possible
to combine. to combine.
Scale is used for fast forward or slow motion control as it changes Scale is used for fast forward or slow motion control as it changes
the amount of content timescale that should be played back per time the amount of content timescale that should be played back per time
unit. Scale > 1.0, means fast forward, e.g. Scale=2.0 results in unit. Scale > 1.0, means fast forward, e.g. Scale=2.0 results in
that 2 seconds of content is played back every second of playback. that 2 seconds of content is played back every second of playback.
Scale = 1.0 is the default value that is used if no Scale is Scale = 1.0 is the default value that is used if no Scale is
specified, i.e. playback at the contents original rate. Scale values specified, i.e. playback at the contents original rate. Scale values
between 0 and 1.0 is providing for slow motion. Scale can be between 0 and 1.0 is providing for slow motion. Scale can be
negative to allow for reverse playback in either regular pace (Scale negative to allow for reverse playback in either regular pace (Scale
skipping to change at page 19, line 4 skipping to change at page 19, line 8
video. video.
It is very difficult to modify the playback rate of audio. A maximum It is very difficult to modify the playback rate of audio. A maximum
of 10-30% is possible by changing the pitch-rate of speech. Music of 10-30% is possible by changing the pitch-rate of speech. Music
goes out of tune if one tries to manipulate the playback rate by goes out of tune if one tries to manipulate the playback rate by
resampling it. This is a well known problem and audio is commonly resampling it. This is a well known problem and audio is commonly
muted or played back in short segments with skips to keep up with the muted or played back in short segments with skips to keep up with the
current playback point. current playback point.
For video is possible to manipulate the number of frames that is For video is possible to manipulate the number of frames that is
displayed per second. But the rendering capabilities are often displayed per second, but the rendering capabilities are often
limited to certain frame rates. The decoding, handling capabilities limited to certain frame rates. The decoding, handling capabilities
and bitrate of received encoded content also limits the number of and bitrate of received encoded content also limits the number of
frames that can be delivered. Therefore when providing fast forward frames that can be delivered. Therefore, when providing fast
one generally picks a subset of the frames from the original content forward, one generally picks a subset of the frames from the original
to be displayed. However, the video encoding methods use will content to be displayed. However, the video encoding methods used
commonly limit the possibilities on which frames that can be chosen will commonly limit the possibilities on which frames that can be
and still be decoded by the receiver. chosen and still be decoded by the receiver.
Due to the media restrictions a particular content will commonly be Due to the media restrictions, a particular content will commonly be
restricted to a limited set of possible scale ratios. To handle this restricted to a limited set of possible scale ratios. To handle this
correctly, RTSP has mechanism to indicate the supported Scale ratios correctly, RTSP has a mechanism to indicate the supported Scale
for the content. To support aggregated or dynamic content where this ratios for the content. To support aggregated or dynamic content,
may change during the ongoing session and dependent on the location where this may change during the ongoing session and dependent on the
within the content a mechanism for updating the media properties and location within the content, a mechanism for updating the media
the current used scale factor exist. properties and the current used scale factor exist.
Speed affects how much of the playback timeline that is delivered in Speed affects how much of the playback timeline that is delivered in
a given wallclock period. The default is Speed = 1 which is to a given wallclock period. The default is Speed = 1 which is to
deliver at the same rate the media is consumed. Speed > 1 means that deliver at the same rate the media is consumed. Speed > 1 means that
the receiver will get content faster than it regularly would consume the receiver will get content faster than it regularly would consume
it. Speed < 1 means that delivery is slower than the regular media it. Speed < 1 means that delivery is slower than the regular media
rate. Speed values of 0 or lower has no meaning and are not allowed. rate. Speed values of 0 or lower has no meaning and are not allowed.
This mechanism enables two general functionalities. Client side This mechanism enables two general functionalities. Client side
scale operations, i.e. the client receives all the frames and makes scale operations, i.e. the client receives all the frames and makes
the adjustment to the playback locally. The second usage is to the adjustment to the playback locally. The second usage is to
control delivery for buffering of media. By specifying a speed over control delivery for buffering of media. By specifying a speed over
1.0 the client can build up the amount of playback time it has 1.0 the client can build up the amount of playback time it has
present in its buffers to a level that is sufficient for its needs. present in its buffers to a level that is sufficient for its needs.
A naive implementation of Speed would only affect the transmission A naive implementation of Speed would only affect the transmission
schedule of the media and has a clear impact on the needed bandwidth. schedule of the media and has a clear impact on the needed bandwidth.
This would result in the data rate being proportional to the speed This would result in the data rate being proportional to the speed
factor. Speed = 1.5, i.e. 50% faster than normal delivery, will then factor. Speed = 1.5, i.e. 50% faster than normal delivery, will then
result in a 50% increase in the data transport rate. If that can be result in a 50% increase in the data transport rate. If that can be
supported or not depends solely on the underlaying network path. supported or not depends solely on the underlying network path.
Scale may also have some impact on the required bandwidth due to the Scale may also have some impact on the required bandwidth due to the
manipulation of the content in the new playback schedule. An example manipulation of the content in the new playback schedule. An example
is fast forward where only the independently decodable intra frames is fast forward where only the independently decodable intra frames
are included in the media stream. This usage of only intra frames are included in the media stream. This usage of solely intra frames
increase the data rate significantly compared to a normal sequence increase the data rate significantly compared to a normal sequence
with the same number of frames where most frames will be encoded with the same number of frames where most frames are encoded using
using prediction. prediction.
This potential increase of the data rate needs to be handled by the This potential increase of the data rate needs to be handled by the
media sender. The client has requested that the media is delivered media sender. The client has requested that the media is delivered
in a specific way, which should be honored. However, the media in a specific way, which should be honored. However, the media
sender can not ignore if the network path between the sender and the sender can not ignore if the network path between the sender and the
receiver can't handle the resulting media stream. In that case the receiver can't handle the resulting media stream. In that case the
media stream needs to be adapted to fit the available resources of media stream needs to be adapted to fit the available resources of
the path. This can result in that media quality has be reduced due the path. This can result in that media quality has be reduced due
to the delivery modifications that the client has requested. to the delivery modifications that the client has requested.
The need for bitrate adaptation becomes especially problematic in The need for bitrate adaptation becomes especially problematic in
regards to Speed. If the is target is to fill up the buffer then the connection to Speed. If the goal is to fill up the buffer, the
client may not want to do that at the cost of reduced quality. If client may not want to do that at the cost of reduced quality. If
you like to do local playout changes then you may actually require you like to do local playout changes then you may actually require
that the requested speed is honored. To resolve this issue the usage that the requested speed is honored. To resolve this issue, the
of speed specifies a range so that both usages can be supported. The usage of speed specifies a range so that both usages can be
server is request to use as high as possible speed value within the supported. The server is requested to use the highest possible speed
range if the bandwidth is insufficient for the upper bound. As long value within the range which is compatible with the available
as the server can maintain a speed value within the range it shall bandwidth. As long as the server can maintain a speed value within
not change the media quality, instead modify the speed value in the range it shall not change the media quality, but instead modify
response to available bandwidth. Only if the server becomes unable the speed value in response to available bandwidth. However, if this
to maintain the lower bound speed value does it need to modify the is not possible, the server should instead modify the media quality
media quality to maintain the lower bound speed value. to respect the lowest speed value and the available bandwidth.
This functionality enables the local scaling implementation to use a This functionality enables the local scaling implementation to use a
tight or even a range where lower bound equals upper bound to tight range, or even a range where the lower bound equals the upper
identify that it requires the server to deliver the requested amount bound, to identify that it requires the server to deliver the
of media time per delivery time independent of how much it needs to requested amount of media time per delivery time independent of how
adapt the media quality to fit within the available path bandwidth. much it needs to adapt the media quality to fit within the available
For buffer refilling it is suitable to use a range with a reasonable path bandwidth. For buffer fill up, it is suitable to use a range
span and with a lower bound at the nominal media rate like 1.0 - 2.5. with a reasonable span and with a lower bound at the nominal media
If one likes to reduce the buffer one specifies an upper bound that rate 1.0, such as 1.0 - 2.5. If the client wants to reduce the
is below 1.0 to force the server to deliver slower than nominal media buffer, it can specify an upper bound that is below 1.0 to force the
rate. server to deliver slower than the nominal media rate.
2.6. Session Maintenance and Termination 2.6. Session Maintenance and Termination
The session context that has been established is kept alive by having The session context that has been established is kept alive by having
the client show liveness. This is done in two main ways: the client show liveness. This is done in two main ways:
o Media transport protocol keep-alive. RTCP is possible to use when o Media transport protocol keep-alive. RTCP is possible to use when
using RTP. using RTP.
o Any RTSP request referencing the session context. o Any RTSP request referencing the session context.
Section 10.5 discusses the methods for showing liveness in more Section 10.5 discusses the methods for showing liveness in more
depth. If the client fails to show liveness for more than the depth. If the client fails to show liveness for more than the
established session timeout value (normally 60 seconds) the server established session timeout value (normally 60 seconds), the server
may terminate the context. Other values may be selected by the may terminate the context. Other values may be selected by the
server through the inclusion of the timeout parameter in the session server through the inclusion of the timeout parameter in the session
header. header.
The session context is normally terminated by the client by sending a The session context is normally terminated by the client by sending a
TEARDOWN request to the server referencing the aggregated control TEARDOWN request to the server referencing the aggregated control
URI. An individual media resource can be removed from a session URI. An individual media resource can be removed from a session
context by a TEARDOWN request referencing that particular media context by a TEARDOWN request referencing that particular media
resource. And if all media resources are removed from a session resource. If all media resources are removed from a session context,
context the session context is also terminated. the session context is terminated.
A client may keep the session alive indefinitely if allowed by the A client may keep the session alive indefinitely if allowed by the
server, however it is recommend to release the session context when server, however it is recommend to release the session context when
extended periods of time without media delivery activity has passed. an extended period of time without media delivery activity has
It can re-establish the session context if required later. One issue passed. It can re-establish the session context if required later.
is that what is extended periods of time is dependent on the server One issue is that what is extended periods of time is dependent on
and its usage. Because of that it is recommended that the client the server and its usage. It is recommended that the client
terminate the session before 10*times the session timeout value has terminates the session before 10*times the session timeout value has
passed. A server may terminate the session after one session timeout passed. A server may terminate the session after one session timeout
period without any client activity beyond keep-alive. When a server period without any client activity beyond keep-alive. When a server
terminates the session context it does that by sending a TEARDOWN terminates the session context, it does that by sending a TEARDOWN
request indicating the reason why. request indicating the reason.
A server can also request that the client tear down the session and A server can also request that the client tear down the session and
re-establish it at an alternative server when needed for maintenance re-establish it at an alternative server, as may be needed for
by using the REDIRECT method. The Terminate-Reason header is used to maintenance. This is done by using the REDIRECT method. The
indicate when and why. The Location header indicates where it should Terminate-Reason header is used to indicate when and why. The
connect if there are an alternative server available. When the Location header indicates where it should connect if there is an
deadline expires the server simply stop providing service. So to alternative server available. When the deadline expires, the server
achieve a clean closure the client will need to initiate session simply stops providing the service. To achieve a clean closure, the
termination prior to the deadline. In case the server has no other client needs to initiate session termination prior to the deadline.
server to redirect and likes to close the session for maintenance it In case the server has no other server to redirect to, and likes to
shall use the TEARDOWN method with a Terminate-Reason header. close the session for maintenance, it shall use the TEARDOWN method
with a Terminate-Reason header.
2.7. Extending RTSP 2.7. Extending RTSP
RTSP is quite a versatile protocol which supports extensions in many RTSP is quite a versatile protocol which supports extensions in many
different directions. Even this core specification contains several different directions. Even this core specification contains several
blocks of functionality that are optional to implement. The use case blocks of functionality that are optional to implement. The use case
and need for the protocol deployment is what should determine what and need for the protocol deployment is what should determine what is
gets implemented. Allowing for extension makes it possible for RTSP implemented. Allowing for extensions makes it possible for RTSP to
to reach out to additional usages. However, extensions will affect reach out to additional use cases. However, extensions will affect
the interoperability of the protocol and therefore it is important the interoperability of the protocol and therefore it is important
that it can be done in a structured way. that it can be done in a structured way.
The client can learn the servers capability through the usage of the The client can learn the servers capability through the usage of the
OPTIONS method (Section 13.1) and the Supported header OPTIONS method (Section 13.1) and the Supported header
(Section 16.49). It can also try and possibly fail by using new (Section 16.49). It can also try and possibly fail by using new
methods or require that particular features are supported using the methods or require that particular features are supported using the
Require or Proxy-Require header. Require or Proxy-Require header.
The RTSP protocol in itself can be extended in three ways, listed The RTSP protocol in itself can be extended in three ways, listed
skipping to change at page 22, line 26 skipping to change at page 22, line 31
methods supported by the server. The server must list the methods methods supported by the server. The server must list the methods
it supports using the Public response header. it supports using the Public response header.
o A new version of the protocol can be defined, allowing almost all o A new version of the protocol can be defined, allowing almost all
aspects (except the position of the protocol version number) to aspects (except the position of the protocol version number) to
change. A new version of the protocol must be registered through change. A new version of the protocol must be registered through
an IETF standard track document. an IETF standard track document.
The basic capability discovery mechanism can be used to both discover The basic capability discovery mechanism can be used to both discover
support for a certain feature and to ensure that a feature is support for a certain feature and to ensure that a feature is
available when performing a request. For detailed explanation of available when performing a request. For a detailed explanation of
this see Section 11. this see Section 11.
New media delivery protocols may be added and negotiated at session New media delivery protocols may be added and negotiated at session
establishment, in addition to extension to the core protocol. establishment, in addition to extension to the core protocol.
Certain type of protocol manipulations can be done through parameter Certain types of protocol manipulations can be done through parameter
formats using SET_PARAMETER and GET_PARAMETER. formats using SET_PARAMETER and GET_PARAMETER.
3. Document Conventions 3. Document Conventions
3.1. Notational Conventions 3.1. Notational Conventions
Since a few of the definitions are identical to HTTP/1.1, this Since a few of the definitions are identical to HTTP/1.1, this
specification only points to the section where they are defined specification only points to the section where they are defined
rather than copying it. For brevity, [HX.Y] is to be taken to refer rather than copying it. For brevity, [HX.Y] is to be taken to refer
to Section X.Y of the current HTTP/1.1 specification ([RFC2616]). to Section X.Y of the current HTTP/1.1 specification ([RFC2616]).
skipping to change at page 25, line 8 skipping to change at page 25, line 8
presentation is invoked. presentation is invoked.
(Media) stream: A single media instance, e.g., an audio stream or a (Media) stream: A single media instance, e.g., an audio stream or a
video stream as well as a single whiteboard or shared application video stream as well as a single whiteboard or shared application
group. When using RTP, a stream consists of all RTP and RTCP group. When using RTP, a stream consists of all RTP and RTCP
packets created by a source within an RTP session. packets created by a source within an RTP session.
Message: The basic unit of RTSP communication, consisting of a Message: The basic unit of RTSP communication, consisting of a
structured sequence of octets matching the syntax defined in structured sequence of octets matching the syntax defined in
Section 20 and transmitted over a connection or a connectionless Section 20 and transmitted over a connection or a connectionless
transport. transport. 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
request or response. An message body consists of meta-information message. A message body consists of meta-information in the form
in the form of message-header and content in the form of an of message-header and content in the form of an message-body, as
message-body, as described in Section 9. 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
information about one or more media streams within a presentation, information about one or more media streams within a presentation,
such as the set of encodings, network addresses and information such as the set of encodings, network addresses and information
about the content. Other IETF protocols such as SDP ([RFC4566]) about the content. Other IETF protocols such as SDP ([RFC4566])
use the term "session" for a presentation. The presentation use the term "session" for a presentation. The presentation
description may take several different formats, including but not description may take several different formats, including but not
limited to the session description protocol format, SDP. limited to the session description protocol format, SDP.
Response: An RTSP response. If an HTTP response is meant, that is Response: An RTSP response to a Request. One type of RTSP message.
indicated explicitly. If an HTTP response is meant, it is indicated explicitly.
Request: An RTSP request. If an HTTP request is meant, that is Request: An RTSP request. One type of RTSP message. If an HTTP
indicated explicitly. request is meant, it is indicated explicitly.
Request-URI: The URI used in a request to indicate the resource on Request-URI: The URI used in a request to indicate the resource on
which the request is to be performed. which the request is to be performed.
RTSP agent: Refers to either an RTSP client, an RTSP server, or an RTSP agent: Refers to either an RTSP client, an RTSP server, or an
RTSP proxy. In this specification, there are many capabilities RTSP proxy. In this specification, there are many capabilities
that are common to these three entities such as the capability to that are common to these three entities such as the capability to
send requests or receive responses. This term will be used when send requests or receive responses. This term will be used when
describing functionality that is applicable to all three of these describing functionality that is applicable to all three of these
entities. entities.
skipping to change at page 31, line 15 skipping to change at page 31, line 15
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 14h37 and 20 and a quarter seconds
UTC: UTC:
19961108T143720.25Z 19961108T143720.25Z
4.7. Feature-tags 4.7. Feature-Tags
Feature-tags are unique identifiers used to designate features in Feature-tags are unique identifiers used to designate features in
RTSP. These tags are used in Require (Section 16.42), Proxy-Require RTSP. These tags are used in Require (Section 16.42), Proxy-Require
(Section 16.35), Proxy-Supported (Section 16.36), and Unsupported (Section 16.35), Proxy-Supported (Section 16.36), and Unsupported
(Section 16.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
skipping to change at page 32, line 11 skipping to change at page 32, line 11
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 Section 16.23 and Section 16.25. Note that RTSP message body
tags apply to the complete presentation; i.e., both the session tags apply to the complete presentation; i.e., both the session
description and the individual media streams. Thus message body tags description and the individual media streams. Thus message body tags
can be used to verify at setup time after a redirect that the same can be used to verify at setup time after a redirect that the same
session description applies to the media at the new location using session description applies to the media at the new location using
the If-Match header. the If-Match header.
4.9. Media Properties 4.9. Media Properties
When RTSP handles media it is important to consider the different When RTSP handles media, it is important to consider the different
properties a media instance for playback can have. This properties a media instance for playback can have. This
specification considers the below listed media properties in its specification considers the below listed media properties in its
protocol operations. They are derived from the differences between a protocol operations. They are derived from the differences between a
number of supported usages. 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 are known at change during the life time of the RTSP session and are known at
the time of the creation of the session. It is expected that the 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
within the media i.e. randomly access any range of the media within the media, i.e., randomly access any range of the media
stream to playback. stream to playback.
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 where a media setup for the RTSP session. The main example is where a
playlist determines the content of the session. playlist determines the content of the session.
Live: Live media represents a progressing content stream (such as Live: Live media represents a progressing content stream (such as
broadcast TV) where the duration may or may not be known. It is broadcast TV) where the duration may or may not be known. It is
not seekable, only the content presently being delivered can be not seekable, only the content presently being delivered can be
skipping to change at page 35, line 32 skipping to change at page 35, line 32
ISO 8859-1 characters with the most-significant bit set are ISO 8859-1 characters with the most-significant bit set are
represented as 1100001x 10xxxxxx. (See RFC 3629 [RFC3629]) represented as 1100001x 10xxxxxx. (See RFC 3629 [RFC3629])
Requests contain methods, the object the method is operating upon and Requests contain methods, the object the method is operating upon and
parameters to further describe the method. Methods are idempotent parameters to further describe the method. Methods are idempotent
unless otherwise noted. Methods are also designed to require little unless otherwise noted. Methods are also designed to require little
or no state maintenance at the media server. or no state maintenance at the media server.
5.1. Message Types 5.1. Message Types
RTSP messages consist of requests from client to server or server to RTSP messages consist of requests from client to server, or server to
client and responses in the reverse direction. Request Section 7 and client, and responses in the reverse direction. Request (
Response Section 8 messages use the generic message format of RFC 822 (Section 7) ) and Response (Section 8) messages use the generic
[9] for transferring entities (the payload of the message). Both message format of RFC 822 [RFC0822] for transferring entities (the
types of message consist of a start-line, zero or more header fields payload of the message). Both types of message consist of a start-
(also known as "headers"), an empty line (i.e., a line with nothing line, zero or more header fields (also known as "headers"), an empty
preceding the CRLF) indicating the end of the header, and possibly a line (i.e., a line with nothing preceding the CRLF) indicating the
message-body. end of the header, and possibly a message-body.
generic-message = start-line generic-message = start-line
*(message-header CRLF) *(message-header CRLF)
CRLF CRLF
[ message-body ] [ message-body ]
start-line = Request-Line | Status-Line start-line = Request-Line | Status-Line
In the interest of robustness, servers SHOULD ignore any empty In the interest of robustness, servers SHOULD ignore any empty
line(s) received where a Request-Line is expected. In other words, line(s) received where a Request-Line is expected. In other words,
if the server is reading the protocol stream at the beginning of a if the server is reading the protocol stream at the beginning of a
skipping to change at page 36, line 51 skipping to change at page 36, line 51
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 an message body. A server (Section 13)) does not allow sending an message body. A server
SHOULD read and forward a message-body on any request; if the request SHOULD read and forward a message-body on any request; if the request
method does not include defined semantics for a message body, then method does not include defined semantics for a message body, then
the message-body SHOULD be ignored when handling the request.. 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 59, line 10 skipping to change at page 59, line 10
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 entity to have more
than one request outstanding and send them over the same persistent than one request outstanding and send them over the same persistent
connection. For RTSP where the relative order of requests will connection. For RTSP, where the relative order of requests will
matter it is important to maintain the order of the requests. matter, it is important to maintain the order of the requests.
Because of this the responding entity MUST process the incoming Because of this, the responding entity MUST process the incoming
requests in their sending order. The sending order can be determined requests in their sending order. The sending order can be determined
by the CSeq header and its sequence number. For TCP the delivery by the CSeq header and its sequence number. For TCP the delivery
order will be the same as the sending order. The processing of the order will be the same as the sending order. The processing of the
request 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 entity. The responses MUST be sent in the
order the requests was processed. order the requests was processed.
RTSP 2.0 has extended support for pipelining compared to RTSP 1.0. RTSP 2.0 has extended support for pipelining compared to RTSP 1.0.
The major improvement is to allow all requests to setup and initiate The major improvement is to allow all requests to setup and initiate
media playback to be pipelined after each other. This is media playback to be pipelined after each other. This is
skipping to change at page 61, line 4 skipping to change at page 61, line 4
| | S -> C | | | | | | 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 optional, but SET_PARAMETER is
For example, a fully functional server can be built to deliver required due to its usage for keep-alive. PAUSE is now required
media without any parameters. SET_PARAMETER is required however due to that it is the only way of getting out of the state
due to its usage for keep-alive. PAUSE is now required due to machines play state without terminating the whole session.
that it is the only way of getting out of the state machines play
state without terminating the whole session.
If an RTSP agent does not support a particular method, it MUST return If an RTSP agent does not support a particular method, it MUST return
501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD 501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD
NOT try this method again for the given agent / resource combination. NOT try this method again for the given agent / resource combination.
An RTSP proxy who's main function is to log or audit and not modify An RTSP proxy who's main function is to log or audit and not modify
transport or media handling in any way MAY forward RTSP messages with transport or media handling in any way MAY forward RTSP messages with
unknown methods. Note, the proxy still needs to perform the minimal unknown methods. Note, the proxy still needs to perform the minimal
required processing, like adding the Via header. required processing, like adding the Via header.
13.1. OPTIONS 13.1. OPTIONS
skipping to change at page 68, line 23 skipping to change at page 68, line 23
The PLAY method tells the server to start sending data via the The PLAY method tells the server to start sending data via the
mechanism specified in SETUP and which part of the media should be mechanism specified in SETUP and which part of the media should be
played out. PLAY requests are valid when the session is in READY or played out. PLAY requests are valid when the session is in READY or
PLAY states. A PLAY request MUST include a Session header to PLAY states. A PLAY request MUST include a Session header to
indicate which session the request applies to. indicate which session the request applies to.
Upon receipt of the PLAY request, the server MUST position the normal Upon receipt of the PLAY request, the server MUST position the normal
play time to the beginning of the range specified in the received play time to the beginning of the range specified in the received
Range header and delivers stream data until the end of the range if Range header and delivers stream data until the end of the range if
given, or until a new PLAY request is received, else to the end of given, or until a new PLAY request is received, else to the end of
the media is reached. If not Range header is present in the PLAY the media is reached. If no Range header is present in the PLAY
request the server shall play from current pause point until the end request the server shall play from current pause point until the end
of media. The pause point defaults at start to the beginning of the of media. The pause point defaults at start to the beginning of the
media. For media that is time-progressing and has no retention, the media. For media that is time-progressing and has no retention, the
pause point will always be set equal to NPT "now", i.e. current pause point will always be set equal to NPT "now", i.e. current
playback point. The pause point may also be set to a particular playback point. The pause point may also be set to a particular
point in the media by the PAUSE method, see Section 13.6. The pause point in the media by the PAUSE method, see Section 13.6. The pause
point for media that is currently playing is equal to the current point for media that is currently playing is equal to the current
media position. For time-progressing media with time-limited media position. For time-progressing media with time-limited
retention, if the pause point represents a position that is older retention, if the pause point represents a position that is older
than what is retained by the server, the pause point will be moved to than what is retained by the server, the pause point will be moved to
skipping to change at page 73, line 10 skipping to change at page 73, line 10
For aggregated sessions where the initial SETUP request (creating a For aggregated sessions where the initial SETUP request (creating a
session) is followed by one or more additional SETUP request, a PLAY session) is followed by one or more additional SETUP request, a PLAY
request MAY be pipelined after those additional SETUP requests request MAY be pipelined after those additional SETUP requests
without awaiting their responses. This procedure can reduce the without awaiting their responses. This procedure can reduce the
delay from start of session establishment until media play-out has delay from start of session establishment until media play-out has
started with one round trip time. However, a client needs to be started with one round trip time. However, a client needs to be
aware that using this procedure will result in the playout of the aware that using this procedure will result in the playout of the
server state established at the time of processing the PLAY, i.e., server state established at the time of processing the PLAY, i.e.,
after the processing of all the requests prior to the PLAY request in after the processing of all the requests prior to the PLAY request in
the pipeline. This may not be the intended one due to failure of any the pipeline. This may not be the intended one due to failure of any
of the prior requests. However a client easily determine this based of the prior requests. However, a client can easily determine this
on the responses from those requests. In case of failure the client based on the responses from those requests. In case of failure the
can halt the media playout using PAUSE and try to establish the client can halt the media playout using PAUSE and try to establish
intended state again before issuing another PLAY request. the intended state again before issuing another PLAY request.
13.4.3. Updating current PLAY Requests 13.4.3. Updating current PLAY Requests
Clients can issue PLAY request while the stream is in PLAYING state Clients can issue PLAY 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 signalled by having the first range
specification have an explicit start value, e.g. npt=45- or specification have an explicit start value, e.g. npt=45- or
skipping to change at page 75, line 23 skipping to change at page 75, line 23
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 changed of media There are ways for the client to get informed about changed of media
resources in play state, if the resource was changed. The client resources in play state, if the resource was changed. The client
will receive a PLAY_NOTIFY request with Notify-Reason header set to will receive a PLAY_NOTIFY request with Notify-Reason header set to
media-properties-update (see Section 13.5.2. The client can use the media-properties-update (see Section 13.5.2). The client can use the
value of the Media-Range to decide further actions, if the Media- value of the Media-Range to decide further actions, if the Media-
Range header is present in the PLAY_NOTIFY request. The second way Range header is present in the PLAY_NOTIFY request. The second way
is that the client issues a GET_PARAMETER request without a body but is that the client issues a GET_PARAMETER request without a body but
including a Media-Range header. The 200 OK response MUST include the including a Media-Range header. The 200 OK response MUST include the
current Media-Range header (see Section 16.29). current Media-Range header (see Section 16.29).
13.4.6. Playing Live Media 13.4.6. Playing Live Media
Live media is indicated by the content of the Media-Properties header Live media is indicated by the content of the Media-Properties header
in the SETUP response by (see also Section 16.28): in the SETUP response by (see also Section 16.28):
skipping to change at page 82, line 29 skipping to change at page 82, line 29
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
one desires to resume playing a ranged request, one simply includes one desires to resume playing a ranged request, one simply includes
the Range header from the PAUSE response and include the Seek-Style the Range header from the PAUSE response and include the Seek-Style
header with the Next policy in the PLAY request. For media that is header with the Next policy in the PLAY request. For media that is
time-progressing and has retention duration=0 the follow-up PLAY time-progressing and has retention duration=0 the follow-up PLAY
request to start media delivery again, will need to use "npt=now-" request to start media delivery again, will need to use "npt=now-"
and not the answer in the pause-response. and not the answer given in the response to PAUSE.
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
Range: npt=10-30 Range: npt=10-30
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 834 CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
skipping to change at page 87, line 36 skipping to change at page 87, line 36
Content-Type: text/parameters Content-Type: text/parameters
Session: 12345678 Session: 12345678
Content-Length: 26 Content-Length: 26
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
packets_received packets_received
jitter jitter
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 431 CSeq: 431
Session: 12345678
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 89, line 9 skipping to change at page 89, line 9
CSeq: 421 CSeq: 421
Content-length: 10 Content-length: 10
Content-type: text/parameters Content-type: text/parameters
barparam: barstuff barparam: barstuff
13.10. REDIRECT 13.10. REDIRECT
The REDIRECT method is issued by a server to inform a client that 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 provided instead. This happens for different reasons. One is can be provided instead. This happens for different reasons. One is
that the server is being administrated such that it must stop that the server is being administrated such that it must stop
providing service. Thus the client is required to connect to another providing service. Thus the client is required to connect to another
server location to access the resource indicated by the Request-URI. server location to access the resource indicated by the Request-URI.
The REDIRECT request SHALL contain a Terminate-Reason header The REDIRECT request SHALL contain a Terminate-Reason header
(Section 16.50) to inform the client of the reason for the request. (Section 16.50) to inform the client of the reason for the request.
Additional parameters related to the reason may also be included. Additional parameters related to the reason may also be included.
The intention here is to allow an server administrator to do a The intention here is to allow an server administrator to do a
controlled shutdown of the RTSP server. That requires sufficient controlled shutdown of the RTSP server. That requires sufficient
time to inform all entities having associated state with the server time to inform all entities having associated state with the server
skipping to change at page 126, line 45 skipping to change at page 126, line 45
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.
Editor's note: The below line is contradicting, as HTTP-date also
allows rfc850 and ASCII style (see [H3.3]);
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.
RTSP/2.0 servers SHOULD NOT send Expires dates more than one year in RTSP/2.0 servers SHOULD NOT send Expires dates more than one year in
the future. the future.
skipping to change at page 141, line 21 skipping to change at page 141, line 21
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 MAY also be included in Section 13.3. The RTP-Info header MAY also be included in
GET_PARAMETER requests from client to server without any value to GET_PARAMETER requests from client to server without any value to
indicate a request for this information. In such a case the Range indicate a request for this information. In such a case the Range
header MUST also be included in the request. The server SHALL header MUST also be included in the request. The server SHALL
respond if the session is in playing state with the RTP-Info value respond if the session is in playing state with the Range header
corresponding to the given Range value. filled in with the current playback point and with the corresponding
RTP-Info values.
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 156, line 10 skipping to change at page 156, line 10
tokens and comments identifying the agent and any subproducts which tokens and comments identifying the agent and any subproducts which
form a significant part of the user agent. By convention, the form a significant part of the user agent. By convention, the
product tokens are listed in order of their significance for product tokens are listed in order of their significance for
identifying the application. identifying the application.
Example: Example:
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
16.55. Vary 16.55. Vary
Editor's note: this section needs to reviewed, as RTSP does not cache
responses.
The Vary field value indicates the set of request-header fields that The Vary field value indicates the set of request-header fields that
fully determines, while the response is fresh, whether a cache is fully determines, while the response is fresh, whether a cache is
permitted to use the response to reply to a subsequent request permitted to use the response to reply to a subsequent request
without revalidation. For uncacheable or stale responses, the Vary without revalidation. For uncacheable or stale responses, the Vary
field value advises the user agent about the criteria that were used field value advises the user agent about the criteria that were used
to select the representation. A Vary field value of "*" implies that to select the representation. A Vary field value of "*" implies that
a cache cannot determine from the request headers of a subsequent a cache cannot determine from the request headers of a subsequent
request whether this response is the appropriate representation. See request whether this response is the appropriate representation.
section 13.6 XXX for use of the Vary header field by caches
An RTSP server SHOULD include a Vary header field with any cacheable An RTSP server SHOULD include a Vary header field with any cacheable
response that is subject to server-driven negotiation. Doing so response that is subject to server-driven negotiation. Doing so
allows a cache to properly interpret future requests on that resource allows a cache to properly interpret future requests on that resource
and informs the user agent about the presence of negotiation on that and informs the user agent about the presence of negotiation on that
resource. A server MAY include a Vary header field with a non- resource. A server MAY include a Vary header field with a non-
cacheable response that is subject to server-driven negotiation, cacheable response that is subject to server-driven negotiation,
since this might provide the user agent with useful information about since this might provide the user agent with useful information about
the dimensions over which the response varies at the time of the the dimensions over which the response varies at the time of the
response. response.
skipping to change at page 166, line 32 skipping to change at page 166, line 32
unless the risk of a breakdown in semantic transparency that could unless the risk of a breakdown in semantic transparency that could
result from using this date in an If-Modified-Since header would result from using this date in an If-Modified-Since header would
lead to serious problems. lead to serious problems.
In other words, the preferred behavior for an RTSP origin server is In other words, the preferred behavior for an RTSP origin server is
to send both a strong message body tag and a Last-Modified value. to send both a strong message body tag and a Last-Modified value.
In order to be legal, a strong message body tag MUST change whenever In order to be legal, a strong message body tag MUST change whenever
the associated entity value changes in any way. A weak message body the associated entity value changes in any way. A weak message body
tag SHOULD change whenever the associated entity changes in a tag SHOULD change whenever the associated entity changes in a
semantically significant way. Editor's note: all this would benefit semantically significant way.
from an example for the implementors IMHO.
Note: in order to provide semantically transparent caching, an Note: in order to provide semantically transparent caching, an
origin server must avoid reusing a specific strong message body origin server must avoid reusing a specific strong message body
tag value for two different entities, or reusing a specific weak tag value for two different entities, or reusing a specific weak
message body tag value for two semantically different entities. message body tag value for two semantically different entities.
Cache entries might persist for arbitrarily long periods, Cache entries might persist for arbitrarily long periods,
regardless of expiration times, so it might be inappropriate to regardless of expiration times, so it might be inappropriate to
expect that a cache will never again attempt to validate an entry expect that a cache will never again attempt to validate an entry
using a validator that it obtained at some point in the past. using a validator that it obtained at some point in the past.
skipping to change at page 169, line 22 skipping to change at page 169, line 22
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.
Editor's note: The text above is still referring to [H15] as the text
over there some sort of granted, i.e., security rules defined and
implemented.
It should be stressed that using the HTTP authentication alone does It should be stressed that using the HTTP authentication alone does
not provide full control message security. Therefore, in not provide full control message security. Therefore, in
environments requiring tighter security for the control messages, TLS environments requiring tighter security for the control messages, TLS
SHOULD be used, see Section 19.2. SHOULD be used, see Section 19.2.
19.2. RTSP over TLS 19.2. RTSP over TLS
RTSP MUST follow the same guidelines with regards to TLS [RFC5246] RTSP MUST follow the same guidelines with regards to TLS [RFC5246]
usage as specified for HTTP, see [RFC2818]. RTSP over TLS is usage as specified for HTTP, see [RFC2818]. RTSP over TLS is
separated from unsecured RTSP both on URI level and port level. separated from unsecured RTSP both on URI level and port level.
skipping to change at page 194, line 8 skipping to change at page 193, line 8
control-attribute = "a=control:" *SP RTSP-REQ-REF control-attribute = "a=control:" *SP RTSP-REQ-REF
a-range-def = "a=range:" ranges-spec CRLF a-range-def = "a=range:" ranges-spec CRLF
a-mtag-def = "a=mtag:" message-tag CRLF a-mtag-def = "a=mtag:" message-tag CRLF
21. Security Considerations 21. Security Considerations
Because of the similarity in syntax and usage between RTSP servers Because of the similarity in syntax and usage between RTSP servers
and HTTP servers, the security considerations outlined in [H15] and HTTP servers, the security considerations outlined in [H15] apply
apply. also.
Editor's note: The text above is still referring to [H15] as the text
over there some sort of granted, i.e., security rules defined and
implemented.
Specifically, please note the following: Specifically, please note the following:
Abuse of Server Log Information: RTSP and HTTP servers will Abuse of Server Log Information: RTSP and HTTP servers will
presumably have similar logging mechanisms, and thus should be presumably have similar logging mechanisms, and thus should be
equally guarded in protecting the contents of those logs, thus equally guarded in protecting the contents of those logs, thus
protecting the privacy of the users of the servers. See protecting the privacy of the users of the servers. See
[H15.1.1] for HTTP server recommendations regarding server [H15.1.1] for HTTP server recommendations regarding server
logs. logs.
skipping to change at page 218, line 11 skipping to change at page 217, line 11
pictures and associated audio information - part 6: pictures and associated audio information - part 6:
Extension for digital storage media and control", Extension for digital storage media and control",
ISO Draft Standard 13818-6, November 1995. ISO Draft Standard 13818-6, November 1995.
[ISO.8601.2000] [ISO.8601.2000]
International Organization for Standardization, "Data International Organization for Standardization, "Data
elements and interchange formats - Information interchange elements and interchange formats - Information interchange
- Representation of dates and times", ISO/IEC Standard - Representation of dates and times", ISO/IEC Standard
8601, December 2000. 8601, December 2000.
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992. Specification, Implementation", RFC 1305, March 1992.
[RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions [RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions
Functional Specification", RFC 1644, July 1994. Functional Specification", RFC 1644, July 1994.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
skipping to change at page 250, line 26 skipping to change at page 249, line 26
agent may believe later packets to be duplicates of packets just agent may believe later packets to be duplicates of packets just
played out. Having the RTP timestamp jump will also affect the played out. Having the RTP timestamp jump will also affect the
RTCP measurements based on this. RTCP measurements based on this.
As an example, assume a RTP timestamp frequency of 8000 Hz, a As an example, assume a RTP timestamp frequency of 8000 Hz, a
packetization interval of 100 ms and an initial sequence number and packetization interval of 100 ms and an initial sequence number and
timestamp of zero. timestamp of zero.
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 4 CSeq: 4
Session: abcdefg Session: abcdefgh
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: 4 CSeq: 4
Session: abcdefg Session: abcdefgh
Range: npt=10-15 Range: npt=10-15
RTP-Info: url="rtsp://example.com/fizzle/audiotrack" RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=0;rtptime=0 ssrc=0D12F123:seq=0;rtptime=0
The ensuing RTP data stream is depicted below: The ensuing RTP data stream is depicted below:
S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s
S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s
. . . . . .
S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s
Immediately after the end of the play range, the client follows up Upon the completion of the requested playback the server sends a
with a request to PLAY from a new NPT. PLAY_NOFIFY
S->C: PLAY_NOTIFY rtsp://example.com/fizzle RTSP/2.0
CSeq: 45
Notify-Reason: end-of-stream
Request-Status: cseq=4 status=200 reason="OK"
Range: npt=-15
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=49;rtptime=39200
Session: abcdefgh
C->S: RTSP/2.0 200 OK
CSeq: 854
User-Agent: PhonyClient/1.2
Upon the completion of the play range, the client follows up with a
request to PLAY from a new NPT.
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 5 CSeq: 5
Session: abcdefg Session: abcdefg
Range: npt=18-20 Range: npt=18-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: 5 CSeq: 5
Session: abcdefg Session: abcdefg
 End of changes. 87 change blocks. 
390 lines changed or deleted 398 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/