draft-ietf-mmusic-rfc2326bis-34.txt   draft-ietf-mmusic-rfc2326bis-35.txt 
MMUSIC Working Group H. Schulzrinne MMUSIC Working Group H. Schulzrinne
Internet-Draft Columbia University Internet-Draft Columbia University
Obsoletes: 2326 (if approved) A. Rao Obsoletes: 2326 (if approved) A. Rao
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: October 6, 2013 R. Lanphier Expires: March 6, 2014 R. Lanphier
M. Westerlund M. Westerlund
Ericsson AB Ericsson AB
M. Stiemerling (Ed.) M. Stiemerling (Ed.)
NEC NEC
April 4, 2013 September 2, 2013
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-34 draft-ietf-mmusic-rfc2326bis-35
Abstract Abstract
This memorandum defines RTSP version 2.0 which obsoletes RTSP version This memorandum defines RTSP version 2.0 which obsoletes RTSP version
1.0 defined in RFC 2326. 1.0 defined in RFC 2326.
The Real Time Streaming Protocol, or RTSP, is an application-level The Real Time Streaming Protocol, or RTSP, is an application-level
protocol for setup and control of the delivery of data with real-time protocol for setup and control of the delivery of data with real-time
properties. RTSP provides an extensible framework to enable properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and controlled, on-demand delivery of real-time data, such as audio and
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 6, 2013. This Internet-Draft will expire on March 6, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 13 skipping to change at page 3, line 13
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 11
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 13 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 13
2.1. Presentation Description . . . . . . . . . . . . . . . . 13 2.1. Presentation Description . . . . . . . . . . . . . . . . 13
2.2. Session Establishment . . . . . . . . . . . . . . . . . 14 2.2. Session Establishment . . . . . . . . . . . . . . . . . 14
2.3. Media Delivery 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 . . . . . . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . . 30
4.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . 29 4.4. Media Time Formats . . . . . . . . . . . . . . . . . . . 30
4.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 30 4.4.1. SMPTE Relative Timestamps . . . . . . . . . . . . . 30
4.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . 31 4.4.2. Normal Play Time . . . . . . . . . . . . . . . . . . 31
4.7. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 31 4.4.3. Absolute Time . . . . . . . . . . . . . . . . . . . 31
4.8. Message Body Tags . . . . . . . . . . . . . . . . . . . 31 4.5. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 32
4.9. Media Properties . . . . . . . . . . . . . . . . . . . . 32 4.6. Message Body Tags . . . . . . . . . . . . . . . . . . . 32
4.9.1. Random Access and Seeking . . . . . . . . . . . . . 33 4.7. Media Properties . . . . . . . . . . . . . . . . . . . . 33
4.9.2. Retention . . . . . . . . . . . . . . . . . . . . . 33 4.7.1. Random Access and Seeking . . . . . . . . . . . . . 34
4.9.3. Content Modifications . . . . . . . . . . . . . . . 34 4.7.2. Retention . . . . . . . . . . . . . . . . . . . . . 34
4.9.4. Supported Scale Factors . . . . . . . . . . . . . . 34 4.7.3. Content Modifications . . . . . . . . . . . . . . . 34
4.9.5. Mapping to the Attributes . . . . . . . . . . . . . 34 4.7.4. Supported Scale Factors . . . . . . . . . . . . . . 35
5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 35 4.7.5. Mapping to the Attributes . . . . . . . . . . . . . 35
5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 35 5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 35 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 36
5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 36 5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 37
5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 36 5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 37
6. General Header Fields . . . . . . . . . . . . . . . . . . . . 38 5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 38
7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6. General Header Fields . . . . . . . . . . . . . . . . . . . . 39
7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 39 7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.2. Request Header Fields . . . . . . . . . . . . . . . . . 41 7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 41
8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 43 7.2. Request Header Fields . . . . . . . . . . . . . . . . . 43
8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 43 8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 43 8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 45
8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 46 8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 45
9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 48 8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 49
9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 48 9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 50
9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 49 9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 50
10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 50 9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 51
10.1. Reliability and Acknowledgements . . . . . . . . . . . . 50 9.3. Message Body Format Negotiation . . . . . . . . . . . . 52
10.2. Using Connections . . . . . . . . . . . . . . . . . . . 51
10.3. Closing Connections . . . . . . . . . . . . . . . . . . 53 10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 53
10.4. Timing Out Connections and RTSP Messages . . . . . . . . 54 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 53
10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 55 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 54
10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 56 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 57
10.7. Overload Control . . . . . . . . . . . . . . . . . . . . 56 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 58
11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 58 10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 59
12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 60 10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 60
13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 61 10.7. Overload Control . . . . . . . . . . . . . . . . . . . . 61
13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 62 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 63
13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 63 11.1. Feature Tag: play.basic . . . . . . . . . . . . . . . . 64
13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 65 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 66
13.3.1. Changing Transport Parameters . . . . . . . . . . . 68 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 67
13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 69 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 68
13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 69 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 69
13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 74 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 71
13.4.3. Updating current PLAY Requests . . . . . . . . . . . 75 13.3.1. Changing Transport Parameters . . . . . . . . . . . 74
13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 77 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 75
13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 78 13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 75
13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 78 13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 80
13.4.7. Playing Live with Recording . . . . . . . . . . . . 79 13.4.3. Updating current PLAY Requests . . . . . . . . . . . 81
13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 79 13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 83
13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 80 13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 84
13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 81 13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 84
13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 82 13.4.7. Playing Live with Recording . . . . . . . . . . . . 85
13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 83 13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 85
13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 84 13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 86
13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 87 13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 87
13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 87 13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 89
13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 88 13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 90
13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 89 13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 91
13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 91 13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 94
13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 92 13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 94
14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 95 13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 95
15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 96
15.1. Proxies and Protocol Extensions . . . . . . . . . . . . 98 13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 98
15.2. Multiplexing and Demultiplexing of Messages . . . . . . 99 13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 100
16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 103
16.1. Validation Model . . . . . . . . . . . . . . . . . . . . 100 15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
16.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 102 15.1. Proxies and Protocol Extensions . . . . . . . . . . . . 106
16.1.2. Message Body Tag Cache Validators . . . . . . . . . 102 15.2. Multiplexing and Demultiplexing of Messages . . . . . . 107
16.1.3. Weak and Strong Validators . . . . . . . . . . . . . 102 16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
16.1. Validation Model . . . . . . . . . . . . . . . . . . . . 108
16.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 110
16.1.2. Message Body Tag Cache Validators . . . . . . . . . 110
16.1.3. Weak and Strong Validators . . . . . . . . . . . . . 110
16.1.4. Rules for When to Use Message Body Tags and 16.1.4. Rules for When to Use Message Body Tags and
Last-Modified Dates . . . . . . . . . . . . . . . . 104 Last-Modified Dates . . . . . . . . . . . . . . . . 112
16.1.5. Non-validating Conditionals . . . . . . . . . . . . 106 16.1.5. Non-validating Conditionals . . . . . . . . . . . . 114
16.2. Invalidation After Updates or Deletions . . . . . . . . 106
17. Status Code Definitions . . . . . . . . . . . . . . . . . . . 108
17.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 108
17.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 108
17.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 108
17.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 108
17.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 108
17.3.1. 301 Moved Permanently . . . . . . . . . . . . . . . 109
17.3.2. 302 Found . . . . . . . . . . . . . . . . . . . . . 109
17.3.3. 303 See Other . . . . . . . . . . . . . . . . . . . 109
17.3.4. 304 Not Modified . . . . . . . . . . . . . . . . . . 109
17.3.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 110
17.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 110
17.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 110
17.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 110
17.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 111
17.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 111
17.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 111
17.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 111
17.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 111
17.4.8. 407 Proxy Authentication Required . . . . . . . . . 112
17.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 112
17.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 112
17.4.11. 411 Length Required . . . . . . . . . . . . . . . . 112
17.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 113
17.4.13. 413 Request Message Body Too Large . . . . . . . . . 113
17.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 113
17.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 113
17.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 113
17.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 114
17.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 114
17.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 114
17.4.20. 455 Method Not Valid in This State . . . . . . . . . 114
17.4.21. 456 Header Field Not Valid for Resource . . . . . . 114
17.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 114
17.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 114
17.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 114
17.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 115
17.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 115
17.4.27. 462 Destination Unreachable . . . . . . . . . . . . 115
17.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 115
17.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 115
17.4.30. 465 Notification Reason Unknown . . . . . . . . . . 115
17.4.31. 466 Key Management Error . . . . . . . . . . . . . . 116
17.4.32. 470 Connection Authorization Required . . . . . . . 116
17.4.33. 471 Connection Credentials not accepted . . . . . . 116
17.4.34. 472 Failure to establish secure connection . . . . . 116
17.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 116
17.5.1. 500 Internal Server Error . . . . . . . . . . . . . 116
17.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 116
17.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 117
17.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 117
17.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 117
17.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 117
17.5.7. 551 Option not supported . . . . . . . . . . . . . . 117
18. Header Field Definitions . . . . . . . . . . . . . . . . . . 118
18.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 128
18.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 128
18.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 129
18.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 130
18.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 131
18.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 131
18.7. Authorization . . . . . . . . . . . . . . . . . . . . . 131
18.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 132
18.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 133
18.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 133
18.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 136
18.12. Connection-Credentials . . . . . . . . . . . . . . . . . 136
18.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 137
18.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 137
18.15. Content-Language . . . . . . . . . . . . . . . . . . . . 138
18.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 139
18.17. Content-Location . . . . . . . . . . . . . . . . . . . . 139
18.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 140
18.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 140
18.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 141
18.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 142
18.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 143
18.23. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 143
18.24. If-Modified-Since . . . . . . . . . . . . . . . . . . . 144
18.25. If-None-Match . . . . . . . . . . . . . . . . . . . . . 144
18.26. Last-Modified . . . . . . . . . . . . . . . . . . . . . 145
18.27. Location . . . . . . . . . . . . . . . . . . . . . . . . 145
18.28. Media-Properties . . . . . . . . . . . . . . . . . . . . 146
18.29. Media-Range . . . . . . . . . . . . . . . . . . . . . . 148
18.30. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 148
18.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 149
18.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 149
18.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 150
18.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 150
18.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 151
18.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 151
18.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 152
18.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 153
18.39. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 154
18.40. Request-Status . . . . . . . . . . . . . . . . . . . . . 155
18.41. Require . . . . . . . . . . . . . . . . . . . . . . . . 155
18.42. Retry-After . . . . . . . . . . . . . . . . . . . . . . 156
18.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 157
18.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 159
18.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 160
18.46. Server . . . . . . . . . . . . . . . . . . . . . . . . . 162
18.47. Session . . . . . . . . . . . . . . . . . . . . . . . . 162
18.48. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 163
18.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 164
18.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 165
18.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 165
18.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 166
18.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 173
18.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 173
18.55. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 174
18.56. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 174
19. Security Framework . . . . . . . . . . . . . . . . . . . . . 175
19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 175
19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 175
19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 176
19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 177
19.3.2. User approved TLS procedure . . . . . . . . . . . . 178
20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 181
20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 183
20.2.1. Generic Protocol elements . . . . . . . . . . . . . 183
20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 186
20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 190
20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 199
21. Security Considerations . . . . . . . . . . . . . . . . . . . 200
21.1. Signaling Protocol Threats . . . . . . . . . . . . . . . 200
21.2. Media Stream Delivery Threats . . . . . . . . . . . . . 203
21.2.1. Remote Denial of Service Attack . . . . . . . . . . 204
21.2.2. RTP Security analysis . . . . . . . . . . . . . . . 205
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 207
22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 207
22.1.1. Description . . . . . . . . . . . . . . . . . . . . 208
22.1.2. Registering New Feature-tags with IANA . . . . . . . 208
22.1.3. Registered entries . . . . . . . . . . . . . . . . . 208
22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 209
22.2.1. Description . . . . . . . . . . . . . . . . . . . . 209
22.2.2. Registering New Methods with IANA . . . . . . . . . 209
22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 209
22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 210
22.3.1. Description . . . . . . . . . . . . . . . . . . . . 210
22.3.2. Registering New Status Codes with IANA . . . . . . . 210
22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 210
22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 210
22.4.1. Description . . . . . . . . . . . . . . . . . . . . 210
22.4.2. Registering New Headers with IANA . . . . . . . . . 211
22.4.3. Registered entries . . . . . . . . . . . . . . . . . 211
22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 212 16.2. Invalidation After Updates or Deletions . . . . . . . . 114
22.5.1. Accept-Credentials policies . . . . . . . . . . . . 212 17. Status Code Definitions . . . . . . . . . . . . . . . . . . . 116
22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 213 17.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 116
22.6. Cache-Control Cache Directive Extensions . . . . . . . . 213 17.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 116
22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 214 17.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 116
22.7.1. Description . . . . . . . . . . . . . . . . . . . . 214 17.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 116
22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 215 17.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 116
22.7.3. Registered Values . . . . . . . . . . . . . . . . . 215 17.3.1. 300 . . . . . . . . . . . . . . . . . . . . . . . . 117
22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 215 17.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 117
22.8.1. Description . . . . . . . . . . . . . . . . . . . . 215 17.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 117
22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 215 17.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 118
22.8.3. Registered Values . . . . . . . . . . . . . . . . . 216 17.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 118
22.9. Range header formats . . . . . . . . . . . . . . . . . . 216 17.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 118
22.9.1. Description . . . . . . . . . . . . . . . . . . . . 216 17.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 118
22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 216 17.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 118
22.9.3. Registered Values . . . . . . . . . . . . . . . . . 216 17.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 119
22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 217 17.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 119
22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 217 17.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 119
22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 217 17.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 119
22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 218 17.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 119
22.11.1. Description . . . . . . . . . . . . . . . . . . . . 218 17.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 120
22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 218 17.4.8. 407 Proxy Authentication Required . . . . . . . . . 120
22.11.3. Registered Values . . . . . . . . . . . . . . . . . 218 17.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 120
22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 218 17.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 120
22.12.1. Description . . . . . . . . . . . . . . . . . . . . 218 17.4.11. 412 Precondition Failed . . . . . . . . . . . . . . 121
22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 219 17.4.12. 413 Request Message Body Too Large . . . . . . . . . 121
22.12.3. Registered Values . . . . . . . . . . . . . . . . . 219 17.4.13. 414 Request-URI Too Long . . . . . . . . . . . . . . 121
22.13. Transport Header Registries . . . . . . . . . . . . . . 219 17.4.14. 415 Unsupported Media Type . . . . . . . . . . . . . 121
22.13.1. Transport Protocol Specification . . . . . . . . . . 219 17.4.15. 451 Parameter Not Understood . . . . . . . . . . . . 121
22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 221 17.4.16. 452 reserved . . . . . . . . . . . . . . . . . . . . 122
22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 221 17.4.17. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 122
22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 222 17.4.18. 454 Session Not Found . . . . . . . . . . . . . . . 122
22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 222 17.4.19. 455 Method Not Valid in This State . . . . . . . . . 122
22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 223 17.4.20. 456 Header Field Not Valid for Resource . . . . . . 122
22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 224 17.4.21. 457 Invalid Range . . . . . . . . . . . . . . . . . 122
22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 225 17.4.22. 458 Parameter Is Read-Only . . . . . . . . . . . . . 122
22.16. Media Type Registration for text/parameters . . . . . . 226 17.4.23. 459 Aggregate Operation Not Allowed . . . . . . . . 123
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 228 17.4.24. 460 Only Aggregate Operation Allowed . . . . . . . . 123
23.1. Normative References . . . . . . . . . . . . . . . . . . 228 17.4.25. 461 Unsupported Transport . . . . . . . . . . . . . 123
23.2. Informative References . . . . . . . . . . . . . . . . . 230 17.4.26. 462 Destination Unreachable . . . . . . . . . . . . 123
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 233 17.4.27. 463 Destination Prohibited . . . . . . . . . . . . . 123
A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 233 17.4.28. 464 Data Transport Not Ready Yet . . . . . . . . . . 123
A.2. Media on Demand using Pipelining . . . . . . . . . . . . 237 17.4.29. 465 Notification Reason Unknown . . . . . . . . . . 124
A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 239 17.4.30. 466 Key Management Error . . . . . . . . . . . . . . 124
A.4. Single Stream Container Files . . . . . . . . . . . . . 243 17.4.31. 470 Connection Authorization Required . . . . . . . 124
A.5. Live Media Presentation Using Multicast . . . . . . . . 245 17.4.32. 471 Connection Credentials not accepted . . . . . . 124
A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 246 17.4.33. 472 Failure to establish secure connection . . . . . 124
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 248 17.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 124
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 248 17.5.1. 500 Internal Server Error . . . . . . . . . . . . . 124
B.2. State variables . . . . . . . . . . . . . . . . . . . . 248 17.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 125
B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 248 17.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 125
B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 249 17.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 125
Appendix C. Media Transport Alternatives . . . . . . . . . . . . 255 17.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 125
C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 255 17.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 125
C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 255 17.5.7. 551 Option not supported . . . . . . . . . . . . . . 126
C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 255 17.5.8. 553 Proxy Unavailable . . . . . . . . . . . . . . . 126
C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 257 18. Header Field Definitions . . . . . . . . . . . . . . . . . . 127
C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 257 18.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 137
C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 259 18.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 138
C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 260 18.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 138
C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 261 18.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 139
C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 262 18.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 140
C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 262 18.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 141
C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 266 18.7. Authentication-Info . . . . . . . . . . . . . . . . . . 141
C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 270 18.8. Authorization . . . . . . . . . . . . . . . . . . . . . 141
C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 272 18.9. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 142
C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 272 18.10. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 143
C.7. Maintaining NPT synchronization with RTP timestamps . . 272 18.11. Cache-Control . . . . . . . . . . . . . . . . . . . . . 143
C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 272 18.12. Connection . . . . . . . . . . . . . . . . . . . . . . . 146
C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 272 18.13. Connection-Credentials . . . . . . . . . . . . . . . . . 146
18.14. Content-Base . . . . . . . . . . . . . . . . . . . . . . 147
18.15. Content-Encoding . . . . . . . . . . . . . . . . . . . . 148
18.16. Content-Language . . . . . . . . . . . . . . . . . . . . 148
18.17. Content-Length . . . . . . . . . . . . . . . . . . . . . 149
18.18. Content-Location . . . . . . . . . . . . . . . . . . . . 149
18.19. Content-Type . . . . . . . . . . . . . . . . . . . . . . 150
18.20. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 151
18.21. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 152
18.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 153
18.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 154
18.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 155
18.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 155
18.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 155
18.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 156
18.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 157
18.29. Media-Properties . . . . . . . . . . . . . . . . . . . . 157
18.30. Media-Range . . . . . . . . . . . . . . . . . . . . . . 159
18.31. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 160
18.32. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 160
18.33. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 160
18.34. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 161
18.35. Proxy-Authentication-Info . . . . . . . . . . . . . . . 162
18.36. Proxy-Authorization . . . . . . . . . . . . . . . . . . 162
18.37. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 162
18.38. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 162
18.39. Public . . . . . . . . . . . . . . . . . . . . . . . . . 163
18.40. Range . . . . . . . . . . . . . . . . . . . . . . . . . 164
18.41. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 166
18.42. Request-Status . . . . . . . . . . . . . . . . . . . . . 166
18.43. Require . . . . . . . . . . . . . . . . . . . . . . . . 167
18.44. Retry-After . . . . . . . . . . . . . . . . . . . . . . 168
18.45. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 168
18.46. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 170
18.47. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 171
18.48. Server . . . . . . . . . . . . . . . . . . . . . . . . . 173
18.49. Session . . . . . . . . . . . . . . . . . . . . . . . . 173
18.50. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 175
18.51. Supported . . . . . . . . . . . . . . . . . . . . . . . 176
18.52. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 176
18.53. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 177
18.54. Transport . . . . . . . . . . . . . . . . . . . . . . . 177
18.55. Unsupported . . . . . . . . . . . . . . . . . . . . . . 184
18.56. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 185
18.57. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 185
18.58. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 186
19. Security Framework . . . . . . . . . . . . . . . . . . . . . 187
19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 187
19.1.1. Digest Authentication . . . . . . . . . . . . . . . 188
19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 188
19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 189
19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 191
19.3.2. User approved TLS procedure . . . . . . . . . . . . 192
20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 194
20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 196
20.2.1. Generic Protocol elements . . . . . . . . . . . . . 196
20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 199
20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 203
20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 212
21. Security Considerations . . . . . . . . . . . . . . . . . . . 213
21.1. Signaling Protocol Threats . . . . . . . . . . . . . . . 213
21.2. Media Stream Delivery Threats . . . . . . . . . . . . . 216
21.2.1. Remote Denial of Service Attack . . . . . . . . . . 217
21.2.2. RTP Security analysis . . . . . . . . . . . . . . . 218
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 220
22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 221
22.1.1. Description . . . . . . . . . . . . . . . . . . . . 221
22.1.2. Registering New Feature-tags with IANA . . . . . . . 221
22.1.3. Registered entries . . . . . . . . . . . . . . . . . 221
22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 222
22.2.1. Description . . . . . . . . . . . . . . . . . . . . 222
22.2.2. Registering New Methods with IANA . . . . . . . . . 222
22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 222
22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 223
22.3.1. Description . . . . . . . . . . . . . . . . . . . . 223
22.3.2. Registering New Status Codes with IANA . . . . . . . 223
22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 223
22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 223
22.4.1. Description . . . . . . . . . . . . . . . . . . . . 224
22.4.2. Registering New Headers with IANA . . . . . . . . . 224
22.4.3. Registered entries . . . . . . . . . . . . . . . . . 224
22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 226
22.5.1. Accept-Credentials policies . . . . . . . . . . . . 226
22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 226
22.6. Cache-Control Cache Directive Extensions . . . . . . . . 227
22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 227
22.7.1. Description . . . . . . . . . . . . . . . . . . . . 228
22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 228
22.7.3. Registered Values . . . . . . . . . . . . . . . . . 228
22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 228
22.8.1. Description . . . . . . . . . . . . . . . . . . . . 228
22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 229
22.8.3. Registered Values . . . . . . . . . . . . . . . . . 229
22.9. Range Header Formats . . . . . . . . . . . . . . . . . . 229
22.9.1. Description . . . . . . . . . . . . . . . . . . . . 229
22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 230
22.9.3. Registered Values . . . . . . . . . . . . . . . . . 230
22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 230
22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 230
22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 231
22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 231
22.11.1. Description . . . . . . . . . . . . . . . . . . . . 231
22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 231
22.11.3. Registered Values . . . . . . . . . . . . . . . . . 232
22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 232
22.12.1. Description . . . . . . . . . . . . . . . . . . . . 232
22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 232
22.12.3. Registered Values . . . . . . . . . . . . . . . . . 232
22.13. Transport Header Registries . . . . . . . . . . . . . . 233
22.13.1. Transport Protocol Identifier . . . . . . . . . . . 233
22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 235
22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 235
22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 236
22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 236
22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 237
22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 239
22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 239
22.16. Media Type Registration for text/parameters . . . . . . 240
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 242
23.1. Normative References . . . . . . . . . . . . . . . . . . 242
23.2. Informative References . . . . . . . . . . . . . . . . . 244
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 247
A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 247
A.2. Media on Demand using Pipelining . . . . . . . . . . . . 251
A.3. Secured Media Session for on Demand Content . . . . . . 253
A.4. Media on Demand (Unicast) . . . . . . . . . . . . . . . 256
A.5. Single Stream Container Files . . . . . . . . . . . . . 260
A.6. Live Media Presentation Using Multicast . . . . . . . . 262
A.7. Capability Negotiation . . . . . . . . . . . . . . . . . 263
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 265
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 265
B.2. State variables . . . . . . . . . . . . . . . . . . . . 265
B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 266
B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 266
Appendix C. Media Transport Alternatives . . . . . . . . . . . . 273
C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 273
C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 273
C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 273
C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 275
C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 275
C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 278
C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 278
C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 280
C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 280
C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 280
C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 284
C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 288
C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 290
C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 290
C.7. Maintaining NPT synchronization with RTP timestamps . . 290
C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 290
C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 290
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 . . . . . . . . . . . . . . . . . . . . . . 272 RTSP Session . . . . . . . . . . . . . . . . . . . . . . 290
C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 273 C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 291
Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 274 Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 292
D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 274 D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 292
D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 274 D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 292
D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 275 D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 293
D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 276 D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 294
D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 276 D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 294
D.1.5. Directionality of media stream . . . . . . . . . . . 276 D.1.5. Directionality of media stream . . . . . . . . . . . 294
D.1.6. Range of Presentation . . . . . . . . . . . . . . . 277 D.1.6. Range of Presentation . . . . . . . . . . . . . . . 295
D.1.7. Time of Availability . . . . . . . . . . . . . . . . 278 D.1.7. Time of Availability . . . . . . . . . . . . . . . . 296
D.1.8. Connection Information . . . . . . . . . . . . . . . 278 D.1.8. Connection Information . . . . . . . . . . . . . . . 296
D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 279 D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 297
D.2. Aggregate Control Not Available . . . . . . . . . . . . 279 D.2. Aggregate Control Not Available . . . . . . . . . . . . 297
D.3. Aggregate Control Available . . . . . . . . . . . . . . 280 D.3. Aggregate Control Available . . . . . . . . . . . . . . 298
D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 281 D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 299
D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 281 D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 299
Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 282
E.1. On-demand Playback of Stored Content . . . . . . . . . . 282 Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 300
E.2. Unicast Distribution of Live Content . . . . . . . . . . 283 E.1. On-demand Playback of Stored Content . . . . . . . . . . 300
E.3. On-demand Playback using Multicast . . . . . . . . . . . 284 E.2. Unicast Distribution of Live Content . . . . . . . . . . 301
E.4. Inviting an RTSP server into a conference . . . . . . . 284 E.3. On-demand Playback using Multicast . . . . . . . . . . . 302
E.5. Live Content using Multicast . . . . . . . . . . . . . . 285 E.4. Inviting an RTSP server into a conference . . . . . . . 302
Appendix F. Text format for Parameters . . . . . . . . . . . . . 287 E.5. Live Content using Multicast . . . . . . . . . . . . . . 303
Appendix G. Requirements for Unreliable Transport of RTSP . . . 288 Appendix F. Text format for Parameters . . . . . . . . . . . . . 305
Appendix H. Backwards Compatibility Considerations . . . . . . . 290 Appendix G. Requirements for Unreliable Transport of RTSP . . . 306
H.1. Play Request in Play State . . . . . . . . . . . . . . . 290 Appendix H. Backwards Compatibility Considerations . . . . . . . 308
H.2. Using Persistent Connections . . . . . . . . . . . . . . 290 H.1. Play Request in Play State . . . . . . . . . . . . . . . 308
Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 291 H.2. Using Persistent Connections . . . . . . . . . . . . . . 308
I.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 291 Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 309
I.2. Detailed List of Changes . . . . . . . . . . . . . . . . 292 I.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 309
Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 299 I.2. Detailed List of Changes . . . . . . . . . . . . . . . . 310
J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 299 Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 317
Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 301 J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 317
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 302 Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 319
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 320
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, similar to the "network remote control" for multimedia servers, similar to the
remote control for a DVD player. remote control for a DVD player.
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 by Clients can request information about streaming media from servers by
asking for a description of the media or use media description asking for a description of the media or use media description
provided externally. The media delivery protocol is used to provided externally. The media delivery protocol is used to
establish 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 DVD players remote control or media completely, as known from DVD players remote control or media
players. The requested media can consist of multiple audio and video players. The requested media can consist of multiple audio and video
streams that are delivered as a time-synchronized streams from streams that are delivered as time-synchronized streams from servers
servers to clients. to clients.
RTSP 2.0 is a replacement of RTSP 1.0 [RFC2326] and obsoletes that RTSP 2.0 is a replacement of RTSP 1.0 [RFC2326] and obsoletes that
specification. This protocol is based on RTSP 1.0 but is not specification. This protocol is based on RTSP 1.0 but is not
backwards compatible other than in the basic version negotiation backwards compatible other than in the basic version negotiation
mechanism. The changes are documented in Appendix I. There are many mechanism. The changes are documented in Appendix I. There are many
reasons why RTSP 2.0 can't be backwards compatible with RTSP 1.0 but reasons why RTSP 2.0 can't be backwards compatible with RTSP 1.0 but
some of the main ones are: some of the main ones are:
o Most headers that needed to be extensible did not define the o Most headers that needed to be extensible did not define the
allowed syntax, preventing safe deployment of extensions; allowed syntax, preventing safe deployment of extensions;
skipping to change at page 11, line 49 skipping to change at page 11, line 49
o Changed behavior of the extensibility model and its mechanism; o Changed behavior of the extensibility model and its mechanism;
o The change of syntax for some headers. o The change of syntax for some headers.
In summary, there are so many small details that changing version In summary, there are so many small details that changing version
became necessary to enable clarification and consistent behavior. became necessary to enable clarification and consistent behavior.
This document is structured as follows. It begins with an overview This document is structured as follows. It begins with an overview
of the protocol operations and its functions in an informal way. of the protocol operations and its functions in an informal way.
Then a set of definitions of used terms and document conventions is Then a set of definitions of terms used and document conventions is
introduced. It is followed by the actual RTSP 2.0 core protocol introduced. It is followed by the actual RTSP 2.0 core protocol
specification. The appendixes describe and define some specification. The appendixes describe and define some
functionalities that are not part of the core RTSP specification, but functionalities that are not part of the core RTSP specification, but
which are still important to enable some usages. Among them, the RTP which are still important to enable some usages. Among them, the RTP
usage is defined in Appendix C and the SDP usage with RTSP is defined usage is defined in Appendix C, the Session Description Protocol
in Appendix D, which are two mandatory appendixes. Others include a (SDP) usage with RTSP is defined in Appendix D, and the text/
number of informational parts discussing the changes, use cases, parameters file format Appendix F, are three normative specification
different considerations or motivations. appendixes. Others include a number of informational parts
discussing the changes, use cases, different considerations or
motivations.
2. Protocol Overview 2. Protocol Overview
This section provides an informative overview of the different This section provides an informative overview of the different
mechanisms in the RTSP 2.0 protocol, to give the reader a high level mechanisms in the RTSP 2.0 protocol, to give the reader a high level
understanding before getting into all the different details. In case understanding before getting into all the different details. In case
of conflict with this description and the later sections, the later of conflict with this description and the later sections, the later
sections take precedence. For more information about considered use sections take precedence. For more information about use cases
cases for RTSP see Appendix E. considered 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
establishes a context including content resources (the media) and establishes a context including content resources (the media) and
then controls the delivery of these content resources from the then controls the delivery of these content resources from the
provider to the consumer. RTSP has three fundamental parts: Session provider to the consumer. RTSP has three fundamental parts: Session
Establishment, Media Delivery Control, and an extensibility model Establishment, Media Delivery Control, and an extensibility model
described below. The protocol is based on some assumptions about described below. The protocol is based on some assumptions about
existing functionality to provide a complete solution for client existing functionality to provide a complete solution for client
controlled real-time media delivery. controlled real-time media delivery.
RTSP uses text-based messages, requests and responses, that may RTSP uses text-based messages, requests and responses, that may
contain a binary message body. An RTSP request starts with a method contain a binary message body. An RTSP request starts with a method
line that identifies the method, the protocol and version and the line that identifies the method, the protocol and version and the
resource to act on. Following the method line are a number of RTSP resource to act on. The resource is identified by an URI and the
headers. This part is ended by two consecutive carriage return line hostname part of the URI is used by RTSP client to resolve the IPv4
feed (CRLF) character pairs. The message body if present follows the or IPv6 address of the RTSP server. Following the method line are a
two CRLF and the body's length is described by a message header. number of RTSP headers. This part is ended by two consecutive
RTSP responses are similar, but start with a response line with the carriage return line feed (CRLF) character pairs. The message body
protocol and version, followed by a status code and a reason phrase. if present follows the two CRLF and the body's length is described by
RTSP messages are sent over a reliable transport protocol between the a message header. RTSP responses are similar, but start with a
client and server. RTSP 2.0 requires clients and servers to response line with the protocol and version, followed by a status
implement TCP, and TLS over TCP, as mandatory transports for RTSP code and a reason phrase. RTSP messages are sent over a reliable
messages. 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. Presentation Description 2.1. Presentation Description
RTSP exists to provide access to multi-media presentations and RTSP exists to provide access to multi-media presentations and
content, but tries to be agnostic about the media type or the actual content, but tries to be agnostic about the media type or the actual
media delivery protocol that is used. To enable a client to media delivery protocol that is used. To enable a client to
implement a complete system, an RTSP-external mechanism for implement a complete system, an RTSP-external mechanism for
describing the presentation and the delivery protocol(s) is used. describing the presentation and the delivery protocol(s) is used.
RTSP assumes that this description is either delivered completely out RTSP assumes that this description is either delivered completely out
of bands or as a data object in the response to a client's request of band or as a data object in the response to a client's request
using the DESCRIBE method (Section 13.2). using the DESCRIBE method (Section 13.2).
Parameters that commonly have to be included in the Presentation Parameters that commonly have to be included in the Presentation
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 vary with o Transport protocol parameters that are not negotiated or vary with
each client; each client;
o Media encoding information enabling a client to correctly decode o Media encoding information enabling a client to correctly decode
the media upon reception; the media upon reception;
skipping to change at page 14, line 18 skipping to change at page 14, line 21
o Transport protocol parameters that are not negotiated or vary with o Transport protocol parameters that are not negotiated or vary with
each client; each client;
o Media encoding information enabling a client to correctly decode o Media encoding information enabling a client to correctly decode
the media upon reception; the media upon reception;
o An aggregate control resource identifier. o An aggregate control resource identifier.
RTSP uses its own URI schemes ("rtsp" and "rtsps") to reference media RTSP uses its own URI schemes ("rtsp" and "rtsps") to reference media
resources and aggregates under common control. resources and aggregates under common control (See Section 4.2).
This specification describes in Appendix D how one uses SDP [RFC4566] This specification describes in Appendix D how one uses SDP [RFC4566]
for Presentation Description for Presentation Description
2.2. Session Establishment 2.2. Session Establishment
The RTSP client can request the establishment of an RTSP session The RTSP client can request the establishment of an RTSP session
after having used the presentation description to determine which after having used the presentation description to determine which
media streams are available, and also which media delivery protocol media streams are available, and also which media delivery protocol
is used and their particular resource identifiers. The RTSP session is used and their particular resource identifiers. The RTSP session
is a common context between the client and the server that consists is a common context between the client and the server that consists
of one or more media resources that are to be under common media of one or more media resources that are to be under common media
delivery control. delivery control.
The client creates an RTSP session by sending a request using the The client creates an RTSP session by sending a 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 parameters necessary to enable client also includes all the transport parameters necessary to enable
the media delivery protocol to function in the "Transport" header the media delivery protocol to function in the "Transport" header
(Section 18.52). This includes parameters that are pre-established (Section 18.54). This includes parameters that are pre-established
by the presentation description but necessary for any middlebox to by the presentation description but necessary for any middlebox to
correctly handle the media delivery protocols. The Transport header correctly handle the media delivery protocols. The Transport header
in a request may contain multiple alternatives for media delivery in in a request may contain multiple alternatives for media delivery in
a prioritized list, which the server can select from. These a prioritized list, which the server can select from. These
alternatives are typically based on information in the presentation alternatives are typically based on information in the presentation
description. description.
The server determines if the media resource is available upon The server determines if the media resource is available upon
receiving a SETUP request and if any of the transport parameter receiving a SETUP request and if any of the transport parameter
specifications are acceptable. If that is successful, an RTSP specifications are acceptable. If that is successful, an RTSP
session context is created and the relevant parameters and state is session context is created and the relevant parameters and state is
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 18.47). The SETUP in the response in the Session header (Section 18.49). The SETUP
response includes a Transport header that specifies which of the response includes a Transport header that specifies which of the
alternatives has been selected and relevant parameters. alternatives has been selected and relevant parameters.
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; i.e., aggregated RTSP sessions, RTSP 2.0 supports pipelined requests; i.e.,
the client can send multiple requests back-to-back without waiting the client can send multiple requests back-to-back without waiting
first for the completion of any of them. The client uses client- first for the completion of any of them. The client uses a client-
selected identifier in the Pipelined-Requests header to instruct the selected identifier in the Pipelined-Requests header (Section 18.33)
server to bind multiple requests together as if they included the to instruct the server to bind multiple requests together as if they
session identifier. 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 a couple of different headers. The Media- established sessions in a couple of different headers. The Media-
Properties header includes a number of properties that apply for the Properties header (Section 18.29) includes a number of properties
aggregate that is valuable when doing media delivery control and that apply for the aggregate that is valuable when doing media
configuring user interface. The Accept-Ranges header informs the delivery control and configuring user interface. The Accept-Ranges
client about which range formats that the server supports with these header (Section 18.5) informs the client about which range formats
media resources. The Media-Range header informs the client about the that the server supports with these media resources. The Media-Range
time range of the media currently available. header (Section 18.30) informs the client about the time range of the
media currently available.
2.3. Media Delivery Control 2.3. Media Delivery Control
After having established an RTSP session, the client can start After having established an RTSP session, the client can start
controlling the media delivery. The basic operations are Start by controlling the media delivery. The basic operations are Start by
using the PLAY method (Section 13.4) and Halt by using the PAUSE using the PLAY method (Section 13.4) and Halt by using the PAUSE
method (Section 13.6). PLAY also allows for choosing the starting method (Section 13.6). PLAY also allows for choosing the starting
media position from which the server should deliver the media. The media position from which the server should deliver the media. The
positioning is done by using the Range header (Section 18.38) that positioning is done by using the Range header (Section 18.40) that
supports several different time formats: Normal Play Time (NPT) supports several different time formats: Normal Play Time (NPT)
(Section 4.5), SMPTE Timestamps (Section 4.4) and absolute time (Section 4.4.2), Society of Motion Picture and Television Engineers
(Section 4.6). The Range header does further allow the client to (SMPTE) Timestamps (Section 4.4.1) and absolute time (Section 4.4.3).
specify a position where delivery should end, thus allowing a The Range header does further allow the client to specify a position
specific interval to be delivered. where delivery should end, thus allowing a 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
content's media properties. Content exists in a number of different content's media properties. Content exists in a number of different
types, such as: on-demand, live, and live with simultaneous types, such as: on-demand, live, and live with simultaneous
recording. Even within these categories there are differences in how recording. Even within these categories there are differences in how
the content is generated and distributed, which affect how it can be the content is generated and distributed, which affect how it can be
accessed for playback. The properties applicable for the RTSP accessed for playback. The properties applicable for the RTSP
session are provided by the server in the SETUP response using the session are provided by the server in the SETUP response using the
Media-Properties header (Section 18.28). These are expressed using Media-Properties header (Section 18.29). These are expressed using
one or several independent attributes. A first attribute is Random one or several independent attributes. A first attribute is Random
Access, which expresses if positioning can be done, and with what Access, which expresses if positioning can be done, and with what
granularity. Another aspect is whether the content will change granularity. Another aspect is whether the content will change
during the lifetime of the session. While on-demand content will be during the lifetime of the session. While on-demand content will be
provided in full from the beginning, a live stream being recorded provided in full from the beginning, a live stream being recorded
results in the length of the accessible content growing as the results in the length of the accessible content growing as the
session goes on. There also exists content that is dynamically built session goes on. There also exists content that is dynamically built
by another protocol than RTSP and thus also changes in steps during by another protocol than RTSP and thus also changes in steps during
the session, but maybe not continuously. Furthermore, when content the session, but maybe not continuously. Furthermore, when content
is recorded, there are cases where not the complete content is is recorded, there are cases where not the complete content is
skipping to change at page 16, line 31 skipping to change at page 16, line 35
When the client accesses on-demand content that allows random access, When the client accesses on-demand content that allows random access,
the client can issue the PLAY request for any point in the content the client can issue the PLAY request for any point in the content
between the start and the end. The server will deliver media from between the start and the end. The server will deliver media from
the closest random access point prior to the requested point and the closest random access point prior to the requested point and
indicate that in its PLAY response. If the client issues a PAUSE, indicate that in its PLAY response. If the client issues a PAUSE,
the delivery will be halted and the point at which the server stopped the delivery will be halted and the point at which the server stopped
will be reported back in the response. The client can later resume will be reported back in the response. The client can later resume
by sending a PLAY request without a range header. When the server is by sending a PLAY request without a range header. When the server is
about to complete the PLAY request by delivering the end of the about to complete the PLAY request by delivering the end of the
content or the requested range, the server will send a PLAY_NOTIFY content or the requested range, the server will send a PLAY_NOTIFY
request indicating this. request (Section 13.5) indicating this.
When playing live content with no extra functions, such as recording, When playing live content with no extra functions, such as recording,
the client will receive the live media from the server after having the client will receive the live media from the server after having
sent a PLAY request. Seeking in such content is not possible as the sent a PLAY request. Seeking in such content is not possible as the
server does not store it, but only forwards it from the source of the server does not store it, but only forwards it from the source of the
session. Thus delivery continues until the client sends a PAUSE session. Thus delivery continues until the client sends a PAUSE
request, tears down the session, or the content ends. request, tears down the session, or the content ends.
For live sessions that are being recorded the client will need to For live sessions that are being recorded the client will need to
keep track of how the recording progresses. Upon session keep track of how the recording progresses. Upon session
establishment the client will learn the current duration of the establishment the client will learn the current duration of the
recording from the Media-Range header. As the recording is ongoing recording from the Media-Range header. As the recording is ongoing
the content grows in direct relation to the passed time. Therefore, the content grows in direct relation to the passed time. Therefore,
each server's response to a PLAY request will contain the current each server's response to a PLAY request will contain the current
Media-Range header. The server should also regularly send every 5 Media-Range header. The server should also regularly send
minutes the current media range in a PLAY_NOTIFY request. If the approximately every 5 minutes the current media range in a
live transmission ends, the server must send a PLAY_NOTIFY request PLAY_NOTIFY request (Section 13.5.2). If the live transmission ends,
with the updated Media-Properties indicating that the content stopped the server must send a PLAY_NOTIFY request with the updated Media-
being a recorded live session and instead became on-demand content; Properties indicating that the content stopped being a recorded live
the request also contains the final media range. While the live session and instead became on-demand content; the request also
delivery continues the client can request to play the current live contains the final media range. While the live delivery continues
point by using the NPT timescale symbol "now", or it can request a the client can request to play the current live point by using the
specific point in the available content by an explicit range request NPT timescale symbol "now", or it can request a specific point in the
for that point. If the requested point is outside of the available available content by an explicit range request for that point. If
interval the server will adjust the position to the closest available the requested point is outside of the available interval the server
point, i.e., either at the beginning or the end. will adjust the position to the closest available point, i.e., either
at the beginning or the end.
A special case of recording is that where the recording is not A special case of recording is that where the recording is not
retained longer than a specific time period, thus as the live retained longer than a specific time period, thus as the live
delivery continues the client can access any media within a moving delivery continues the client can access any media within a moving
window that covers, for example, "now" to "now" minus 1 hour. A window that covers, for example, "now" to "now" minus 1 hour. A
client that pauses on a specific point within the content may not be client that pauses on a specific point within the content may not be
able to retrieve the content anymore. If the client waits too long able to retrieve the content anymore. If the client waits too long
before resuming the pause point, the content may no longer be before resuming the pause point, the content may no longer be
available. In this case the pause point will be adjusted to the end available. In this case the pause point will be adjusted to the
of the available media. closest point in the available media.
2.4. Session Parameter Manipulations 2.4. Session Parameter Manipulations
A session may have additional state or functionality that affects how A session may have additional state or functionality that affects 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 for retrieving and setting parameter values on RTSP has two methods for retrieving and setting parameter values on
either the client or the server: GET_PARAMETER (Section 13.8) and either the client or the server: GET_PARAMETER (Section 13.8) and
SET_PARAMETER (Section 13.9). These methods carry the parameters in SET_PARAMETER (Section 13.9). These methods carry the parameters in
a message body of the appropriate format. One can also use headers a message body of the appropriate format. One can also use headers
to query state with the GET_PARAMETER method. As an example, clients to query state with the GET_PARAMETER method. As an example, clients
needing to know the current media-range for a time-progressing needing to know the current media-range for a time-progressing
session can use the GET_PARAMETER method and include the media-range. session can use the GET_PARAMETER method and include the media-range.
Furthermore, synchronization information can be requested by using a Furthermore, synchronization information can be requested by using a
combination of RTP-Info and Range. combination of RTP-Info (Section 18.45) and Range (Section 18.40).
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 the headers, or parameters and their formats, which can be used.
However, responses will indicate request headers or parameters that However, responses will indicate request headers or parameters that
are not supported. A priori determination of what features are are not supported. A priori determination of what features are
available needs to be done through out-of-band mechanisms, like the available needs to be done through out-of-band mechanisms, like the
session description, or through the usage of feature tags session description, or through the usage of feature tags
(Section 4.7). (Section 4.5).
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 [RFC3550] over UDP [RFC0768], TCP [RFC0793] or the RTSP control RTP [RFC3550] over UDP [RFC0768], TCP [RFC0793] or the RTSP
connection. Additional protocols may be specified in the future connection. Additional protocols may be specified in the future
based on demand. based on demand.
The usage of RTP as media delivery protocol requires some additional The usage of RTP as media delivery protocol requires some additional
information to function well. The PLAY response contains information information to function well. The PLAY response contains information
to enable reliable and timely delivery of how a client should to enable reliable and timely delivery of how a client should
synchronize different sources in the different RTP sessions. It also synchronize different sources in the different RTP sessions. It also
provides a mapping between RTP timestamps and the content time scale. provides a mapping between RTP timestamps and the content time scale.
When the server wants to notify the client about the completion of When the server wants to notify the client about the completion of
the media delivery, it sends a PLAY_NOTIFY request to the client. the media delivery, it sends a PLAY_NOTIFY request to the client.
skipping to change at page 18, line 34 skipping to change at page 18, line 42
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.
Both affect the media delivery per time unit. However, they Both affect the media delivery per time unit. However, they
manipulate 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 (Section 18.46) is used for fast forward or slow motion control
the amount of content timescale that should be played back per time as it changes the amount of content timescale that should be played
unit. Scale > 1.0, means fast forward, e.g. Scale=2.0 results in back per time unit. Scale > 1.0, means fast forward, e.g., Scale=2.0
that 2 seconds of content is played back every second of playback. results in that 2 seconds of content is played back every second of
Scale = 1.0 is the default value that is used if no Scale is playback. Scale = 1.0 is the default value that is used if no Scale
specified, i.e., playback at the content's original rate. Scale is specified, i.e., playback at the content's original rate. Scale
values between 0 and 1.0 is providing for slow motion. Scale can be values between 0 and 1.0 is providing for slow motion. Scale can be
negative to allow for reverse playback in either regular pace (Scale negative to allow for reverse playback in either regular pace (Scale
= -1.0) or fast backwards (Scale < -1.0) or slow motion backwards = -1.0) or fast backwards (Scale < -1.0) or slow motion backwards
(-1.0 < Scale < 0). Scale = 0 is equal to pause and is not allowed. (-1.0 < Scale < 0). Scale = 0 is equal to pause and is not allowed.
In most cases the realization of scale means server side manipulation In most cases the realization of scale means server side manipulation
of the media to ensure that the client can actually play it back. of the media to ensure that the client can actually play it back.
These media manipulation and when they are needed are highly media- The nature of these media manipulations and when they are needed is
type dependent. Let's consider an example with two common media highly media-type dependent. Let's consider an example with two
types audio and video. common media types audio and 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 it is possible to manipulate the frame rate, although the For video it is possible to manipulate the frame rate, although the
rendering capabilities are often limited to certain frame rates. rendering capabilities are often limited to certain frame rates.
skipping to change at page 19, line 24 skipping to change at page 19, line 32
the rendering device limits the possible manipulations. Therefore, the rendering device limits the possible manipulations. Therefore,
the basic fast forward capabilities often are implemented by the basic fast forward capabilities often are implemented by
selecting certain subsets of frames. selecting certain subsets of frames.
Due to the media restrictions, the possible scale values are commonly Due to the media restrictions, the possible scale values are commonly
restricted to the set of realizable scale ratios. To enable the restricted to the set of realizable scale ratios. To enable the
clients to select from the possible scale values, RTSP can signal the clients to select from the possible scale values, RTSP can signal the
supported Scale ratios for the content. To support aggregated or supported Scale ratios for the content. To support aggregated or
dynamic content, where this may change during the ongoing session and dynamic content, where this may change during the ongoing session and
dependent on the location within the content, a mechanism for dependent on the location within the content, a mechanism for
updating the media properties and the currently used scale factor updating the media properties and the scale factor currently in use,
exist. exists.
Speed affects how much of the playback timeline is delivered in a Speed (Section 18.50) affects how much of the playback timeline is
given wallclock period. The default is Speed = 1 which means to delivered in a given wallclock period. The default is Speed = 1
deliver at the same rate the media is consumed. Speed > 1 means that which means to deliver at the same rate the media is consumed. Speed
the receiver will get content faster than it regularly would consume > 1 means that the receiver will get content faster than it regularly
it. Speed < 1 means that delivery is slower than the regular media would consume it. Speed < 1 means that delivery is slower than the
rate. Speed values of 0 or lower have no meaning and are not regular media rate. Speed values of 0 or lower have no meaning and
allowed. This mechanism enables two general functionalities. One is are not allowed. This mechanism enables two general functionalities.
client side scale operations, i.e. the client receives all the frames One is client side scale operations, i.e., the client receives all
and makes the adjustment to the playback locally. The second is the frames and makes the adjustment to the playback locally. The
delivery control for buffering of media. By specifying a speed over second is delivery control for buffering of media. By specifying a
1.0 the client can build up the amount of playback time it has speed over 1.0 the client can build up the amount of playback time it
present in its buffers to a level that is sufficient for its needs. has 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, would factor. Speed = 1.5, i.e., 50% faster than normal delivery, would
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 underlying 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
skipping to change at page 20, line 45 skipping to change at page 21, line 5
with a reasonable span and with a lower bound at the nominal media with a reasonable span and with a lower bound at the nominal media
rate 1.0, such as 1.0 - 2.5. If the client wants to reduce the rate 1.0, such as 1.0 - 2.5. If the client wants to reduce the
buffer, it can specify an upper bound that is below 1.0 to force the buffer, it can specify an upper bound that is below 1.0 to force the
server to deliver slower than the nominal media 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 may be used when using o Media transport protocol keep-alive. RTP Control Protocol (RTCP)
RTP. may be used when 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 sending a The session context is normally terminated by the client sending a
TEARDOWN request to the server referencing the aggregated control TEARDOWN request (Section 13.7) to the server referencing the
URI. An individual media resource can be removed from a session aggregated control URI. An individual media resource can be removed
context by a TEARDOWN request referencing that particular media from a session context by a TEARDOWN request referencing that
resource. If all media resources are removed from a session context, particular media resource. If all media resources are removed from a
the session context is terminated. session context, 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 recommended to release the session context server; however, it is recommended to release the session context
when an extended period of time without media delivery activity has when an extended period of time without media delivery activity has
passed. The client can re-establish the session context if required passed. The client can re-establish the session context if required
later. What constitutes an extended period of time is dependent on later. What constitutes an extended period of time is dependent on
the server and its usage. It is recommended that the client the server and its usage. It is recommended that the client
terminates the session before 10*times the session timeout value has terminates the session before ten 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. 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, as may be needed for re-establish it at an alternative server, as may be needed for
maintenance. This is done by using the REDIRECT method. The maintenance. This is done by using the REDIRECT method
Terminate-Reason header is used to indicate when and why. The (Section 13.10). The Terminate-Reason header (Section 18.52) is used
Location header indicates where it should connect if there is an to indicate when and why. The Location header indicates where it
alternative server available. When the deadline expires, the server should connect if there is an alternative server available. When the
simply stops providing the service. To achieve a clean closure, the deadline expires, the server simply stops providing the service. To
client needs to initiate session termination prior to the deadline. achieve a clean closure, the client needs to initiate session
In case the server has no other server to redirect to, and wants to termination prior to the deadline. In case the server has no other
close the session for maintenance, it shall use the TEARDOWN method server to redirect to, and wants to close the session for
with a Terminate-Reason header. 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 should determine what parts are and need for the protocol deployment should determine what parts are
implemented. Allowing for extensions makes it possible for RTSP to implemented. Allowing for extensions makes it possible for RTSP to
reach out to additional use cases. 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 they can be added in a structured way. that they can be added in a structured way.
The client can learn the capability of a server by using the OPTIONS The client can learn the capability of a server by using the OPTIONS
method (Section 13.1) and the Supported header (Section 18.49). It method (Section 13.1) and the Supported header (Section 18.51). It
can also try and possibly fail using new methods, or require that can also try and possibly fail using new methods, or require that
particular features are supported using the Require or Proxy-Require particular features are supported using the Require (Section 18.43)
header. or Proxy-Require (Section 18.37) 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
here in order of the magnitude of changes supported: here in increasing order of the magnitude of changes supported:
o Existing methods can be extended with new parameters, for example, o Existing methods can be extended with new parameters, for example,
headers, as long as these parameters can be safely ignored by the headers, as long as these parameters can be safely ignored by the
recipient. If the client needs negative acknowledgment when a recipient. If the client needs negative acknowledgment when a
method extension is not supported, a tag corresponding to the method extension is not supported, a tag corresponding to the
extension may be added in the field of the Require or Proxy- extension may be added in the field of the Require or Proxy-
Require headers (see Section 18.35). Require headers.
o New methods can be added. If the recipient of the message does o New methods can be added. If the recipient of the message does
not understand the request, it must respond with error code 501 not understand the request, it must respond with error code 501
(Not Implemented) so that the sender can avoid using this method (Not Implemented) so that the sender can avoid using this method
again. A client may also use the OPTIONS method to inquire about again. A client may also use the OPTIONS method to inquire about
methods supported by the server. The server must list the methods methods supported by the server. The server must list the methods
it supports using the Public response header. it supports using the Public response header.
o A new version of the protocol can be defined, allowing almost all o A new version of the protocol can be defined, allowing almost all
aspects (except the position of the protocol version number) to aspects (except the position of the protocol version number) to
change. A new version of the protocol must be registered through change. A new version of the protocol must be registered through
an IETF standard track document. an IETF standards 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 a 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 extensions to the core protocol. establishment, in addition to extensions to the core protocol.
Certain types 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.
skipping to change at page 23, line 18 skipping to change at page 23, line 18
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]).
All the mechanisms specified in this document are described in both All the mechanisms specified in this document are described in both
prose and the Augmented Backus-Naur form (ABNF) described in detail prose and the Augmented Backus-Naur form (ABNF) described in detail
in [RFC5234]. in [RFC5234].
Indented and smaller-type paragraphs are used to provide informative Indented paragraphs are used to provide informative background and
background and motivation. This is intended to give readers who were motivation. This is intended to give readers who were not involved
not involved with the formulation of the specification an with the formulation of the specification an understanding of why
understanding of why things are the way they are in RTSP. things are the way they are in RTSP.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
The word, "unspecified" is used to indicate functionality or features The word, "unspecified" is used to indicate functionality or features
that are not defined in this specification. Such functionality that are not defined in this specification. Such functionality
cannot be used in a standardized manner without further definition in cannot be used in a standardized manner without further definition in
an extension specification to RTSP. an extension specification to RTSP.
skipping to change at page 24, line 19 skipping to change at page 24, line 19
streams within these files. streams within these files.
Continuous media: Data where there is a timing relationship between Continuous media: Data where there is a timing relationship between
source and sink; that is, the sink needs to reproduce the timing source and sink; that is, the sink needs to reproduce the timing
relationship that existed at the source. The most common examples relationship that existed at the source. The most common examples
of continuous media are audio and motion video. Continuous media of continuous media are audio and motion video. Continuous media
can be real-time (interactive or conversational), where there is a can be real-time (interactive or conversational), where there is a
"tight" timing relationship between source and sink, or streaming "tight" timing relationship between source and sink, or streaming
where the relationship is less strict. where the relationship is less strict.
Feature-tag: A tag representing a certain set of functionality, i.e. Feature-tag: A tag representing a certain set of functionality,
a feature. i.e., a feature.
IRI: Internationalized Resource Identifier, is the same as an URI, IRI: Internationalized Resource Identifier, is the same as an URI,
with the exception that it allows characters from the whole with the exception that it allows characters from the whole
Universal Character Set (Unicode/ISO 10646), rather than the US- Universal Character Set (Unicode/ISO 10646), rather than the US-
ASCII only. See [RFC3987] for more information. ASCII only. See [RFC3987] for more information.
Live: Normally used to describe a presentation or session with media Live: Normally used to describe a presentation or session with media
coming from an ongoing event. This generally results in the coming from an ongoing event. This generally results in the
session having an unbound or only loosely defined duration, and session having an unbound or only loosely defined duration, and
sometimes no seek operations are possible. sometimes no seek operations are possible.
skipping to change at page 25, line 7 skipping to change at page 25, line 7
server may reside on the same host or on a different host from server may reside on the same host or on a different host from
which the presentation is invoked. which the 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-based transport. A
transport. A message is either a Request or a Response. message is either a Request or a Response.
Message Body: The information transferred as the payload of a Message Body: The information transferred as the payload of a
message (Request or response). A message body consists of meta- message (Request or response). A message body consists of meta-
information in the form of message-body headers and content in the information in the form of message-body headers and content in the
form of a message-body, as described in Section 9. form of a message-body, as described in Section 9.
Non-Aggregated Control: Control of a single media stream. Non-Aggregated Control: Control of a single media stream.
Presentation: A set of one or more streams presented to the client Presentation: A set of one or more streams presented to the client
as a complete media feed and described by a presentation as a complete media feed and described by a presentation
skipping to change at page 27, line 33 skipping to change at page 27, line 33
incremented when the format of a message within the protocol is incremented when the format of a message within the protocol is
changed. The version of an RTSP message is indicated by an RTSP- changed. The version of an RTSP message is indicated by an RTSP-
Version field in the first line of the message. Note that the major Version field in the first line of the message. Note that the major
and minor numbers MUST be treated as separate integers and that each and minor numbers MUST be treated as separate integers and that each
MAY be incremented higher than a single digit. Thus, RTSP/2.4 is a MAY be incremented higher than a single digit. Thus, RTSP/2.4 is a
lower version than RTSP/2.13, which in turn is lower than RTSP/12.3. lower version than RTSP/2.13, which in turn is lower than RTSP/12.3.
Leading zeros MUST be ignored by recipients and MUST NOT be sent. Leading zeros MUST be ignored by recipients and MUST NOT be sent.
4.2. RTSP IRI and URI 4.2. RTSP IRI and URI
RTSP 2.0 defines and registers three URI schemes "rtsp", "rtsps" and RTSP 2.0 defines and registers or updates three URI schemes "rtsp",
"rtspu". The usage of the last, "rtspu", is unspecified in RTSP 2.0, "rtsps" and "rtspu". The usage of the last, "rtspu", is unspecified
and is defined here to register and reserve the URI scheme that is in RTSP 2.0, and is defined here to register the URI scheme that was
defined in RTSP 1.0. The "rtspu" scheme indicates unspecified defined in RTSP 1.0. The "rtspu" scheme indicates unspecified
transport of the RTSP messages over unreliable transport (UDP in RTSP transport of the RTSP messages over unreliable transport (UDP in RTSP
1.0). An RTSP server MUST respond with an error code indicating the 1.0). An RTSP server MUST respond with an error code indicating the
"rtspu" scheme is not implemented (501) to a request that carries a "rtspu" scheme is not implemented (501) to a request that carries a
"rtspu" URI scheme. The details of the syntax of "rtsp" and "rtsps" "rtspu" URI scheme.
URIs has been changed from RTSP 1.0.
The details of the syntax of "rtsp" and "rtsps" URIs has been changed
from RTSP 1.0. These changes are:
o Support for IPV6 literal in host part and future IP literals
through RFC 3986 defined mechanism.
o A new relative format to use in the RTSP protocol elements that is
not required to start with "/".
Neither should have any significant impact on interoperability. If
one is required to use IPv6 literals to reach an RTSP server, then
that RTSP server must be IPv6 capable, and RTSP 1.0 is not a fully
IPv6 capable protocol. If an RTSP 1.0 client attempts to process the
URI it will not match the allowed syntax and be considered invalid
and processing will be stopped. This is clearly a failure to reach
the resource, however it is not a signification issue as RTSP 2.0
support was needed anyway in both server and client. Thus failure
will only occur in a later step when there is a RTSP version mismatch
between client and server. The second change will only occur inside
RTSP message headers, as the request URI must be an absolute URI.
Thus such usages are occurring after agents has accepted processing
RTSP 2.0 messages, and an RTSP 1.0 only agent will not be required to
parse such types of relative URIs.
This specification also defines the format of the RTSP IRI [RFC3987] This specification also defines the format of the RTSP IRI [RFC3987]
that can be used as RTSP resource identifiers and locators, in web that can be used as RTSP resource identifiers and locators, in web
pages, user interfaces, on paper, etc. However, the RTSP request pages, user interfaces, on paper, etc. However, the RTSP request
message format only allows usage of the absolute URI format. The message format only allows usage of the absolute URI format. The
RTSP IRI format MUST use the rules and transformation for IRIs to RTSP IRI format MUST use the rules and transformation for IRIs to
URIs, as defined in [RFC3987]. This way RTSP 2.0 URIs for request URIs, as defined in [RFC3987]. This allows a URI that matches the
can be produced from an RTSP IRI. RTSP 2.0 specification, and so is suitable for use in a request, to
be created from an RTSP IRI.
The RTSP IRI and URI are both syntax restricted compared to the The RTSP IRI and URI are both syntax restricted compared to the
generic syntax defined in [RFC3986] and [RFC3987]: generic syntax defined in [RFC3986] and [RFC3987]:
o An absolute URI requires the authority part; i.e., a host identity o An absolute URI requires the authority part; i.e., a host identity
MUST be provided. MUST be provided.
o Parameters in the path element are prefixed with the reserved o Parameters in the path element are prefixed with the reserved
separator ";". separator ";".
skipping to change at page 28, line 36 skipping to change at page 29, line 12
due to the RFC 3986 relative URI handling rules. Any change of the due to the RFC 3986 relative URI handling rules. Any change of the
path element using a relative URI results in the stripping of the path element using a relative URI results in the stripping of the
query, which means the relative part needs to contain the query. query, which means the relative part needs to contain the query.
The URI scheme "rtsp" requires that commands are issued via a The URI scheme "rtsp" requires that commands are issued via a
reliable protocol (within the Internet, TCP), while the scheme reliable protocol (within the Internet, TCP), while the scheme
"rtsps" identifies a reliable transport using secure transport (TLS "rtsps" identifies a reliable transport using secure transport (TLS
[RFC5246], see (Section 19). [RFC5246], see (Section 19).
For the scheme "rtsp", if no port number is provided in the authority For the scheme "rtsp", if no port number is provided in the authority
part of the URI port number 554 MUST be used. For the scheme part of the URI, the port number 554 MUST be used. For the scheme
"rtsps", the TCP port 322 is registered and MUST be assumed. "rtsps", if no port number is provided in the authority part of the
URI port number, the TCP port 322 MUST be used.
A presentation or a stream is identified by a textual media A presentation or a stream is identified by a textual media
identifier, using the character set and escape conventions of URIs identifier, using the character set and escape conventions of URIs
[RFC3986]. URIs may refer to a stream or an aggregate of streams; [RFC3986]. URIs may refer to a stream or an aggregate of streams;
i.e., a presentation. Accordingly, requests described in i.e., a presentation. Accordingly, requests described in
(Section 13) can apply to either the whole presentation or an (Section 13) can apply to either the whole presentation or an
individual stream within the presentation. Note that some request individual stream within the presentation. Note that some request
methods can only be applied to streams, not presentations, and vice methods can only be applied to streams, not presentations, and vice
versa. versa.
skipping to change at page 29, line 37 skipping to change at page 30, line 14
This decoupling also allows presentation descriptions to be used This decoupling also allows presentation descriptions to be used
with non-RTSP media control protocols simply by replacing the with non-RTSP media control protocols simply by replacing the
scheme in the URI. scheme in the URI.
4.3. Session Identifiers 4.3. Session Identifiers
Session identifiers are strings of length 8-128 characters. A Session identifiers are strings of length 8-128 characters. A
session identifier MUST be chosen cryptographically random (see session identifier MUST be chosen cryptographically random (see
[RFC4086]). It is RECOMMENDED that it contains 128 bits of entropy, [RFC4086]). It is RECOMMENDED that it contains 128 bits of entropy,
i.e. approximately 22 characters from a high quality generator (see i.e., approximately 22 characters from a high quality generator (see
Section 21). However, note that the session identifier does not Section 21). However, note that the session identifier does not
provide any security against session hijacking unless it is kept provide any security against session hijacking unless it is kept
confidential by the client, server and trusted proxies. confidential by the client, server and trusted proxies.
4.4. SMPTE Relative Timestamps 4.4. Media Time Formats
A SMPTE relative timestamp expresses time relative to the start of RTSP currently supports three different media time formats defined
the clip. Relative timestamps are expressed as SMPTE time codes for below. Additional time formats may be specified in the future.
frame-level access accuracy. The time code has the format These time formats can be used with the Range header (Section 18.40)
to request playback and specify at which media position protocol
requests actually will or has taken place. They are also used in
description of the media's properties using the Media-Range header
(Section 18.30). The format identifier only are used in Accept-
Ranges header (Section 18.5) to declare supported time formats and
also in the Range header (Section 18.40) to request the time format
used in the response.
4.4.1. SMPTE Relative Timestamps
A Society of Motion Picture and Television Engineers (SMPTE) relative
timestamp expresses time relative to the start of the clip. Relative
timestamps are expressed as SMPTE time codes [SMPTE_TC] for frame-
level access accuracy. The time code has the format
hours:minutes:seconds:frames.subframes, hours:minutes:seconds:frames.subframes,
with the origin at the start of the clip. The default SMPTE format with the origin at the start of the clip. The default SMPTE format
is "SMPTE 30 drop" format, with frame rate is 29.97 frames per is "SMPTE 30 drop" format, with frame rate is 29.97 frames per
second. Other SMPTE codes MAY be supported (such as "SMPTE 25") second. Other SMPTE codes MAY be supported (such as "SMPTE 25")
through the use of "smpte-type". For SMPTE 30, the "frames" field in through the use of "smpte-type". For SMPTE 30, the "frames" field in
the time value can assume the values 0 through 29. The difference the time value can assume the values 0 through 29. The difference
between 30 and 29.97 frames per second is handled by dropping the between 30 and 29.97 frames per second is handled by dropping the
first two frame indices (values 00 and 01) of every minute, except first two frame indices (values 00 and 01) of every minute, except
skipping to change at page 30, line 19 skipping to change at page 31, line 10
they may be omitted. Subframes are measured in one-hundredth of a they may be omitted. Subframes are measured in one-hundredth of a
frame. frame.
Examples: Examples:
smpte=10:12:33:20- smpte=10:12:33:20-
smpte=10:07:33- smpte=10:07:33-
smpte=10:07:00-10:07:33:05.01 smpte=10:07:00-10:07:33:05.01
smpte-25=10:07:00-10:07:33:05.01 smpte-25=10:07:00-10:07:33:05.01
4.5. Normal Play Time 4.4.2. Normal Play Time
Normal play time (NPT) indicates the stream absolute position Normal play time (NPT) indicates the stream absolute position
relative to the beginning of the presentation, not to be confused relative to the beginning of the presentation, not to be confused
with the Network Time Protocol (NTP) [RFC5905]. The timestamp with the Network Time Protocol (NTP) [RFC5905]. The timestamp
consists of two parts: the mandatory first part may be expressed in consists of two parts: the mandatory first part may be expressed in
either seconds or hours, minutes, and seconds. The optional second either seconds or hours, minutes, and seconds. The optional second
part consists of a decimal point and decimal figures and indicates part consists of a decimal point and decimal figures and indicates
fractions of a second. fractions of a second.
The beginning of a presentation corresponds to 0.0 seconds. Negative The beginning of a presentation corresponds to 0.0 seconds. Negative
skipping to change at page 31, line 4 skipping to change at page 31, line 40
play mode (scale = 1), advances at a faster rate when in fast scan play mode (scale = 1), advances at a faster rate when in fast scan
forward (high positive scale ratio), decrements when in scan reverse forward (high positive scale ratio), decrements when in scan reverse
(negative scale ratio) and is fixed in pause mode. NPT is (negative scale ratio) and is fixed in pause mode. NPT is
(logically) equivalent to SMPTE time codes." (logically) equivalent to SMPTE time codes."
Examples: Examples:
npt=123.45-125 npt=123.45-125
npt=12:05:35.3- npt=12:05:35.3-
npt=now- npt=now-
The syntax conforms to ISO 8601 [ISO.8601.2000]. The npt-sec The syntax conforms to ISO 8601 [ISO.8601.2000]. The npt-sec
notation is optimized for automatic generation, the npt-hhmmss notation is optimized for automatic generation, the npt-hhmmss
notation for consumption by human readers. The "now" constant notation for consumption by human readers. The "now" constant
allows clients to request to receive the live feed rather than the allows clients to request to receive the live feed rather than the
stored or time-delayed version. This is needed since neither stored or time-delayed version. This is needed since neither
absolute time nor zero time are appropriate for this case. absolute time nor zero time are appropriate for this case.
4.6. Absolute Time 4.4.3. 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 14h 37 min and 20 and a quarter Example for clock format range request for a starting time of
seconds UTC: November 8, 1996 at 14h 37 min and 20 and a quarter seconds UTC
playing for 10 min and 5 seconds, a Media-Properties header's "Time-
Limited UTC property for 24th of December 2014 at 15 hours and 00
mins, and a Terminate-Readon headers "time" property for 18th of June
2013 at 16 hours, 12 minutes and 56 seconds:
19961108T143720.25Z clock=19961108T143720.25Z-19961108T144725.25Z
Time-Limited=20141224T1500Z
time=20130618T161256Z
4.7. Feature-Tags 4.5. 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 18.41), Proxy-Require RTSP. These tags are used in Require (Section 18.43), Proxy-Require
(Section 18.35), Proxy-Supported (Section 18.36), Supported (Section 18.37), Proxy-Supported (Section 18.38), Supported
(Section 18.49) and Unsupported (Section 18.53) header fields. (Section 18.51) and Unsupported (Section 18.55) 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 it applies to. servers or proxies it applies to.
The creator of a new RTSP feature-tag should either prefix the The creator of a new RTSP feature-tag should either prefix the
feature-tag with a reverse domain name (e.g., feature-tag with a reverse domain name (e.g.,
"com.example.mynewfeature" is an apt name for a feature whose "com.example.mynewfeature" is an apt name for a feature whose
inventor can be reached at "example.com"), or register the new inventor can be reached at "example.com"), or register the new
feature-tag with the Internet Assigned Numbers Authority (IANA) (see feature-tag with the Internet Assigned Numbers Authority (IANA) (see
IANA Section 22). IANA Section 22).
The usage of feature-tags is further described in Section 11 that The usage of feature-tags is further described in Section 11 that
deals with capability handling. deals with capability handling.
4.8. Message Body Tags 4.6. Message Body Tags
Message body tags are opaque strings that are used to compare two Message body tags are opaque strings that are used to compare two
message bodies from the same resource, for example in caches or to message bodies from the same resource, for example in caches or to
optimize setup after a redirect. Message body tags can be carried in optimize setup after a redirect. Message body tags can be carried in
the MTag header (see Section 18.30) or in SDP (see Appendix D.1.9). the MTag header (see Section 18.31) or in SDP (see Appendix D.1.9).
MTag is similar to ETag in HTTP/1.1. MTag is similar to ETag in HTTP/1.1 (see Section 3.11 of [RFC2068]).
A message body tag MUST be unique across all versions of all message A message body tag MUST be unique across all versions of all message
bodies associated with a particular resource. A given message body bodies associated with a particular resource. A given message body
tag value MAY be used for message bodies obtained by requests on tag value MAY be used for message bodies obtained by requests on
different URIs. The use of the same message body tag value in different URIs. The use of the same message body tag value in
conjunction with message bodies obtained by requests on different conjunction with message bodies obtained by requests on different
URIs does not imply the equivalence of those message bodies URIs does not imply the equivalence of those message bodies
Message body tags are used in RTSP to make some methods conditional. Message body tags are used in RTSP to make some methods conditional.
The methods are made conditional through the inclusion of headers; The methods are made conditional through the inclusion of headers;
see "If-Match" (Section 18.23) and "If-None-Match" (Section 18.25). see "If-Match" (Section 18.24) and "If-None-Match" (Section 18.26).
Note that RTSP message body tags apply to the complete presentation; Note that RTSP message body tags apply to the complete presentation;
i.e., both the presentation description and the individual media i.e., both the presentation description and the individual media
streams. Thus message body tags can be used to verify at setup time streams. Thus message body tags can be used to verify at setup time
after a redirect that the same session description applies to the after a redirect that the same session description applies to the
media at the new location using the If-Match header. media at the new location using the If-Match header.
4.9. Media Properties 4.7. Media Properties
When an RTSP server handles media, it is important to consider the When an RTSP server handles media, it is important to consider the
different properties a media instance for delivery and playback can different properties a media instance for delivery and playback can
have. This specification considers the below listed media properties have. This specification considers the media properties listed below
in its protocol operations. They are derived from the differences in its protocol operations. They are derived from the differences
between a number of supported usages. between a number of supported usages.
On-demand: Media that has a fixed (given) duration that doesn't On-demand: Media that has a fixed (given) duration that doesn't
change during the life time of the RTSP session and is known at change during the life time of the RTSP session and is known at
the time of the creation of the session. It is expected that the the time of the creation of the session. It is expected that the
content of the media will not change, even if the representation, content of the media will not change, even if the representation,
i.e encoding, quality, etc, may change. Generally one can seek, i.e encoding, quality, etc, may change. Generally one can seek,
i.e. request any range, within the media. i.e., request any range, within the media.
Dynamic On-demand: This is a variation of the on-demand case where Dynamic On-demand: This is a variation of the on-demand case where
external methods are used to manipulate the actual content of the external methods are used to manipulate the actual content of the
media setup for the RTSP session. The main example is a content media setup for the RTSP session. The main example is a content
defined by a playlist. defined by a playlist.
Live: Live media represents a progressing content stream (such as Live: Live media represents a progressing content stream (such as
broadcast TV) where the duration may or may not be known. It is broadcast TV) where the duration may or may not be known. It is
not seekable, only the content presently being delivered can be not seekable, only the content presently being delivered can be
accessed. accessed.
skipping to change at page 33, line 10 skipping to change at page 34, line 5
complete media stream, or it will have a limitation in how much complete media stream, or it will have a limitation in how much
will be retained. The media range will dynamically change as the will be retained. The media range will dynamically change as the
session progress. For servers with a limited amount of storage session progress. For servers with a limited amount of storage
available for recording, there will typically be a sliding window available for recording, there will typically be a sliding window
that moves forward while new data is made available and older data that moves forward while new data is made available and older data
is discarded. is discarded.
To cover the above usages, the following media properties with To cover the above usages, the following media properties with
appropriate values are specified: appropriate values are specified:
4.9.1. Random Access and Seeking 4.7.1. Random Access and Seeking
Random Access is the ability to specify and get media delivered from Random Access is the ability to specify and get media delivered
any point inside the content, an operation called seeking. This starting from any time instant within the content, an operation
possibility is signaled using the Seek-Style header (see called seeking. The Media-Properties header will indicate the
Section 18.45) which can take the following different values: general capability for a media resource to perform random access:
Random Access: The media is seekable to any out of a large number of Random-Access: The media is seekable to any out of a large number of
points within the media. Due to media encoding limitations, a points within the media. Due to media encoding limitations, a
particular point may not be reachable, but seeking to a point particular point may not be reachable, but seeking to a point
close by is enabled. A floating point number of seconds may be close by is enabled. A floating point number of seconds may be
provided to express the worst case distance between random access provided to express the worst case distance between random access
points. points.
Conditional Random Access: Based on the above Random Access but Beginning-Only: Seeking is only possible to the beginning of the
intended to handle a case where the distance in the media between
random access points is large, and where small seek forward using
Random Access would move the client further away than the current
point.
Return To Start: Seeking is only possible to the beginning of the
content. content.
No seeking: Seeking is not possible at all. No-seeking: Seeking is not possible at all.
4.9.2. Retention If random access is possible, as indicated by Media-Properties
header, the actual behavior policy when seeking can be controlled
using the Seek-Style header (Section 18.47).
4.7.2. Retention
Media may have different retention policies in place that affect the Media may have different retention policies in place that affect the
operation on media. The following different media retention policies operation on media. The following different media retention policies
are envisioned and taken into consideration where applicable: are envisioned and taken into consideration where applicable:
Unlimited: The media will not be removed as long as the RTSP session Unlimited: The media will not be removed as long as the RTSP session
is in existence. is in existence.
Time Limited: The media will not be removed before given wallclock Time-Limited: The media will not be removed before the given
time. After that time it may or may not be available any more. wallclock time. After that time it may or may not be available
any more.
Duration limited: Each individual unit of the media will be retained Time-Duration: Each individual unit of the media will be retained
for the specified duration. for the specified duration.
4.9.3. Content Modifications 4.7.3. Content Modifications
There is also the question of how the content may change during time There is also the question of how the content may change over time
for a given media resource: for a given media resource:
Immutable: The content of the media will not change, even if the Immutable: The content of the media will not change, even if the
representation, i.e., encoding, quality, etc., may change. representation, i.e., encoding, quality, etc., may change.
Dynamic: Between explicit updates the media content will not change, Dynamic: Between explicit updates the media content will not change,
but the content may change due to external methods or triggers, but the content may change due to external methods or triggers,
such as playlists. such as playlists.
Time Progressing: As time progresses new content will become Time-Progressing: As time progresses new content will become
available. If the content also is retained it will become longer available. If the content also is retained it will become longer
as everything between the start point and the point currently as everything between the start point and the point currently
being made available can be accessed. If the media server uses a being made available can be accessed. If the media server uses a
sliding window policy for retention, the start point will also sliding window policy for retention, the start point will also
change as time progresses. change as time progresses.
4.9.4. Supported Scale Factors 4.7.4. Supported Scale Factors
Content often supports only a limited set or range of scales when Content often supports only a limited set or range of scales when
delivering the media.. To enable the client to know what values or delivering the media.. To enable the client to know what values or
ranges of scale operations that the whole content or the current ranges of scale operations that the whole content or the current
position supports, a media properties attribute for this is defined position supports, a media properties attribute for this is defined
which contains a list with the values and/or ranges that are which contains a list with the values and/or ranges that are
supported. The attribute is named "Scales". It may be updated at supported. The attribute is named "Scales". It may be updated at
any point in the content due to content consisting of spliced pieces any point in the content due to content consisting of spliced pieces
or content being dynamically updated by out-of-band mechanisms. or content being dynamically updated by out-of-band mechanisms.
4.9.5. Mapping to the Attributes 4.7.5. Mapping to the Attributes
This section shows examples of how one would map the above usages to This section shows examples of how one would map the above usages to
the properties and their values. the properties and their values.
On-demand: Random Access: Random Access=5s, Content Modifications: On-demand: Random Access: Random-Access=5.0, Content Modifications:
Immutable, Retention: unlimited or time limited. Immutable, Retention: Unlimited or Time-Limited.
Dynamic On-demand: Random Access: Random Access=3s, Content Dynamic On-demand: Random Access: Random-Access=3.0, Content
Modifications: Dynamic, Retention: unlimited or time limited. Modifications: Dynamic, Retention: Unlimited or Time-Limited.
Live: Random Access: No seeking, Content Modifications: Time Live: Random Access: No-seeking, Content Modifications: Time-
Progressing, Retention: Duration limited=0.0s Progressing, Retention: Time-Duration=0.0
Live with Recording: Random Access: Random Access=3s, Content Live with Recording: Random Access: Random-Access=3.0, Content
Modifications: Time Progressing, Retention: Duration limited=2H Modifications: Time-Progressing, Retention: Time-Duration=7200.0
5. RTSP Message 5. RTSP Message
RTSP is a text-based protocol and uses the ISO 10646 character set in RTSP is a text-based protocol and uses the ISO 10646 character set in
UTF-8 encoding RFC 3629 [RFC3629]. Lines MUST be terminated by CRLF. UTF-8 encoding RFC 3629 [RFC3629]. Lines MUST be terminated by CRLF.
Text-based protocols make it easier to add optional parameters in Text-based protocols make it easier to add optional parameters in
a self-describing manner. Since the number of parameters and the a self-describing manner. Since the number of parameters and the
frequency of commands is low, processing efficiency is not a frequency of commands is low, processing efficiency is not a
concern. Text-based protocols, if done carefully, also allow easy concern. Text-based protocols, if done carefully, also allow easy
implementation of research prototypes in scripting languages such implementation of research prototypes in scripting languages such
as TCL, Visual Basic and Perl. as TCL, Visual Basic and Perl.
The ISO 10646 character set avoids tricky character set switching, The ISO 10646 character set avoids character set switching, but is
but is invisible to the application as long as US-ASCII is being invisible to the application as long as US-ASCII is being used. This
used. This is also the encoding used for RTCP [RFC3550]. is also the encoding used for RTCP [RFC3550].
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) client, and responses in the reverse direction. Request (Section 7)
and Response (Section 8) messages use a format based on the generic and Response (Section 8) messages use a format based on the generic
message format of RFC 2822 [RFC2822] for transferring bodies (the message format of RFC 2822 [RFC2822] for transferring bodies (the
payload of the message). Both types of messages consist of a start- payload of the message). Both types of messages consist of a start-
line, zero or more header fields (also known as "headers"), an empty line, zero or more header fields (also known as "headers"), an empty
line (i.e., a line with nothing preceding the CRLF) indicating the line (i.e., a line with nothing preceding the CRLF) indicating the
end of the headers, and possibly the data of the message body. end of the headers, and possibly the data of the message body. The
below ABNF [RFC5234] is for information and the formal message
specification is present in Section 20.2.2.
generic-message = start-line generic-message = start-line
*(message-header CRLF) *(message-header CRLF)
CRLF CRLF
[ message-body-data ] [ message-body-data ]
start-line = Request-Line | Status-Line start-line = Request-Line | Status-Line
In the interest of robustness, agents MUST ignore any empty line(s) In the interest of robustness, agents MUST ignore any empty line(s)
received where a Request-Line or Response-Line is expected. In other received where a Request-Line or Response-Line is expected. In other
words, if the agent is reading the protocol stream at the beginning words, if the agent is reading the protocol stream at the beginning
of a message and receives a CRLF first, it MUST ignore the CRLF. of a message and receives a CRLF first, it MUST ignore the CRLF.
skipping to change at page 36, line 24 skipping to change at page 37, line 31
a comma. The order in which header fields with the same field-name a comma. The order in which header fields with the same field-name
are received is therefore significant to the interpretation of the are received is therefore significant to the interpretation of the
combined field value, and thus a proxy MUST NOT change the order of combined field value, and thus a proxy MUST NOT change the order of
these field values when a message is forwarded. these field values when a message is forwarded.
Unknown message headers MUST be ignored (skipping over the header to Unknown message headers MUST be ignored (skipping over the header to
the next protocol element, and not causing an error) by a RTSP server the next protocol element, and not causing an error) by a RTSP server
or client. An RTSP Proxy MUST forward unknown message headers. or client. An RTSP Proxy MUST forward unknown message headers.
Message headers defined outside of this specification that are Message headers defined outside of this specification that are
required to be interpreted by the RTSP agent will need to use feature required to be interpreted by the RTSP agent will need to use feature
tags (Section 4.7) and include them in the appropriate Require tags (Section 4.5) and include them in the appropriate Require
(Section 18.41) or Proxy-Require (Section 18.35) header. (Section 18.43) or Proxy-Require (Section 18.37) header.
5.3. Message Body 5.3. Message Body
The message body (if any) of an RTSP message is used to carry further The message body (if any) of an RTSP message is used to carry further
information for a particular resource associated with the request or information for a particular resource associated with the request or
response. An example of a message body is the Session Description response. An example of a message body is a Session Description
Protocol (SDP). Protocol (SDP) message.
The presence of a message body in either a request or a response MUST The presence of a message body in either a request or a response MUST
be signaled by the inclusion of a Content-Length header (see be signaled by the inclusion of a Content-Length header (see
Section 18.16). A message body MUST NOT be included in a request or Section 18.17) and Content-Type (see Section 18.19). A message body
response if the specification of the particular method (see Method MUST NOT be included in a request or response if the specification of
Definitions (Section 13)) does not allow sending a message body. the particular method (see Method Definitions (Section 13)) does not
allow sending a message body. In case a message body is received in
a message when not expected the message body data SHOULD be
discarded. This is to allow future extensions to define optional use
of message body.
5.4. Message Length 5.4. Message Length
When a message body is included in a message, the length of that body RTSP Messages that doesn't contain any message body is terminated by
is determined by one of the following (in order of precedence): the first empty line after the header fields (Note: An empty line is
a line with nothing preceding the CRLF.). In RTSP messages that
1. Any response message which MUST NOT include a message body (such contains message bodies the empty line is followed by the message
as the 1xx, 204, and 304 responses) is always terminated by the body. The length of that body is determined by the value of the
first empty line after the header fields, regardless of the Content-Length header (Section 18.17). The headers value represents
message-header fields present in the message. (Note: An empty the length of the message-body in octets. If this header field is
line is a line with nothing preceding the CRLF.) not present, a value of zero is assumed, i.e. no message body present
in message. Unlike an HTTP message, an RTSP message MUST contain a
2. If a Content-Length header(Section 18.16) is present, its value Content-Length header whenever it contains a message body. Note that
in bytes represents the length of the message-body. If this RTSP does not support the HTTP/1.1 "chunked" transfer coding (see
header field is not present, a value of zero is assumed. [H3.6.1]).
Unlike an HTTP message, an RTSP message MUST contain a Content-Length
header whenever it contains a message body. Note that RTSP does not
support the HTTP/1.1 "chunked" transfer coding (see [H3.6.1]).
Given the moderate length of presentation descriptions returned, Given the moderate length of presentation descriptions returned,
the server should always be able to determine its length, even if the server should always be able to determine its length, even if
it is generated dynamically, making the chunked transfer encoding it is generated dynamically, making the chunked transfer encoding
unnecessary. unnecessary.
6. General Header Fields 6. General Header Fields
General headers are headers that may be used in both requests and General headers are headers that may be used in both requests and
responses. The general headers are listed in Table 1: responses. The general headers are listed in Table 1:
+--------------------+--------------------+ +--------------------+--------------------+
| Header Name | Defined in Section | | Header Name | Defined in Section |
+--------------------+--------------------+ +--------------------+--------------------+
| Accept-Ranges | Section 18.5 | | Accept-Ranges | Section 18.5 |
| | | | | |
| Cache-Control | Section 18.10 | | Cache-Control | Section 18.11 |
| | | | | |
| Connection | Section 18.11 | | Connection | Section 18.12 |
| | | | | |
| CSeq | Section 18.19 | | CSeq | Section 18.20 |
| | | | | |
| Date | Section 18.20 | | Date | Section 18.21 |
| | | | | |
| Media-Properties | Section 18.28 | | Media-Properties | Section 18.29 |
| | | | | |
| Media-Range | Section 18.29 | | Media-Range | Section 18.30 |
| | | | | |
| Pipelined-Requests | Section 18.32 | | Pipelined-Requests | Section 18.33 |
| | | | | |
| Proxy-Supported | Section 18.36 | | Proxy-Supported | Section 18.38 |
| | | | | |
| RTP-Info | Section 18.43 | | Range | Section 18.40 |
| | | | | |
| Seek-Style | Section 18.45 | | RTP-Info | Section 18.45 |
| | | | | |
| Supported | Section 18.49 | | Scale | Section 18.46 |
| | | | | |
| Timestamp | Section 18.51 | | Seek-Style | Section 18.47 |
| | | | | |
| Via | Section 18.55 | | Server | Section 18.48 |
| | |
| Session | Section 18.49 |
| | |
| Speed | Section 18.50 |
| | |
| Supported | Section 18.51 |
| | |
| Timestamp | Section 18.53 |
| | |
| Transport | Section 18.54 |
| | |
| User-Agent | Section 18.56 |
| | |
| Via | Section 18.57 |
+--------------------+--------------------+ +--------------------+--------------------+
Table 1: The general headers used in RTSP Table 1: The general headers used in RTSP
7. Request 7. Request
A request message uses the format outlined below regardless of the A request message uses the format outlined below regardless of the
direction of a request, client to server or server to client: direction of a request, client to server or server to client:
o Request line, containing the method to be applied to the resource, o Request line, containing the method to be applied to the resource,
the identifier of the resource, and the protocol version in use; the identifier of the resource, and the protocol version in use;
o Zero or more Header lines, that can be of the following types: o Zero or more Header lines, that can be of the following types:
general headers (Section 6), request headers (Section 7.2), or general headers (Section 6), request headers (Section 7.2), or
message body headers (Section 9.1); message body headers (Section 9.1);
o One empty line (CRLF) to indicate the end of the header section; o One empty line (CRLF) to indicate the end of the header section;
o Optionally a message-body, consisting of one or more lines. The o Optionally a message-body, consisting of one or more lines. The
length of the message body in bytes is indicated by the Content- length of the message body in octets is indicated by the Content-
Length message header. Length message header.
7.1. Request Line 7.1. Request Line
The request line provides the key information about the request: what The request line provides the key information about the request: what
method, on what resources and using which RTSP version. The methods method, on what resources and using which RTSP version. The methods
that are defined by this specification are listed in Table 2. that are defined by this specification are listed in Table 2.
+---------------+--------------------+ +---------------+--------------------+
| Method | Defined in Section | | Method | Defined in Section |
skipping to change at page 41, line 22 skipping to change at page 43, line 22
capability of an intervening proxy, the server should be addressed capability of an intervening proxy, the server should be addressed
explicitly with an absolute URI that contains the server's address. explicitly with an absolute URI that contains the server's address.
For example: For example:
OPTIONS rtsp://example.com RTSP/2.0 OPTIONS rtsp://example.com RTSP/2.0
7.2. Request Header Fields 7.2. Request Header Fields
The RTSP headers in Table 3 can be included in a request, as request The RTSP headers in Table 3 can be included in a request, as request
headers, to modify the specifics of the request. Some of these headers, to modify the specifics of the request.
headers may also be used in the response to a request, as response
headers, to modify the specifics of a response (Section 8.2).
+--------------------+--------------------+ +---------------------+--------------------+
| Header | Defined in Section | | Header | Defined in Section |
+--------------------+--------------------+ +---------------------+--------------------+
| Accept | Section 18.1 | | Accept | Section 18.1 |
| | | | | |
| Accept-Credentials | Section 18.2 | | Accept-Credentials | Section 18.2 |
| | | | | |
| Accept-Encoding | Section 18.3 | | Accept-Encoding | Section 18.3 |
| | | | | |
| Accept-Language | Section 18.4 | | Accept-Language | Section 18.4 |
| | | | | |
| Authorization | Section 18.7 | | Authorization | Section 18.8 |
| | | | | |
| Bandwidth | Section 18.8 | | Bandwidth | Section 18.9 |
| | | | | |
| Blocksize | Section 18.9 | | Blocksize | Section 18.10 |
| | | | | |
| From | Section 18.22 | | From | Section 18.23 |
| | | | | |
| If-Match | Section 18.23 | | If-Match | Section 18.24 |
| | | | | |
| If-Modified-Since | Section 18.24 | | If-Modified-Since | Section 18.25 |
| | | | | |
| If-None-Match | Section 18.25 | | If-None-Match | Section 18.26 |
| | | | | |
| Notify-Reason | Section 18.31 | | Notify-Reason | Section 18.32 |
| | | | | |
| Proxy-Require | Section 18.35 | | Proxy-Authorization | Section 18.36 |
| | | | | |
| Range | Section 18.38 | | Proxy-Require | Section 18.37 |
| | | | | |
| Referrer | Section 18.39 | | Referrer | Section 18.41 |
| | | | | |
| Request-Status | Section 18.40 | | Request-Status | Section 18.42 |
| | | | | |
| Require | Section 18.41 | | Require | Section 18.43 |
| | | | | |
| Scale | Section 18.44 | | Terminate-Reason | Section 18.52 |
| | | +---------------------+--------------------+
| Session | Section 18.47 |
| | |
| Speed | Section 18.48 |
| | |
| Supported | Section 18.49 |
| | |
| Terminate-Reason | Section 18.50 |
| | |
| Transport | Section 18.52 |
| | |
| User-Agent | Section 18.54 |
+--------------------+--------------------+
Table 3: The RTSP request headers Table 3: The RTSP request headers
Detailed header definitions are provided in Section 18. Detailed header definitions are provided in Section 18.
New request headers may be defined. If the receiver of the request New request headers may be defined. If the receiver of the request
is required to understand the request header, the request MUST is required to understand the request header, the request MUST
include a corresponding feature tag in a Require or Proxy-Require include a corresponding feature tag in a Require or Proxy-Require
header to ensure the processing of the header. header to ensure the processing of the header.
skipping to change at page 43, line 46 skipping to change at page 45, line 46
The first digit of the Status-Code defines the class of response. The first digit of the Status-Code defines the class of response.
The last two digits do not have any categorization role. There are 5 The last two digits do not have any categorization role. There are 5
values for the first digit: values for the first digit:
1xx: Informational - Request received, continuing process 1xx: Informational - Request received, continuing process
2xx: Success - The action was successfully received, understood, and 2xx: Success - The action was successfully received, understood, and
accepted accepted
3rr: Redirection - Further action needs to be taken in order to 3rr: Redirection - Further action needs to be taken in order to
complete the request complete the request (3rr rather than 3xx is used as 304 is
excluded, see Section 17.3)
4xx: Client Error - The request contains bad syntax or cannot be 4xx: Client Error - The request contains bad syntax or cannot be
fulfilled fulfilled
5xx: Server Error - The server failed to fulfill an apparently valid 5xx: Server Error - The server failed to fulfill an apparently valid
request request
The individual values of the numeric status codes defined for The individual values of the numeric status codes defined for
RTSP/2.0, and an example set of corresponding Reason-Phrases, are RTSP/2.0, and an example set of corresponding Reason-Phrases, are
presented in Table 4. The reason phrases listed here are only presented in Table 4. The reason phrases listed here are only
recommended; they may be replaced by local equivalents without recommended; they may be replaced by local equivalents without
affecting the protocol. Note that RTSP adopts most HTTP/1.1 affecting the protocol. Note that RTSP adopts most HTTP/1.1
[RFC2616] status codes and adds RTSP-specific status codes starting [RFC2616] status codes and adds RTSP-specific status codes starting
at x50 to avoid conflicts with future HTTP status codes that are at x50 to avoid conflicts with future HTTP status codes that are
desirable to import into RTSP. desirable to import into RTSP. All these codes are RTSP specific and
RTSP has its own registry separate from HTTP for status codes.
RTSP status codes are extensible. RTSP applications are not required RTSP status codes are extensible. RTSP applications are not required
to understand the meaning of all registered status codes, though such to understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST understanding is obviously desirable. However, applications MUST
understand the class of any status code, as indicated by the first understand the class of any status code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the digit, and treat any unrecognized response as being equivalent to the
x00 status code of that class, with the exception that an x00 status code of that class, with an exception for unknown 3xx
unrecognized response MUST NOT be cached. For example, if an codes, which MUST be treated as a 302 (Found). The reason being that
no 300 (Multiple Choices in HTTP) is defined for RTSP. An response
with unrecognized status code MUST NOT be cached. For example, if an
unrecognized status code of 431 is received by the client, it can unrecognized status code of 431 is received by the client, it can
safely assume that there was something wrong with its request and safely assume that there was something wrong with its request and
treat the response as if it had received a 400 status code. In such treat the response as if it had received a 400 status code. In such
cases, user agents SHOULD present to the user the message body cases, user agents SHOULD present to the user the message body
returned with the response, since that message body is likely to returned with the response, since that message body is likely to
include human-readable information which will explain the unusual include human-readable information which will explain the unusual
status. status.
+------+---------------------------------+--------------------------+ +--------------------------------+-------------------------+--------+
| Code | Reason | Method | | Code | Reason | Method |
+------+---------------------------------+--------------------------+ +--------------------------------+-------------------------+--------+
| 100 | Continue | all | | 100 | Continue | all |
| | | | | | | |
| | | | | | | |
| 200 | OK | all | | 200 | OK | all |
| | | | | | | |
| | | | | | | |
| 301 | Moved Permanently | all | | 301 | Moved Permanently | all |
| | | | | | | |
| 302 | Found | all | | 302 | Found | all |
| | | | | | | |
| 303 | reserved | n/a | | 303 | reserved | n/a |
| | | | | | | |
| 304 | Not Modified | all | | 304 | Not Modified | all |
| | | | | | | |
| 305 | Use Proxy | all | | 305 | Use Proxy | all |
| | | | | 400 | Bad Request | all |
| | | | | | | |
| 400 | Bad Request | all | | 401 | Unauthorized | all |
| 401 | Unauthorized | all | | | | |
| | | | | 402 | Payment Required | all |
| 402 | Payment Required | all | | | | |
| | | | | 403 | Forbidden | all |
| 403 | Forbidden | all | | | | |
| | | | | 404 | Not Found | all |
| 404 | Not Found | all | | | | |
| | | | | 405 | Method Not Allowed | all |
| 405 | Method Not Allowed | all | | | | |
| | | | | 406 | Not Acceptable | all |
| 406 | Not Acceptable | all | | | | |
| | | | | 407 | Proxy Authentication | all |
| 407 | Proxy Authentication Required | all | | | Required | |
| | | | | | | |
| 408 | Request Timeout | all | | 408 | Request Timeout | all |
| | | | | | | |
| 410 | Gone | all | | 410 | Gone | all |
| | | | | | | |
| 411 | Length Required | all | | Precondition Failed | DESCRIBE, SETUP | 413 |
| | | | | | | |
| 412 | Precondition Failed | DESCRIBE, SETUP | | Request Message Body Too Large | all | 414 |
| | | | | | | |
| 413 | Request Message Body Too Large | all | | Request-URI Too Long | all | 415 |
| | | | | | | |
| 414 | Request-URI Too Long | all | | Unsupported Media Type | all | 451 |
| | | | | | | |
| 415 | Unsupported Media Type | all | | Parameter Not Understood | SET_PARAMETER, | 452 |
| | | | | | GET_PARAMETER | |
| 451 | Parameter Not Understood | SET_PARAMETER, | | | | |
| | | GET_PARAMETER | | reserved | n/a | 453 |
| | | | | | | |
| 452 | reserved | n/a | | Not Enough Bandwidth | SETUP | 454 |
| | | | | | | |
| 453 | Not Enough Bandwidth | SETUP | | Session Not Found | all | 455 |
| | | | | | | |
| 454 | Session Not Found | all | | Method Not Valid In This State | all | 456 |
| | | | | | | |
| 455 | Method Not Valid In This State | all | | Header Field Not Valid | all | 457 |
| | | | | | | |
| 456 | Header Field Not Valid | all | | Invalid Range | PLAY, PAUSE | 458 |
| | | | | | | |
| 457 | Invalid Range | PLAY, PAUSE | | Parameter Is Read-Only | SET_PARAMETER | 459 |
| | | | | | | |
| 458 | Parameter Is Read-Only | SET_PARAMETER | | Aggregate Operation Not | all | 460 |
| | | | | Allowed | | |
| 459 | Aggregate Operation Not Allowed | all | | Only Aggregate Operation | all | 461 |
| | | | | Allowed | | |
| 460 | Only Aggregate Operation | all | | | | |
| | Allowed | | | Unsupported Transport | all | 462 |
| | | | | | | |
| 461 | Unsupported Transport | all | | Destination Unreachable | all | 463 |
| | | | | | | |
| 462 | Destination Unreachable | all | | Destination Prohibited | SETUP | 464 |
| | | | | | | |
| 463 | Destination Prohibited | SETUP | | Data Transport Not Ready Yet | PLAY | 465 |
| | | | | | | |
| 464 | Data Transport Not Ready Yet | PLAY | | Notification Reason Unknown | PLAY_NOTIFY | 466 |
| | | | | | | |
| 465 | Notification Reason Unknown | PLAY_NOTIFY | | Key Management Error | all | 470 |
| | | | | | | |
| 466 | Key Management Error | all | | Connection Authorization | all | 471 |
| | | | | Required | | |
| 470 | Connection Authorization | all | | | | |
| | Required | | | Connection Credentials not | all | 472 |
| | | | | accepted | | |
| 471 | Connection Credentials not | all | | | | |
| | accepted | | | Failure to establish secure | all | |
| | | | | connection | | |
| 472 | Failure to establish secure | all | | | | |
| | connection | | | | | 500 |
| | | | | | | |
| | | | | Internal Server Error | all | 501 |
| 500 | Internal Server Error | all | | | | |
| | | | | Not Implemented | all | 502 |
| 501 | Not Implemented | all | | | | |
| | | | | Bad Gateway | all | 503 |
| 502 | Bad Gateway | all | | | | |
| | | | | Service Unavailable | all | 504 |
| 503 | Service Unavailable | all | | | | |
| | | | | Gateway Timeout | all | 505 |
| 504 | Gateway Timeout | all | | | | |
| | | | | RTSP Version Not Supported | all | 551 |
| 505 | RTSP Version Not Supported | all | | | | |
| | | | | Option Not Supported | all | 553 |
| 551 | Option Not Support | all | | | | |
+------+---------------------------------+--------------------------+ | Proxy Unavailable | all | |
+--------------------------------+-------------------------+--------+
Table 4: Status codes and their usage with RTSP methods Table 4: Status codes and their usage with RTSP methods
8.2. Response Headers 8.2. Response Headers
The response-headers allow the request recipient to pass additional The response-headers allow the request recipient to pass additional
information about the response which cannot be placed in the Status- information about the response which cannot be placed in the Status-
Line. This header gives information about the server and about Line. This header gives information about the server and about
further access to the resource identified by the Request-URI. All further access to the resource identified by the Request-URI. All
headers currently classified as response headers are listed in headers currently classified as response headers are listed in
Table 5. Table 5.
+------------------------+--------------------+ +------------------------+--------------------+
| Header | Defined in Section | | Header | Defined in Section |
+------------------------+--------------------+ +------------------------+--------------------+
| Connection-Credentials | Section 18.12 | | Authentication-Info | Section 18.7 |
| | |
| Location | Section 18.27 |
| | |
| MTag | Section 18.30 |
| | |
| Proxy-Authenticate | Section 18.33 |
| | |
| Public | Section 18.37 |
| | |
| Range | Section 18.38 |
| | | | | |
| Retry-After | Section 18.42 | | Connection-Credentials | Section 18.13 |
| | | | | |
| Scale | Section 18.44 | | Location | Section 18.28 |
| | | | | |
| Session | Section 18.47 | | MTag | Section 18.31 |
| | | | | |
| Server | Section 18.46 | | Proxy-Authenticate | Section 18.34 |
| | | | | |
| Speed | Section 18.48 | | Public | Section 18.39 |
| | | | | |
| Transport | Section 18.52 | | Retry-After | Section 18.44 |
| | | | | |
| Unsupported | Section 18.53 | | Unsupported | Section 18.55 |
| | | | | |
| WWW-Authenticate | Section 18.56 | | WWW-Authenticate | Section 18.58 |
+------------------------+--------------------+ +------------------------+--------------------+
Table 5: The RTSP response headers Table 5: The RTSP response headers
Response-header names can be extended reliably only in combination Response-header names can be extended reliably only in combination
with a change in the protocol version. However, the usage of with a change in the protocol version. However, the usage of
feature-tags in the request allows the responding party to learn the feature-tags in the request allows the responding party to learn the
capability of the receiver of the response. A new or experimental capability of the receiver of the response. A new or experimental
header MAY be given the semantics of response-header if all parties header MAY be given the semantics of response-header if all parties
in the communication recognize them to be response-header. in the communication recognize them to be a response-header.
Unrecognized headers in responses are treated as message-headers and Unrecognized headers in responses are treated as message-headers and
hence MUST be ignored. hence MUST be ignored.
9. Message Body 9. Message Body
Request and Response messages MAY transfer a message body, if not Request and Response messages MAY transfer a message body, if not
otherwise restricted by the request method or response status code. otherwise restricted by the request method or response status code.
The message body consists of the content data itself (see also The message body consists of the content data itself (see also
Section 5.2). Section 5.3).
The SET_PARAMETER and GET_PARAMETER request and response, and The SET_PARAMETER and GET_PARAMETER requests and responses, and the
DESCRIBE response MAY have a message body. All 4xx and 5xx responses DESCRIBE response as defined by this specification MAY have a message
MAY also have a message body. body; the purpose of the message body is defined in each case. All
4xx and 5xx responses MAY also have a message body to carry
additional response information. Generally a message body MAY be
attached to any RTSP 2.0 request or response, but the content of the
message body MAY be ignored by the receiver. Extensions to this
specification can specify the purpose and content of message bodies,
including requiring their inclusion.
In this section, both sender and recipient refer to either the client In this section, both sender and recipient refer to either the client
or the server, depending on who sends and who receives the message or the server, depending on who sends and who receives the message
body. body.
9.1. Message-Body Header Fields 9.1. Message-Body Header Fields
Message-body header fields define meta-information about the content Message-body header fields define meta-information about the content
data in the message body. The message-body header fields are listed data in the message body. The message-body header fields are listed
in Table 6. in Table 6.
+------------------+--------------------+ +------------------+--------------------+
| Header | Defined in Section | | Header | Defined in Section |
+------------------+--------------------+ +------------------+--------------------+
| Allow | Section 18.6 | | Allow | Section 18.6 |
| | | | | |
| Content-Base | Section 18.13 | | Content-Base | Section 18.14 |
| | | | | |
| Content-Encoding | Section 18.14 | | Content-Encoding | Section 18.15 |
| | | | | |
| Content-Language | Section 18.15 | | Content-Language | Section 18.16 |
| | | | | |
| Content-Length | Section 18.16 | | Content-Length | Section 18.17 |
| | | | | |
| Content-Location | Section 18.17 | | Content-Location | Section 18.18 |
| | | | | |
| Content-Type | Section 18.18 | | Content-Type | Section 18.19 |
| | | | | |
| Expires | Section 18.21 | | Expires | Section 18.22 |
| | | | | |
| Last-Modified | Section 18.26 | | Last-Modified | Section 18.27 |
+------------------+--------------------+ +------------------+--------------------+
Table 6: The RTSP message-body headers Table 6: The RTSP message-body headers
The extension-header mechanism allows additional message-body header The extension-header mechanism allows additional message-body header
fields to be defined without changing the protocol, but these fields fields to be defined without changing the protocol, but these fields
cannot be assumed to be recognizable by the recipient. Unrecognized cannot be assumed to be recognizable by the recipient. Unrecognized
header fields MUST be ignored by the recipient and forwarded by header fields MUST be ignored by the recipient and forwarded by
proxies. proxies.
skipping to change at page 49, line 21 skipping to change at page 51, line 49
message, the data type of that content data is determined via the message, the data type of that content data is determined via the
header fields Content-Type and Content-Encoding. header fields Content-Type and Content-Encoding.
Content-Type specifies the media type of the underlying data. Content-Type specifies the media type of the underlying data.
Content-Encoding may be used to indicate any additional content Content-Encoding may be used to indicate any additional content
codings applied to the data, usually for the purpose of data codings applied to the data, usually for the purpose of data
compression, that are a property of the requested resource. There is compression, that are a property of the requested resource. There is
no default encoding. no default encoding.
The Content-Length of a message is the length of the content, The Content-Length of a message is the length of the content,
measured in bytes. measured in octets.
9.3. Message Body Format Negotiation
The content format of the message body is provided using the Content-
Type header (Section 18.19). To enable the responder of a request to
determine which media type it should use, the requestor may include
the Accept header (Section 18.1) in a request to identify supported
media types or media type ranges suitable to the response. In cases
the responder is not supporting any of the specified formats, then
the request response will be a 406 (Not Acceptable) error code.
The media types that may be used on requests with message bodies
needs to be determined through the use of feature-tags, specification
requirement or trial and error. Trial and error works in the regards
that in case the responder is not supporting the media type of the
message body it will respond with a 415 (Unsupported Media Type).
The formats supported and their negotiation is done individually on a
per method and direction (request or response body) direction.
Requirements on supporting particular media types for use as message
bodies in requests and response SHALL also be specified on per method
and direction basis.
10. Connections 10. Connections
RTSP Messages are transferred between RTSP agents and proxies using a
transport connection. This transport connection uses TCP or TCP/TLS.
This transport connection is referred to as the connection or
possibly RTSP connection within this document.
RTSP requests can be transmitted using the two different connection RTSP requests can be transmitted using the two different connection
scenarios listed below: scenarios listed below:
o persistent - a transport connection is used for several request/ o persistent - a transport connection is used for several request/
response transactions; response transactions;
o transient - a transport connection is used for a single request/ o transient - a transport connection is used for a single request/
response transaction. response transaction.
RFC 2326 attempted to specify an optional mechanism for transmitting RFC 2326 attempted to specify an optional mechanism for transmitting
RTSP messages in connectionless mode over a transport protocol such RTSP messages in connectionless mode over a transport protocol such
as UDP. However, it was not specified in sufficient detail to allow as UDP. However, it was not specified in sufficient detail to allow
for interoperable implementations. In an attempt to reduce for interoperable implementations. In an attempt to reduce
complexity and scope, and due to lack of interest, RTSP 2.0 does not complexity and scope, and due to lack of interest, RTSP 2.0 does not
attempt to define a mechanism for supporting RTSP over UDP or other attempt to define a mechanism for supporting RTSP over UDP or other
connectionless transport protocols. A side-effect of this is that connectionless transport protocols. A side-effect of this is that
RTSP requests MUST NOT be sent to multicast groups since no RTSP requests MUST NOT be sent to multicast groups since no
connection can be established with a specific receiver in multicast connection can be established with a specific receiver in multicast
environments. environments.
Certain RTSP headers, such as the CSeq header (Section 18.19), which Certain RTSP headers, such as the CSeq header (Section 18.20), which
may appear to be relevant only to connectionless transport scenarios may appear to be relevant only to connectionless transport scenarios
are still retained and MUST be implemented according to the are still retained and MUST be implemented according to the
specification. In the case of CSeq, it is quite useful for matching specification. In the case of CSeq, it is quite useful for matching
responses to requests if the requests are pipelined (see Section 12). responses to requests if the requests are pipelined (see Section 12).
It is also useful in proxies for keeping track of the different It is also useful in proxies for keeping track of the different
requests when aggregating several client requests on a single TCP requests when aggregating several client requests on a single TCP
connection. connection.
10.1. Reliability and Acknowledgements 10.1. Reliability and Acknowledgements
skipping to change at page 51, line 19 skipping to change at page 54, line 28
10.2. Using Connections 10.2. Using Connections
A TCP transport can be used for both persistent connections (for A TCP transport can be used for both persistent connections (for
several message exchanges) and transient connections (for a single several message exchanges) and transient connections (for a single
message exchange). Implementations of this specification MUST message exchange). Implementations of this specification MUST
support RTSP over TCP. The scheme of the RTSP URI (Section 4.2) support RTSP over TCP. The scheme of the RTSP URI (Section 4.2)
indicates the default port that the server will listen on if the port indicates the default port that the server will listen on if the port
is not explicitly given. is not explicitly given.
In addition to the registered default ports, i.e. 554 (rtsp) and 322 In addition to the registered default ports, i.e., 554 (rtsp) and 322
(rtsps), there are an alternative port 8554 registered. This port (rtsps), there is an alternative port 8554 registered. This port may
may provide some benefits from non-registered ports if a RTSP server provide some benefits from non-registered ports if a RTSP server is
is unable to use the default ports. The benefits may include pre- unable to use the default ports. The benefits may include pre-
configured security policies as well as classifiers in network configured security policies as well as classifiers in network
monitoring tools. monitoring tools.
A RTSP client opening a TCP connection for accessing a particular
resource as identified by a URI uses the IP address and port derived
from the host and port parts of the URI. The IP address is either
the explicit address provided in the URI or any of the addresses
provided when performing A and AAAA record DNS lookups of the host
name in the URI.
A server MUST handle both persistent and transient connections. A server MUST handle both persistent and transient connections.
Transient connections facilitate mechanisms for fault tolerance. Transient connections facilitate mechanisms for fault tolerance.
They also allow for application layer mobility. A server and They also allow for application layer mobility. A server and
client pair that support transient connections can survive the client pair that support transient connections can survive the
loss of a TCP connection; e.g., due to a NAT timeout. When the loss of a TCP connection; e.g., due to a NAT timeout. When the
client has discovered that the TCP connection has been lost, it client has discovered that the TCP connection has been lost, it
can set up a new one when there is need to communicate again. can set up a new one when there is need to communicate again.
A persistent connection is RECOMMENDED to be used for all A persistent connection is RECOMMENDED to be used for all
transactions between the server and client, including messages for transactions between the server and client, including messages for
multiple RTSP sessions. However, a persistent connection MAY be multiple RTSP sessions. However, a persistent connection MAY be
closed after a few message exchanges. For example, a client may use closed after a few message exchanges. For example, a client may use
a persistent connection for the initial SETUP and PLAY message a persistent connection for the initial SETUP and PLAY message
exchanges in a session and then close the connection. Later, when exchanges in a session and then close the connection. Later, when
the client wishes to send a new request, such as a PAUSE for the the client wishes to send a new request, such as a PAUSE for the
session, a new connection would be opened. This connection may session, a new connection would be opened. This connection may
either be transient or persistent. either be transient or persistent.
An RTSP agent SHOULD NOT have more than one connection to the server An RTSP agent MAY use one connection to handle multiple RTSP sessions
at any given point. If a client or proxy handles multiple RTSP on the same server. The RTSP agent SHALL NOT use more than one
sessions on the same server, it SHOULD use only one connection for connection per RTSP session at any given point.
managing those sessions.
This saves connection resources on the server. It also reduces Using a single connection for multiple RTSP session saves
complexity by enabling the server to maintain less state about its connection resources on the server. Not using more than one
sessions and connections. connection at a time for a particular RTSP session avoids wasting
connection resources and allows the server to track only for the
latest in client to server used connection for each RTSP session
as being the currently valid server to client connection.
RTSP allows a server to send requests to a client. However, this can RTSP allows a server to send requests to a client. However, this can
be supported only if a client establishes a persistent connection be supported only if a client establishes a persistent connection
with the server. In cases where a persistent connection does not with the server. In cases where a persistent connection does not
exist between a server and its client, due to the lack of a signaling exist between a server and its client, due to the lack of a signaling
channel the server may be forced to silently discard RTSP messages, channel the server may be forced to silently discard RTSP messages,
and may even drop an RTSP session without notifying the client. An and may even drop an RTSP session without notifying the client. An
example of such a case is when the server desires to send a REDIRECT example of such a case is when the server desires to send a REDIRECT
request for an RTSP session to the client but is not able to do so request for an RTSP session to the client but is not able to do so
because it cannot reach the client. A server that attempts to send a because it cannot reach the client. A server that attempts to send a
request to a client that has no connection currently to the server request to a client that has no connection currently to the server
SHOULD discard the request directly, but it MAY queue it for later SHALL discard the request directly.
delivery. However, if the server queues the request it SHOULD when
adding additional requests to the queue ensure to remove older
requests that are now redundant.
Without a persistent connection between the client and the server, Without a persistent connection between the client and the server,
the media server has no reliable way of reaching the client. the media server has no reliable way of reaching the client.
Because the likely failure of server to client established Because the likely failure of server to client established
connections the server will not even attempt establishing any connections the server will not even attempt establishing any
connection. connection.
Queuing of server to client requests has been considered. However
a security issue exist in how one authorizes a client establishing
a new connection as being a legit receiver of request related to a
particular RTSP session without the client first issuing requests
related to the request. Thus, likely making any such requests
even more delayed and less useful.
The sending of client and server requests can be asynchronous events. The sending of client and server requests can be asynchronous events.
To avoid deadlock situations both client and server MUST be able to To avoid deadlock situations both client and server MUST be able to
send and receive requests simultaneously. As an RTSP response may be send and receive requests simultaneously. As an RTSP response may be
queued up for transmission, reception or processing behind the peer queued up for transmission, reception or processing behind the peer
RTSP agent's own requests, all RTSP agents are required to have a RTSP agent's own requests, all RTSP agents are required to have a
certain capability of handling outstanding messages. A potential certain capability of handling outstanding messages. A potential
issue is that outstanding requests may timeout despite them being issue is that outstanding requests may timeout despite them being
processed by the peer due to the response is caught in the queue processed by the peer due to the response being caught in the queue
behind a number of request that the RTSP agent is processing but that behind a number of requests that the RTSP agent is processing but
take some time to complete. To avoid this problem an RTSP agent is that take some time to complete. To avoid this problem an RTSP agent
recommended to buffer incoming messages locally so that any response is recommended to buffer incoming messages locally so that any
messages can be processed immediately upon reception. If responses response messages can be processed immediately upon reception. If
are separated from requests and directly forwarded for processing, responses are separated from requests and directly forwarded for
not only can the result be used immediately, the state associated processing, not only can the result be used immediately, the state
with that outstanding request can also be released. However, associated with that outstanding request can also be released.
buffering a number of requests on the receiving RTSP agent consumes However, buffering a number of requests on the receiving RTSP agent
resources and enables a resource exhaustion attack on the agent. consumes resources and enables a resource exhaustion attack on the
Therefore this buffer should be limited so that an unreasonable agent. Therefore this buffer should be limited so that an
number of requests or total message size is not allowed to consume unreasonable number of requests or total message size is not allowed
the receiving agent's resources. In most APIs, having the receiving to consume the receiving agent's resources. In most APIs, having the
agent stop reading from the TCP socket will result in TCP's window receiving agent stop reading from the TCP socket will result in TCP's
being clamped. Thus forcing the buffering onto the sending agent window being clamped. Thus forcing the buffering onto the sending
when the load is larger than expected. However, as both RTSP message agent when the load is larger than expected. However, as both RTSP
sizes and frequency may be changed in the future by protocol message sizes and frequency may be changed in the future by protocol
extensions, an agent should be careful against taking harsher extensions, an agent should be careful against taking harsher
measurements against a potential attack. When under attack an RTSP measurements against a potential attack. When under attack an RTSP
agent can close TCP connections and release state associated with agent can close TCP connections and release state associated with
that TCP connection. that TCP connection.
To provide some guidance on what is reasonable the following To provide some guidance on what is reasonable the following
guidelines are given. It is RECOMMENDED that: guidelines are given. It is RECOMMENDED that:
o an RTSP agent should not have more than 10 outstanding requests o an RTSP agent should not have more than 10 outstanding requests
per RTSP session; per RTSP session;
o an RTSP agent should not have more than 10 outstanding requests o an RTSP agent should not have more than 10 outstanding requests
that are not related to an RTSP session or that are requesting to that are not related to an RTSP session or that are requesting to
create an RTSP session. create an RTSP session.
In light of the above, it is RECOMMENDED that clients use persistent In light of the above, it is RECOMMENDED that clients use persistent
connections whenever possible. A client that supports persistent connections whenever possible. A client that supports persistent
connections MAY "pipeline" its requests (see Section 12). connections MAY "pipeline" its requests (see Section 12).
RTSP Agents can send requests to multiple different destinations,
either servers or client contexts over the same connection to a
proxy. Then the proxy forks the message to the different
destinations over proxy to agent connections. In these cases when
multiple requests are outstanding the requesting agent MUST be ready
to receive the responses out of order compared to the order they
where sent on the connection. The order between multiple messages
for each destination will be maintained, however, the order between
response from different destinations can be different.
The reason for this is to avoid a head of line blocking. In a
sequence of request an early outstanding request may take time to
be processed at one destination. Simultaneously a responses from
any other destinations, that was later in the sequence of requests
may have arrived at the proxy. Thus allowing out-of-order
responses avoid forcing the proxy to buffer this response and
instead deliver it as soon as possible. Note, this will not
affect the order they where processed at request destination.
This scenario can occur in two cases involving proxies. The first is
a client issuing requests for sessions on different servers using a
common client to proxy connection. The second is for server to
client requests, like REDIRECT being sent by the server over a common
transport connection the proxy created for its different connecting
clients.
10.3. Closing Connections 10.3. Closing Connections
The client MAY close a connection at any point when no outstanding The client MAY close a connection at any point when no outstanding
request/response transactions exist for any RTSP session being request/response transactions exist for any RTSP session being
managed through the connection. The server, however, SHOULD NOT managed through the connection. The server, however, SHOULD NOT
close a connection until all RTSP sessions being managed through the close a connection until all RTSP sessions being managed through the
connection have been timed out (Section 18.47). A server SHOULD NOT connection have been timed out (Section 18.49). A server SHOULD NOT
close a connection immediately after responding to a session-level close a connection immediately after responding to a session-level
TEARDOWN request for the last RTSP session being controlled through TEARDOWN request for the last RTSP session being controlled through
the connection. Instead, it should wait for a reasonable amount of the connection. Instead, the server should wait for a reasonable
time for the client to receive the TEARDOWN response, take amount of time for the client to receive and act upon the TEARDOWN
appropriate action, and initiate the connection closing. The server response, and initiate the connection closing. The server SHOULD
SHOULD wait at least 10 seconds after sending the TEARDOWN response wait at least 10 seconds after sending the TEARDOWN response before
before closing the connection. closing the connection.
This is to ensure that the client has time to issue a SETUP for a This is to ensure that the client has time to issue a SETUP for a
new session on the existing connection after having torn the last new session on the existing connection after having torn the last
one down. 10 seconds should give the client ample opportunity to one down. 10 seconds should give the client ample opportunity to
get its message to the server. get its message to the server.
A server SHOULD NOT close the connection directly as a result of A server SHOULD NOT close the connection directly as a result of
responding to a request with an error code. responding to a request with an error code.
Certain error responses such as "460 Only Aggregate Operation Certain error responses such as "460 Only Aggregate Operation
Allowed" (Section 17.4.25) are used for negotiating capabilities Allowed" (Section 17.4.24) are used for negotiating capabilities
of a server with respect to content or other factors. In such of a server with respect to content or other factors. In such
cases, it is inefficient for the server to close a connection on cases, it is inefficient for the server to close a connection on
an error response. Also, such behavior would prevent an error response. Also, such behavior would prevent
implementation of advanced/special types of requests or result in implementation of advanced/special types of requests or result in
extra overhead for the client when testing for new features. On extra overhead for the client when testing for new features. On
the flip side, keeping connections open after sending an error the other hand, keeping connections open after sending an error
response poses a Denial of Service security risk (Section 21). response poses a Denial of Service security risk (Section 21).
The server MAY close a connection if it receives an incomplete The server MAY close a connection if it receives an incomplete
message and if the message is not completed within a reasonable message and if the message is not completed within a reasonable
amount of time. It is RECOMMENDED that the server waits at least 10 amount of time. It is RECOMMENDED that the server waits at least 10
seconds for the completion of a message or for the next part of the seconds for the completion of a message or for the next part of the
message to arrive (which is an indication that the transport and the message to arrive (which is an indication that the transport and the
client are still alive). Servers believing they are under attack or client are still alive). Servers believing they are under attack or
otherwise starved for resources during that event MAY consider using otherwise starved for resources during that event MAY consider using
a shorter timeout. a shorter timeout.
skipping to change at page 54, line 49 skipping to change at page 58, line 45
possible. It SHOULD continue sending a 100 response every 5 seconds possible. It SHOULD continue sending a 100 response every 5 seconds
thereafter until it is ready to send the final response to the thereafter until it is ready to send the final response to the
requester. After sending a 100 response, the receiver MUST send a requester. After sending a 100 response, the receiver MUST send a
final response indicating the success or failure of the request. final response indicating the success or failure of the request.
A requester SHOULD wait at least 10 seconds for a response before A requester SHOULD wait at least 10 seconds for a response before
concluding that the responder will not be responding to its request. concluding that the responder will not be responding to its request.
After receiving a 100 response, the requester SHOULD continue waiting After receiving a 100 response, the requester SHOULD continue waiting
for further responses. If more than 10 seconds elapses without for further responses. If more than 10 seconds elapses without
receiving any response, the requester MAY assume that the responder receiving any response, the requester MAY assume that the responder
is unresponsive and abort the connection. is unresponsive and abort the connection by closing the TCP
connection.
Note: In cases multiple RTSP sessions share the same transport
connection, abandoning a request closing the connection may have
significant impact on those other sessions. First of all, other
RTSP requests may have become queued up due to the request taking
long time. Secondly also those sessions loose the possibility to
receive server to client requests. To mitigate that situation the
RTSP agent should establish a new connection and send any queued
up and non-responded requests on this new connection. Secondly,
to ensure that the RTSP server knows which connection that is
valid for a particular RTSP session, the RTSP agent should send a
keep-alive request, if no other request will be sent immediately
for that RTSP session, for each RTSP session on the old
connection. The keep-alive request will normally be a
GET_PARAMETER with a session header to inform the server that this
agent cares about this RTSP session.
A requester SHOULD wait longer than 10 seconds for a response if it A requester SHOULD wait longer than 10 seconds for a response if it
is experiencing significant transport delays on its connection to the is experiencing significant transport delays on its connection to the
responder. The requester is capable of determining the RTT of the responder. The requester is capable of determining the round trip
request/response cycle using the Timestamp header (Section 18.51) in time (RTT) of the request/response cycle using the Timestamp header
any RTSP request. (Section 18.53) in any RTSP request.
10 seconds was chosen for the following reasons. It gives TCP 10 seconds was chosen for the following reasons. It gives TCP
time to perform a couple of retransmissions, even if operating on time to perform a couple of retransmissions, even if operating on
default values. It is short enough that users may not abandon the default values. It is short enough that users may not abandon the
process themselves. However, it should be noted that 10 seconds process themselves. However, it should be noted that 10 seconds
can be aggressive on certain type of networks. The 5 seconds can be aggressive on certain type of networks. The 5 seconds
value for 1xx messages is half the timeout giving a reasonable value for 1xx messages is half the timeout giving a reasonable
chance of successful delivery before timeout happens on the chance of successful delivery before timeout happens on the
requester side. requester side.
10.5. Showing Liveness 10.5. Showing Liveness
The mechanisms for showing liveness of the client is, any RTSP The mechanisms for showing liveness of the client is, any RTSP
request with a Session header, if RTP & RTCP is used an RTCP message, request with a Session header, if RTP & RTCP is used an RTCP message,
or through any other used media protocol capable of indicating or through any other used media protocol capable of indicating
liveness of the RTSP client. It is RECOMMENDED that a client does liveness of the RTSP client. It is RECOMMENDED that a client does
not wait to the last second of the timeout before trying to send a not wait to the last second of the timeout before trying to send a
liveness message. The RTSP message may be lost or when using liveness message. The RTSP message may be lost or when using
reliable protocols, such as TCP, the message may take some time to reliable protocols, such as TCP, the message may take some time to
arrive safely at the receiver. To show liveness between RTSP request arrive safely at the receiver. To show liveness between RTSP
issued to accomplish other things, the following mechanisms can be requests being issued to accomplish other things, the following
used, in descending order of preference: mechanisms can be used, in descending order of preference:
RTCP: If RTP is used for media transport RTCP SHOULD be used. If RTCP: If RTP is used for media transport RTCP SHOULD be used. If
RTCP is used to report transport statistics, it MUST also work RTCP is used to report transport statistics, it will
as keep alive. The server can determine the client by network necessarily also function as a keep-alive. The server can
address and port together with the fact that the client is determine the client by network address and port together with
reporting on the servers SSRC(s). A downside of using RTCP is the fact that the client is reporting on the server's RTP
that it only gives statistical guarantees to reach the server. sender sources (SSRCs). A downside of using RTCP is that it
only gives statistical guarantees of reaching the server.
However, the probability of a false client timeout is so low However, the probability of a false client timeout is so low
that it can be ignored in most cases. For example, assume a that it can be ignored in most cases. For example, assume a
session with 60 seconds timeout and enough bitrate assigned to session with 60 seconds timeout and enough bitrate assigned to
RTCP messages to send a message from client to server on RTCP messages to send a message from client to server on
average every 5 seconds. That client has, for a network with 5 average every 5 seconds. That client has, for a network with
% packet loss, the probability to fail showing liveness sign in 5% packet loss, a probability of failing to confirm liveness
that session within the timeout interval of 2.4*E-16. Sessions within the timeout interval for that session of 2.4*E-16.
with shorter timeouts, or much higher packet loss, or small Sessions with shorter timeouts, or much higher packet loss, or
RTCP bandwidths SHOULD also use any of the mechanisms below. small RTCP bandwidths SHOULD also implement one or more of the
mechanisms below.
SET_PARAMETER: When using SET_PARAMETER for keep alive, a body SET_PARAMETER: When using SET_PARAMETER for keep-alive, a body
SHOULD NOT be included. This method is the RECOMMENDED RTSP SHOULD NOT be included. This method is the RECOMMENDED RTSP
method to use for a request intended only to perform keep- method to use for a request intended only to perform keep-
alive. alive. Support of SET_PARAMETER is mandatory for RTSP Servers
to ensure clients can use this method.
GET_PARAMETER: When using GET_PARAMETER for keep alive, no body GET_PARAMETER: When using GET_PARAMETER for keep-alive, no body
SHOULD be included. SHOULD be included. Dependent on implementation support in
server.
OPTIONS: This method is also usable, but it causes the server to OPTIONS: This method is also usable, but it causes the server to
perform more unnecessary processing and results in bigger perform more unnecessary processing and results in bigger
responses than necessary for the task. The reason is that the responses than necessary for the task. The reason is that the
server needs to determine the capabilities associated with the server needs to determine the capabilities associated with the
media resource to correctly populate the Public and Allow media resource to correctly populate the Public and Allow
headers. headers.
The timeout parameter MAY be included in a SETUP response, and MUST The timeout parameter of the Session header (Section 18.49) MAY be
NOT be included in requests. The server uses it to indicate to the included in a SETUP response, and MUST NOT be included in requests.
client how long the server is prepared to wait between RTSP commands The server uses it to indicate to the client how long the server is
or other signs of life before closing the session due to lack of prepared to wait between RTSP commands or other signs of life before
activity (see Appendix B). The timeout is measured in seconds, with closing the session due to lack of activity (see Appendix B). The
a default of 60 seconds. The length of the session timeout MUST NOT timeout is measured in seconds, with a default of 60 seconds. The
be changed in an established session. length of the session timeout MUST NOT be changed in an established
session.
10.6. Use of IPv6 10.6. Use of IPv6
Explicit IPv6 [RFC2460] support was not present in RTSP 1.0 (RFC Explicit IPv6 [RFC2460] support was not present in RTSP 1.0 (RFC
2326). RTSP 2.0 has been updated for explicit IPv6 support. 2326). RTSP 2.0 has been updated for explicit IPv6 support.
Implementations of RTSP 2.0 MUST understand literal IPv6 addresses in Implementations of RTSP 2.0 MUST understand literal IPv6 addresses in
URIs and headers. URIs and RTSP headers. Although the general URI format envisages
potential future new versions of the literal IP address, usage of any
such new version would require other modifications to the RTSP
specification (e.g. address fields in the Transport header
(Section 18.54)).
10.7. Overload Control 10.7. Overload Control
Overload in RTSP can occur when servers and proxies have insufficient Overload in RTSP can occur when servers and proxies have insufficient
resources to complete the processing of a request. An improper resources to complete the processing of a request. An improper
handling of such an overload situation at proxies and servers can handling of such an overload situation at proxies and servers can
impact the operation of the RTSP deployment, and probably worsen the impact the operation of the RTSP deployment, and probably worsen the
situation. RTSP defines the 503 (Service Unavailable) response situation. RTSP defines the 503 (Service Unavailable) response
(Section 17.5.4) to let servers and proxies notify requesting proxies (Section 17.5.4) to let servers and proxies notify requesting proxies
and RTSP clients about an overload situation. In conjunction with and RTSP clients about an overload situation. In conjunction with
the Retry-After header (Section 18.42) the server or proxy can the Retry-After header (Section 18.44) the server or proxy can
indicate the time after the requesting entity can send another indicate the time after the requesting entity can send another
request to the proxy or server. request to the proxy or server.
Simply implementing and using the 503 (Service Unavailable) is not There are two scopes of such 503 answers, one for established RTSP
sufficient for properly handling overload situations. For instance, sessions, where the request resulting in the 503 response as well as
a simplistic approach would be to send the 503 response with a Retry- the response carries a Session header identifying the session which
After header set to a fixed value. However, this can cause the is suffering overload. This response only applies to this particular
situation where multiple RTSP clients again send requests to a proxy session. The other scope is the general RTSP server as identified by
or server at roughly the same time which may again cause an overload the host in the request URL. Such a 503 answer with any Retyr-After
situation, or if the "old" overload situation is not yet solved, header applies to all non-session specific requests to that server,
i.e., the length indicated in the Retry-After header was too short. including SETUP request intended to create a new RTSP session.
Another scope for overload situation exists, which is the RTSP proxy.
To enable an RTSP proxy to signal that it is overloaded, or otherwise
unavailable and can't handle the request, a 553 response code has
been defined with the meaning "Proxy Unavailable". Also for proxies
there is a separation in response scopes between requests associated
with existing RTSP sessions, and requests to create new sessions or
general proxy requests.
Simply implementing and using the 503 (Service Unavailable) and 553
(Proxy Unavailable) is not sufficient for properly handling overload
situations. For instance, a simplistic approach would be to send the
503 response with a Retry-After header set to a fixed value.
However, this can cause the situation where multiple RTSP clients
again send requests to a proxy or server at roughly the same time
which may again cause an overload situation, or if the "old" overload
situation is not yet solved, i.e., the length indicated in the Retry-
After header was too short.
An RTSP server or proxy in an overload situation must select the An RTSP server or proxy in an overload situation must select the
value of the Retry-After header carefully and in dependency of its value of the Retry-After header carefully and bearing in mind its
current load situation. It is RECOMMENDED to increase the length current load situation. It is REQUIRED to increase the timeout
proportional with the current load of the server, i.e., an increasing period in proportion to the current load on the server, i.e., an
workload should result in an increased length of the indicated increasing workload should result in an increased length of the
unavailability. It is RECOMMENDED to not send the same value in the indicated unavailability. It is REQUIRED to not send the same value
Retry-After header to all requesting proxies and clients, but to add in the Retry-After header to all requesting proxies and clients, but
a variation to the mean value of the Retry-After header. to add a variation to the mean value of the Retry-After header.
Another issue are load balancing RTSP proxies, i.e., where an RTSP A more complex case may arise when a load balancing RTSP proxy is in
proxy is used to select amongst a set of RTSP servers to handle the use, i.e., where an RTSP proxy is used to select amongst a set of
requests, or when multiple server addresses are available for a given RTSP servers to handle the requests, or when multiple server
server name. The proxy or client may receive a 503 (Service addresses are available for a given server name. The proxy or client
Unavailable) from one of its RTSP servers or a TCP timeout (if the may receive a 503 (Service Unavailable) or 553 (Proxy Unavailable)
from one of its RTSP servers or proxies, or a TCP timeout (if the
server is even unable to handle the request message). The proxy or server is even unable to handle the request message). The proxy or
client simply retries the other addresses, but may also receive a 503 client simply retries the other addresses or configured proxies, but
(Service Unavailable) response or TCP timeouts from those addresses. may also receive a 503 (Service Unavailable) or 553 (Proxy
In such a situation, where none of the RTSP servers/addresses can Unavailable) response or TCP timeouts from those addresses. In such
a situation, where none of the RTSP servers/proxies/addresses can
handle the request, the RTSP agent has to wait before it can send any handle the request, the RTSP agent has to wait before it can send any
new requests to the RTSP server. Any additional request to a new requests to the RTSP server. Any additional request to a
specific address MUST be delayed according to the Retry-After headers specific address MUST be delayed according to the Retry-After headers
received. For addresses where no response was received or TCP received. For addresses where no response was received or TCP
timeout occurred, an initial wait timer SHOULD be set to 5 seconds. timeout occurred, an initial wait timer SHOULD be set to 5 seconds.
That timer MUST be doubled for each additional failure to connect or That timer MUST be doubled for each additional failure to connect or
receive response. It is RECOMMENDED to not set the same value in the receive response until the value exceeds 30 minutes when the timers
timer, but to add a variation to the mean value. mean value may be set to 30 minutes. It is REQUIRED to not set the
same value in the timer for each scheduling, but instead to add a
variation to the mean value, resulting in picking a random value
within the range of 0.5 to 1.5 of the mean value.
11. Capability Handling 11. Capability Handling
This section describes the available capability handling mechanism This section describes the available capability handling mechanism
which allows RTSP to be extended. Extensions to this version of the which allows RTSP to be extended. Extensions to this version of the
protocol are basically done in two ways. First, new headers can be protocol are basically done in two ways. First, new headers can be
added. Secondly, new methods can be added. The capability handling added. Secondly, new methods can be added. The capability handling
mechanism is designed to handle both cases. mechanism is designed to handle both cases.
When a method is added, the involved parties can use the OPTIONS When a method is added, the involved parties can use the OPTIONS
skipping to change at page 58, line 28 skipping to change at page 63, line 28
contain a Public header which declares all methods supported for the contain a Public header which declares all methods supported for the
indicated resource. indicated resource.
It is not necessary to use OPTIONS to discover support of a method, It is not necessary to use OPTIONS to discover support of a method,
as the client could simply try the method. If the receiver of the as the client could simply try the method. If the receiver of the
request does not support the method it will respond with an error request does not support the method it will respond with an error
code indicating the method is either not implemented (501) or does code indicating the method is either not implemented (501) or does
not apply for the resource (405). The choice between the two not apply for the resource (405). The choice between the two
discovery methods depends on the requirements of the service. discovery methods depends on the requirements of the service.
Feature-Tags are defined to handle functionality additions that are Feature-tags are defined to handle functionality additions that are
not new methods. Each feature-tag represents a certain block of not new methods. Each feature-tag represents a certain block of
functionality. The amount of functionality that a feature-tag functionality. The amount of functionality that a feature-tag
represents can vary significantly. A feature-tag can for example represents can vary significantly. A feature-tag can for example
represent the functionality a single RTSP header provides. Another represent the functionality a single RTSP header provides. Another
feature-tag can represent much more functionality, such as the feature-tag can represent much more functionality, such as the
"play.basic" feature-tag which represents the minimal media delivery "play.basic" feature-tag (Section 11.1) which represents the minimal
for playback implementation. media delivery for playback implementation.
Feature-tags are used to determine whether the client, server or Feature-tags are used to determine whether the client, server or
proxy supports the functionality that is necessary to achieve the proxy supports the functionality that is necessary to achieve the
desired service. To determine support of a feature-tag, several desired service. To determine support of a feature-tag, several
different headers can be used, each explained below: different headers can be used, each explained below:
Supported: This header is used to determine the complete set of Supported: This header is used to determine the complete set of
functionality that both client and server have. The intended functionality that both client and server have in general and
usage is to determine before one needs to use a functionality is not dependent on specific resource. The intended usage is
that it is supported. It can be used in any method, but to determine before one needs to use a functionality that it is
OPTIONS is the most suitable one as it at the same time supported. It can be used in any method, but OPTIONS is the
determines all methods that are implemented. When sending a most suitable one as it at the same time determines all methods
request the requester declares all its capabilities by that are implemented. When sending a request the requester
including all supported feature-tags. This results in the declares all its capabilities by including all supported
receiver is learning the requester's feature support. The feature-tags. This results in the receiver is learning the
receiver then includes its set of features in the response. requester's feature support. The receiver then includes its
set of features in the response.
Proxy-Supported: This header is used similarly to the Supported Proxy-Supported: This header is used similarly to the Supported
header, but instead of giving the supported functionality of header, but instead of giving the supported functionality of
the client or server it provides both the requester and the the client or server it provides both the requester and the
responder a view of what functionality the proxy chain between responder a view of the common functionality supported in
the two supports. Proxies are required to add this header general by all members of the proxy chain between the two
whenever the Supported header is present, but proxies may also supports and not dependent on the resource. Proxies are
add it independently of the requester. required to add this header whenever the Supported header is
present, but proxies may also add it independently of the
requester.
Require: This header can be included in any request where the end- Require: This header can be included in any request where the end-
point, i.e. the client or server, is required to understand the point, i.e., the client or server, is required to understand
feature to correctly perform the request. This can, for the feature to correctly perform the request. This can, for
example, be a SETUP request where the server is required to example, be a SETUP request where the server is required to
understand a certain parameter to be able to set up the media understand a certain parameter to be able to set up the media
delivery correctly. Ignoring this parameter would not have the delivery correctly. Ignoring this parameter would not have the
desired effect and is not acceptable. Therefore the end-point desired effect and is not acceptable. Therefore the end-point
receiving a request containing a Require MUST negatively receiving a request containing a Require MUST negatively
acknowledge any feature that it does not understand and not acknowledge any feature that it does not understand and not
perform the request. The response in cases where features are perform the request. The response in cases where features are
not supported are 551 (Option Not Supported). Also the not supported are 551 (Option Not Supported). Also the
features that are not supported are given in the Unsupported features that are not supported are given in the Unsupported
header in the response. header in the response.
skipping to change at page 60, line 5 skipping to change at page 64, line 42
end-points need to be included in both the Require and Proxy- end-points need to be included in both the Require and Proxy-
Require header. Require header.
Unsupported: This header is used in a 551 error response, to Unsupported: This header is used in a 551 error response, to
indicate which features were not supported. Such a response is indicate which features were not supported. Such a response is
only the result of the usage of the Require and/or Proxy- only the result of the usage of the Require and/or Proxy-
Require header where one or more features where not supported. Require header where one or more features 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.
11.1. Feature Tag: play.basic
The play.basic feature tag represents an RTSP implementation
according to all normative RTSP protocol features specified in this
specification. This specification is both a RTSP core specification
as well intended to enable setup and control of playback of media.
Thus following all normative parts in the main sections (the ones
with numbers), not the appendices (starting with letters), unless
explicitly specified in a main section for being a required appendix.
Note: This feature tag does not mandate any media delivery
protocol, such as RTP.
In RTSP 1.0 there was a minimal implementation section. However,
that was not consistent with the rest of the specification. So
rather than making an attempt to explicitly enumerate the features
for play.basic this specification have to be read in completeness
and the necessary features normatively defined as being required
are included.
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 agent to have more than response protocols by allowing the requesting agent to have more than
one request outstanding and send them over the same persistent one request outstanding and send them over the same persistent
connection. For RTSP, where the relative order of requests will connection. For RTSP, where the relative order of requests will
matter, it is important to maintain the order of the requests. matter, it is important to maintain the order of the requests.
Because of this, the responding agent MUST process the incoming Because of this, the responding agent MUST process the incoming
requests in their sending order. The sending order can be determined requests in their sending order. The sending order can be determined
by the CSeq header and its sequence number. For TCP the delivery by the CSeq header and its sequence number. For TCP the delivery
order will be the same between two agents, as the sending order. The order will be the same between two agents, as the sending order. The
processing of the request MUST also have been finished before processing of the request MUST also have been finished before
processing the next request from the same agent. The responses MUST processing the next request from the same agent. The responses MUST
be sent in the order the requests were processed. be sent in the order the requests were 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 involved in setting up
media delivery to be pipelined after each other. This is and initiating media delivery to be pipelined after each other. This
accomplished by the utilization of the Pipelined-Requests header (see is accomplished by the utilization of the Pipelined-Requests header
Section 18.32). This header allows a client to request that two or (see Section 18.33). This header allows a client to request that two
more requests are processed in the same RTSP session context which or more requests are processed in the same RTSP session context which
the first request creates. In other words, a client can request that the first request creates. In other words, a client can request that
two or more media streams are set-up and then played without needing two or more media streams are set-up and then played without needing
to wait for a single response. This speeds up the initial startup to wait for a single response. This speeds up the initial startup
time for an RTSP session with at least one RTT. time for an RTSP session by at least one RTT.
If a pipelined request builds on the successful completion of one or If a pipelined request builds on the successful completion of one or
more prior requests the requester must verify that all requests were more prior requests the requester must verify that all requests were
executed as expected. A common example will be two SETUP requests executed as expected. A common example will be two SETUP requests
and a PLAY request. In case one of the SETUP fails unexpectedly, the and a PLAY request. In case one of the SETUP fails unexpectedly, the
PLAY request can still be successfully executed. However, the PLAY request can still be successfully executed. However, the
resulting presentation will not be as expected by the requesting resulting presentation will not be as expected by the requesting
client, as only a single media instead of two will be played. In client, as only a single media instead of two will be played. In
this case the client can send a PAUSE request, correct the failing this case the client can send a PAUSE request, correct the failing
SETUP request and then request it to be played. SETUP request and then request it to be played.
skipping to change at page 61, line 47 skipping to change at page 67, line 47
| SET_PARAMETER | C -> S | P,S | required | optional | | SET_PARAMETER | C -> S | P,S | required | optional |
| | | | | | | | | | | |
| | S -> C | P,S | optional | optional | | | S -> C | P,S | optional | optional |
| | | | | | | | | | | |
| TEARDOWN | C -> S | P,S | required | required | | TEARDOWN | C -> S | P,S | required | required |
| | | | | | | | | | | |
| | S -> C | P | required | required | | | S -> C | P | 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. (P: presentation, S: stream) they operate on. Further it indicates if
a server or a client implementation are required (mandatory),
recommended or if it is optional to implement the method.
Note on Table 7: GET_PARAMETER is optional. For example, a fully Note on Table 7: GET_PARAMETER is optional. For example, a fully
functional server can be built to deliver media without any functional server can be built to deliver media without any
parameters. SET_PARAMETER is required, however, due to its usage parameters. However, SET_PARAMETER is required, i.e. mandatory to
for keep-alive. PAUSE is now required because it is the only way implement for the server, this is due to its usage for keep-alive.
of leaving the Play state without terminating the whole session. PAUSE is required because it is the only way of leaving the 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 whose main function is to log or audit and not modify An RTSP proxy whose 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 that the proxy still needs to perform the unknown methods. Note that the proxy still needs to perform the
minimal required processing, like adding the Via header. minimal required processing, like adding the Via header.
13.1. OPTIONS 13.1. OPTIONS
The semantics of the RTSP OPTIONS method is similar to that of the The semantics of the RTSP OPTIONS method is similar to that of the
HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is
bi-directional, in that a client can request it to a server and vice bi-directional, in that a client can send the request to a server and
versa. A client MUST implement the capability to send an OPTIONS vice versa. A client MUST implement the capability to send an
request and a server or a proxy MUST implement the capability to OPTIONS request and a server or a proxy MUST implement the capability
respond to an OPTIONS request. The client, server or proxy MAY also to respond to an OPTIONS request. In addition to this "MUST
implement the converse of their required capability, but still retain implement" functionality, clients, servers and proxies MAY provide
the prior mentioned about what is a "MUST implement". support both for sending OPTIONS requests and generating responses to
the requests.
An OPTIONS request may be issued at any time. Such a request does An OPTIONS request may be issued at any time. Such a request does
not modify the session state. However, it may prolong the session not modify the session state. However, it may prolong the session
lifespan (see below). The URI in an OPTIONS request determines the lifespan (see below). The URI in an OPTIONS request determines the
scope of the request and the corresponding response. If the Request- scope of the request and the corresponding response. If the Request-
URI refers to a specific media resource on a given host, the scope is URI refers to a specific media resource on a given host, the scope is
limited to the set of methods supported for that media resource by limited to the set of methods supported for that media resource by
the indicated RTSP agent. A Request-URI with only the host address the indicated RTSP agent. A Request-URI with only the host address
limits the scope to the specified RTSP agent's general capabilities limits the scope to the specified RTSP agent's general capabilities
without regard to any specific media. If the Request-URI is an without regard to any specific media. If the Request-URI is an
asterisk ("*"), the scope is limited to the general capabilities of asterisk ("*"), the scope is limited to the general capabilities of
the next hop (i.e. the RTSP agent in direct communication with the the next hop (i.e., the RTSP agent in direct communication with the
request sender). request sender).
Regardless of scope of the request, the Public header MUST always be Regardless of the scope of the request, the Public header MUST always
included in the OPTIONS response listing the methods that are be included in the OPTIONS response listing the methods that are
supported by the responding RTSP agent. In addition, if the scope of supported by the responding RTSP agent. In addition, if the scope of
the request is limited to a media resource, the Allow header MUST be the request is limited to a media resource, the Allow header MUST be
included in the response to enumerate the set of methods that are included in the response to enumerate the set of methods that are
allowed for that resource unless the set of methods completely allowed for that resource unless the set of methods completely
matches the set in the Public header. If the given resource is not matches the set in the Public header. If the given resource is not
available, the RTSP agent SHOULD return an appropriate response code available, the RTSP agent SHOULD return an appropriate response code
such as 3rr or 4xx. The Supported header MAY be included in the such as 3rr or 4xx. The Supported header MAY be included in the
request to query the set of features that are supported by the request to query the set of features that are supported by the
responding RTSP agent. responding RTSP agent.
The OPTIONS method can be used to keep an RTSP session alive. The OPTIONS method can be used to keep an RTSP session alive.
However, this is not the preferred way of session keep-alive However, this is not the preferred way of session keep-alive
signaling, see Section 18.47. An OPTIONS request intended for signaling, see Section 18.49. An OPTIONS request intended for
keeping alive an RTSP session MUST include the Session header with keeping alive an RTSP session MUST include the Session header with
the associated session ID. Such a request SHOULD also use the media the associated session identifier. Such a request SHOULD also use
or the aggregated control URI as the Request-URI. the media or the aggregated control URI as the Request-URI.
Example: Example:
C->S: OPTIONS rtsp://server.example.com RTSP/2.0 C->S: OPTIONS rtsp://server.example.com RTSP/2.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Proxy-Require: gzipped-messages Proxy-Require: gzipped-messages
Supported: play.basic Supported: play.basic
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS
Supported: play.basic, setup.rtp.rtcp.mux, play.scale Supported: play.basic, setup.rtp.rtcp.mux, play.scale
Server: PhonyServer/1.1 Server: PhonyServer/1.1
Note that some of the feature-tags in Supported and Proxy-Require are Note that some of the feature-tags in Supported and Proxy-Require are
fictional features. fictitious features.
13.2. DESCRIBE 13.2. DESCRIBE
The DESCRIBE method is used to retrieve the description of a The DESCRIBE method is used to retrieve the description of a
presentation or media object from a server. The Request-URI of the presentation or media object from a server. The Request-URI of the
DESCRIBE request identifies the media resource of interest. The DESCRIBE request identifies the media resource of interest. The
client MAY include the Accept header in the request to list the client MAY include the Accept header in the request to list the
description formats that it understands. The server MUST respond description formats that it understands. The server MUST respond
with a description of the requested resource and return the with a description of the requested resource and return the
description in the message body of the response, if the DESCRIBE description in the message body of the response, if the DESCRIBE
skipping to change at page 64, line 27 skipping to change at page 70, line 27
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 312 CSeq: 312
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.1 Server: PhonyServer/1.1
Content-Base: rtsp://server.example.com/fizzle/foo/ Content-Base: rtsp://server.example.com/fizzle/foo/
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 358 Content-Length: 358
v=0 v=0
o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46 o=MNobody 2890844526 2890842807 IN IP4 192.0.2.46
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
u=http://www.example.com/lectures/sdp.ps u=http://www.example.com/lectures/sdp.ps
e=seminar@example.com (Seminar Management) e=seminar@example.com (Seminar Management)
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
a=control:* a=control:*
t=2873397496 2873404696 t=2873397496 2873404696
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
a=control:audio a=control:audio
m=video 2232 RTP/AVP 31 m=video 2232 RTP/AVP 31
skipping to change at page 65, line 16 skipping to change at page 71, line 16
session establishment conditional on being valid. session establishment conditional on being valid.
It is RECOMMENDED that minimal servers support the DESCRIBE method, It is RECOMMENDED that minimal servers support the DESCRIBE method,
and highly recommended that minimal clients support the ability to and highly recommended that minimal clients support the ability to
act as "helper applications" that accept a media initialization file act as "helper applications" that accept a media initialization file
from a user interface, and/or other means that are appropriate to the from a user interface, and/or other means that are appropriate to the
operating environment of the clients. operating environment of the clients.
13.3. SETUP 13.3. SETUP
Note: The states described in this section and the following are The below description uses the following states in a protocol state
described in detail in Appendix B. machine that are related to a specific session when that session has
been created. The state transitions are driven by protocol
interactions. For additional information about the state machine see
Appendix B.
Init: Initial state: no session exists.
Ready: Session is ready to start playing.
Play: Session is playing, i.e., sending media stream data in the
direction S->C.
The SETUP request for an URI specifies the transport mechanism to be The SETUP request for an URI specifies the transport mechanism to be
used for the streamed media. The SETUP method may be used in two used for the streamed media. The SETUP method may be used in two
different cases; Create an RTSP session and change the transport different cases; Create an RTSP session and change the transport
parameters of already set up media stream(s). SETUP can be used in parameters of already set up media stream(s). SETUP can be used in
all three states; Init, and Ready, for both purposes and in PLAY to all three states; Init, and Ready, for both purposes and in PLAY to
change the transport parameters. There is also a third possible change the transport parameters. There is also a third possible
usage for the SETUP method which is not specified in this memo: usage for the SETUP method which is not specified in this memo:
adding a media to a session. Using SETUP to add media to an existing adding a media to a session. Using SETUP to add media to an existing
session, when the session is in Play state, is unspecified. session, when the session is in Play state, is unspecified.
The Transport header, see Section 18.52, specifies the media The Transport header, see Section 18.54, specifies the media
transport parameters acceptable to the client for data transmission; transport parameters acceptable to the client for data transmission;
the response will contain the transport parameters selected by the the response will contain the transport parameters selected by the
server. This allows the client to enumerate in descending order of server. This allows the client to enumerate in descending order of
preference the transport mechanisms and parameters acceptable to it, preference the transport mechanisms and parameters acceptable to it,
while the server can select the most appropriate. It is expected while the server can select the most appropriate. It is expected
that the session description format used will enable the client to that the session description format used will enable the client to
select a limited number of possible configurations that are offered select a limited number of possible configurations that are offered
to the server to choose from. All transport related parameters SHALL to the server to choose from. All transport related parameters SHALL
be included in the Transport header; the use of other headers for be included in the Transport header; the use of other headers for
this purpose is NOT RECOMMENDED due to middleboxes, such as firewalls this purpose is NOT RECOMMENDED due to middleboxes, such as firewalls
skipping to change at page 66, line 19 skipping to change at page 72, line 30
request. If the client does not support a time format necessary for request. If the client does not support a time format necessary for
the presentation, the server MUST respond using 456 (Header Field Not the presentation, the server MUST respond using 456 (Header Field Not
Valid for Resource) and include the Accept-Ranges header with the Valid for Resource) and include the Accept-Ranges header with the
range unit formats supported for the resource. range unit formats supported for the resource.
In a SETUP response the server MUST include the Accept-Ranges header In a SETUP response the server MUST include the Accept-Ranges header
(see Section 18.5) to indicate which time formats are acceptable to (see Section 18.5) to indicate which time formats are acceptable to
use for this media resource. use for this media resource.
The SETUP response 200 OK MUST include the Media-Properties header The SETUP response 200 OK MUST include the Media-Properties header
(see Section 18.28 ). The combination of the parameters of the (see Section 18.29 ). The combination of the parameters of the
Media-Properties header indicates the nature of the content present Media-Properties header indicates the nature of the content present
in the session (see also Section 4.9). For example, a live stream in the session (see also Section 4.7). For example, a live stream
with time shifting is indicated by with time shifting is indicated by
o Random Access set to Random-Access, o Random Access set to Random-Access,
o Content Modifications set to Time Progressing, o Content Modifications set to Time Progressing,
o Retention set to Time-Duration (with specific recording window o Retention set to Time-Duration (with specific recording window
time value). time value).
The SETUP response 200 OK MUST include the Media-Range header (see The SETUP response 200 OK MUST include the Media-Range header (see
Section 18.29) if the media is Time-Progressing. Section 18.30) if the media is Time-Progressing.
A basic example for SETUP: A basic example for SETUP:
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302 CSeq: 302
Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589", Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589",
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, UTC Accept-Ranges: npt, clock
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 302 CSeq: 302
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.1 Server: PhonyServer/1.1
Session: 47112344;timeout=60 Session: 47112344;timeout=60
Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/ Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/
"192.0.2.53:4589"; src_addr="198.51.100.241:6256"/ "192.0.2.53:4589"; src_addr="198.51.100.241:6256"/
"198.51.100.241:6257"; ssrc=2A3F93ED "198.51.100.241:6257"; ssrc=2A3F93ED
Accept-Ranges: NPT Accept-Ranges: npt
Media-Properties: Random-Access=3.2, Time-Progressing, Media-Properties: Random-Access=3.2, Time-Progressing,
Time-Duration=3600.0 Time-Duration=3600.0
Media-Range: npt=0-2893.23 Media-Range: npt=0-2893.23
In the above example the client wants to create an RTSP session In the above example the client wants to create an RTSP session
containing the media resource "rtsp://example.com/foo/bar/baz.rm". containing the media resource "rtsp://example.com/foo/bar/baz.rm".
The transport parameters acceptable to the client are either RTP/AVP/ The transport parameters acceptable to the client are either RTP/AVP/
UDP (UDP per default) to be received on client port 4588 and 4589 at UDP (UDP per default) to be received on client port 4588 and 4589 at
the address the RTSP setup connection comes from or RTP/AVP the address the RTSP setup connection comes from or RTP/AVP
interleaved on the RTSP control channel. The server selects the RTP/ interleaved on the RTSP control channel. The server selects the RTP/
AVP/UDP transport and adds the address and ports it will send and AVP/UDP transport and adds the address and ports it will send and
receive RTP and RTCP from, and the RTP SSRC that will be used by the receive RTP and RTCP from, and the RTP SSRC that will be used by the
server. server.
The server MUST generate a session identifier in response to a The server MUST generate a session identifier in response to a
successful SETUP request, unless a SETUP request to a server includes successful SETUP request, unless a SETUP request to a server includes
a session identifier or a Pipelined-Requests header referencing an a session identifier or a Pipelined-Requests header referencing an
existing session context, in which case the server MUST bundle this existing session context, in which case the server MUST bundle this
SETUP request into the existing session (aggregated session) or SETUP request into the existing session (aggregated session) or
return error 459 (Aggregate Operation Not Allowed) (see return error 459 (Aggregate Operation Not Allowed) (see
Section 17.4.24). An Aggregate control URI MUST be used to control Section 17.4.23). An Aggregate control URI MUST be used to control
an aggregated session. This URI MUST be different from the stream an aggregated session. This URI MUST be different from the stream
control URIs of the individual media streams included in the control URIs of the individual media streams included in the
aggregate (see Section 13.4.2 for aggregated sessions and for the aggregate (see Section 13.4.2 for aggregated sessions and for the
particular URIs see Appendix D.1.1). The Aggregate control URI is to particular URIs see Appendix D.1.1). The Aggregate control URI is to
be specified by the session description if the server supports be specified by the session description if the server supports
aggregated control and aggregated control is desired for the session. aggregated control and aggregated control is desired for the session.
However, even if aggregated control is offered the client MAY chose However, even if aggregated control is offered the client MAY chose
to not set up the session in aggregated control. If an Aggregate to not set up the session in aggregated control. If an Aggregate
control URI is not specified in the session description, it is control URI is not specified in the session description, it is
normally an indication that non-aggregated control should be used. normally an indication that non-aggregated control should be used.
skipping to change at page 68, line 21 skipping to change at page 74, line 21
route the request to the appropriate server, and for logging, route the request to the appropriate server, and for logging,
where it is useful to note the actual resource that a request was where it is useful to note the actual resource that a request was
operating on. operating on.
A session will exist until it is either removed by a TEARDOWN request A session will exist until it is either removed by a TEARDOWN request
or is timed-out by the server. The server MAY remove a session that or is timed-out by the server. The server MAY remove a session that
has not demonstrated liveness signs from the client(s) within a has not demonstrated liveness signs from the client(s) within a
certain timeout period. The default timeout value is 60 seconds; the certain timeout period. The default timeout value is 60 seconds; the
server MAY set this to a different value and indicate so in the server MAY set this to a different value and indicate so in the
timeout field of the Session header in the SETUP response. For timeout field of the Session header in the SETUP response. For
further discussion see Section 18.47. Signs of liveness for an RTSP further discussion see Section 18.49. Signs of liveness for an RTSP
session are: session are:
o Any RTSP request from a client which includes a Session header o Any RTSP request from a client which includes a Session header
with that session's ID. with that session's ID.
o If RTP is used as a transport for the underlying media streams, an o If RTP is used as a transport for the underlying media streams, an
RTCP sender or receiver report from the client(s) for any of the RTCP sender or receiver report from the client(s) for any of the
media streams in that RTSP session. RTCP Sender Reports may for media streams in that RTSP session. RTCP Sender Reports may for
example be received in sessions where the server is invited into a example be received in sessions where the server is invited into a
conference session and is valid for keep-alive. conference session and is valid for keep-alive.
skipping to change at page 69, line 44 skipping to change at page 75, line 44
13.4.1. General Usage 13.4.1. General Usage
The PLAY method tells the server to start sending data via the The PLAY method tells the server to start sending data via the
mechanism specified in SETUP and which part of the media should be mechanism specified in SETUP and which part of the media should be
played out. PLAY requests are valid when the session is in Ready or played out. PLAY requests are valid when the session is in Ready or
Play states. A PLAY request MUST include a Session header to Play states. A PLAY request MUST include a Session header to
indicate which session the request applies to. indicate which session the request applies to.
Upon receipt of the PLAY request, the server 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 deliver stream data until the end of the range if Range header, within the limits of the media resource and in
given, until a new PLAY request is received, or until the end of the accordance with the Seek-Style header (Section 18.47) and deliver
media is reached. If no Range header is present in the PLAY request stream data until the end of the range if given, until a new PLAY
the server SHALL play from current pause point until the end of request is received, or until the end of the media is reached. If no
media. The pause point defaults at session start to the beginning of Range header is present in the PLAY request the server SHALL play
the media. For media that is time-progressing and has no retention, from current pause point until the end of media. The pause point
the pause point will always be set equal to NPT "now", i.e., the defaults at session start to the beginning of the media. For media
current delivery point. The pause point may also be set to a that is time-progressing and has no retention, the pause point will
particular point in the media by the PAUSE method, see Section 13.6. always be set equal to NPT "now", i.e., the current delivery point.
The pause point for media that is currently playing is equal to the The pause point may also be set to a particular point in the media by
current media position. For time-progressing media with time-limited the PAUSE method, see Section 13.6. The pause point for media that
retention, if the pause point represents a position that is older is currently playing is equal to the current media position. For
than what is retained by the server, the pause point will be moved to time-progressing media with time-limited retention, if the pause
the oldest retained. point represents a position that is older than what is retained by
the server, the pause point will be moved to the oldest retained.
What range values are valid depends on the type of content. For What range values are valid depends on the type of content. For
content that isn't time progressing the range value is valid if the content that isn't time progressing the range value is valid if the
given range is part of any media within the aggregate. In other given range is part of any media within the aggregate. In other
words the valid media range for the aggregate is the union of all of words the valid media range for the aggregate is the union of all of
the media components in the aggregate. If a given range value points the media components in the aggregate. If a given range value points
outside of the media, the response MUST be the 457 (Invalid Range) outside of the media, the response MUST be the 457 (Invalid Range)
error code and include the Media-Range header (Section 18.29) with error code and include the Media-Range header (Section 18.30) with
the valid range for the media. Except for time progressing content the valid range for the media. Except for time progressing content
where the client requests a start point prior to what is retained, where the client requests a start point prior to what is retained,
the start point is adjusted to the oldest retained content. For a the start point is adjusted to the oldest retained content. For a
start point that is beyond the media front edge, i.e. beyond the start point that is beyond the media front edge, i.e., beyond the
current value for "now", the server SHALL adjust the start value to current value for "now", the server SHALL adjust the start value to
the current front edge. The Range header's stop point value may the current front edge. The Range header's stop point value may
point beyond the current media edge. In that case, the server SHALL point beyond the current media edge. In that case, the server SHALL
deliver media from the requested (and possibly adjusted) start point deliver media from the requested (and possibly adjusted) start point
until the provided stop point, or the end of the media is reached until the provided stop point, or the end of the media is reached
prior to the specified stop point. Please note that if one simply prior to the specified stop point. Please note that if one simply
wants to play from a particular start point until the end of media wants to play from a particular start point until the end of media
using a Range header with an implicit stop point is RECOMMENDED. using a Range header with an implicit stop point is RECOMMENDED.
If a client requests to start playing at the end of media, either If a client requests to start playing at the end of media, either
explicitly with a Range header or implicitly with a pause point that explicitly with a Range header or implicitly with a pause point that
is at the end of media, a 457 (Invalid Range) error MUST be sent and is at the end of media, a 457 (Invalid Range) error MUST be sent and
include the Media-Range header (Section 18.29). It is specified include the Media-Range header (Section 18.30). It is specified
below that the Range header also must be included in the response and below that the Range header also must be included in the response and
that it will carry the pause point in the media, in the case of the that it will carry the pause point in the media, in the case of the
session being in Ready State. Note that this also applies if the session being in Ready State. Note that this also applies if the
pause point or requested start point is at the beginning of the media pause point or requested start point is at the beginning of the media
and a Scale header (Section 18.44) is included with a negative value and a Scale header (Section 18.46) is included with a negative value
(playing backwards). (playing backwards).
For media with random access properties a client may express its For media with random access properties a client may express its
preference on which policy for start point selection the server shall preference on which policy for start point selection the server shall
use. This is done by including the Seek-Style header (Section 18.45) use. This is done by including the Seek-Style header (Section 18.47)
in the PLAY request. The Seek-Style applied will effect the content in the PLAY request. The Seek-Style applied will effect the content
of the Range header as it will be adjusted to indicate from what of the Range header as it will be adjusted to indicate from what
point the media actually is delivered. point the media actually is delivered.
A client desiring to play the media from the beginning MUST send a A client desiring to play the media from the beginning MUST send a
PLAY request with a Range header pointing at the beginning, e.g. PLAY request with a Range header pointing at the beginning, e.g.,
"npt=0-". If a PLAY request is received without a Range header and "npt=0-". If a PLAY request is received without a Range header and
media delivery has stopped at the end, the server SHOULD respond with media delivery has stopped at the end, the server SHOULD respond with
a 457 "Invalid Range" error response. In that response, the current a 457 "Invalid Range" error response. In that response, the current
pause point MUST be included in a Range header. pause point MUST be included in a Range header.
All range specifiers in this specification allow for ranges with an All range specifiers in this specification allow for ranges with an
implicit start point (e.g. "npt=-30"). When used in a PLAY request, implicit start point (e.g., "npt=-30"). When used in a PLAY request,
the server treats this as a request to start or resume delivery from the server treats this as a request to start or resume delivery from
the current pause point, ending at the end time specified in the the current pause point, ending at the end time specified in the
Range header. If the pause point is located later than the given end Range header. If the pause point is located later than the given end
value, a 457 (Invalid Range) response MUST be given. value, a 457 (Invalid Range) response MUST be given.
The example below will play seconds 10 through 25. It also requests The example below will play seconds 10 through 25. It also requests
the server to deliver media from the first Random Access Point prior the server to deliver media from the first Random Access Point prior
to the indicated start point. to the indicated start point.
C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0 C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0
skipping to change at page 71, line 51 skipping to change at page 78, line 4
real-time due to limited retention, the current pause point is real-time due to limited retention, the current pause point is
returned. For sessions in Play state, the current playout point and returned. For sessions in Play state, the current playout point and
the remaining parts of the range request is returned. For any media the remaining parts of the range request is returned. For any media
with retention longer than 0 seconds the currently valid Media-Range with retention longer than 0 seconds the currently valid Media-Range
header SHALL also be included in the response. header SHALL also be included in the response.
A PLAY response MAY include a header carrying synchronization A PLAY response MAY include a header carrying synchronization
information. As the information necessary is dependent on the media information. As the information necessary is dependent on the media
transport format, further rules specifying the header and its usage transport format, further rules specifying the header and its usage
are needed. For RTP the RTP-Info header is specified, see are needed. For RTP the RTP-Info header is specified, see
Section 18.43, and used in the following example. Section 18.45, and used in the following example.
Here is a simple example for a single audio stream where the client Here is a simple example for a single audio stream where the client
requests the media starting from 3.52 seconds and to the end. The requests the media starting from 3.52 seconds and to the end. The
server sends a 200 OK response with the actual play time which is 10 server sends a 200 OK response with the actual play time which is 10
ms prior (3.51) and the RTP-Info header that contains the necessary ms prior (3.51) and the RTP-Info header that contains the necessary
parameters for the RTP stack. parameters for the RTP stack.
C->S: PLAY rtsp://example.com/audio RTSP/2.0 C->S: PLAY rtsp://example.com/audio RTSP/2.0
CSeq: 836 CSeq: 836
Session: 12345678 Session: 12345678
skipping to change at page 73, line 28 skipping to change at page 79, line 28
ssrc=0D12F123:seq=14783;rtptime=2345962545 ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTP Packet TS=2345962545 => NPT=3.52 S->C: RTP Packet TS=2345962545 => NPT=3.52
Duration=4.15 seconds Duration=4.15 seconds
After playing the desired range, the presentation does NOT change to After playing the desired range, the presentation does NOT change to
the Ready state, media delivery simply stops. A PAUSE request MUST the Ready state, media delivery simply stops. A PAUSE request MUST
be issued to make the stream enter the Ready state. A PLAY request be issued to make the stream enter the Ready state. A PLAY request
while the stream is still in the Play state is legal, and can be while the stream is still in the Play state is legal, and can be
issued without an intervening PAUSE request. Such a request MUST issued without an intervening PAUSE request. Such a request MUST
replace the current PLAY action with the new one requested, i.e. replace the current PLAY action with the new one requested, i.e.,
being handled the same as the request was received in Ready state. being handled in the same way as if as the request was received in
In the case the range in Range header has an implicit start time Ready state. In the case that the range in Range header has an
(-endtime), the server MUST continue to play from where it currently implicit start time ("-endtime"), the server MUST continue to play
was until the specified end point. This is useful to change the end from where it currently was until the specified end point. This is
to at another point than in the previous request. useful to change the end to at another point than in the previous
request.
The following example plays the whole presentation starting at SMPTE The following example plays the whole presentation starting at SMPTE
time code 0:10:20 until the end of the clip. Note: The RTP-Info time code 0:10:20 until the end of the clip. Note: The RTP-Info
headers has been broken into several lines, where following lines headers has been broken into several lines, where following lines
start with whitespace as allowed by the syntax. start with whitespace as allowed by the syntax.
C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0
CSeq: 833 CSeq: 833
Session: 12345678 Session: 12345678
Range: smpte=0:10:20- Range: smpte=0:10:20-
skipping to change at page 75, line 27 skipping to change at page 81, line 27
13.4.3. Updating current PLAY Requests 13.4.3. Updating current PLAY Requests
Clients can issue PLAY requests while the stream is in Play state and Clients can issue PLAY requests while the stream is in Play state and
thus updating their request. 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
the request is constructed. The session is actively playing media the request is constructed. The session is actively playing media
and the play point will be moving, making the exact time a request and the play point will be moving, making the exact time a request
will take action hard to predict. Depending on how the PLAY header will take effect 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 signaled by having the first range A total replacement is signaled by having the first range
specification have an explicit start value, e.g. "npt=45-" or specification have an explicit start value, e.g., "npt=45-" or
"npt=45-60", in which case the server stops playout at the current "npt=45-60", in which case the server stops playout at the current
playout point and then starts delivering media according to the Range playout point and then starts delivering media according to the Range
header. This is equivalent to having the client first send a PAUSE header. This is equivalent to having the client first send a PAUSE
and then a new PLAY request that isn't based on the pause point. In and then a new PLAY request that isn't based on the pause point. In
the case of continuation the first range specifier has an implicit the case of continuation the first range specifier has an implicit
start point and an explicit stop value (Z), e.g. "npt=-60", which start point and an explicit stop value (Z), e.g., "npt=-60", which
indicate that it MUST convert the range specifier being played prior indicate that it MUST convert the range specifier being played prior
to this PLAY request (X to Y) into (X to Z) and continue as this was to this PLAY request (X to Y) into (X to Z) and continue as this was
the request originally played. If the current delivery point is the request originally played. If the current delivery point is
beyond the stop point, the server SHALL immediately pause delivery. beyond the stop point, the server SHALL immediately pause delivery.
As the request has been completed successfully it shall be responded As the request has been completed successfully it shall be responded
with 200 OK. A PLAY_NOTIFY with end-of-stream is also sent to with 200 OK. A PLAY_NOTIFY with end-of-stream is also sent to
indicate the actual stop point. The pause point is set to the indicate the actual stop point. The pause point is set to the
requested stop point. requested stop point.
Following is an example of this behavior: The server has received Following is an example of this behavior: The server has received
requests to play ranges 10 to 15. If the new PLAY request arrives at requests to play ranges 10 to 15. If the new PLAY request arrives at
the server 4 seconds after the previous one, it will take effect the server 4 seconds after the previous one, it will take effect
while the server still plays the first range (10-15). The server while the server still plays the first range (10-15). The server
changes the current play to continue to 25 seconds, i.e. the changes the current play to continue to 25 seconds, i.e., the
equivalent single request would be PLAY with "range: npt=10-25". equivalent single request would be PLAY with "range: npt=10-25".
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
Range: npt=10-15 Range: npt=10-15
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 834 CSeq: 834
skipping to change at page 76, line 43 skipping to change at page 82, line 43
Session: 12345678 Session: 12345678
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Range: npt=14-25 Range: npt=14-25
Seek-Style: Next Seek-Style: Next
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934239921, ssrc=0D12F123:seq=5712;rtptime=934239921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792842193 ssrc=789DAF12:seq=57654;rtptime=2792842193
A common use of a PLAY request while in Play state is changing the A common use of a PLAY request while in Play state is changing the
scale of the media, i.e., entering or leaving from fast forward or scale of the media, i.e., entering or leaving fast forward or fast
fast rewind. The client can issue an updating PLAY request that is rewind. The client can issue an updating PLAY request that is either
either a continuation or a complete replacement, as discussed above a continuation or a complete replacement, as discussed above this
this section. We give an example of a client that is requesting a section. We give an example of a client that is requesting a fast
fast forward (scale=2) without giving a stop point and then change forward (scale=2) without giving a stop point and then change from
from fast forward to regular playout (scale = 1). In the second PLAY fast forward to regular playout (scale = 1). In the second PLAY
request the time is set explicitly to be where ever the server request the time is set explicitly to be where ever the server
currently plays out (npt=now-) and the server responds with the currently plays out (npt=now-) and the server responds with the
actual playback point where the new scale actually takes effect actual playback point where the new scale actually takes effect
(npt=2:17:27.144-). (npt=2:17:27.144-).
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2034 CSeq: 2034
Session: 12345678 Session: 12345678
Range: npt=now- Range: npt=now-
Scale: 2.0 Scale: 2.0
skipping to change at page 77, line 48 skipping to change at page 83, line 48
Range: npt=2:17:27.144- Range: npt=2:17:27.144-
Seek-Style: Next Seek-Style: Next
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934239921, ssrc=0D12F123:seq=5712;rtptime=934239921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792842193 ssrc=789DAF12:seq=57654;rtptime=2792842193
13.4.4. Playing On-Demand Media 13.4.4. Playing On-Demand Media
On-demand media is indicated by the content of the Media-Properties On-demand media is indicated by the content of the Media-Properties
header in the SETUP response by (see also Section 18.28): header in the SETUP response by (see also Section 18.29):
o Random-Access property is set to Random Access; o Random Access property is set to Random-Access;
o Content Modifications set to Immutable; o Content Modifications set to Immutable;
o Retention set to Unlimited or Time-Limited. o Retention set to Unlimited or Time-Limited.
Playing on-demand media follows the general usage as described in Playing on-demand media follows the general usage as described in
Section 13.4.1. Section 13.4.1.
13.4.5. Playing Dynamic On-Demand Media 13.4.5. Playing Dynamic On-Demand Media
Dynamic on-demand media is indicated by the content of the Media- Dynamic on-demand media is indicated by the content of the Media-
Properties header in the SETUP response by (see also Section 18.28): Properties header in the SETUP response by (see also Section 18.29):
o RandomAccess set to Random-Access; o Random Access set to Random-Access;
o Content Modifications set to Dynamic; o Content Modifications set to Dynamic;
o Retention set to Unlimited or Time-Limited. o Retention set to 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 two ways for the client to be informed about changes of There are two ways for the client to be informed about changes of
media resources in Play state. The client will receive a PLAY_NOTIFY media resources in Play state. The client will receive a PLAY_NOTIFY
request with Notify-Reason header set to media-properties-update (see request with Notify-Reason header set to media-properties-update (see
Section 13.5.2. The client can use the value of the Media-Range to Section 13.5.2. The client can use the value of the Media-Range to
decide further actions, if the Media-Range header is present in the decide further actions, if the Media-Range header is present in the
PLAY_NOTIFY request. The second way is that the client issues a PLAY_NOTIFY request. The second way is that the client issues a
GET_PARAMETER request without a body but including a Media-Range GET_PARAMETER request without a body but including a Media-Range
header. The 200 OK response MUST include the current Media-Range header. The 200 OK response MUST include the current Media-Range
header (see Section 18.29). header (see Section 18.30).
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 18.28): in the SETUP response by (see also Section 18.29):
o Random-Access set to No-Seeking; o Random-Access set to No-Seeking;
o Content Modifications set to Time-Progressing; o Content Modifications set to Time-Progressing;
o Retention with Time-Duration set to 0.0. o Retention with Time-Duration set to 0.0.
For live media, the SETUP response 200 OK MUST include the Media- For live media, the SETUP response 200 OK MUST include the Media-
Range header (see Section 18.29). Range header (see Section 18.30).
A client MAY send PLAY requests without the Range header. If the A client MAY send PLAY requests without the Range header. If the
request includes the Range header it MUST use a symbolic value request includes the Range header it MUST use a symbolic value
representing "now". For NPT that range specification is "npt=now-". representing "now". For NPT that range specification is "npt=now-".
The server MUST include the Range header in the response and it MUST The server MUST include the Range header in the response and it MUST
indicate an explicit time value and not a symbolic value. In other indicate an explicit time value and not a symbolic value. In other
words, "npt=now-" is not valid to be used in the response. Instead words, "npt=now-" is not valid to be used in the response. Instead
the time since session start is recommended expressed as an open the time since session start is recommended expressed as an open
interval, e.g. "npt=96.23-". An absolute time value (clock) for the interval, e.g., "npt=96.23-". An absolute time value (clock) for the
corresponding time MAY be given, i.e. "clock=20030213T143205Z-". The corresponding time MAY be given, i.e., "clock=20030213T143205Z-".
UTC clock format can only be used if client has shown support for it The Absolute Time format can only be used if client has shown support
using the Accept-Ranges header. for it using the Accept-Ranges header.
13.4.7. Playing Live with Recording 13.4.7. Playing Live with Recording
Certain media servers may offer recording services of live sessions Certain media servers may offer recording services of live sessions
to their clients. This recording would normally be from the to their clients. This recording would normally be from the
beginning of the media session. Clients can randomly access the beginning of the media session. Clients can randomly access the
media between now and the beginning of the media session. This live media between now and the beginning of the media session. This live
media with recording is indicated by the content of the Media- media with recording is indicated by the content of the Media-
Properties header in the SETUP response by (see also Section 18.28): Properties header in the SETUP response by (see also Section 18.29):
o Random-Access set to Random-Access; o Random Access set to Random-Access;
o Content Modifications set to Time-Progressing; o Content Modifications set to Time-Progressing;
o Retention set to Time-limited or Unlimited o Retention set to Time-Limited or Unlimited
The SETUP response 200 OK MUST include the Media-Range header (see The SETUP response 200 OK MUST include the Media-Range header (see
Section 18.29) for this type of media. For live media with Section 18.30) for this type of media. For live media with
recording, the Range header indicates the current delivery point in recording, the Range header indicates the current delivery point in
the media and the Media-Range header indicates the currently the media and the Media-Range header indicates the currently
available media window around the current time. This window can available media window around the current time. This window can
cover recorded content in the past (seen from current time in the cover recorded content in the past (seen from current time in the
media) or recorded content in the future (seen from current time in media) or recorded content in the future (seen from current time in
the media). The server adjusts the delivery point to the requested the media). The server adjusts the delivery point to the requested
border of the window, if the client requests a delivery point that is border of the window. If the client requests a delivery point that
located outside the recording windows, e.g., if requested to far in is located outside the recording window, e.g., if the requested point
the past, the server selects the oldest range in the recording. The is too far in the past, the server selects the oldest point in the
considerations in Section 13.5.3 apply, if a client requests delivery recording. The considerations in Section 13.5.3 apply if a client
with Scale (Section 18.44) values other than 1.0 (Normal playback requests delivery with Scale (Section 18.46) values other than 1.0
rate) while delivering live media with recording. (Normal playback rate) while delivering live media with recording.
13.4.8. Playing Live with Time-Shift 13.4.8. Playing Live with Time-Shift
Certain media servers may offer time-shift services to their clients. Certain media servers may offer time-shift services to their clients.
This time shift records a fixed interval in the past, i.e., a sliding This time shift records a fixed interval in the past, i.e., a sliding
window recording mechanism, but not past this interval. Clients can window recording mechanism, but not past this interval. Clients can
randomly access the media between now and the interval. This live randomly access the media between now and the interval. This live
media with recording is indicated by the content of the Media- media with recording is indicated by the content of the Media-
Properties header in the SETUP response by (see also Section 18.28): Properties header in the SETUP response by (see also Section 18.29):
o Random-Access set to Random-Access; o Random Access set to Random-Access;
o Content Modifications set to Time-Progressing; o Content Modifications set to Time-Progressing;
o Retention set to Time-Duration and a value indicating the o Retention set to Time-Duration and a value indicating the
recording interval (>0). recording interval (>0).
The SETUP response 200 OK MUST include the Media-Range header (see The SETUP response 200 OK MUST include the Media-Range header (see
Section 18.29) for this type of media. For live media with recording Section 18.30) for this type of media. For live media with recording
the Range header indicates the current time in the media and the the Range header indicates the current time in the media and the
Media Range indicates a window around the current time. This window Media Range indicates a window around the current time. This window
can cover recorded content in the past (seen from current time in the can cover recorded content in the past (seen from current time in the
media) or recorded content in the future (seen from current time in media) or recorded content in the future (seen from current time in
the media). The server adjusts the play point to the requested the media). The server adjusts the play point to the requested
border of the window, if the client requests a play point that is border of the window, if the client requests a play point that is
located outside the recording windows, e.g., if requested too far in located outside the recording windows, e.g., if requested too far in
the past, the server selects the oldest range in the recording. The the past, the server selects the oldest range in the recording. The
considerations in Section 13.5.3 apply, if a client requests delivery considerations in Section 13.5.3 apply, if a client requests delivery
using a Scale (Section 18.44) value other than 1.0 (Normal playback using a Scale (Section 18.46) value other than 1.0 (Normal playback
rate) while delivering live media with time-shift. rate) while delivering live media with time-shift.
13.5. PLAY_NOTIFY 13.5. PLAY_NOTIFY
The PLAY_NOTIFY method is issued by a server to inform a client about The PLAY_NOTIFY method is issued by a server to inform a client about
an asynchronous event for a session in Play state. The Session an asynchronous event for a session in Play state. The Session
header MUST be presented in a PLAY_NOTIFY request and indicates the header MUST be presented in a PLAY_NOTIFY request and indicates the
scope of the request. Sending of PLAY_NOTIFY requests requires a scope of the request. Sending of PLAY_NOTIFY requests requires a
persistent connection between server and client, otherwise there is persistent connection between server and client, otherwise there is
no way for the server to send this request method to the client. no way for the server to send this request method to the client.
PLAY_NOTIFY requests have an end-to-end (i.e. server to client) PLAY_NOTIFY requests have an end-to-end (i.e., server to client)
scope, as they carry the Session header, and apply only to the given scope, as they carry the Session header, and apply only to the given
session. The client SHOULD immediately return a response to the session. The client SHOULD immediately return a response to the
server. server.
PLAY_NOTIFY requests MAY use both aggregate control URI and
individual media resource URIs depending on scope of the
notification. This scope may have important distinctions for
aggregated sessions, and each reason for a PLAY_NOTIFY request needs
to specify the interpretation and if aggregated control URIs or
individual URIs may be used in requests.
PLAY_NOTIFY requests MAY be used with a message body, depending on PLAY_NOTIFY requests MAY be used with a message body, depending on
the value of the Notify-Reason header. It is described in the the value of the Notify-Reason header. It is described in the
particular section for each Notify-Reason if a message body is used. particular section for each Notify-Reason if a message body is used.
However, currently there is no Notify-Reason that allows using a However, currently there is no Notify-Reason that allows using a
message body. In this case, there is a need to obey some limitations message body. In this case, there is a need to obey some limitations
when adding new Notify-Reasons that intend to use a message body: the when adding new Notify-Reasons that intend to use a message body: the
server can send any type of message body, but it is not ensured that server can send any type of message body, but it is not ensured that
the client can understand the received message body. This is related the client can understand the received message body. This is related
to DESCRIBE (see Section 13.2 ), but in this particular case the to DESCRIBE (see Section 13.2 ), but in this particular case the
client can state its acceptable message bodies by using the Accept client can state its acceptable message bodies by using the Accept
header. In the case of PLAY_NOTIFY, the server does not know which header. In the case of PLAY_NOTIFY, the server does not know which
message bodies are understood by the client. message bodies are understood by the client.
The Notify-Reason header (see Section 18.31) specifies the reason why The Notify-Reason header (see Section 18.32) specifies the reason why
the server sends the PLAY_NOTIFY request. This is extensible and new the server sends the PLAY_NOTIFY request. This is extensible and new
reasons MAY be added in the future (see Section 22.8). In case the reasons MAY be added in the future (see Section 22.8). In case the
client does not understand the reason for the notification it MUST client does not understand the reason for the notification it MUST
respond with a 465 (Notification Reason Unknown) (Section 17.4.30) respond with a 465 (Notification Reason Unknown) (Section 17.4.29)
error code. Servers can send PLAY_NOTIFY with these types: error code. Servers can send PLAY_NOTIFY with these types:
o end-of-stream (see Section 13.5.1); o end-of-stream (see Section 13.5.1);
o media-properties-update (see Section 13.5.2); o media-properties-update (see Section 13.5.2);
o scale-change (see Section 13.5.3). o scale-change (see Section 13.5.3).
13.5.1. End-of-Stream 13.5.1. End-of-Stream
A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream
indicates the completion or near completion of the PLAY request and indicates the completion or near completion of the PLAY request and
the ending delivery of the media stream(s). The request MUST NOT be the ending delivery of the media stream(s). The request MUST NOT be
issued unless the server is in the Play state. The end of the media issued unless the server is in the Play state. The end of the media
stream delivery notification may be used to indicate either a stream delivery notification may be used to indicate either a
successful completion of the PLAY request currently being served, or successful completion of the PLAY request currently being served, or
to indicate some error resulting in failure to complete the request. to indicate some error resulting in failure to complete the request.
The Request-Status header (Section 18.40) MUST be included to The Request-Status header (Section 18.42) MUST be included to
indicate which request the notification is for and its completion indicate which request the notification is for and its completion
status. The message response status codes (Section 8.1.1) are used status. The message response status codes (Section 8.1.1) are used
to indicate how the PLAY request concluded. The sender of a to indicate how the PLAY request concluded. The sender of a
PLAY_NOTIFY can issue an updated PLAY_NOTIFY, in the case of a PLAY_NOTIFY can issue an updated PLAY_NOTIFY, in the case of a
PLAY_NOTIFY sent with wrong information. For instance, a PLAY_NOTIFY PLAY_NOTIFY sent with wrong information. For instance, a PLAY_NOTIFY
was issued before reaching the end-of-stream, but some error occurred was issued before reaching the end-of-stream, but some error occurred
resulting in that the previously sent PLAY_NOTIFY contained a wrong resulting in that the previously sent PLAY_NOTIFY contained a wrong
time when the stream will end. In this case a new PLAY_NOTIFY MUST time when the stream will end. In this case a new PLAY_NOTIFY MUST
be sent including the correct status for the completion and all be sent including the correct status for the completion and all
additional information. additional information.
skipping to change at page 82, line 10 skipping to change at page 88, line 17
e.g., "npt=-15", if npt is currently at 14.2 seconds. The Scale e.g., "npt=-15", if npt is currently at 14.2 seconds. The Scale
header is to be included so that it is evident if the media time header is to be included so that it is evident if the media time
scale is moving backwards and/or have a non-default pace. The end- scale is moving backwards and/or have a non-default pace. The end-
of-stream notification does not prevent the client from sending a new of-stream notification does not prevent the client from sending a new
PLAY request. PLAY request.
If RTP is used as media transport, a RTP-Info header MUST be If RTP is used as media transport, a RTP-Info header MUST be
included, and the RTP-Info header MUST indicate the last sequence included, and the RTP-Info header MUST indicate the last sequence
number in the seq parameter. number in the seq parameter.
For RTSP Session where media resources under aggregated control the
media resources will normally end at approximately the same time,
although some small differences may exist, on the scale of a few
hundred of milliseconds. In those cases a RTSP session under
aggregated control SHOULD send only a single PLAY_NOTIFY request. By
using the aggregate control URI in the PLAY_NOTIFY request the RTSP
server indicates that this applies to all media resources within the
session. In cases RTP is used for media delivery corresponding RTP-
Info needs to be included for all media resources. In cases where
one or more media resource has significantly shorter duration than
some other resources in the aggregated session the server MAY send
end-of-stream notifications using individual media resource URIs to
indicate to agents that there will be no more media for this
particular media resource related to the current active PLAY request.
In such cases when the remaining media resources comes to end-of-
stream they MUST send a PLAY_NOTIFY request using the aggregate
control URI to indicate that no more resources remains.
A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream
MUST NOT carry a message body. MUST NOT carry a message body.
This example request notifies the client about a future end-of-stream This example request notifies the client about a future end-of-stream
event: event:
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 854 CSeq: 854
Notify-Reason: end-of-stream Notify-Reason: end-of-stream
Request-Status: cseq=853 status=200 reason="OK" Request-Status: cseq=853 status=200 reason="OK"
Range: npt=-145 Range: npt=-145
RTP-Info:url="rtsp://example.com/audio" RTP-Info:url="rtsp://example.com/fizzle/foo/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545 ssrc=0D12F123:seq=14783;rtptime=2345962545,
url="rtsp://example.com/fizzle/video"
ssrc=789DAF12:seq=57654;rtptime=2792482193
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
Date: Mon, 08 Mar 2010 13:37:16 GMT Date: Mon, 08 Mar 2010 13:37:16 GMT
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 854 CSeq: 854
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
13.5.2. Media-Properties-Update 13.5.2. Media-Properties-Update
A PLAY_NOTIFY request with Notify-Reason header set to media- A PLAY_NOTIFY request with Notify-Reason header set to media-
properties-update indicates an update of the media properties for the properties-update indicates an update of the media properties for the
given session (see Section 18.28) and/or the available media range given session (see Section 18.29) and/or the available media range
that can be played as indicated by Media-Range (Section 18.29). that can be played as indicated by Media-Range (Section 18.30).
PLAY_NOTIFY requests with Notify-Reason header set to media- PLAY_NOTIFY requests with Notify-Reason header set to media-
properties-update MUST include a Media-Properties and Date header and properties-update MUST include a Media-Properties and Date header and
SHOULD include a Media-Range header. SHOULD include a Media-Range header. The Media-Properties header has
session scope, thus for aggregated sessions the PLAY_NOTIFY request
MUST be using the aggregated control URI.
This notification MUST be sent for media that are time-progressing This notification MUST be sent for media that are Time-Progressing
every time an event happens that changes the basis for making every time an event happens that changes the basis for making
estimates on how the media range progress. In addition it is estimates on how the available for play-back media range will
RECOMMENDED that the server sends these notifications every 5 minutes progress with wall clock time. In addition it is RECOMMENDED that
the server sends these notifications approximately every 5 minutes
for time-progressing content to ensure the long-term stability of the for time-progressing content to ensure the long-term stability of the
client estimation and allowing for clock skew detection by the client estimation and allowing for clock skew detection by the
client. Requests for the just mentioned reasons MUST include Media- client. The time between notifications should be greater than 1
Range header to provide current Media duration and the Range header minute and less than 2 hours. Requests for the just mentioned
to indicate the current playing point and any remaining parts of the reasons MUST include Media-Range header to provide current Media
requested range. duration and the Range header to indicate the current playing point
and any remaining parts of the requested range.
The recommendation for sending updates every 5 minutes is due to The recommendation for sending updates every 5 minutes is due to
any clock skew issues. In 5 minutes the clock skew should not any clock skew issues. In 5 minutes the clock skew should not
become too significant as this is not used for media playback and become too significant as this is not used for media playback and
synchronization, only for determining which content is available synchronization, only for determining which content is available
to the user. to the user.
A PLAY_NOTIFY request with Notify-Reason header set to media- A PLAY_NOTIFY request with Notify-Reason header set to media-
properties-update MUST NOT carry a message body. properties-update MUST NOT carry a message body.
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
Date: Tue, 14 Apr 2008 15:48:06 GMT Date: Tue, 14 Apr 2008 15:48:06 GMT
CSeq: 854 CSeq: 854
Notify-Reason: media-properties-update Notify-Reason: media-properties-update
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
Media-Properties: Time-Progressing, Media-Properties: Time-Progressing,
Time-Limited=20080415T153919.36Z, Random-Access=5.0 Time-Limited=20080415T153919.36Z, Random-Access=5.0
Media-Range: npt=0-1:37:21.394 Media-Range: npt=0-1:37:21.394
Range: npt=1:15:49.873- Range: npt=1:15:49.873-
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 854 CSeq: 854
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
13.5.3. Scale-Change 13.5.3. Scale-Change
The server may be forced to change the rate, when a client requests The server may be forced to change the rate of media time per
delivery using a Scale (Section 18.44) value other than 1.0 (normal playback time when a client requests delivery using a Scale
playback rate). For time progressing media with some retention, i.e. (Section 18.46) value other than 1.0 (normal playback rate). For
the server stores already sent content, a client requesting to play time progressing media with some retention, i.e., the server stores
with Scale values larger than 1 may catch up with the front end of already sent content, a client requesting to play with Scale values
the media. The server will then be unable to continue to provide larger than 1 may catch up with the front end of the media. The
content at Scale larger than 1 as content is only made available by server will then be unable to continue to provide content at Scale
the server at Scale=1. Another case is when Scale < 1 and the media larger than 1 as content is only made available by the server at
retention is time-duration limited. In this case the delivery point Scale=1. Another case is when Scale < 1 and the media retention is
can reach the oldest media unit available, and further playback at time-duration limited. In this case the delivery point can reach the
this scale becomes impossible as there will be no media available. oldest media unit available, and further playback at this scale
To avoid having the client lose any media, the scale will need to be becomes impossible as there will be no media available. To avoid
adjusted to the same rate at which the media is removed from the having the client lose any media, the scale will need to be adjusted
storage buffer, commonly Scale = 1.0. to the same rate at which the media is removed from the storage
buffer, commonly Scale = 1.0.
Another case is when the content itself consists of spliced pieces or Another case is when the content itself consists of spliced pieces or
is dynamically updated. In these cases the server may be required to is dynamically updated. In these cases the server may be required to
change from one supported scale value (different than Scale=1.0) to change from one supported scale value (different than Scale=1.0) to
another. In this case the server will pick the closest value and another. In this case the server will pick the closest value and
inform the client of what it has picked. In these cases the media inform the client of what it has picked. In these cases the media
properties will also be sent updating the supported Scale values. properties will also be sent updating the supported Scale values.
This enables a client to adjust the used Scale value. This enables a client to adjust the Scale value used.
To minimize impact on playback in any of the above cases the server To minimize impact on playback in any of the above cases the server
MUST modify the playback properties and set Scale to a supportable MUST modify the playback properties and set Scale to a supportable
value and continue delivery of the media. When doing this value and continue delivery of the media. When doing this
modification it MUST send a PLAY_NOTIFY message with the Notify- modification it MUST send a PLAY_NOTIFY message with the Notify-
Reason header set to "scale-change". The request MUST contain a Reason header set to "scale-change". The request MUST contain a
Range header with the media time where the change took effect, a Range header with the media time when the change took effect, a Scale
Scale header with the new value in use, Session header with the ID header with the new value in use, Session header with the identifier
for the session it applies to and a Date header with the server for the session it applies to and a Date header with the server
wallclock time of the change. For time progressing content also the wallclock time of the change. For time progressing content also the
Media-Range and the Media-Properties at this point in time MUST be Media-Range and the Media-Properties at this point in time MUST be
included. The Media-Properties header MUST be included if the scale included. The Media-Properties header MUST be included if the scale
change was due to the content changing what scale values that is change was due to the content changing what scale values that is
supported. supported.
For media streams being delivered using RTP also a RTP-Info header For media streams being delivered using RTP also a RTP-Info header
MUST be included. It MUST contain the rtptime parameter with a value MUST be included. It MUST contain the rtptime parameter with a value
corresponding to the point of change in that media and optionally corresponding to the point of change in that media and optionally
also the sequence number. also the sequence number.
PLAY_NOTIFY requests for aggregated sessions MUST use the aggregated
control URI in the request. The scale change for any aggregated
session do apply to all media streams part of the aggregate.
A PLAY_NOTIFY request with Notify-Reason header set to "Scale-Change" A PLAY_NOTIFY request with Notify-Reason header set to "Scale-Change"
MUST NOT carry a message body. MUST NOT carry a message body.
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
Date: Tue, 14 Apr 2008 15:48:06 GMT Date: Tue, 14 Apr 2008 15:48:06 GMT
CSeq: 854 CSeq: 854
Notify-Reason: scale-change Notify-Reason: scale-change
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
Media-Properties: Time-Progressing, Media-Properties: Time-Progressing,
Time-Limited=20080415T153919.36Z, Random-Access=5.0 Time-Limited=20080415T153919.36Z, Random-Access=5.0
Media-Range: npt=0-1:37:21.394 Media-Range: npt=0-1:37:21.394
Range: npt=1:37:21.394- Range: npt=1:37:21.394-
Scale: 1 Scale: 1
RTP-Info: url="rtsp://example.com/fizzle/foo/audio" RTP-Info: url="rtsp://example.com/fizzle/foo/audio"
ssrc=0D12F123:rtptime=2345962545 ssrc=0D12F123:rtptime=2345962545,
url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792482193
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 854 CSeq: 854
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
13.6. PAUSE 13.6. PAUSE
The PAUSE request causes the stream delivery to immediately be The PAUSE request causes the stream delivery to immediately be
interrupted (halted). A PAUSE request MUST be done either with the interrupted (halted). A PAUSE request MUST be done either with the
skipping to change at page 85, line 26 skipping to change at page 92, line 29
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 834 CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Range: npt=45.76-75.00 Range: npt=45.76-75.00
The PAUSE request causes stream delivery to be interrupted The PAUSE request causes stream delivery to be interrupted
immediately on receipt of the message and the pause point is set to immediately on receipt of the message and the pause point is set to
the current point in the presentation. That pause point in the media the current point in the presentation. That pause point in the media
stream needs to be maintained. A subsequent PLAY request without stream needs to be maintained. A subsequent PLAY request without
Range header resume from the pause point and plays until media end. Range header resumes from the pause point and plays 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 includes the Seek-Style the Range header from the PAUSE response and includes 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, MUST use "npt=now-" and not
and not the answer given in the response to PAUSE. 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
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Range: npt=10-30 Range: npt=10-30
Seek-Style: First-Prior Seek-Style: First-Prior
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921, ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=4FAD8726:seq=57654;rtptime=2792482193 ssrc=4FAD8726:seq=57654;rtptime=2792482193
Session: 12345678 Session: 12345678
After 11 seconds, i.e. at 21 seconds into the presentation: After 11 seconds, i.e., at 21 seconds into the presentation:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 835 CSeq: 835
Date: 23 Jan 1997 15:35:17 GMT Date: 23 Jan 1997 15:35:17 GMT
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Range: npt=21-30 Range: npt=21-30
skipping to change at page 87, line 36 skipping to change at page 94, line 36
13.7. TEARDOWN 13.7. TEARDOWN
13.7.1. Client to Server 13.7.1. Client to Server
The TEARDOWN client to server request stops the stream delivery for The TEARDOWN client to server request stops the stream delivery for
the given URI, freeing the resources associated with it. A TEARDOWN the given URI, freeing the resources associated with it. A TEARDOWN
request MAY be performed on either an aggregated or a media control request MAY be performed on either an aggregated or a media control
URI. However, some restrictions apply depending on the current URI. However, some restrictions apply depending on the current
state. The TEARDOWN request MUST contain a Session header indicating state. The TEARDOWN request MUST contain a Session header indicating
what session the request applies to. what session the request applies to. The TEARDOWN request MUST NOT
include a Terminate-Reason header.
A TEARDOWN using the aggregated control URI or the media URI in a A TEARDOWN using the aggregated control URI or the media URI in a
session under non-aggregated control (single media session) MAY be session under non-aggregated control (single media session) MAY be
done in any state (Ready and Play). A successful request MUST result done in any state (Ready and Play). A successful request MUST result
in that media delivery being immediately halted and the session state in that media delivery being immediately halted and the session state
being destroyed. This MUST be indicated through the lack of a being destroyed. This MUST be indicated through the lack of a
Session header in the response. Session header in the response.
A TEARDOWN using a media URI in an aggregated session MAY only be A TEARDOWN using a media URI in an aggregated session MAY only be
done in Ready state. Such a request only removes the indicated media done in Ready state. Such a request only removes the indicated media
stream and associated resources from the session. This may result in stream and associated resources from the session. This may result in
that a session returns to non-aggregated control, due to that it only a session returning to non-aggregated control, because it only
contains a single media after the requests completion. A session contains a single media after the request's completion. A session
that will exist after the processing of the TEARDOWN request MUST in that will exist after the processing of the TEARDOWN request MUST in
the response to that TEARDOWN request contain a Session header. Thus the response to that TEARDOWN request contain a Session header. Thus
the presence of the Session header indicates to the receiver of the the presence of the Session header indicates to the receiver of the
response if the session is still existing or has been removed. response if the session is still existing or has been removed.
Example: Example:
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 892 CSeq: 892
Session: 12345678 Session: 12345678
skipping to change at page 88, line 24 skipping to change at page 95, line 25
CSeq: 892 CSeq: 892
Server: PhonyServer/1.0 Server: PhonyServer/1.0
13.7.2. Server to Client 13.7.2. Server to Client
The server can send TEARDOWN requests in the server to client The server can send TEARDOWN requests in the server to client
direction to indicate that the server has been forced to terminate direction to indicate that the server has been forced to terminate
the ongoing session. This may happen for several reasons, such as the ongoing session. This may happen for several reasons, such as
server maintenance without available backup, or that the session has server maintenance without available backup, or that the session has
been inactive for extended periods of time. The reason is provided been inactive for extended periods of time. The reason is provided
in the Terminate-Reason header (Section 18.50). in the Terminate-Reason header (Section 18.52).
When a RTSP client has maintained a RTSP session that otherwise is When a RTSP client has maintained a RTSP session that otherwise is
inactive for an extended period of time the server may reclaim the inactive for an extended period of time the server may reclaim the
resources. That is done by issuing a TEARDOWN request with the resources. That is done by issuing a TEARDOWN request with the
Terminate-Reason set to "Session-Timeout". This MAY be done when the Terminate-Reason set to "Session-Timeout". This MAY be done when the
client has been inactive in the RTSP session for more than one client has been inactive in the RTSP session for more than one
Session Timeout period (Section 18.47). However, the server is Session Timeout period (Section 18.49). However, the server is
RECOMMENDED to not perform this operation until an extended period of RECOMMENDED to not perform this operation until an extended period of
inactivity has passed. The time period is considered extended when inactivity of 10 times the Session Timeout period has passed. It is
it is 10 times the Session Timeout period. Consideration of the to the operator of the RTSP server to actually configure how long
application of the server and its content should be performed when this extended period of inactivity is. An operator should take into
configuring what is considered as extended period of time. account when doing this configuration what the served content is and
what this means for the extended period of inactivity.
In case the server needs to stop providing service to the established In case the server needs to stop providing service to the established
sessions and there is no server to point at in a REDIRECT request, sessions and there is no server to point at in a REDIRECT request,
then TEARDOWN SHALL be used to terminate the session. This method then TEARDOWN SHALL be used to terminate the session. This method
can also be used when non-recoverable internal errors have happened can also be used when non-recoverable internal errors have happened
and the server has no other option then to terminate the sessions. and the server has no other option then to terminate the sessions.
The TEARDOWN request MUST be done only on the session aggregate The TEARDOWN request MUST be done only on the session aggregate
control URI (i.e., it is not allowed to terminate individual media control URI (i.e., it is not allowed to terminate individual media
streams, if it is a session aggregate) and MUST include the following streams, if it is a session aggregate) and MUST include the following
headers; Session and Terminate-Reason headers. The request only headers; Session and Terminate-Reason headers. The request only
applies to the session identified in the Session header. The server applies to the session identified in the Session header. The server
may include a message to the client's user with the "user-msg" may include a message to the client's user with the "user-msg"
parameter. parameter.
The TEARDOWN request may alternatively be done on the wild card URI * The TEARDOWN request may alternatively be done on the wild card URI *
and without any session header. The scope of such a request is and without any session header. The scope of such a request is
limited to the next-hop (i.e. the RTSP agent in direct communication limited to the next-hop (i.e., the RTSP agent in direct communication
with the server) and applies, as well, to the control connection with the server) and applies, as well, to the RTSP connection between
between the next-hop RTSP agent and the server. This request the next-hop RTSP agent and the server. This request indicates that
indicates that all sessions and pending requests being managed via all sessions and pending requests being managed via the connection
the control connection are terminated. Any intervening proxies are terminated. Any intervening proxies SHOULD do all of the
SHOULD do all of the following in the order listed: following in the order listed:
1. respond to the TEARDOWN request 1. respond to the TEARDOWN request
2. disconnect the control channel from the requesting server 2. disconnect the control channel from the requesting server
3. pass the TEARDOWN request to each applicable client (typically 3. pass the TEARDOWN request to each applicable client (typically
those clients with an active session or an unanswered request) those clients with an active session or an unanswered request)
Note: The proxy is responsible for accepting TEARDOWN responses Note: The proxy is responsible for accepting TEARDOWN responses
from its clients; these responses MUST NOT be passed on to either from its clients; these responses MUST NOT be passed on to either
the original server or the target server in the redirect. the original server or the target server in the redirect.
13.8. GET_PARAMETER 13.8. GET_PARAMETER
The GET_PARAMETER request retrieves the value of any specified The GET_PARAMETER request retrieves the value of any specified
parameter or parameters for a presentation or stream specified in the parameter or parameters for a presentation or stream specified in the
URI. If the Session header is present in a request, the value of a URI. If the Session header is present in a request, the value of a
parameter MUST be retrieved in the specified session context. There parameter MUST be retrieved in the specified session context. There
are two ways of specifying the parameters to be retrieved. The first are two ways of specifying the parameters to be retrieved.
is by including headers which have been defined such that you can use
them for this purpose. Headers for this purpose should allow empty,
or stripped value parts to avoid having to specify bogus data when
indicating the desire to retrieve a value. The successful completion
of the request should also be evident from any filled out values in
the response. The Media-Range header (Section 18.29) is one such
header. The other way is to specify a message body that lists the
parameter(s) that are desired to be retrieved. The Content-Type
header (Section 18.18) is used to specify which format the message
body has.
The headers that MAY be used for retrieving their current value using The first is by including headers which have been defined such that
GET_PARAMETER are: you can use them for this purpose. Headers for this purpose should
allow empty, or stripped value parts to avoid having to specify bogus
data when indicating the desire to retrieve a value. The successful
completion of the request should also be evident from any filled out
values in the response. The headers in this specification that MAY
be used for retrieving their current value using GET_PARAMETER below.
Additional headers MAY be specified in the future:
o Accept-Ranges o Accept-Ranges
o Media-Range o Media-Range
o Media-Properties o Media-Properties
o Range
o Range
o RTP-Info o RTP-Info
The method MAY also be used without a message body or any header that The other way is to specify a message body that lists the
request parameters for keep-alive purpose. The keep-alive timer has parameter(s) that are desired to be retrieved. The Content-Type
been updated for any request that is successful, i.e., a 200 OK header (Section 18.19) is used to specify which format the message
response is received. Any non-required header present in such a body has. If the receiver of the request is not supporting the media
request may or may not have been processed. Normally the presence of type used for the message body, it SHALL respond using the error code
filled out values in the header will be indication that the header 415 (Unsupported Media Type). The responder to a GET_PARAMETER
has been processed. However, for cases when this is difficult to request MUST use the media type of the request for the response. For
determine, it is recommended to use a feature-tag and the Require additional considerations regarding message body negotiation see
header. Due to this reason it is usually easier if any parameters to Section 9.3.
be retrieved are sent in the body, rather than using any header.
RTSP Agents implementing support for responding to GET_PARAMETER
requests SHALL implement the text/parameters format (Appendix F).
This to ensure that at least one known format for parameter are
implemented and thus prevent parameter format negotiation failure.
Parameters specified within the body of the message must all be Parameters specified within the body of the message must all be
understood by the request receiving agent. If one or more parameters understood by the request receiving agent. If one or more parameters
are not understood a 451 (Parameter Not Understood) MUST be sent are not understood a 451 (Parameter Not Understood) MUST be sent
including a body listing these parameters that weren't understood. including a body listing these parameters that weren't understood.
If all parameters are understood their values are filled in and If all parameters are understood their values are filled in and
returned in the response message body. returned in the response message body.
The method MAY also be used without a message body or any header that
requests parameters for keep-alive purpose. The keep-alive timer has
been updated for any request that is successful, i.e., a 200 OK
response is received. Any non-required header present in such a
request may or may not have been processed. Normally the presence of
filled out values in the header will be indication that the header
has been processed. However, for cases when this is difficult to
determine, it is recommended to use a feature-tag and the Require
header. For this reason it is usually easier if any parameters to be
retrieved are sent in the body, rather than using any header.
Example: Example:
S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 431 CSeq: 431
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 12345678 Session: 12345678
Content-Length: 26 Content-Length: 26
Content-Type: text/parameters Content-Type: text/parameters
packets_received packets_received
skipping to change at page 91, line 12 skipping to change at page 98, line 33
packets_received: 10 packets_received: 10
jitter: 0.3838 jitter: 0.3838
13.9. SET_PARAMETER 13.9. SET_PARAMETER
This method requests to set the value of a parameter or a set of This method requests to set the value of a parameter or a set of
parameters for a presentation or stream specified by the URI. The parameters for a presentation or stream specified by the URI. The
method MAY also be used without a message body. It is the method MAY also be used without a message body. It is the
RECOMMENDED method to be used in a request sent for the sole purpose RECOMMENDED method to be used in a request sent for the sole purpose
of updating the keep-alive timer. If this request is successful, of updating the keep-alive timer. If this request is successful,
i.e. a 200 OK response is received, then the keep-alive timer has i.e., a 200 OK response is received, then the keep-alive timer has
been updated. Any non-required header present in such a request may been updated. Any non-required header present in such a request may
or may not have been processed. To allow a client to determine if or may not have been processed. To allow a client to determine if
any such header has been processed, it is necessary to use a feature any such header has been processed, it is necessary to use a feature
tag and the Require header. Due to this reason it is RECOMMENDED tag and the Require header. Due to this reason it is RECOMMENDED
that any parameters are sent in the body, rather than using any that any parameters are sent in the body, rather than using any
header. header.
When using a message body to list the parameter(s) that are desired
to be set the Content-Type header (Section 18.19) is used to specify
which format the message body has. If the receiver of the request is
not supporting the media type used for the message body, it SHALL
respond using the error code 415 (Unsupported Media Type). For
additional considerations regarding message body negotiation see
Section 9.3.
RTSP Agents implementing support for responding to SET_PARAMETER
requests SHALL implement the text/parameters format (Appendix F).
This to ensure that at least one known format for parameters are
implemented and thus prevent parameter format negotiation failure.
A request is RECOMMENDED to only contain a single parameter to allow A request is RECOMMENDED to only contain a single parameter to allow
the client to determine why a particular request failed. If the the client to determine why a particular request failed. If the
request contains several parameters, the server MUST only act on the request contains several parameters, the server MUST only act on the
request if all of the parameters can be set successfully. A server request if all of the parameters can be set successfully. A server
MUST allow a parameter to be set repeatedly to the same value, but it MUST allow a parameter to be set repeatedly to the same value, but it
MAY disallow changing parameter values. If the receiver of the MAY disallow changing parameter values. If the receiver of the
request does not understand or cannot locate a parameter, error 451 request does not understand or cannot locate a parameter, error 451
(Parameter Not Understood) MUST be used. In the case a parameter is (Parameter Not Understood) MUST be used. When a parameter is not
not allowed to change, the error code is 458 (Parameter Is Read- allowed to change, the error code is 458 (Parameter Is Read-Only).
Only). The response body MUST contain only the parameters that have The response body MUST contain only the parameters that have errors.
errors. Otherwise no body MUST be returned. Otherwise no body MUST be returned. The response body MUST use the
media type of the request for the response.
Note: transport parameters for the media stream MUST only be set with Note: transport parameters for the media stream MUST only be set with
the SETUP command. the SETUP command.
Restricting setting transport parameters to SETUP is for the Restricting setting transport parameters to SETUP is for the
benefit of firewalls. benefit of firewalls.
The parameters are split in a fine-grained fashion so that there The parameters are split in a fine-grained fashion so that there
can be more meaningful error indications. However, it may make can be more meaningful error indications. However, it may make
sense to allow the setting of several parameters if an atomic sense to allow the setting of several parameters if an atomic
skipping to change at page 92, line 35 skipping to change at page 100, line 15
13.10. REDIRECT 13.10. REDIRECT
The REDIRECT method is issued by a server to inform a client that the The REDIRECT method is issued by a server to inform a client that the
service provided will be terminated and where a corresponding service service provided will be terminated and where a corresponding service
can be provided instead. This may happen for different reasons. One can be provided instead. This may happen for different reasons. One
is that the server is being administered such that it must stop is that the server is being administered 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 18.50) to inform the client of the reason for the request. (Section 18.52) 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 a server administrator to do a The intention here is to allow a 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
and for them to perform a controlled migration from this server to a and for them to perform a controlled migration from this server to a
fall back server. fall back server.
A REDIRECT request with a Session header has end-to-end (i.e. server A REDIRECT request with a Session header has end-to-end (i.e., server
to client) scope and applies only to the given session. Any to client) scope and applies only to the given session. Any
intervening proxies SHOULD NOT disconnect the control channel while intervening proxies SHOULD NOT disconnect the control channel while
there are other remaining end-to-end sessions. The REQUIRED Location there are other remaining end-to-end sessions. The REQUIRED Location
header MUST contain a complete absolute URI pointing to the resource header MUST contain a complete absolute URI pointing to the resource
to which the client SHOULD reconnect. Specifically, the Location to which the client SHOULD reconnect. Specifically, the Location
MUST NOT contain just the host and port. A client may receive a MUST NOT contain just the host and port. A client may receive a
REDIRECT request with a Session header, if and only if, an end-to-end REDIRECT request with a Session header, if and only if, an end-to-end
session has been established. session has been established.
A client may receive a REDIRECT request without a Session header at A client may receive a REDIRECT request without a Session header at
any time when it has communication or a connection established with a any time when it has communication or a connection established with a
server. The scope of such a request is limited to the next-hop (i.e. server. The scope of such a request is limited to the next-hop
the RTSP agent in direct communication with the server) and applies (i.e., the RTSP agent in direct communication with the server) and
to all sessions controlled, as well as the control connection between applies to all sessions controlled, as well as the connection between
the next-hop RTSP agent and the server. A REDIRECT request without a the next-hop RTSP agent and the server. A REDIRECT request without a
Session header indicates that all sessions and pending requests being Session header indicates that all sessions and pending requests being
managed via the control connection MUST be redirected. The Location managed via the connection MUST be redirected. The Location header,
header, if included in such a request, SHOULD contain an absolute URI if included in such a request, SHOULD contain an absolute URI with
with only the host address and the OPTIONAL port number of the server only the host address and the OPTIONAL port number of the server to
to which the RTSP agent SHOULD reconnect. Any intervening proxies which the RTSP agent SHOULD reconnect. Any intervening proxies
SHOULD do all of the following in the order listed: SHOULD do all of the following in the order listed:
1. respond to the REDIRECT request 1. respond to the REDIRECT request
2. disconnect the control channel from the requesting server 2. disconnect the control channel from the requesting server
3. connect to the server at the given host address 3. connect to the server at the given host address
4. pass the REDIRECT request to each applicable client (typically 4. pass the REDIRECT request to each applicable client (typically
those clients with an active session or an unanswered request) those clients with an active session or an unanswered request)
Note: The proxy is responsible for accepting REDIRECT responses Note: The proxy is responsible for accepting REDIRECT responses
from its clients; these responses MUST NOT be passed on to either from its clients; these responses MUST NOT be passed on to either
the original server or the redirected server. the original server or the redirected server.
When the server lacks any alternative server and needs to terminate a When the server lacks any alternative server and needs to terminate a
session or all sessions the TEARDOWN request SHALL be used instead. session or all sessions the TEARDOWN request SHALL be used instead.
skipping to change at page 93, line 34 skipping to change at page 101, line 14
4. pass the REDIRECT request to each applicable client (typically 4. pass the REDIRECT request to each applicable client (typically
those clients with an active session or an unanswered request) those clients with an active session or an unanswered request)
Note: The proxy is responsible for accepting REDIRECT responses Note: The proxy is responsible for accepting REDIRECT responses
from its clients; these responses MUST NOT be passed on to either from its clients; these responses MUST NOT be passed on to either
the original server or the redirected server. the original server or the redirected server.
When the server lacks any alternative server and needs to terminate a When the server lacks any alternative server and needs to terminate a
session or all sessions the TEARDOWN request SHALL be used instead. session or all sessions the TEARDOWN request SHALL be used instead.
When no Terminate-Reason "time" parameter are included in a REDIRECT When no Terminate-Reason "time" parameter is included in a REDIRECT
request, the client SHALL perform the redirection immediately and request, the client SHALL perform the redirection immediately and
return a response to the server. The server shall consider the return a response to the server. The server shall consider the
session as terminated and can free any associated state after it session as terminated and can free any associated state after it
receives the successful (2xx) response. The server MAY close the receives the successful (2xx) response. The server MAY close the
signaling connection upon receiving the response and the client signaling connection upon receiving the response and the client
SHOULD close the signaling connection after sending the 2xx response. SHOULD close the signaling connection after sending the 2xx response.
The exception to this is when the client has several sessions on the The exception to this is when the client has several sessions on the
server being managed by the given signaling connection. In this server being managed by the given signaling connection. In this
case, the client SHOULD close the connection when it has received and case, the client SHOULD close the connection when it has received and
responded to REDIRECT requests for all the sessions managed by the responded to REDIRECT requests for all the sessions managed by the
signaling connection. signaling connection.
The Terminate-Reason header "time" parameter MAY be used to indicate The Terminate-Reason header "time" parameter MAY be used to indicate
the wallclock time by when the redirection MUST have taken place. To the wallclock time by when the redirection MUST have taken place. To
allow a client to determine that redirect time without being time allow a client to determine that redirect time without being time
synchronized with the server, the server MUST include a Date header synchronized with the server, the server MUST include a Date header
in the request. The client should have terminated the session and in the request. The client should have terminated the session and
closed the control connection before the redirection time-line closed the connection before the redirection time-line terminated.
terminated. The server MAY simply cease to provide service when the The server MAY simply cease to provide service when the deadline time
deadline time has been reached, or it may issue TEARDOWN requests to has been reached, or it may issue TEARDOWN requests to the remaining
the remaining sessions. sessions.
If the REDIRECT request times out following the rules in Section 10.4 If the REDIRECT request times out following the rules in Section 10.4
the server MAY terminate the session or transport connection that the server MAY terminate the session or transport connection that
would be redirected by the request. This is a safeguard against would be redirected by the request. This is a safeguard against
misbehaving clients that refuse to respond to a REDIRECT request. misbehaving clients that refuse to respond to a REDIRECT request.
That should not provide any benefit. Thus, removing any incentive to not acknowledge the reception of a
REDIRECT request.
After a REDIRECT request has been processed, a client that wants to After a REDIRECT request has been processed, a client that wants to
continue to send or receive media for the resource identified by the continue to receive media for the resource identified by the Request-
Request-URI will have to establish a new session with the designated URI will have to establish a new session with the designated host.
host. If the URI given in the Location header is a valid resource If the URI given in the Location header is a valid resource URI, a
URI, a client SHOULD issue a DESCRIBE request for the URI. client SHOULD issue a DESCRIBE request for the URI.
Note: The media resource indicated by the Location header can be Note: The media resource indicated by the Location header can be
identical, slightly different or totally different. This is the identical, slightly different or totally different. This is the
reason why a new DESCRIBE request SHOULD be issued. reason why a new DESCRIBE request SHOULD be issued.
If the Location header contains only a host address, the client MAY If the Location header contains only a host address, the client MAY
assume that the media on the new server is identical to the media on assume that the media on the new server is identical to the media on
the old server, i.e. all media configuration information from the old the old server, i.e., all media configuration information from the
session is still valid except for the host address. However, the old session is still valid except for the host address. However, the
usage of conditional SETUP using MTag identifiers are RECOMMENDED to usage of conditional SETUP using MTag identifiers is RECOMMENDED as a
verify the assumption. means to verify the assumption.
This example request redirects traffic for this session to the new This example request redirects traffic for this session to the new
server at the given absolute time: server at the given absolute time:
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 732 CSeq: 732
Location: rtsp://s2.example.com:8001 Location: rtsp://s2.example.com:8001
Terminate-Reason: Server-Admin ;time=19960213T143205Z Terminate-Reason: Server-Admin ;time=19960213T143205Z
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
Date: Thu, 13 Feb 1996 14:30:43 GMT Date: Thu, 13 Feb 1996 14:30:43 GMT
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 732 CSeq: 732
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
14. Embedded (Interleaved) Binary Data 14. Embedded (Interleaved) Binary Data
In order to fulfill certain requirements on the network side, e.g. in In order to fulfill certain requirements on the network side, e.g.,
conjunction with network address translators that block RTP traffic in conjunction with network address translators that block RTP
over UDP, it may be necessary to interleave RTSP messages and media traffic over UDP, it may be necessary to interleave RTSP messages and
stream data. This interleaving should generally be avoided unless media stream data. This interleaving should generally be avoided
necessary since it complicates client and server operation and unless necessary since it complicates client and server operation and
imposes additional overhead. Also, head of line blocking may cause imposes additional overhead. Also, head of line blocking may cause
problems. Interleaved binary data SHOULD only be used if RTSP is problems. Interleaved binary data SHOULD only be used if RTSP is
carried over TCP. Interleaved data is not allowed inside RTSP carried over TCP. Interleaved data is not allowed inside RTSP
messages. messages.
Stream data such as RTP packets is encapsulated by an ASCII dollar Stream data such as RTP packets is encapsulated by an ASCII dollar
sign (36 decimal), followed by a one-byte channel identifier, sign (36 decimal), followed by a one-octet channel identifier,
followed by the length of the encapsulated binary data as a binary, followed by the length of the encapsulated binary data as a binary,
two-byte integer in network byte order. The stream data follows two-octet unsigned integer in network byte order. The stream data
immediately afterwards, without a CRLF, but including the upper-layer follows immediately afterwards, without a CRLF, but including the
protocol headers. Each $ block MUST contain exactly one upper-layer upper-layer protocol headers. Each $ block MUST contain exactly one
protocol data unit, e.g., one RTP packet. upper-layer protocol data unit, e.g., one RTP packet.
Note that this mechanism does not support larger PDUs than 65535
bytes, which is the same that regular IPv4 and IPv6 is capable.
If the media delivery protocol intended to be used has larger PDUs
than that, the definition of such mechanisms usage of this
mechanism will require the definition of a PDU fragmentation
mechanism.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "$" = 36 | Channel ID | Length in bytes | | "$" = 36 | Channel ID | Length in octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Length number of bytes of binary data : : Binary data (Length according to Length field) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Embedded Interleaved Binary Data Format
The channel identifier is defined in the Transport header with the The channel identifier is defined in the Transport header with the
interleaved parameter (Section 18.52). interleaved parameter (Section 18.54).
When the transport choice is RTP, RTCP messages are also interleaved When the transport choice is RTP, RTCP messages are also interleaved
by the server over the TCP connection. The usage of RTCP messages is by the server over the TCP connection. The usage of RTCP messages is
indicated by including an interval containing a second channel in the indicated by including an interval containing a second channel in the
interleaved parameter of the Transport header, see Section 18.52. If interleaved parameter of the Transport header, see Section 18.54. If
RTCP is used, packets MUST be sent on the first available channel RTCP is used, packets MUST be sent on the first available channel
higher than the RTP channel. The channels are bi-directional, using higher than the RTP channel. The channels are bi-directional, using
the same Channel ID in both directions, and therefore RTCP traffic is the same Channel ID in both directions, and therefore RTCP traffic is
sent on the second channel in both directions. sent on the second channel in both directions.
RTCP is sometimes needed for synchronization when two or more RTCP is sometimes needed for synchronization when two or more
streams are interleaved in such a fashion. Also, this provides a streams are interleaved in such a fashion. Also, this provides a
convenient way to tunnel RTP/RTCP packets through the TCP control convenient way to tunnel RTP/RTCP packets through the RTSP
connection when required by the network configuration and transfer connection (TCP or TCP/TLS) when required by the network
them onto UDP when possible. configuration and transfer them onto UDP when possible.
C->S: SETUP rtsp://example.com/bar.file RTSP/2.0 C->S: SETUP rtsp://example.com/bar.file RTSP/2.0
CSeq: 2 CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1 Transport: RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: npt, smpte, clock
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Date: Thu, 05 Jun 1997 18:57:18 GMT Date: Thu, 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;unicast;interleaved=5-6 Transport: RTP/AVP/TCP;unicast;interleaved=5-6
Session: 12345678 Session: 12345678
Accept-Ranges: NPT Accept-Ranges: npt
Media-Properties: Random-Access=0.2, Immutable, Unlimited Media-Properties: Random-Access=0.2, Immutable, Unlimited
C->S: PLAY rtsp://example.com/bar.file RTSP/2.0 C->S: PLAY rtsp://example.com/bar.file RTSP/2.0
CSeq: 3 CSeq: 3
Session: 12345678 Session: 12345678
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Session: 12345678 Session: 12345678
Date: Thu, 05 Jun 1997 18:57:19 GMT Date: Thu, 05 Jun 1997 18:57:19 GMT
RTP-Info: url="rtsp://example.com/bar.file" RTP-Info: url="rtsp://example.com/bar.file"
ssrc=0D12F123:seq=232433;rtptime=972948234 ssrc=0D12F123:seq=232433;rtptime=972948234
Range: npt=0-56.8 Range: npt=0-56.8
Seek-Style: RAP Seek-Style: RAP
S->C: $005{2 byte length}{"length" bytes data, w/RTP header} S->C: $005{2 octet length}{"length" octets data, w/RTP header}
S->C: $005{2 byte length}{"length" bytes data, w/RTP header} S->C: $005{2 octet length}{"length" octets data, w/RTP header}
S->C: $006{2 byte length}{"length" bytes RTCP packet} S->C: $006{2 octet length}{"length" octets RTCP packet}
15. Proxies 15. Proxies
RTSP Proxies are RTSP agents that are located in between a client and RTSP Proxies are RTSP agents that are located in between a client and
a server. A proxy can take on both the role as a client and as a server. A proxy can take on both the role as a client and as
server depending on what it tries to accomplish. Proxies are also server depending on what it tries to accomplish. RTSP proxies use
introduced for several different reasons and the below listed are two transport layer connections, one from the RTSP client to the RTSP
proxy and a second from the RTSP proxy to the RTSP server. Proxies
are introduced for several different reasons and the below listed are
often combined. often combined.
In general there are two categories of RTSP proxies, transparent (of
which the client is not aware) and the non-transparent proxies (of
which the client is aware). Transparent proxies are not visible to
the client in terms of the transport layer connection, e.g., TCP for
RTSP, as there is only a single transport connection which is
terminated at the RTSP client and the RTSP server. In the case of
non-transparent proxies, there are two transport layer connections,
one from the RTSP client to the RTSP proxy and a second from the RTSP
proxy to the RTSP server.
There are these types of RTSP proxies: There are these types of RTSP proxies:
Caching Proxy: This type of proxy is used to reduce the workload on Caching Proxy: This type of proxy is used to reduce the workload on
servers and connections. By caching the description and media servers and connections. By caching the description and media
streams, i.e., the presentation, the proxy can serve a client streams, i.e., the presentation, the proxy can serve a client
with content, but without requesting it from the server once it with content, but without requesting it from the server once it
has been cached and has not become stale. See the caching has been cached and has not become stale. See the caching
Section 16. This type of proxy is also expected to understand Section 16. This type of proxy is also expected to understand
RTSP end-point functionality, i.e., functionality identified in RTSP end-point functionality, i.e., functionality identified in
the Require header in addition to what Proxy-Require demands. the Require header in addition to what Proxy-Require demands.
Translator Proxy: This type of proxy is used to ensure that an RTSP Translator Proxy: This type of proxy is used to ensure that an RTSP
client gets access to servers and content on an external client gets access to servers and content on an external
network or using content encodings not supported by the client. network or using content encodings not supported by the client.
The proxy performs the necessary translation of addresses, The proxy performs the necessary translation of addresses,
protocols or encodings. This type of proxy is expected to also protocols or encodings. This type of proxy is expected to also
understand RTSP end-point functionality, i.e. functionality understand RTSP end-point functionality, i.e., functionality
identified in the Require header in addition to what Proxy- identified in the Require header in addition to what Proxy-
Require demands. Require demands.
Access Proxy: This type of proxy is used to ensure that an RTSP Access Proxy: This type of proxy is used to ensure that an RTSP
client gets access to servers on an external network. Thus client gets access to servers on an external network. Thus
this proxy is placed on the border between two domains, e.g. a this proxy is placed on the border between two domains, e.g., a
private address space and the public Internet. The proxy private address space and the public Internet. The proxy
performs the necessary translation, usually addresses. This performs the necessary translation, usually addresses. This
type of proxy is required to redirect the media to itself or a type of proxy is required to redirect the media to itself or a
controlled gateway that performs the translation before the controlled gateway that performs the translation before the
media can reach the client. media can reach the client.
Security Proxy: This type of proxy is used to help facilitate Security Proxy: This type of proxy is used to help facilitate
security functions around RTSP. For example when having a security functions around RTSP. For example when having a
firewalled network, the security proxy requests that the firewalled network, the security proxy requests that the
necessary pinholes in the firewall are opened when a client in necessary pinholes in the firewall are opened when a client in
the protected network wants to access media streams on the the protected network wants to access media streams on the
external side. This proxy can also limit the client's access external side. This proxy can also limit the client's access
to certain types of content. This proxy can perform its to certain types of content. This proxy can perform its
function without redirecting the media between the server and function without redirecting the media between the server and
client. However, in deployments with private address spaces client. However, in deployments with private address spaces
this proxy is likely to be combined with the access proxy. this proxy is likely to be combined with the access proxy.
Anyway, the functionality of this proxy is usually closely tied Anyway, the functionality of this proxy is usually closely tied
into understanding all aspects of the media transport. into understanding all aspects of the media transport.
Auditing Proxy: RTSP proxies can also provide network owners with a Auditing Proxy: RTSP proxies can also provide network owners with a
logging and audit point for RTSP sessions, e.g. for logging and audit point for RTSP sessions, e.g., for
corporations that track their employees usage of the network. corporations that track their employees usage of the network.
This type of proxy can perform its function without inserting This type of