draft-ietf-mmusic-rfc2326bis-40.txt   rfc7826.txt 
MMUSIC Working Group H. Schulzrinne Internet Engineering Task Force (IETF) H. Schulzrinne
Internet-Draft Columbia University Request for Comments: 7826 Columbia University
Obsoletes: 2326 (if approved) A. Rao Obsoletes: 2326 A. Rao
Intended status: Standards Track Cisco Category: Standards Track Cisco
Expires: August 14, 2014 R. Lanphier ISSN: 2070-1721 R. Lanphier
M. Westerlund M. Westerlund
Ericsson AB Ericsson
M. Stiemerling (Ed.) M. Stiemerling, Ed.
NEC University of Applied Sciences Darmstadt
February 10, 2014 December 2016
Real Time Streaming Protocol 2.0 (RTSP) Real-Time Streaming Protocol Version 2.0
draft-ietf-mmusic-rfc2326bis-40
Abstract Abstract
This memorandum defines RTSP version 2.0 which obsoletes RTSP version This memorandum defines the Real-Time Streaming Protocol (RTSP)
1.0 defined in RFC 2326. version 2.0, which obsoletes RTSP version 1.0 defined in RFC 2326.
The Real Time Streaming Protocol, or RTSP, is an application-layer RTSP is an application-layer protocol for the setup and control of
protocol for setup and control of the delivery of data with real-time the delivery of data with real-time properties. RTSP provides an
properties. RTSP provides an extensible framework to enable extensible framework to enable controlled, on-demand delivery of
controlled, on-demand delivery of real-time data, such as audio and real-time data, such as audio and video. Sources of data can include
video. Sources of data can include both live data feeds and stored both live data feeds and stored clips. This protocol is intended to
clips. This protocol is intended to control multiple data delivery control multiple data delivery sessions; provide a means for choosing
sessions, provide a means for choosing delivery channels such as UDP, delivery channels such as UDP, multicast UDP, and TCP; and provide a
multicast UDP and TCP, and provide a means for choosing delivery means for choosing delivery mechanisms based upon RTP (RFC 3550).
mechanisms based upon RTP (RFC 3550).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on August 14, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7826.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 34 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction ...................................................10
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11 2. Protocol Overview ..............................................11
2.1. Presentation Description . . . . . . . . . . . . . . . . 11 2.1. Presentation Description ..................................12
2.2. Session Establishment . . . . . . . . . . . . . . . . . . 12 2.2. Session Establishment .....................................12
2.3. Media Delivery Control . . . . . . . . . . . . . . . . . 13 2.3. Media Delivery Control ....................................14
2.4. Session Parameter Manipulations . . . . . . . . . . . . . 15 2.4. Session Parameter Manipulations ...........................15
2.5. Media Delivery . . . . . . . . . . . . . . . . . . . . . 16 2.5. Media Delivery ............................................16
2.5.1. Media Delivery Manipulations . . . . . . . . . . . . 16 2.5.1. Media Delivery Manipulations .......................16
2.6. Session Maintenance and Termination . . . . . . . . . . . 19 2.6. Session Maintenance and Termination .......................19
2.7. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 20 2.7. Extending RTSP ............................................20
3. Document Conventions . . . . . . . . . . . . . . . . . . . . 21 3. Document Conventions ...........................................21
3.1. Notational Conventions . . . . . . . . . . . . . . . . . 21 3.1. Notational Conventions ....................................21
3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 21 3.2. Terminology ...............................................21
4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 24 4. Protocol Parameters ............................................25
4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 24 4.1. RTSP Version ..............................................25
4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 25 4.2. RTSP IRI and URI ..........................................25
4.3. Session Identifiers . . . . . . . . . . . . . . . . . . . 27 4.3. Session Identifiers .......................................28
4.4. Media Time Formats . . . . . . . . . . . . . . . . . . . 27 4.4. Media-Time Formats ........................................28
4.4.1. SMPTE Relative Timestamps . . . . . . . . . . . . . . 28 4.4.1. SMPTE-Relative Timestamps ..........................28
4.4.2. Normal Play Time . . . . . . . . . . . . . . . . . . 28 4.4.2. Normal Play Time ...................................29
4.4.3. Absolute Time . . . . . . . . . . . . . . . . . . . . 30 4.4.3. Absolute Time ......................................30
4.5. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 30 4.5. Feature Tags ..............................................31
4.6. Message Body Tags . . . . . . . . . . . . . . . . . . . . 31 4.6. Message Body Tags .........................................32
4.7. Media Properties . . . . . . . . . . . . . . . . . . . . 31 4.7. Media Properties ..........................................32
4.7.1. Random Access and Seeking . . . . . . . . . . . . . . 32 4.7.1. Random Access and Seeking ..........................33
4.7.2. Retention . . . . . . . . . . . . . . . . . . . . . . 33 4.7.2. Retention ..........................................34
4.7.3. Content Modifications . . . . . . . . . . . . . . . . 33 4.7.3. Content Modifications ..............................34
4.7.4. Supported Scale Factors . . . . . . . . . . . . . . . 33 4.7.4. Supported Scale Factors ............................34
4.7.5. Mapping to the Attributes . . . . . . . . . . . . . . 34 4.7.5. Mapping to the Attributes ..........................35
5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 34 5. RTSP Message ...................................................35
5.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 34 5.1. Message Types .............................................36
5.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 35 5.2. Message Headers ...........................................36
5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 36 5.3. Message Body ..............................................37
5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 36 5.4. Message Length ............................................37
6. General Header Fields . . . . . . . . . . . . . . . . . . . . 36 6. General-Header Fields ..........................................37
7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 7. Request ........................................................39
7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 38 7.1. Request Line ..............................................40
7.2. Request Header Fields . . . . . . . . . . . . . . . . . . 40 7.2. Request-Header Fields .....................................42
8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 42 8. Response .......................................................43
8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 42 8.1. Status-Line ...............................................43
8.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 42 8.1.1. Status Code and Reason Phrase ......................43
8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 46 8.2. Response Headers ..........................................47
9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 46 9. Message Body ...................................................47
9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 47 9.1. Message Body Header Fields ................................48
9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 48 9.2. Message Body ..............................................49
9.3. Message Body Format Negotiation . . . . . . . . . . . . . 48 9.3. Message Body Format Negotiation ...........................49
10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 49 10. Connections ...................................................50
10.1. Reliability and Acknowledgements . . . . . . . . . . . . 49 10.1. Reliability and Acknowledgements .........................50
10.2. Using Connections . . . . . . . . . . . . . . . . . . . 50 10.2. Using Connections ........................................51
10.3. Closing Connections . . . . . . . . . . . . . . . . . . 53 10.3. Closing Connections ......................................54
10.4. Timing Out Connections and RTSP Messages . . . . . . . . 54 10.4. Timing Out Connections and RTSP Messages .................56
10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 55 10.5. Showing Liveness .........................................57
10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 57 10.6. Use of IPv6 ..............................................58
10.7. Overload Control . . . . . . . . . . . . . . . . . . . . 57 10.7. Overload Control .........................................58
11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 58 11. Capability Handling ...........................................60
11.1. Feature Tag: play.basic . . . . . . . . . . . . . . . . 60 11.1. Feature Tag: play.basic ..................................62
12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 61 12. Pipelining Support ............................................62
13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 61 13. Method Definitions ............................................63
13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 63 13.1. OPTIONS ..................................................65
13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 64 13.2. DESCRIBE .................................................66
13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 66 13.3. SETUP ....................................................68
13.3.1. Changing Transport Parameters . . . . . . . . . . . 69 13.3.1. Changing Transport Parameters .....................71
13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 70 13.4. PLAY .....................................................72
13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 70 13.4.1. General Usage .....................................72
13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 75 13.4.2. Aggregated Sessions ...............................77
13.4.3. Updating current PLAY Requests . . . . . . . . . . . 76 13.4.3. Updating Current PLAY Requests ....................78
13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 79 13.4.4. Playing On-Demand Media ...........................81
13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 79 13.4.5. Playing Dynamic On-Demand Media ...................81
13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 79 13.4.6. Playing Live Media ................................81
13.4.7. Playing Live with Recording . . . . . . . . . . . . 80 13.4.7. Playing Live with Recording .......................82
13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 81 13.4.8. Playing Live with Time-Shift ......................83
13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 81 13.5. PLAY_NOTIFY ..............................................83
13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 82 13.5.1. End-of-Stream .....................................84
13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 84 13.5.2. Media-Properties-Update ...........................86
13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 85 13.5.3. Scale-Change ......................................87
13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 86 13.6. PAUSE ....................................................89
13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 89 13.7. TEARDOWN .................................................92
13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 89 13.7.1. Client to Server ..................................92
13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 90 13.7.2. Server to Client ..................................93
13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 91 13.8. GET_PARAMETER ............................................94
13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 93 13.9. SET_PARAMETER ............................................96
13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 95 13.10. REDIRECT ................................................98
14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 97 14. Embedded (Interleaved) Binary Data ...........................101
15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 15. Proxies ......................................................103
15.1. Proxies and Protocol Extensions . . . . . . . . . . . . 101 15.1. Proxies and Protocol Extensions .........................104
15.2. Multiplexing and Demultiplexing of Messages . . . . . . 102 15.2. Multiplexing and Demultiplexing of Messages .............105
16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 16. Caching ......................................................106
16.1. Validation Model . . . . . . . . . . . . . . . . . . . 103 16.1. Validation Model ........................................107
16.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 104 16.1.1. Last-Modified Dates ..............................108
16.1.2. Message Body Tag Cache Validators . . . . . . . . . 104 16.1.2. Message Body Tag Cache Validators ................108
16.1.3. Weak and Strong Validators . . . . . . . . . . . . . 104 16.1.3. Weak and Strong Validators .......................108
16.1.4. Rules for When to Use Message Body Tags and Last- 16.1.4. Rules for When to Use Message Body Tags
Modified Dates . . . . . . . . . . . . . . . . . . . 107 and Last-Modified Dates ..........................110
16.1.5. Non-validating Conditionals . . . . . . . . . . . . 108 16.1.5. Non-validating Conditionals ......................112
16.2. Invalidation After Updates or Deletions . . . . . . . . 108 16.2. Invalidation after Updates or Deletions .................112
17. Status Code Definitions . . . . . . . . . . . . . . . . . . . 109 17. Status Code Definitions ......................................113
17.1. Informational 1xx . . . . . . . . . . . . . . . . . . . 109 17.1. Informational 1xx .......................................113
17.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 109 17.1.1. 100 Continue .....................................113
17.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 110 17.2. Success 2xx .............................................113
17.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 110 17.2.1. 200 OK ...........................................113
17.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 110 17.3. Redirection 3xx .........................................113
17.3.1. 300 . . . . . . . . . . . . . . . . . . . . . . . . 111 17.3.1. 300 ..............................................114
17.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 111 17.3.2. 301 Moved Permanently ............................114
17.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 111 17.3.3. 302 Found ........................................114
17.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 111 17.3.4. 303 See Other ....................................115
17.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 111 17.3.5. 304 Not Modified .................................115
17.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 112 17.3.6. 305 Use Proxy ....................................115
17.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 112 17.4. Client Error 4xx ........................................116
17.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 112 17.4.1. 400 Bad Request ..................................116
17.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 112 17.4.2. 401 Unauthorized .................................116
17.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 113 17.4.3. 402 Payment Required .............................116
17.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 113 17.4.4. 403 Forbidden ....................................116
17.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 113 17.4.5. 404 Not Found ....................................116
17.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 113 17.4.6. 405 Method Not Allowed ...........................117
17.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 113 17.4.7. 406 Not Acceptable ...............................117
17.4.8. 407 Proxy Authentication Required . . . . . . . . . 114 17.4.8. 407 Proxy Authentication Required ................117
17.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 114 17.4.9. 408 Request Timeout ..............................117
17.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 114 17.4.10. 410 Gone ........................................118
17.4.11. 411 Length Required . . . . . . . . . . . . . . . . 114 17.4.11. 412 Precondition Failed .........................118
17.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 114 17.4.12. 413 Request Message Body Too Large ..............118
17.4.13. 413 Request Message Body Too Large . . . . . . . . . 115 17.4.13. 414 Request-URI Too Long ........................118
17.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 115 17.4.14. 415 Unsupported Media Type ......................119
17.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 115 17.4.15. 451 Parameter Not Understood ....................119
17.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 115 17.4.16. 452 Illegal Conference Identifier ...............119
17.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 115 17.4.17. 453 Not Enough Bandwidth ........................119
17.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 116 17.4.18. 454 Session Not Found ...........................119
17.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 116 17.4.19. 455 Method Not Valid in This State ..............119
17.4.20. 455 Method Not Valid in This State . . . . . . . . . 116 17.4.20. 456 Header Field Not Valid for Resource .........119
17.4.21. 456 Header Field Not Valid for Resource . . . . . . 116 17.4.21. 457 Invalid Range ...............................120
17.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 116 17.4.22. 458 Parameter Is Read-Only ......................120
17.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 116 17.4.23. 459 Aggregate Operation Not Allowed .............120
17.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 116 17.4.24. 460 Only Aggregate Operation Allowed ............120
17.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 116 17.4.25. 461 Unsupported Transport .......................120
17.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 117 17.4.26. 462 Destination Unreachable .....................120
17.4.27. 462 Destination Unreachable . . . . . . . . . . . . 117 17.4.27. 463 Destination Prohibited ......................120
17.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 117 17.4.28. 464 Data Transport Not Ready Yet ................121
17.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 117 17.4.29. 465 Notification Reason Unknown .................121
17.4.30. 465 Notification Reason Unknown . . . . . . . . . . 117 17.4.30. 466 Key Management Error ........................121
17.4.31. 466 Key Management Error . . . . . . . . . . . . . . 117 17.4.31. 470 Connection Authorization Required ...........121
17.4.32. 470 Connection Authorization Required . . . . . . . 118 17.4.32. 471 Connection Credentials Not Accepted .........121
17.4.33. 471 Connection Credentials not accepted . . . . . . 118 17.4.33. 472 Failure to Establish Secure Connection ......121
17.4.34. 472 Failure to establish secure connection . . . . . 118 17.5. Server Error 5xx ........................................122
17.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 118 17.5.1. 500 Internal Server Error ........................122
17.5.1. 500 Internal Server Error . . . . . . . . . . . . . 118 17.5.2. 501 Not Implemented ..............................122
17.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 118 17.5.3. 502 Bad Gateway ..................................122
17.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 118 17.5.4. 503 Service Unavailable ..........................122
17.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 119 17.5.5. 504 Gateway Timeout ..............................123
17.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 119 17.5.6. 505 RTSP Version Not Supported ...................123
17.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 119 17.5.7. 551 Option Not Supported .........................123
17.5.7. 551 Option not supported . . . . . . . . . . . . . . 119 17.5.8. 553 Proxy Unavailable ............................123
17.5.8. 553 Proxy Unavailable . . . . . . . . . . . . . . . 119 18. Header Field Definitions .....................................124
18. Header Field Definitions . . . . . . . . . . . . . . . . . . 120 18.1. Accept ..................................................134
18.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 131 18.2. Accept-Credentials ......................................135
18.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 131 18.3. Accept-Encoding .........................................135
18.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 132 18.4. Accept-Language .........................................136
18.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 133 18.5. Accept-Ranges ...........................................137
18.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 134 18.6. Allow ...................................................138
18.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 134 18.7. Authentication-Info .....................................138
18.7. Authentication-Info . . . . . . . . . . . . . . . . . . 135 18.8. Authorization ...........................................138
18.8. Authorization . . . . . . . . . . . . . . . . . . . . . 135 18.9. Bandwidth ...............................................139
18.9. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 136 18.10. Blocksize ..............................................140
18.10. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 136 18.11. Cache-Control ..........................................140
18.11. Cache-Control . . . . . . . . . . . . . . . . . . . . . 137 18.12. Connection .............................................143
18.12. Connection . . . . . . . . . . . . . . . . . . . . . . . 139 18.13. Connection-Credentials .................................143
18.13. Connection-Credentials . . . . . . . . . . . . . . . . . 140 18.14. Content-Base ...........................................144
18.14. Content-Base . . . . . . . . . . . . . . . . . . . . . . 141 18.15. Content-Encoding .......................................145
18.15. Content-Encoding . . . . . . . . . . . . . . . . . . . . 141 18.16. Content-Language .......................................145
18.16. Content-Language . . . . . . . . . . . . . . . . . . . . 142 18.17. Content-Length .........................................146
18.17. Content-Length . . . . . . . . . . . . . . . . . . . . . 143 18.18. Content-Location .......................................146
18.18. Content-Location . . . . . . . . . . . . . . . . . . . . 143 18.19. Content-Type ...........................................148
18.19. Content-Type . . . . . . . . . . . . . . . . . . . . . . 144 18.20. CSeq ...................................................148
18.20. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 144 18.21. Date ...................................................150
18.21. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 146 18.22. Expires ................................................151
18.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 147 18.23. From ...................................................151
18.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 148 18.24. If-Match ...............................................152
18.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 148 18.25. If-Modified-Since ......................................152
18.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 149 18.26. If-None-Match ..........................................153
18.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 149 18.27. Last-Modified ..........................................154
18.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 150 18.28. Location ...............................................154
18.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 150 18.29. Media-Properties .......................................154
18.29. Media-Properties . . . . . . . . . . . . . . . . . . . . 151 18.30. Media-Range ............................................156
18.30. Media-Range . . . . . . . . . . . . . . . . . . . . . . 153 18.31. MTag ...................................................157
18.31. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 153 18.32. Notify-Reason ..........................................158
18.32. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 154 18.33. Pipelined-Requests .....................................158
18.33. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 154 18.34. Proxy-Authenticate .....................................159
18.34. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 155 18.35. Proxy-Authentication-Info ..............................159
18.35. Proxy-Authentication-Info . . . . . . . . . . . . . . . 155 18.36. Proxy-Authorization ....................................159
18.36. Proxy-Authorization . . . . . . . . . . . . . . . . . . 156 18.37. Proxy-Require ..........................................160
18.37. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 156 18.38. Proxy-Supported ........................................160
18.38. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 156 18.39. Public .................................................161
18.39. Public . . . . . . . . . . . . . . . . . . . . . . . . . 157 18.40. Range ..................................................162
18.40. Range . . . . . . . . . . . . . . . . . . . . . . . . . 158 18.41. Referrer ...............................................164
18.41. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 160 18.42. Request-Status .........................................164
18.42. Request-Status . . . . . . . . . . . . . . . . . . . . . 160 18.43. Require ................................................165
18.43. Require . . . . . . . . . . . . . . . . . . . . . . . . 161 18.44. Retry-After ............................................166
18.44. Retry-After . . . . . . . . . . . . . . . . . . . . . . 162 18.45. RTP-Info ...............................................167
18.45. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 162 18.46. Scale ..................................................169
18.46. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 164 18.47. Seek-Style .............................................170
18.47. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 165 18.48. Server .................................................171
18.48. Server . . . . . . . . . . . . . . . . . . . . . . . . . 167 18.49. Session ................................................172
18.49. Session . . . . . . . . . . . . . . . . . . . . . . . . 167 18.50. Speed ..................................................173
18.50. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 168 18.51. Supported ..............................................174
18.51. Supported . . . . . . . . . . . . . . . . . . . . . . . 169 18.52. Terminate-Reason .......................................175
18.52. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 170 18.53. Timestamp ..............................................175
18.53. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 170 18.54. Transport ..............................................176
18.54. Transport . . . . . . . . . . . . . . . . . . . . . . . 171 18.55. Unsupported ............................................183
18.55. Unsupported . . . . . . . . . . . . . . . . . . . . . . 178 18.56. User-Agent .............................................184
18.56. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 178 18.57. Via ....................................................184
18.57. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 179 18.58. WWW-Authenticate .......................................185
18.58. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 179
19. Security Framework . . . . . . . . . . . . . . . . . . . . . 180
19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 180
19.1.1. Digest Authentication . . . . . . . . . . . . . . . 181
19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 182
19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 183
19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 184
19.3.2. User approved TLS procedure . . . . . . . . . . . . 185
20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 187
20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 189
20.2.1. Generic Protocol elements . . . . . . . . . . . . . 190
20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 192
20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 196
20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 205
21. Security Considerations . . . . . . . . . . . . . . . . . . . 205
21.1. Signaling Protocol Threats . . . . . . . . . . . . . . . 206
21.2. Media Stream Delivery Threats . . . . . . . . . . . . . 209
21.2.1. Remote Denial of Service Attack . . . . . . . . . . 210
21.2.2. RTP Security analysis . . . . . . . . . . . . . . . 211
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 212
22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 213
22.1.1. Description . . . . . . . . . . . . . . . . . . . . 214
22.1.2. Registering New Feature-tags with IANA . . . . . . . 214
22.1.3. Registered entries . . . . . . . . . . . . . . . . . 214
22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 215
22.2.1. Description . . . . . . . . . . . . . . . . . . . . 215
22.2.2. Registering New Methods with IANA . . . . . . . . . 215
22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 216
22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 216
22.3.1. Description . . . . . . . . . . . . . . . . . . . . 216
22.3.2. Registering New Status Codes with IANA . . . . . . . 216
22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 217
22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 217
22.4.1. Description . . . . . . . . . . . . . . . . . . . . 217
22.4.2. Registering New Headers with IANA . . . . . . . . . 217
22.4.3. Registered entries . . . . . . . . . . . . . . . . . 217
22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 219
22.5.1. Accept-Credentials policies . . . . . . . . . . . . 219
22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 219
22.6. Cache-Control Cache Directive Extensions . . . . . . . . 220
22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 221
22.7.1. Description . . . . . . . . . . . . . . . . . . . . 221
22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 221
22.7.3. Registered Values . . . . . . . . . . . . . . . . . 221
22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 222
22.8.1. Description . . . . . . . . . . . . . . . . . . . . 222
22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 222
22.8.3. Registered Values . . . . . . . . . . . . . . . . . 222
22.9. Range Header Formats . . . . . . . . . . . . . . . . . . 223
22.9.1. Description . . . . . . . . . . . . . . . . . . . . 223
22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 223
22.9.3. Registered Values . . . . . . . . . . . . . . . . . 223
22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 223
22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . 224
22.10.2. Terminate-Reason Header Parameters . . . . . . . . 224
22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 225
22.11.1. Description . . . . . . . . . . . . . . . . . . . . 225
22.11.2. Registration Rules . . . . . . . . . . . . . . . . 225
22.11.3. Registered Values . . . . . . . . . . . . . . . . . 225
22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 225
22.12.1. Description . . . . . . . . . . . . . . . . . . . . 226
22.12.2. Registration Rules . . . . . . . . . . . . . . . . 226
22.12.3. Registered Values . . . . . . . . . . . . . . . . . 226
22.13. Transport Header Registries . . . . . . . . . . . . . . 227
22.13.1. Transport Protocol Identifier . . . . . . . . . . . 227
22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 228
22.13.3. Transport Parameters . . . . . . . . . . . . . . . 229
22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 230
22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 230
22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . 231
22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . 232
22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 233
22.16. Media Type Registration for text/parameters . . . . . . 234
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 235
23.1. Normative References . . . . . . . . . . . . . . . . . . 235
23.2. Informative References . . . . . . . . . . . . . . . . . 239
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 241
A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . . 241
A.2. Media on Demand using Pipelining . . . . . . . . . . . . 245
A.3. Secured Media Session for on Demand Content . . . . . . . 247
A.4. Media on Demand (Unicast) . . . . . . . . . . . . . . . . 250
A.5. Single Stream Container Files . . . . . . . . . . . . . . 254
A.6. Live Media Presentation Using Multicast . . . . . . . . . 256
A.7. Capability Negotiation . . . . . . . . . . . . . . . . . 257
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 258
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 259
B.2. State variables . . . . . . . . . . . . . . . . . . . . . 259
B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 259
B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 260
Appendix C. Media Transport Alternatives . . . . . . . . . . . . 264
C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . . 265
C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . . 265
C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 266
C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 267
C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 269
C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 269
C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 271 19. Security Framework ...........................................185
C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 271 19.1. RTSP and HTTP Authentication ............................185
C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 272 19.1.1. Digest Authentication ............................186
C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 276 19.2. RTSP over TLS ...........................................187
C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . . 280 19.3. Security and Proxies ....................................188
C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 282 19.3.1. Accept-Credentials ...............................189
C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 282 19.3.2. User-Approved TLS Procedure ......................190
C.7. Maintaining NPT synchronization with RTP timestamps . . . 282 20. Syntax .......................................................192
C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 282 20.1. Base Syntax .............................................193
C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 282 20.2. RTSP Protocol Definition ................................195
C.10. Usage of SSRCs and the RTCP BYE Message During an RTSP 20.2.1. Generic Protocol Elements ........................195
Session . . . . . . . . . . . . . . . . . . . . . . . . . 283 20.2.2. Message Syntax ...................................198
C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 283 20.2.3. Header Syntax ....................................201
Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 284 20.3. SDP Extension Syntax ....................................209
D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 284 21. Security Considerations ......................................209
D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . . 284 21.1. Signaling Protocol Threats ..............................210
D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . . 286 21.2. Media Stream Delivery Threats ...........................213
D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . . 286 21.2.1. Remote DoS Attack ................................215
D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 286 21.2.2. RTP Security Analysis ............................216
D.1.5. Directionality of media stream . . . . . . . . . . . 287 22. IANA Considerations ..........................................217
D.1.6. Range of Presentation . . . . . . . . . . . . . . . . 287 22.1. Feature Tags ............................................218
D.1.7. Time of Availability . . . . . . . . . . . . . . . . 288 22.1.1. Description ......................................218
D.1.8. Connection Information . . . . . . . . . . . . . . . 288 22.1.2. Registering New Feature Tags with IANA ...........218
D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 289 22.1.3. Registered Entries ...............................219
D.2. Aggregate Control Not Available . . . . . . . . . . . . . 289 22.2. RTSP Methods ............................................219
D.3. Aggregate Control Available . . . . . . . . . . . . . . . 290 22.2.1. Description ......................................219
D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 291 22.2.2. Registering New Methods with IANA ................219
D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 292 22.2.3. Registered Entries ...............................220
Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 292 22.3. RTSP Status Codes .......................................220
E.1. On-demand Playback of Stored Content . . . . . . . . . . 292 22.3.1. Description ......................................220
E.2. Unicast Distribution of Live Content . . . . . . . . . . 294 22.3.2. Registering New Status Codes with IANA ...........220
E.3. On-demand Playback using Multicast . . . . . . . . . . . 294 22.3.3. Registered Entries ...............................221
E.4. Inviting an RTSP server into a conference . . . . . . . . 295 22.4. RTSP Headers ............................................221
E.5. Live Content using Multicast . . . . . . . . . . . . . . 296 22.4.1. Description ......................................221
Appendix F. Text format for Parameters . . . . . . . . . . . . . 296 22.4.2. Registering New Headers with IANA ................221
Appendix G. Requirements for Unreliable Transport of RTSP . . . 297 22.4.3. Registered Entries ...............................222
Appendix H. Backwards Compatibility Considerations . . . . . . . 298 22.5. Accept-Credentials ......................................223
H.1. Play Request in Play State . . . . . . . . . . . . . . . 299 22.5.1. Accept-Credentials Policies ......................223
H.2. Using Persistent Connections . . . . . . . . . . . . . . 299 22.5.2. Accept-Credentials Hash Algorithms ...............224
Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 299 22.6. Cache-Control Cache Directive Extensions ................224
I.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 299 22.7. Media Properties ........................................225
I.2. Detailed List of Changes . . . . . . . . . . . . . . . . 300 22.7.1. Description ......................................225
Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 307 22.7.2. Registration Rules ...............................226
J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 308 22.7.3. Registered Values ................................226
Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 308 22.8. Notify-Reason Values ....................................226
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 308 22.8.1. Description ......................................226
22.8.2. Registration Rules ...............................226
22.8.3. Registered Values ................................227
22.9. Range Header Formats ....................................227
22.9.1. Description ......................................227
22.9.2. Registration Rules ...............................227
22.9.3. Registered Values ................................228
22.10. Terminate-Reason Header ................................228
22.10.1. Redirect Reasons ................................228
22.10.2. Terminate-Reason Header Parameters ..............229
22.11. RTP-Info Header Parameters .............................229
22.11.1. Description .....................................229
22.11.2. Registration Rules ..............................229
22.11.3. Registered Values ...............................230
22.12. Seek-Style Policies ....................................230
22.12.1. Description .....................................230
22.12.2. Registration Rules ..............................230
22.12.3. Registered Values ...............................230
22.13. Transport Header Registries ............................231
22.13.1. Transport Protocol Identifier ...................231
22.13.2. Transport Modes .................................233
22.13.3. Transport Parameters ............................233
22.14. URI Schemes ............................................234
22.14.1. The "rtsp" URI Scheme ...........................234
22.14.2. The "rtsps" URI Scheme ..........................235
22.14.3. The "rtspu" URI Scheme ..........................237
22.15. SDP Attributes .........................................238
22.16. Media Type Registration for text/parameters ............238
23. References ...................................................240
23.1. Normative References ....................................240
23.2. Informative References ..................................245
Appendix A. Examples .............................................248
A.1. Media on Demand (Unicast) ................................248
A.2. Media on Demand Using Pipelining .........................251
A.3. Secured Media Session for On-Demand Content ..............254
A.4. Media on Demand (Unicast) ................................257
A.5. Single-Stream Container Files ............................260
A.6. Live Media Presentation Using Multicast ..................263
A.7. Capability Negotiation ...................................264
Appendix B. RTSP Protocol State Machine ..........................265
B.1. States ...................................................266
B.2. State Variables ..........................................266
B.3. Abbreviations ............................................266
B.4. State Tables .............................................267
Appendix C. Media-Transport Alternatives .........................272
C.1. RTP ......................................................272
C.1.1. AVP ..................................................272
C.1.2. AVP/UDP ..............................................273
C.1.3. AVPF/UDP .............................................274
C.1.4. SAVP/UDP .............................................275
C.1.5. SAVPF/UDP ............................................277
C.1.6. RTCP Usage with RTSP .................................278
C.2. RTP over TCP .............................................279
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 ......................287
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 RTSP
Session .................................................290
C.11. Future Additions ........................................291
Appendix D. Use of SDP for RTSP Session Descriptions .............292
D.1. Definitions .............................................292
D.1.1. Control URI ..........................................292
D.1.2. Media Streams ........................................294
D.1.3. Payload Type(s) ......................................294
D.1.4. Format-Specific Parameters ...........................294
D.1.5. Directionality of Media Stream .......................295
D.1.6. Range of Presentation ................................295
D.1.7. Time of Availability .................................296
D.1.8. Connection Information ...............................297
D.1.9. Message Body Tag .....................................297
D.2. Aggregate Control Not Available ..........................298
D.3. Aggregate Control Available ..............................298
D.4. Grouping of Media Lines in SDP ...........................299
D.5. RTSP External SDP Delivery ...............................300
Appendix E. RTSP Use Cases .......................................300
E.1. On-Demand Playback of Stored Content .....................300
E.2. Unicast Distribution of Live Content .....................302
E.3. On-Demand Playback Using Multicast .......................303
E.4. Inviting an RTSP Server into a Conference ................303
E.5. Live Content Using Multicast .............................304
Appendix F. Text Format for Parameters ...........................305
Appendix G. Requirements for Unreliable Transport of RTSP ........305
Appendix H. Backwards-Compatibility Considerations ...............306
H.1. Play Request in Play State ...............................307
H.2. Using Persistent Connections .............................307
Appendix I. Changes ..............................................307
I.1. Brief Overview ...........................................308
I.2. Detailed List of Changes .................................309
Acknowledgements .................................................316
Contributors ....................................................317
Authors' Addresses ...............................................318
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-layer protocol for setup and (RTSP 2.0). RTSP 2.0 is an application-layer protocol for the setup
control over the delivery of data with real-time properties, and 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. "network remote control" for multimedia servers.
The protocol operates between RTSP 2.0 clients and servers, but also The protocol operates between RTSP 2.0 clients and servers, but it
supports the usage of proxies placed between clients and servers. also supports the use 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. The requested media can consist of multiple audio and completely. The requested media can consist of multiple audio and
video streams that are delivered as time-synchronized streams from video streams that are delivered as time-synchronized streams from
servers to clients. servers 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 this document
specification. This protocol is based on RTSP 1.0 but is not obsoletes that specification. This protocol is based on RTSP 1.0 but
backwards compatible other than in the basic version negotiation is not backwards compatible other than in the basic version
mechanism. The changes are documented in Appendix I. There are many negotiation mechanism. The changes between the two documents are
reasons why RTSP 2.0 can't be backwards compatible with RTSP 1.0 but listed in Appendix I. There are many reasons why RTSP 2.0 can't be
some of the main ones are: backwards compatible with RTSP 1.0; some of the main ones are as
follows:
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;
o The changed behavior of the PLAY method when received in Play o the changed behavior of the PLAY method when received in Play
state; state;
o Changed behavior of the extensibility model and its mechanism; o the changed behavior of the extensibility model and its mechanism;
and
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 There are so many small updates that changing versions became
became necessary to enable clarification and consistent behavior. necessary to enable clarification and consistent behavior. Anyone
Anyone implementing RTSP for a new usage where they have no installed implementing RTSP for a new use case in which they have not installed
based of RTSP 1.0 should only implement RTSP 2.0 to avoid having to RTSP 1.0 should only implement RTSP 2.0 to avoid having to deal with
deal with RTSP 1.0 inconsistencies. RTSP 1.0 inconsistencies.
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 terms used 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. These are followed by the actual RTSP 2.0 core protocol
specification. The appendixes describe and define some specification. The appendices 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, the Session Description Protocol usage is defined in Appendix C, the Session Description Protocol
(SDP) usage with RTSP is defined in Appendix D, and the text/ (SDP) usage with RTSP is defined in Appendix D, and the "text/
parameters file format Appendix F, are three normative specification parameters" file format Appendix F, are three normative specification
appendixes. Others include a number of informational parts appendices. Other appendices include a number of informational parts
discussing the changes, use cases, different considerations or discussing the changes, use cases, different considerations or
motivations. 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 specific 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 use cases sections take precedence. For more information about use cases
considered 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 bidirectional 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. The resource is identified by a URI and the resource on which to act. The resource is identified by a URI and
hostname part of the URI is used by RTSP client to resolve the IPv4 the hostname part of the URI is used by RTSP client to resolve the
or IPv6 address of the RTSP server. Following the method line are a IPv4 or IPv6 address of the RTSP server. Following the method line
number of RTSP headers. This part is ended by two consecutive are a number of RTSP headers. These lines are ended by two
carriage return line feed (CRLF) character pairs. The message body consecutive carriage return line feed (CRLF) character pairs. The
if present follows the two CRLF and the body's length is described by message body, if present, follows the two CRLF character pairs, and
a message header. RTSP responses are similar, but start with a the body's length is described by a message header. RTSP responses
response line with the protocol and version, followed by a status are similar, but they start with a response line with the protocol
code and a reason phrase. RTSP messages are sent over a reliable and version followed by a status code and a reason phrase. RTSP
transport protocol between the client and server. RTSP 2.0 requires messages are sent over a reliable transport protocol between the
clients and servers to implement TCP, and TLS over TCP, as mandatory client and server. RTSP 2.0 requires clients and servers to
transports for RTSP messages. 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 multimedia presentations and content
content, but tries to be agnostic about the media type or the actual but tries to be agnostic about the media type or the actual media
media delivery protocol that is used. To enable a client to delivery protocol that is used. To enable a client to implement a
implement a complete system, an RTSP-external mechanism for complete system, an RTSP-external mechanism for describing the
describing the presentation and the delivery protocol(s) is used. presentation and the delivery protocol(s) is used. RTSP assumes that
RTSP assumes that this description is either delivered completely out this description is either delivered completely out of band or as a
of band or as a data object in the response to a client's request data object in the response to a client's request using the DESCRIBE
using the DESCRIBE method (Section 13.2). 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 The 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 will be used to deliver each media stream;
o Transport protocol parameters that are not negotiated or vary with o the transport protocol parameters that are not negotiated or vary
each client; with each client;
o Media encoding information enabling a client to correctly decode o the media-encoding information enabling a client to correctly
the media upon reception; decode the media upon reception; and
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 (See Section 4.2). 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 describing the presentation.
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, which media delivery protocol is used media streams are available, which media delivery protocol is used,
and the resource identifiers of the media streams. The RTSP session and the resource identifiers of the media streams. 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 "Transport" header SETUP method (Section 13.3) to the server. In the Transport header
(Section 18.54) of the SETUP request, the client also includes all (Section 18.54) of the SETUP request, the client also includes all
the transport parameters necessary to enable the media delivery the transport parameters necessary to enable the media delivery
protocol to function. This includes parameters that are pre- protocol to function. This includes parameters that are
established by the presentation description but necessary for any preestablished by the presentation description but necessary for any
middlebox to correctly handle the media delivery protocols. The middlebox to correctly handle the media delivery protocols. The
Transport header in a request may contain multiple alternatives for Transport header in a request may contain multiple alternatives for
media delivery in a prioritized list, which the server can select media delivery in a prioritized list, which the server can select
from. These alternatives are typically based on information in the from. These alternatives are typically based on information in the
presentation description. presentation description.
The server determines if the media resource is available upon When receiving a SETUP request, the server determines if the media
receiving a SETUP request and if any of the transport parameter resource is available and if one or more of the of the transport
specifications are acceptable. If that is successful, an RTSP parameter specifications are acceptable. If that is successful, an
session context is created and the relevant parameters and state is RTSP session context is created and the relevant parameters and state
stored. An identifier is created for the RTSP session and included is stored. An identifier is created for the RTSP session and
in the response in the Session header (Section 18.49). The SETUP included in the response in the Session header (Section 18.49). The
response includes a Transport header that specifies which of the SETUP response includes a Transport header that specifies which of
alternatives has been selected and relevant parameters. the 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 multimedia
content. However, aggregating resources from different content are content container. However, a server will likely refuse to aggregate
likely to be refused by the server. Even if a RTSP session contains resources from different content containers. Even if an RTSP session
only a single media, the RTSP session can be referenced by the contains only a single media stream, the RTSP session can be
aggregate control URI. referenced by the aggregate control URI.
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 a client- first for the completion of any of them. The client uses a client-
selected identifier in the Pipelined-Requests header (Section 18.33) selected identifier in the Pipelined-Requests header (Section 18.33)
to instruct the server to bind multiple requests together as if they to instruct the server to bind multiple requests together as if they
included the 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 (Section 18.29) includes a number of properties Properties header (Section 18.29) includes a number of properties
that apply for the aggregate that is valuable when doing media that apply for the aggregate that is valuable when doing media
delivery control and configuring user interface. The Accept-Ranges delivery control and configuring user interface. The Accept-Ranges
header (Section 18.5) informs the client about which range formats header (Section 18.5) informs the client about range formats that the
that the server supports with these media resources. The Media-Range server supports for these media resources. The Media-Range header
header (Section 18.30) informs the client about the time range of the (Section 18.30) informs the client about the time range of the media
media currently available. 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 "begin
using the PLAY method (Section 13.4) and Halt by using the PAUSE playback", using the PLAY method (Section 13.4) and "suspend (pause)
method (Section 13.6). PLAY also allows for choosing the starting playback" by using the PAUSE method (Section 13.6). PLAY also allows
media position from which the server should deliver the media. The for choosing the starting media position from which the server should
positioning is done by using the Range header (Section 18.40) that deliver the media. The positioning is done by using the Range header
supports several different time formats: Normal Play Time (NPT) (Section 18.40) that supports several different time formats: Normal
(Section 4.4.2), Society of Motion Picture and Television Engineers Play Time (NPT) (Section 4.4.2), Society of Motion Picture and
(SMPTE) Timestamps (Section 4.4.1) and absolute time (Section 4.4.3). Television Engineers (SMPTE) Timestamps (Section 4.4.1), and absolute
The Range header does further allow the client to specify a position time (Section 4.4.3). The Range header also allows the client to
where delivery should end, thus allowing a specific interval to be specify a position where delivery should end, thus allowing a
delivered. specific interval to be delivered.
The support for positioning/searching within a media content depends The support for positioning/searching within media content depends on
on the content's media properties. Content exists in a number of the content's media properties. Content exists in a number of
different types, such as: on-demand, live, and live with simultaneous different 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
the content is generated and distributed, which affect how it can be how the content is generated and distributed, which affect how it can
accessed for playback. The properties applicable for the RTSP be 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.29). 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 indicates whether positioning is possible, and with
granularity. Another aspect is whether the content will change what 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 a protocol other 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 the complete content is not
maintained, but, for example, only the last hour. All these maintained, but, for example, only the last hour. All of these
properties result in the need for mechanisms that will be discussed properties result in the need for mechanisms that will be discussed
below. below.
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 (Section 13.5) 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. Because the recording is
the content grows in direct relation to the passed time. Therefore, ongoing, the content grows in direct relation to the time passed.
each server's response to a PLAY request will contain the current Therefore, each server's response to a PLAY request will contain the
Media-Range header. The server should also regularly send current Media-Range header. The server should also regularly send
approximately every 5 minutes the current media range in a (approximately every 5 minutes) the current media range in a
PLAY_NOTIFY request (Section 13.5.2). If the live transmission ends, PLAY_NOTIFY request (Section 13.5.2). If the live transmission ends,
the server must send a PLAY_NOTIFY request with the updated Media- the server must send a PLAY_NOTIFY request with the updated Media-
Properties indicating that the content stopped being a recorded live Properties indicating that the content stopped being a recorded live
session and instead became on-demand content; the request also session and instead became on-demand content; the request also
contains the final media range. While the live delivery continues contains the final media range. While the live delivery continues,
the client can request to play the current live point by using the the client can request to play the current live point by using the
NPT timescale symbol "now", or it can request a specific point in the NPT timescale symbol "now", or it can request a specific point in the
available content by an explicit range request for that point. If available content by an explicit range request for that point. If
the requested point is outside of the available interval the server the requested point is outside of the available interval, the server
will adjust the position to the closest available point, i.e., either will adjust the position to the closest available point, i.e., either
at the beginning or the end. 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 available. In this case, the pause point will be adjusted to the
closest point in 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 or 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 they may be covered in various
RTSP has two methods for retrieving and setting parameter values on extensions. RTSP has two methods for retrieving and setting
either the client or the server: GET_PARAMETER (Section 13.8) and parameter values on either the client or the server: GET_PARAMETER
SET_PARAMETER (Section 13.9). These methods carry the parameters in (Section 13.8) and SET_PARAMETER (Section 13.9). These methods carry
a message body of the appropriate format. One can also use headers the parameters in a message body of the appropriate format. One can
to query state with the GET_PARAMETER method. As an example, clients also use headers to query state with the GET_PARAMETER method. As an
needing to know the current media-range for a time-progressing example, clients needing to know the current media range for a time-
session can use the GET_PARAMETER method and include the media-range. progressing session can use the GET_PARAMETER method and include the
Furthermore, synchronization information can be requested by using a media range. Furthermore, synchronization information can be
combination of RTP-Info (Section 18.45) and Range (Section 18.40). requested by using a combination of RTP-Info (Section 18.45) and
Range (Section 18.40).
RTSP 2.0 does not have a strong mechanism for providing negotiation
of the headers, or parameters and their formats, that can be used.
However, responses will indicate request-headers or parameters that RTSP 2.0 does not have a strong mechanism for negotiating the headers
are not supported. A priori determination of what features are or parameters and their formats. However, responses will indicate
available needs to be done through out-of-band mechanisms, like the request-headers or parameters that are not supported. A priori
session description, or through the usage of feature tags determination of what features are available needs to be done through
(Section 4.5). out-of-band mechanisms, like the session description, or through the
usage of feature tags (Section 4.5).
2.5. Media Delivery 2.5. Media Delivery
This document specifies how media is delivered with RTP [RFC3550] This document specifies how media is delivered with RTP [RFC3550]
over UDP [RFC0768], TCP [RFC0793] or the RTSP connection. Additional over UDP [RFC768], TCP [RFC793], or the RTSP connection. Additional
protocols may be specified in the future based on demand. protocols may be specified in the future as needed.
The usage of RTP as media delivery protocol requires some additional The usage of RTP as a media delivery protocol requires some
information to function well. The PLAY response contains information additional information to function well. The PLAY response contains
to enable reliable and timely delivery of how a client should information to enable reliable and timely delivery of how a client
synchronize different sources in the different RTP sessions. It also should synchronize different sources in the different RTP sessions.
provides a mapping between RTP timestamps and the content time scale. It also provides a mapping between RTP timestamps and the content-
When the server wants to notify the client about the completion of time scale. When the server wants to notify the client about the
the media delivery, it sends a PLAY_NOTIFY request to the client. completion of the media delivery, it sends a PLAY_NOTIFY request to
The PLAY_NOTIFY request includes information about the stream end, the client. The PLAY_NOTIFY request includes information about the
including the last RTP sequence number for each stream, thus enabling stream end, including the last RTP sequence number for each stream,
the client to empty the buffer smoothly. thus enabling the client to empty the buffer smoothly.
2.5.1. Media Delivery Manipulations 2.5.1. Media Delivery Manipulations
The basic playback functionality of RTSP enables delivery of a range The basic playback functionality of RTSP enables delivery of a range
of requested content to the client at the pace intended by the of requested content to the client at the pace intended by the
content's creator. However, RTSP can also manipulate the delivery to content's creator. However, RTSP can also manipulate the delivery to
the client in two ways. the client in two ways.
Scale: The ratio of media content time delivered per unit playback Scale: The ratio of media-content time delivered per unit of
time. playback 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 timescales and the effects are possible to
to combine. combine.
Scale (Section 18.46) is used for fast forward or slow motion control Scale (Section 18.46) is used for fast-forward or slow-motion control
as it changes the amount of content timescale that should be played as it changes the amount of content timescale that should be played
back per time unit. Scale > 1.0, means fast forward, e.g., Scale=2.0 back per time unit. Scale > 1.0, means fast forward, e.g., scale =
results in that 2 seconds of content is played back every second of 2.0 results in that 2 seconds of content being played back every
playback. Scale = 1.0 is the default value that is used if no Scale second of playback. Scale = 1.0 is the default value that is used if
is specified, i.e., playback at the content's original rate. Scale no scale is specified, i.e., playback at the content's original rate.
values between 0 and 1.0 is providing for slow motion. Scale can be Scale values between 0 and 1.0 provide 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
= -1.0) or fast backwards (Scale < -1.0) or slow motion backwards (scale = -1.0), fast backwards (scale < -1.0), or slow-motion
(-1.0 < Scale < 0). Scale = 0 would be equal to pause and is not backwards (-1.0 < scale < 0). Scale = 0 would be equal to pause and
allowed. is not allowed.
In most cases the realization of scale means server side manipulation In most cases, the realization of scale means server-side
of the media to ensure that the client can actually play it back. manipulation of the media to ensure that the client can actually play
The nature of these media manipulations and when they are needed is it back. The nature of these media manipulations and when they are
highly media-type dependent. Let's consider an example with two needed is highly media-type dependent. Let's consider two common
common media types audio and video. 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.
of 10-30% is possible by changing the pitch-rate of speech. Music Typically, no more than a factor of two is possible while maintaining
goes out of tune if one tries to manipulate the playback rate by intelligibility by changing the pitch and rate of speech. Music goes
resampling it. This is a well known problem and audio is commonly out of tune if one tries to manipulate the playback rate by
resampling it. This is a well-known problem, and audio is commonly
muted or played back in short segments with skips to keep up with the 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.
Also the allowed bitrates in decoding, the structure used in the Also, the allowed bitrates in decoding, the structure used in the
encoding and the dependency between frames and other capabilities of encoding, and the dependency between frames and other capabilities of
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 scale factor currently in use, updating the media properties and the scale factor currently in use,
exists. exists.
Speed (Section 18.50) affects how much of the playback timeline is Speed (Section 18.50) affects how much of the playback timeline is
delivered in a given wallclock period. The default is Speed = 1 delivered in a given wallclock period. The default is Speed = 1
which means to deliver at the same rate the media is consumed. Speed which means to deliver at the same rate the media is consumed.
> 1 means that the receiver will get content faster than it regularly Speed > 1 means that the receiver will get content faster than it
would consume it. Speed < 1 means that delivery is slower than the regularly would consume it. Speed < 1 means that delivery is slower
regular media rate. Speed values of 0 or lower have no meaning and than the regular media rate. Speed values of 0 or lower have no
are not allowed. This mechanism enables two general functionalities. meaning and are not allowed. This mechanism enables two general
One is client side scale operations, i.e., the client receives all functionalities. One is client-side scale operations, i.e., the
the frames and makes the adjustment to the playback locally. The client receives all the frames and makes the adjustment to the
second is delivery control for buffering of media. By specifying a playback locally. The second is delivery control for the buffering
speed over 1.0 the client can build up the amount of playback time it of media. By specifying a speed over 1.0, the client can build up
has present in its buffers to a level that is sufficient for its the amount of playback time it has present in its buffers to a level
needs. 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. Whether or not
supported or not depends solely on the underlying network path. that can be supported depends solely on the underlying network path.
Scale may also have some impact on the required bandwidth due to the Scale may also have some impact on the required bandwidth due to the
manipulation of the content in the new playback schedule. An example manipulation of the content in the new playback schedule. An example
is fast forward where only the independently decodable intra frames is fast forward where only the independently decodable intra-frames
are included in the media stream. This usage of solely intra frames are included in the media stream. This usage of solely intra-frames
increases the data rate significantly compared to a normal sequence increases the data rate significantly compared to a normal sequence
with the same number of frames, where most frames are encoded using with the same number of frames, where most frames are encoded using
prediction. prediction.
This potential increase of the data rate needs to be handled by the This potential increase of the data rate needs to be handled by the
media sender. The client has requested that the media will be media sender. The client has requested that the media be delivered
delivered in a specific way, which should be honored. However, the in a specific way, which should be honored. However, the media
media sender cannot ignore if the network path between the sender and sender cannot ignore if the network path between the sender and the
the receiver can't handle the resulting media stream. In that case receiver can't handle the resulting media stream. In that case, the
the media stream needs to be adapted to fit the available resources media stream needs to be adapted to fit the available resources of
of the path. This can result in a reduced media quality. the path. This can result in a reduced media quality.
The need for bitrate adaptation becomes especially problematic in The need for bitrate adaptation becomes especially problematic in
connection with the Speed semantics. If the goal is to fill up the connection with the Speed semantics. If the goal is to fill up the
buffer, the client may not want to do that at the cost of reduced buffer, the client may not want to do that at the cost of reduced
quality. If the client wants to make local playout changes then it quality. If the client wants to make local playout changes, then it
may actually require that the requested speed be honored. To resolve may actually require that the requested speed be honored. To resolve
this issue, Speed uses a range so that both cases can be supported. this issue, Speed uses a range so that both cases can be supported.
The server is requested to use the highest possible speed value The server is requested to use the highest possible speed value
within the range which is compatible with the available bandwidth. within the range, which is compatible with the available bandwidth.
As long as the server can maintain a speed value within the range it As long as the server can maintain a speed value within the range, it
shall not change the media quality, but instead modify the actual shall not change the media quality, but instead modify the actual
delivery rate in response to available bandwidth and reflect this in delivery rate in response to available bandwidth and reflect this in
the Speed value in the response. However, if this is not possible, the Speed value in the response. However, if this is not possible,
the server should instead modify the media quality to respect the the server should instead modify the media quality to respect the
lowest speed value and the available bandwidth. lowest speed value and the available bandwidth.
This functionality enables the local scaling implementation to use a This functionality enables the local scaling implementation to use a
tight range, or even a range where the lower bound equals the upper tight range, or even a range where the lower bound equals the upper
bound, to identify that it requires the server to deliver the bound, to identify that it requires the server to deliver the
requested amount of media time per delivery time independent of how requested amount of media time per delivery time, independent of how
much it needs to adapt the media quality to fit within the available much it needs to adapt the media quality to fit within the available
path bandwidth. For buffer filling, it is suitable to use a range path bandwidth. For buffer filling, it is suitable to use a range
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. RTP Control Protocol (RTCP) o Media-transport protocol keep-alive. RTP Control Protocol (RTCP)
may be used when using 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 (Section 13.7) to the server referencing the TEARDOWN request (Section 13.7) to the server referencing the
aggregated control URI. An individual media resource can be removed aggregated control URI. An individual media resource can be removed
from a session context by a TEARDOWN request referencing that from a session context by a TEARDOWN request referencing that
particular media resource. If all media resources are removed from a particular media resource. If all media resources are removed from a
session context, 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, a client is recommended to release the session server; however, a client is advised to release the session context
context when an extended period of time without media delivery when an extended period of time without media delivery activity has
activity has passed. The client can re-establish the session context passed. The client can re-establish the session context if required
if required later. What constitutes an extended period of time is later. What constitutes an extended period of time is dependent on
dependent on the client, server and their usage. It is recommended the client, server, and their usage. It is recommended that the
that the client terminates the session before ten times the session client terminate the session before ten times the session timeout
timeout value has passed. A server may terminate the session after value has passed. A server may terminate the session after one
one session timeout period without any client activity beyond keep- session timeout period without any client activity beyond keep-alive.
alive. When a server terminates the session context, it does that by When a server terminates the session context, it does so by sending a
sending a TEARDOWN request indicating the reason. TEARDOWN 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 maintenance. This is done by using the REDIRECT method
(Section 13.10). The Terminate-Reason header (Section 18.52) is used (Section 13.10). The Terminate-Reason header (Section 18.52) is used
to indicate when and why. The Location header indicates where it to indicate when and why. The Location header indicates where it
should connect if there is an alternative server available. When the should connect if there is an alternative server available. When the
deadline expires, the server simply stops providing the service. To deadline expires, the server simply stops providing the service. To
achieve a clean closure, the client needs to initiate session achieve a clean closure, the client needs to initiate session
termination prior to the deadline. In case the server has no other termination prior to the deadline. In case the server has no other
server to redirect to, and wants to close the session for server to redirect to, and it wants to close the session for
maintenance, it shall use the TEARDOWN method with a Terminate-Reason maintenance, it shall use the TEARDOWN method with a Terminate-Reason
header. 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 that 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 address additional use cases. However, extensions will affect the
the interoperability of the protocol and therefore it is important interoperability of the protocol; therefore, it is important that
that they can be added in a structured way. 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.51). 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 (Section 18.43) particular features be supported using the Require (Section 18.43) or
or Proxy-Require (Section 18.37) header. Proxy-Require (Section 18.37) header.
The RTSP protocol in itself can be extended in three ways, listed The RTSP, in itself, can be extended in three ways, listed here in
here in increasing order of the magnitude of changes supported: 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. 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 standards track document. a 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.
3. Document Conventions 3. Document Conventions
3.1. Notational Conventions 3.1. Notational Conventions
Since a few of the definitions are identical to HTTP/1.1, this
specification only points to the section where they are defined
rather than copying it. For brevity, [HX.Y] is to be taken to refer
to Section X.Y of the 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 paragraphs are used to provide informative background and Indented paragraphs are used to provide informative background and
motivation. This is intended to give readers who were not involved motivation. This is intended to give readers who were not involved
with the formulation of the specification an understanding of why with the formulation of the specification an 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",
skipping to change at page 21, line 36 skipping to change at page 21, line 46
[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.
3.2. Terminology 3.2. Terminology
Aggregate control: The concept of controlling multiple streams using Aggregate control: The concept of controlling multiple streams using
a single timeline, generally maintained by the server. A client, a single timeline, generally one maintained by the server. A
for example, uses aggregate control when it issues a single play client, for example, uses aggregate control when it issues a
or pause message to simultaneously control both the audio and single play or pause message to simultaneously control both the
video in a movie. A session which is under aggregate control is audio and video in a movie. A session that is under aggregate
referred to as an aggregated session. control is referred to as an "aggregated session".
Aggregate control URI: The URI used in an RTSP request to refer to Aggregate control URI: The URI used in an RTSP request to refer to
and control an aggregated session. It normally, but not always, and control an aggregated session. It normally, but not always,
corresponds to the presentation URI specified in the session corresponds to the presentation URI specified in the session
description. See Section 13.3 for more information. description. See Section 13.3 for more information.
Client: The client requests media service from the media server. Client: The client is the requester of media service from the media
server.
Connection: A transport layer virtual circuit established between Connection: A transport-layer virtual circuit established between
two programs for the purpose of communication. two programs for the purpose of communication.
Container file: A file which may contain multiple media streams Container file: A file that may contain multiple media streams that
which often constitutes a presentation when played together. The often constitute a presentation when played together. The concept
concept of a container file is not embedded in the protocol. of a container file is not embedded in the protocol. However,
However, RTSP servers may offer aggregate control on the media RTSP servers may offer aggregate control on the media streams
streams within these files. 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 it can be
where the relationship is less strict. streaming where the relationship is less strict.
Feature-tag: A tag representing a certain set of functionality, Feature tag: A tag representing a certain set of functionality,
i.e., a feature. i.e., a feature.
IRI: Internationalized Resource Identifier, is similar to a URI, but IRI: An Internationalized Resource Identifier is similar to a URI
allows characters from the whole Universal Character Set (Unicode/ but allows characters from the whole Universal Character Set
ISO 10646), rather than the US-ASCII only. See [RFC3987] for more (Unicode/ISO 10646), rather than the US-ASCII only. See [RFC3987]
information. for more information.
Live: Normally used to describe a presentation or session with media Live: A live presentation or session originates media from an event
coming from an ongoing event. This generally results in the taking place at the same time as the media delivery. Live
session having an unbound or only loosely defined duration, and sessions often have an unbound or only loosely defined duration
sometimes no seek operations are possible. and seek operations may not be possible.
Media initialization: Datatype/codec specific initialization. This Media initialization: The datatype- or codec-specific
includes such things as clock rates, color tables, etc. Any initialization. This includes such things as clock rates, color
transport-independent information which is required by a client tables, etc. Any transport-independent information that is
for playback of a media stream occurs in the media initialization required by a client for playback of a media stream occurs in the
phase of stream setup. media initialization phase of stream setup.
Media parameter: Parameter specific to a media type that may be Media parameter: A parameter specific to a media type that may be
changed before or during stream delivery. changed before or during stream delivery.
Media server: The server providing media delivery services for one Media server: The server providing media-delivery services for one
or more media streams. Different media streams within a or more media streams. Different media streams within a
presentation may originate from different media servers. A media presentation may originate from different media servers. A media
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 media 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-based transport. A Section 20 and transmitted over a transport between RTSP agents.
message is either a Request or a Response. A message is either a request or a response.
Message Body: The information transferred as the payload of a Message body: The information transferred as the payload of a
message (Request 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 an arbitrary number of data octets, as described in
Section 9.
Non-Aggregated Control: Control of a single media stream. Non-aggregated control: Control of a single media stream.
Presentation: A set of one or more streams presented to the client Presentation: A set of one or more streams presented to the client
as a complete media feed and described by a presentation as a complete media feed and described by a presentation
description as defined below. Presentations with more than one description as defined below. Presentations with more than one
media stream are often handled in RTSP under aggregate control. media stream are often handled in RTSP under aggregate control.
Presentation description: A presentation description contains Presentation description: A presentation description contains
information about one or more media streams within a presentation, information about one or more media streams within a presentation,
such as the set of encodings, network addresses and information such as the set of encodings, network addresses, and information
about the content. Other IETF protocols such as SDP ([RFC4566]) about the content. Other IETF protocols, such as SDP ([RFC4566]),
use the term "session" for a presentation. The presentation use the term "session" for a presentation. The presentation
description may take several different formats, including but not description may take several different formats, including but not
limited to the session description protocol format, SDP. limited to SDP format.
Response: An RTSP response to a Request. One type of RTSP message. Response: An RTSP response to a request. One type of RTSP message.
If an HTTP response is meant, it is indicated explicitly. If an HTTP response is meant, it is indicated explicitly.
Request: An RTSP request. One type of RTSP message. If an HTTP Request: An RTSP request. One type of RTSP message. If an HTTP
request is meant, it is indicated explicitly. request is meant, it is indicated explicitly.
Request-URI: The URI used in a request to indicate the resource on Request-URI: The URI used in a request to indicate the resource on
which the request is to be performed. which the request is to be performed.
RTSP agent: Refers to either an RTSP client, an RTSP server, or an RTSP agent: Either an RTSP client, an RTSP server, or an RTSP proxy.
RTSP proxy. In this specification, there are many capabilities In this specification, there are many capabilities that are common
that are common to these three entities such as the capability to to these three entities such as the capability to send requests or
send requests or receive responses. This term will be used when receive responses. This term will be used when describing
describing functionality that is applicable to all three of these functionality that is applicable to all three of these entities.
entities.
RTSP session: A stateful abstraction upon which the main control RTSP session: A stateful abstraction upon which the main control
methods of RTSP operate. An RTSP session is a common context; it methods of RTSP operate. An RTSP session is a common context; it
is created and maintained on client's request and can be destroyed is created and maintained on a client's request and can be
by either the client or server. It is established by an RTSP destroyed by either the client or server. It is established by an
server upon the completion of a successful SETUP request (when a RTSP server upon the completion of a successful SETUP request
200 OK response is sent) and is labeled with a session identifier (when a 200 OK response is sent) and is labeled with a session
at that time. The session exists until timed out by the server or identifier at that time. The session exists until timed out by
explicitly removed by a TEARDOWN request. An RTSP session is a the server or explicitly removed by a TEARDOWN request. An RTSP
stateful entity; an RTSP server maintains an explicit session session is a stateful entity; an RTSP server maintains an explicit
state machine (see Appendix B) where most state transitions are session state machine (see Appendix B) where most state
triggered by client requests. The existence of a session implies transitions are triggered by client requests. The existence of a
the existence of state about the session's media streams and their session implies the existence of state about the session's media
respective transport mechanisms. A given session can have one or streams and their respective transport mechanisms. A given
more media streams associated with it. An RTSP server uses the session can have one or more media streams associated with it. An
session to aggregate control over multiple media streams. RTSP server uses the session to aggregate control over multiple
media streams.
Origin Server: The server on which a given resource resides. Origin server: The server on which a given resource resides.
Seeking: Requesting playback from a particular point in the content
time line.
Transport initialization: The negotiation of transport information Transport initialization: The negotiation of transport information
(e.g., port numbers, transport protocols) between the client and (e.g., port numbers, transport protocols) between the client and
the server. the server.
URI: Universal Resource Identifier, see [RFC3986]. The URIs used in URI: A Universal Resource Identifier; see [RFC3986]. The URIs used
RTSP are generally URLs as they give a location for the resource. in RTSP are generally URLs as they give a location for the
As URLs are a subset of URIs, they will be referred to as URIs to resource. As URLs are a subset of URIs, they will be referred to
cover also the cases when an RTSP URI would not be an URL. as URIs to cover also the cases when an RTSP URI would not be a
URL.
URL: Universal Resource Locator, is a URI which identifies the URL: A Universal Resource Locator is a URI that identifies the
resource through its primary access mechanism, rather than resource through its primary access mechanism rather than
identifying the resource by name or by some other attribute(s) of identifying the resource by name or by some other attribute(s) of
that resource. that resource.
4. Protocol Parameters 4. Protocol Parameters
4.1. RTSP Version 4.1. RTSP Version
This specification defines version 2.0 of RTSP. This specification defines version 2.0 of RTSP.
RTSP uses a "<major>.<minor>" numbering scheme to indicate versions RTSP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. The protocol versioning policy is intended to allow of the protocol. The protocol versioning policy is intended to allow
the sender to indicate the format of a message and its capacity for the sender to indicate the format of a message and its capacity for
understanding further RTSP communication, rather than the features understanding further RTSP communication rather than the features
obtained via that communication. No change is made to the version obtained via that communication. No change is made to the version
number for the addition of message components which do not affect number for the addition of message components that do not affect
communication behavior or which only add to extensible field values. communication behavior or that only add to extensible field values.
The <minor> number is incremented when the changes made to the The <minor> number is incremented when the changes made to the
protocol add features which do not change the general message parsing protocol add features that do not change the general message parsing
algorithm, but which may add to the message semantics and imply algorithm but that may add to the message semantics and imply
additional capabilities of the sender. The <major> number is additional capabilities of the sender. The <major> number is
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
Leading zeros SHALL NOT be sent and MUST be ignored by recipients. RTSP/12.3. Leading zeros SHALL NOT be sent and MUST be ignored by
recipients.
4.2. RTSP IRI and URI 4.2. RTSP IRI and URI
RTSP 2.0 defines and registers or updates three URI schemes "rtsp", RTSP 2.0 defines and registers or updates three URI schemes "rtsp",
"rtsps" and "rtspu". The usage of the last, "rtspu", is unspecified "rtsps", and "rtspu". The usage of the last, "rtspu", is unspecified
in RTSP 2.0, and is defined here to register the URI scheme that was 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 means (UDP
1.0). An RTSP server MUST respond with an error code indicating the in RTSP 1.0). An RTSP server MUST respond with an error code
"rtspu" scheme is not implemented (501) to a request that carries a indicating the "rtspu" scheme is not implemented (501) to a request
"rtspu" URI scheme. that carries a "rtspu" URI scheme.
The details of the syntax of "rtsp" and "rtsps" URIs has been changed The details of the syntax of "rtsp" and "rtsps" URIs have been
from RTSP 1.0. These changes are: changed from RTSP 1.0. These changes include the addition of:
o Support for IPV6 literal in host part and future IP literals o Support for an IPv6 literal in the host part and future IP
through RFC 3986 defined mechanism. literals through a mechanism defined in [RFC3986].
o A new relative format to use in the RTSP protocol elements that is o A new relative format to use in the RTSP elements that is not
not required to start with "/". required to start with "/".
Neither should have any significant impact on interoperability. If Neither should have any significant impact on interoperability. If
one is required to use IPv6 literals to reach an RTSP server, then IPv6 literals are needed in the RTSP URI, then that RTSP server must
that RTSP server must be IPv6 capable, and RTSP 1.0 is not a fully be IPv6 capable, and RTSP 1.0 is not a fully IPv6 capable protocol.
IPv6 capable protocol. If an RTSP 1.0 client attempts to process the If an RTSP 1.0 client attempts to process the URI, the URI will not
URI it will not match the allowed syntax and be considered invalid match the allowed syntax, it will be considered invalid, and
and processing will be stopped. This is clearly a failure to reach processing will be stopped. This is clearly a failure to reach the
the resource, however it is not a signification issue as RTSP 2.0 resource; however, it is not a signification issue as RTSP 2.0
support was needed anyway in both server and client. Thus failure 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 will only occur in a later step when there is an RTSP version
between client and server. The second change will only occur inside mismatch between client and server. The second change will only
RTSP message headers, as the request URI must be an absolute URI. occur inside RTSP message headers, as the Request-URI must be an
Thus such usages will only occur after an agent has accepted and absolute URI. Thus, such usages will only occur after an agent has
started processing RTSP 2.0 messages, and an RTSP 1.0 only agent will accepted and started processing RTSP 2.0 messages, and an agent using
not be required to parse such types of relative URIs. RTSP 1.0 only 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 RTSP IRIs [RFC3987]
that can be used as RTSP resource identifiers and locators, in web that can be used as RTSP resource identifiers and locators on 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 allows a URI that matches the URIs, as defined in [RFC3987]. This allows a URI that matches the
RTSP 2.0 specification, and so is suitable for use in a request, to RTSP 2.0 specification, and so is suitable for use in a request, to
be created from an RTSP IRI. 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 ";".
The "scheme" and "host" parts of all URIs [RFC3986] and IRIs The "scheme" and "host" parts of all URIs [RFC3986] and IRIs
[RFC3987] are case-insensitive. All other parts of RTSP URIs and [RFC3987] are case insensitive. All other parts of RTSP URIs and
IRIs are case- sensitive, and MUST NOT be case-mapped. IRIs are case sensitive, and they MUST NOT be case mapped.
The fragment identifier is used as defined in sections 3.5 and 4.3 of The fragment identifier is used as defined in Sections 3.5 and 4.3 of
[RFC3986], i.e., the fragment is to be stripped from the IRI by the [RFC3986], i.e., the fragment is to be stripped from the IRI by the
requester and not included in the request URI. The user agent needs requester and not included in the Request-URI. The user agent needs
to interpret the value of the fragment based on the media type the to interpret the value of the fragment based on the media type the
request relates to; i.e., the media type indicated in Content-Type request relates to; i.e., the media type indicated in Content-Type
header in the response to DESCRIBE. header in the response to a DESCRIBE request.
The syntax of any URI query string is unspecified and responder The syntax of any URI query string is unspecified and responder
(usually the server) specific. The query is, from the requester's (usually the server) specific. The query is, from the requester's
perspective, an opaque string and needs to be handled as such. perspective, an opaque string and needs to be handled as such.
Please note that relative URI with queries are difficult to handle
due to the RFC 3986 relative URI handling rules. Any change of the Please note that relative URIs with queries are difficult to handle
path element using a relative URI results in the stripping of the due to the relative URI handling rules of RFC 3986. Any change of
the path element using a relative URI results in the stripping of the
query, which means the relative part needs to contain the query. 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 be issued via a reliable
reliable protocol (within the Internet, TCP), while the scheme protocol (within the Internet, TCP), while the scheme "rtsps"
"rtsps" identifies a reliable transport using secure transport (TLS 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, the port number 554 MUST be used. For the scheme part of the URI, the port number 554 MUST be used. For the scheme
"rtsps", if no port number is provided in the authority part of the "rtsps", if no port number is provided in the authority part of the
URI port number, the TCP port 322 MUST be used. 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
(Section 13) can apply to either the whole presentation or an can apply to either the whole presentation or an individual stream
individual stream within the presentation. Note that some request within the presentation. Note that some request methods can only be
methods can only be applied to streams, not presentations, and vice applied to streams, not presentations, and vice versa.
versa.
For example, the RTSP URI: For example, the RTSP URI:
rtsp://media.example.com:554/twister/audiotrack rtsp://media.example.com:554/twister/audiotrack
may identify the audio stream within the presentation "twister", may identify the audio stream within the presentation "twister",
which can be controlled via RTSP requests issued over a TCP which can be controlled via RTSP requests issued over a TCP
connection to port 554 of host media.example.com. connection to port 554 of host media.example.com.
Also, the RTSP URI: Also, the RTSP URI:
rtsp://media.example.com:554/twister rtsp://media.example.com:554/twister
identifies the presentation "twister", which may be composed of audio identifies the presentation "twister", which may be composed of audio
and video streams, but could also be something else like a random and video streams, but could also be something else, such as a random
media redirector. media redirector.
This does not imply a standard way to reference streams in URIs. This does not imply a standard way to reference streams in URIs.
The presentation description defines the hierarchical The presentation description defines the hierarchical
relationships in the presentation and the URIs for the individual relationships in the presentation and the URIs for the individual
streams. A presentation description may name a stream "a.mov" and streams. A presentation description may name a stream "a.mov" and
the whole presentation "b.mov". the whole presentation "b.mov".
The path components of the RTSP URI are opaque to the client and do The path components of the RTSP URI are opaque to the client and do
not imply any particular file system structure for the server. not imply any particular file system structure for the server.
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 a length between 8-128 characters.
session identifier MUST be generated cryptographically random (see A session identifier MUST be generated using methods that make it
[RFC4086]). It is RECOMMENDED that it contains 128 bits of entropy, cryptographically random (see [RFC4086]). It is RECOMMENDED that a
i.e., approximately 22 characters from a high quality generator (see session identifier contain 128 bits of entropy, i.e., approximately
Section 21). However, note that the session identifier does not 22 characters from a high-quality generator (see Section 21).
provide any security against session hijacking unless it is kept However, note that the session identifier does not provide any
confidential by the client, server and trusted proxies. security against session hijacking unless it is kept confidential by
the client, server, and trusted proxies.
4.4. Media Time Formats 4.4. Media-Time Formats
RTSP currently supports three different media time formats defined RTSP currently supports three different media-time formats defined
below. Additional time formats may be specified in the future. below. Additional time formats may be specified in the future.
These time formats can be used with the Range header (Section 18.40) These time formats can be used with the Range header (Section 18.40)
to request playback and specify at which media position protocol to request playback and specify at which media position protocol
requests actually will or have taken place. They are also used in requests actually will or have taken place. They are also used in
description of the media's properties using the Media-Range header description of the media's properties using the Media-Range header
(Section 18.30). The unqualified format identifier is used on its (Section 18.30). The unqualified format identifier is used on its
own in Accept-Ranges header (Section 18.5) to declare supported time own in Accept-Ranges header (Section 18.5) to declare supported time
formats and also in the Range header (Section 18.40) to request the formats and also in the Range header (Section 18.40) to request the
time format used in the response. time format used in the response.
4.4.1. SMPTE Relative Timestamps 4.4.1. SMPTE-Relative Timestamps
A Society of Motion Picture and Television Engineers (SMPTE) relative A timestamp may use a format derived from a Society of Motion Picture
timestamp expresses time relative to the start of the clip. Relative and Television Engineers (SMPTE) specification and expresses time
timestamps are expressed as SMPTE time codes [SMPTE_TC] for frame- offsets anchored at the start of the media clip. Relative timestamps
level access accuracy. The time code has the format 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 a frame rate of 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
every tenth minute. If the frame and the subframe values are zero, every tenth minute. If the frame and the subframe values are zero,
they may be omitted. Subframes are measured in one-hundredth of a they may be omitted. Subframes are measured in hundredths 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.4.2. 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. The timestamp relative to the beginning of the presentation. 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 only or in hours, minutes, and seconds. The optional
part consists of a decimal point and decimal figures and indicates second part consists of a decimal point and decimal figures and
fractions of a second. indicates fractions of a second.
The beginning of a presentation corresponds to 0.0 seconds. Negative The beginning of a presentation corresponds to 0.0 seconds. Negative
values are not defined. values are not defined.
The special constant "now" is defined as the current instant of a The special constant "now" is defined as the current instant of a
live event. It MAY only be used for live events, and MUST NOT be live event. It MAY only be used for live events and MUST NOT be used
used for on-demand (i.e., non-live) content. for on-demand (i.e., non-live) content.
NPT is defined as in DSM-CC [ISO.13818-6.1995]: "Intuitively, NPT is NPT is defined as in Digital Storage Media Command and Control
the clock the viewer associates with a program. It is often (DSMb;CC) [ISO.13818-6.1995]:
digitally displayed on a VCR. NPT advances normally when in normal
play mode (scale = 1), advances at a faster rate when in fast scan Intuitively, NPT is the clock the viewer associates with a
forward (high positive scale ratio), decrements when in scan reverse program. It is often digitally displayed on a DVD player. NPT
(negative scale ratio) and is fixed in pause mode. NPT is advances normally when in normal play mode (scale = 1), advances
(logically) equivalent to SMPTE time codes." at a faster rate when in fast-scan forward (high positive scale
ratio), decrements when in scan reverse (negative scale ratio) and
is fixed in pause mode. NPT is (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 is based on ISO 8601 [ISO.8601.2000] and expresses the The syntax is based on ISO 8601 [ISO.8601.2000] and expresses the
time elapsed since presentation start, with two different notations time elapsed since presentation start, with two different notations
allowed: allowed:
o The npt-hhmmss notation uses an ISO 8601 extended complete o The npt-hhmmss notation uses an ISO 8601 extended complete
representation of the time of the day format (Section 5.3.1.1 of representation of the time of the day format (Section 5.3.1.1 of
[ISO.8601.2000] ) using colon (":") as separators between hours, [ISO.8601.2000] ) using colons (":") as separators between hours,
minutes and seconds (hh:mm:ss). The hour counter is not limited minutes, and seconds (hh:mm:ss). The hour counter is not limited
to 0-24 hours; up to nineteen (19) digits of hours are allowed. to 0-24 hours; up to nineteen (19) hour digits are allowed.
o In accordance with the requirements of the ISO 8601 time format, * In accordance with the requirements of the ISO 8601 time
the hours, minutes, and seconds MUST all be present, with two format, the hours, minutes, and seconds MUST all be present,
digits used for minutes and for seconds, and with a least two with two digits used for minutes and for seconds and with at
digits for hours. An NPT of 7 minutes and 0 seconds is least two digits for hours. An NPT of 7 minutes and 0 seconds
represented as "00:07:00", and an NPT of 392 hours, 0 minutes, and is represented as "00:07:00", and an NPT of 392 hours, 0
6 seconds is represented as "392:00:06". minutes, and 6 seconds is represented as "392:00:06".
o RTSP 1.0 allowed NPT in the npt-hhmmss notation without any * RTSP 1.0 allowed NPT in the npt-hhmmss notation without any
leading zeros, to ensure that implementations doesn't fail if any leading zeros to ensure that implementations don't fail; for
implementation follows the RTSP 1.0 format, all implementations backward compatibility, all RTSP 2.0 implementations are
are REQUIRED to support receiving NPT values, hours, minutes or REQUIRED to support receiving NPT values, hours, minutes, or
seconds, without leading zeros. seconds, without leading zeros.
o The npt-sec notation expresses the time in seconds, using between o The npt-sec notation expresses the time in seconds, using between
one and nineteen (19) digits. one and nineteen (19) digits.
Both notations allow decimal fractions of seconds as specified in Both notations allow decimal fractions of seconds as specified in
Section 5.3.1.3 of [ISO.8601.2000], using at most 9 digits, and Section 5.3.1.3 of [ISO.8601.2000], using at most nine digits, and
allowing only "." (full stop) as the decimal separator. allowing only "." (full stop) as the decimal separator.
The npt-sec notation is optimized for automatic generation, the npt- The npt-sec notation is optimized for automatic generation; the npt-
hhmmss notation for consumption by human readers. The "now" constant hhmmss notation is optimized for consumption by human readers. The
allows clients to request to receive the live feed rather than the "now" constant allows clients to request to receive the live feed
stored or time-delayed version. This is needed since neither rather than the stored or time-delayed version. This is needed since
absolute time nor zero time are appropriate for this case. neither absolute time nor zero time are appropriate for this case.
4.4.3. Absolute Time 4.4.3. Absolute Time
Absolute time is expressed following a specific types of ISO 8601 Absolute time is expressed using a timestamp based on ISO 8601
[ISO.8601.2000] based timestamps. The date is complete [ISO.8601.2000]. The date is a complete representation of the
representation calendar date in basic format (YYYYMMDD) without calendar date in basic format (YYYYMMDD) without separators (per
separators (per Section 5.2.1.1 of [ISO.8601.2000]). The time of day Section 5.2.1.1 of [ISO.8601.2000]). The time of day is provided in
is provided in the complete representation basic format (hhmmss) as the complete representation basic format (hhmmss) as specified in
specified in Section 5.3.1.1 of [ISO.8601.2000], allowing decimal Section 5.3.1.1 of [ISO.8601.2000], allowing decimal fractions of
fractions of seconds following Section 5.3.1.3 requiring "." (full seconds following Section 5.3.1.3 requiring "." (full stop) as
stop) as decimal separator and limiting the number of digits to no decimal separator and limiting the number of digits to no more than
more than nine (9). The time expressed MUST be using UTC (GMT), i.e. nine. The time expressed MUST use UTC (GMT), i.e., no time zone
no timezone offsets allowed. The full date and time specification is offsets are allowed. The full date and time specification is the
the eight digit date followed by a "T" followed by the six digits eight-digit date followed by a "T" followed by the six-digit time
time value, optionally followed by a full stop followed by one to value, optionally followed by a full stop followed by one to nine
nine fractions of a second and ended by "Z", e.g. fractions of a second and ended by "Z", e.g., YYYYMMDDThhmmss.ssZ.
YYYYMMDDThhmmss.ssZ.
The reason for this time format rather than using "Date and Time The reasons for this time format rather than using "Date and Time
on the Internet: Timestamps" [RFC3339] are historic and using the on the Internet: Timestamps" [RFC3339] are historic. We continue
format specified in RTSP 1.0. The motivations raised in RFC 3339 to use the format specified in RTSP 1.0. The motivations raised
applies to why a selection from ISO 8601 was done, but a different in RFC 3339 apply to why a selection from ISO 8601 was made;
and even more restrictive selection was applied in this case. however, a different and even more restrictive selection was
applied in this case.
Example for clock format range request for a starting time of Below are three examples of media time formats, first, a request for
November 8, 1996 at 14h 37 min and 20 and a quarter seconds UTC a clock format range request for a starting time of November 8, 1996
playing for 10 min and 5 seconds, a Media-Properties header's "Time- at 14 h 37 min and 20 1/4 seconds UTC playing for 10 min and 5
Limited UTC property for 24th of December 2014 at 15 hours and 00 seconds, followed by a Media-Properties header's "Time-Limited" UTC
mins, and a Terminate-Readon headers "time" property for 18th of June property for the 24th of December 2014 at 15 hours and 00 minutes,
2013 at 16 hours, 12 minutes and 56 seconds: and finally a Terminate-Reason header "time" property for the 18th of
June 2013 at 16 hours, 12 minutes, and 56 seconds:
clock=19961108T143720.25Z-19961108T144725.25Z clock=19961108T143720.25Z-19961108T144725.25Z
Time-Limited=20141224T1500Z Time-Limited=20141224T1500Z
time=20130618T161256Z time=20130618T161256Z
4.5. 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.43), Proxy-Require RTSP. These tags are used in Require (Section 18.43), Proxy-Require
(Section 18.37), Proxy-Supported (Section 18.38), Supported (Section 18.37), Proxy-Supported (Section 18.38), Supported
(Section 18.51) and Unsupported (Section 18.55) 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 to which it applies.
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
feature-tag with the Internet Assigned Numbers Authority (IANA) (see tag with the Internet Assigned Numbers Authority (IANA). (See
IANA Section 22). Section 22, "IANA Considerations".)
The usage of feature-tags is further described in Section 11 that The usage of feature tags is further described in Section 11, which
deals with capability handling. deals with capability handling.
4.6. 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.31) 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 (see Section 3.11 of [RFC2068]). 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.24) and "If-None-Match" (Section 18.26). see Section 18.24 and Section 18.26 for information on the If-Match
Note that RTSP message body tags apply to the complete presentation; and If-None-Match headers, respectively. Note that RTSP message body
i.e., both the presentation description and the individual media tags apply to the complete presentation, i.e., both the presentation
streams. Thus message body tags can be used to verify at setup time description and the individual media streams. Thus, message body
after a redirect that the same session description applies to the tags can be used to verify at setup time after a redirect that the
media at the new location using the If-Match header. same session description applies to the media at the new location
using the If-Match header.
4.7. 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 media properties listed below 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 lifetime of the RTSP session and is known at the
the time of the creation of the session. It is expected that 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, such as encoding, or quality, may change. Generally, one can
i.e., request any range, within the media. seek, 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 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.
Live with Recording: A Live stream that is combined with a server- Live with Recording: A live stream that is combined with a server-
side capability to store and retain the content of the live side capability to store and retain the content of the live
session, and allow for random access delivery within the part of session and allow for random access delivery within the part of
the already recorded content. The actual behavior of the media the already-recorded content. The actual behavior of the media
stream is very much dependent on the retention policy for the stream is very much dependent on the retention policy for the
media stream; either the server will be able to capture the media stream; either the server will be able to capture the
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.7.1. Random Access and Seeking 4.7.1. Random Access and Seeking
Random Access is the ability to specify and get media delivered Random access is the ability to specify and get media delivered
starting from any time instant within the content, an operation starting from any time (instant) within the content, an operation
called seeking. The Media-Properties header will indicate the called "seeking". The Media-Properties header will indicate the
general capability for a media resource to perform random access: 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.
Beginning-Only: Seeking is only possible to the beginning of the Beginning-Only: 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.
If random access is possible, as indicated by the Media-Properties If random access is possible, as indicated by the Media-Properties
header, the actual behavior policy when seeking can be controlled header, the actual behavior policy when seeking can be controlled
using the Seek-Style header (Section 18.47). using the Seek-Style header (Section 18.47).
4.7.2. Retention 4.7.2. Retention
Media may have different retention policies in place that affect the The following retention policies are used by media to limit possible
operation on media. The following different media retention policies protocol operations:
are defined:
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 the given Time-Limited: The media will not be removed before the given
wallclock time. After that time it may or may not be available wallclock time. After that time, it may or may not be available
any more. anymore.
Time-Duration: The media (on fragment or unit basis) will be Time-Duration: The media (on fragment or unit basis) will be
retained for the specified duration. retained for the specified duration.
4.7.3. Content Modifications 4.7.3. Content Modifications
There is also the question of how the content may change over time The media content and its timeline can be of different types, e.g.
for a given media resource: pre-produced content on demand, a live source that is being generated
as time progresses, or something that is dynamically altered or
recomposed during playback. Therefore, a media property for content
modifications is needed and the following initial values are defined:
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, such as encoding or quality changes.
Dynamic: The content can change due to external methods or triggers, Dynamic: The content can change due to external methods or triggers,
such as playlists, but this will be announced by explicit updates. such as playlists, but this will be announced by explicit updates.
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 is also 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.7.4. Supported Scale Factors 4.7.4. Supported Scale Factors
Content often supports only a limited set or range of scales when A particular media content item often supports only a limited set or
delivering the media. To enable the client to know what values or range of scales when delivering the media. To enable the client to
ranges of scale operations that the whole content or the current know what values or ranges of scale operations that the whole content
position supports, a media properties attribute for this is defined or the current position supports, a media properties attribute for
which contains a list with the values and/or ranges that are this is defined that contains a list with the values or ranges that
supported. The attribute is named "Scales". The "Scales" attribute are supported. The attribute is named "Scales". The "Scales"
may be updated at any point in the content due to content consisting attribute may be updated at any point in the content due to content
of spliced pieces or content being dynamically updated by out-of-band consisting of spliced pieces or content being dynamically updated by
mechanisms. out-of-band mechanisms.
4.7.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.
Example of On-demand: Example of On-Demand:
Random Access: Random-Access=5.0, Content Modifications: Random Access: Random-Access=5.0, Content Modifications:
Immutable, Retention: Unlimited or Time-Limited. Immutable, Retention: Unlimited or Time-Limited.
Example of Dynamic On-demand: Example of Dynamic On-Demand:
Random Access: Random-Access=3.0, Content Modifications: Dynamic, Random Access: Random-Access=3.0, Content Modifications: Dynamic,
Retention: Unlimited or Time-Limited. Retention: Unlimited or Time-Limited.
Example of Live: Example of Live:
Random Access: No-seeking, Content Modifications: Time- Random Access: No-Seeking, Content Modifications: Time-
Progressing, Retention: Time-Duration=0.0 Progressing, Retention: Time-Duration=0.0
Example of Live with Recording: Example of Live with Recording:
Random Access: Random-Access=3.0, Content Modifications: Time- Random Access: Random-Access=3.0, Content Modifications: Time-
Progressing, Retention: Time-Duration=7200.0 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 that uses the ISO 10646 character set
UTF-8 encoding RFC 3629 [RFC3629]. Lines MUST be terminated by CRLF. in UTF-8 encoding per RFC 3629 [RFC3629]. Lines MUST be terminated
by a 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 used 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 Python, PHP, Perl and TCL.
The ISO 10646 character set avoids character set switching, but is The ISO 10646 character set avoids character-set switching, but is
invisible to the application as long as US-ASCII is being used. This invisible to the application as long as US-ASCII is being used. This
is also the encoding used for RTCP [RFC3550]. is also the encoding used for text fields in RTCP [RFC3550].
A request contains a method, the object the method is operating upon, A request contains a method, the object the method is operating upon,
and parameters to further describe the method. Methods are and parameters to further describe the method. Methods are
idempotent unless otherwise noted. Methods are also designed to idempotent unless otherwise noted. Methods are also designed to
require little or no state maintenance at the media server. require little or no state maintenance at the media server.
5.1. Message Types 5.1. Message Types
RTSP messages are either requests from client to server, or server to RTSP messages are either requests from client to server or from
client, and responses in the reverse direction. Request (Section 7) server to client, and responses in the reverse direction. Request
and Response (Section 8) messages use a format based on the generic (Section 7) and response (Section 8) messages use a format based on
message format of RFC 5322 [RFC5322] for transferring bodies (the the generic message format of RFC 5322 [RFC5322] for transferring
payload of the message). Both types of messages consist of a start- bodies (the payload of the message). Both types of messages consist
line, zero or more header fields (also known as "headers"), an empty of a start-line, zero or more header fields (also known as
line (i.e., a line with nothing preceding the CRLF) indicating the "headers"), an empty line (i.e., a line with nothing preceding the
end of the headers, and possibly the data of the message body. The CRLF) indicating the end of the headers, and possibly the data of the
below ABNF [RFC5234] is for information and the formal message message body. The ABNF [RFC5234] below is for illustration only; the
specification is present in Section 20.2.2. formal message specification is presented in Section 20.2.2.
generic-message = start-line generic-message = start-line
*(rtsp-header CRLF) *(rtsp-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 Status-Line is expected. In other received where a Request-Line or Status-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 any number of CRLFs first, it MUST ignore of a message and receives any number of CRLFs first, it MUST ignore
any of the CRLFs. all of the CRLFs.
5.2. Message Headers 5.2. Message Headers
RTSP header fields (see Section 18) include general-header, request- RTSP header fields (see Section 18) include general-header, request-
header, response-header, and message-body header fields. header, response-header, and message body header fields.
The order in which header fields with differing field names are The order in which header fields with differing field names are
received is not significant. However, it is "good practice" to send received is not significant. However, it is "good practice" to send
general-header fields first, followed by request-header or response- general-header fields first, followed by a request-header or
header fields, and ending with the Message-body header fields. response-header field, and ending with the message body header
fields.
Multiple header fields with the same field-name MAY be present in a Multiple header fields with the same field-name MAY be present in a
message if and only if the entire field-value for that header field message if and only if the entire field-value for that header field
is defined as a comma-separated list. It MUST be possible to combine is defined as a comma-separated list. It MUST be possible to combine
the multiple header fields into one "field-name: field-value" pair, the multiple header fields into one "field-name: field-value" pair,
without changing the semantics of the message, by appending each without changing the semantics of the message, by appending each
subsequent field-value to the first, each separated by a comma. The subsequent field-value to the first, each separated by a comma. The
order in which header fields with the same field-name are received is order in which header fields with the same field-name are received is
therefore significant to the interpretation of the combined field therefore significant to the interpretation of the combined field
value, and thus a proxy MUST NOT change the order of these field value; thus, a proxy MUST NOT change the order of these field-values
values when a message is forwarded. 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 an RTSP
or client. An RTSP Proxy MUST forward unknown message headers. server or client. An RTSP proxy MUST forward unknown message
Message headers defined outside of this specification that are headers. Message headers defined outside of this specification that
required to be interpreted by the RTSP agent will need to use feature are required to be interpreted by the RTSP agent will need to use
tags (Section 4.5) and include them in the appropriate Require feature tags (Section 4.5) and include them in the appropriate
(Section 18.43) or Proxy-Require (Section 18.37) header. Require (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 a Session Description response. An example of a message body is an SDP message.
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.17) and Content-Type (see Section 18.19). A message body Section 18.17) and Content-Type header (see Section 18.19). A
MUST NOT be included in a request or response if the specification of message body MUST NOT be included in a request or response if the
the particular method (see Method Definitions (Section 13)) does not specification of the particular method (see Method Definitions
allow sending a message body. In case a message body is received in (Section 13)) does not allow sending a message body. In case a
a message when not expected the message body data SHOULD be message body is received in a message when not expected, the message
discarded. This is to allow future extensions to define optional use body data SHOULD be discarded. This is to allow future extensions to
of a message body. define optional use of a message body.
5.4. Message Length 5.4. Message Length
An RTSP Message that does not contain any message body is terminated An RTSP message that does not contain any message body is terminated
by the first empty line after the header fields (Note: An empty line by the first empty line after the header fields (note: an empty line
is a line with nothing preceding the CRLF.). In RTSP messages that is a line with nothing preceding the CRLF.). In RTSP messages that
contain message bodies the empty line is followed by the message contain message bodies, the empty line is followed by the message
body. The length of that body is determined by the value of the body. The length of that body is determined by the value of the
Content-Length header (Section 18.17). The value in the header Content-Length header (Section 18.17). The value in the header
represents the length of the message-body in octets. If this header represents the length of the message body in octets. If this header
field is not present, a value of zero is assumed, i.e., no message field is not present, a value of zero is assumed, i.e., no message
body present in the message. Unlike an HTTP message, an RTSP message body present in the message. Unlike an HTTP message, an RTSP message
MUST contain a Content-Length header whenever it contains a message MUST contain a Content-Length header whenever it contains a message
body. Note that RTSP does not support the HTTP/1.1 "chunked" body. Note that RTSP does not support the HTTP/1.1 "chunked"
transfer coding (see [H3.6.1]). transfer coding (see Section 4.1 of [RFC7230]).
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 |
+--------------------+--------------------+ +--------------------+----------------+
| Accept-Ranges | Section 18.5 | | Accept-Ranges | Section 18.5 |
| | | | | |
| Cache-Control | Section 18.11 | | Cache-Control | Section 18.11 |
| | | | | |
| Connection | Section 18.12 | | Connection | Section 18.12 |
| | | | | |
| CSeq | Section 18.20 | | CSeq | Section 18.20 |
| | | | | |
| Date | Section 18.21 | | Date | Section 18.21 |
| | | | | |
| Media-Properties | Section 18.29 | | Media-Properties | Section 18.29 |
| | | | | |
| Media-Range | Section 18.30 | | Media-Range | Section 18.30 |
| | | | | |
| Pipelined-Requests | Section 18.33 | | Pipelined-Requests | Section 18.33 |
| | | | | |
| Proxy-Supported | Section 18.38 | | Proxy-Supported | Section 18.38 |
| | | | | |
| Range | Section 18.40 | | Range | Section 18.40 |
| | | | | |
| RTP-Info | Section 18.45 | | RTP-Info | Section 18.45 |
| | | | | |
| Scale | Section 18.46 | | Scale | Section 18.46 |
| | | | | |
| Seek-Style | Section 18.47 | | Seek-Style | Section 18.47 |
| | | | | |
| Server | Section 18.48 | | Server | Section 18.48 |
| | | | | |
| Session | Section 18.49 | | Session | Section 18.49 |
| | | | | |
| Speed | Section 18.50 | | Speed | Section 18.50 |
| | | | | |
| Supported | Section 18.51 | | Supported | Section 18.51 |
| | | | | |
| Timestamp | Section 18.53 | | Timestamp | Section 18.53 |
| | | | | |
| Transport | Section 18.54 | | Transport | Section 18.54 |
| | | | | |
| User-Agent | Section 18.56 | | User-Agent | Section 18.56 |
| | | | | |
| Via | Section 18.57 | | 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, whether 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, which 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 octets 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 |
+---------------+--------------------+ +---------------+----------------+
| DESCRIBE | Section 13.2 | | DESCRIBE | Section 13.2 |
| | | | | |
| GET_PARAMETER | Section 13.8 | | GET_PARAMETER | Section 13.8 |
| | | | | |
| OPTIONS | Section 13.1 | | OPTIONS | Section 13.1 |
| | | | | |
| PAUSE | Section 13.6 | | PAUSE | Section 13.6 |
| | | | | |
| PLAY | Section 13.4 | | PLAY | Section 13.4 |
| | | | | |
| PLAY_NOTIFY | Section 13.5 | | PLAY_NOTIFY | Section 13.5 |
| | | | | |
| REDIRECT | Section 13.10 | | REDIRECT | Section 13.10 |
| | | | | |
| SETUP | Section 13.3 | | SETUP | Section 13.3 |
| | | | | |
| SET_PARAMETER | Section 13.9 | | SET_PARAMETER | Section 13.9 |
| | | | | |
| TEARDOWN | Section 13.7 | | TEARDOWN | Section 13.7 |
+---------------+--------------------+ +---------------+----------------+
Table 2: The RTSP Methods Table 2: The RTSP Methods
The syntax of the RTSP request line is the following: The syntax of the RTSP request line has the following:
<Method> SP <Request-URI> SP <RTSP-Version> CRLF <Method> SP <Request-URI> SP <RTSP-Version> CRLF
Note: This syntax cannot be freely changed in future versions of Note: This syntax cannot be freely changed in future versions of
RTSP. This line needs to remain parsable by older RTSP RTSP. This line needs to remain parsable by older RTSP
implementations since it indicates the RTSP version of the message. implementations since it indicates the RTSP version of the message.
In contrast to HTTP/1.1 [RFC2616], RTSP requests identify the In contrast to HTTP/1.1 [RFC7230], RTSP requests identify the
resource through an absolute RTSP URI (including scheme, host, and resource through an absolute RTSP URI (including scheme, host, and
port) (see Section 4.2) rather than just the absolute path. port) (see Section 4.2) rather than just the absolute path.
HTTP/1.1 requires servers to understand the absolute URI, but HTTP/1.1 requires servers to understand the absolute URI, but
clients are supposed to use the Host request-header. This is clients are supposed to use the Host request-header. This is
purely needed for backward-compatibility with HTTP/1.0 servers, a purely needed for backward compatibility with HTTP/1.0 servers, a
consideration that does not apply to RTSP. consideration that does not apply to RTSP.
An asterisk "*" can be used instead of an absolute URI in the An asterisk "*" can be used instead of an absolute URI in the
Request-URI part to indicate that the request does not apply to a Request-URI part to indicate that the request does not apply to a
particular resource, but to the server or proxy itself, and is only particular resource but to the server or proxy itself, and is only
allowed when the request method does not necessarily apply to a allowed when the request method does not necessarily apply to a
resource. resource.
For example: For example:
OPTIONS * RTSP/2.0 OPTIONS * RTSP/2.0
An OPTIONS in this form will determine the capabilities of the server An OPTIONS in this form will determine the capabilities of the server
or the proxy that first receives the request. If the capability of or the proxy that first receives the request. If the capability of
the specific server needs to be determined, without regard to the the specific server needs to be determined, without regard to the
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. headers, to modify the specifics of the request.
+---------------------+--------------------+ +---------------------+----------------+
| Header | Defined in Section | | Header | Defined in |
+---------------------+--------------------+ +---------------------+----------------+
| 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.8 | | Authorization | Section 18.8 |
| | | | | |
| Bandwidth | Section 18.9 | | Bandwidth | Section 18.9 |
| | | | | |
| Blocksize | Section 18.10 | | Blocksize | Section 18.10 |
| | | | | |
| From | Section 18.23 | | From | Section 18.23 |
| | | | | |
| If-Match | Section 18.24 | | If-Match | Section 18.24 |
| | | | | |
| If-Modified-Since | Section 18.25 | | If-Modified-Since | Section 18.25 |
| | | | | |
| If-None-Match | Section 18.26 | | If-None-Match | Section 18.26 |
| | | | | |
| Notify-Reason | Section 18.32 | | Notify-Reason | Section 18.32 |
| | | | | |
| Proxy-Authorization | Section 18.36 | | Proxy-Authorization | Section 18.36 |
| | | | | |
| Proxy-Require | Section 18.37 | | Proxy-Require | Section 18.37 |
| | | | | |
| Referrer | Section 18.41 | | Referrer | Section 18.41 |
| | | | | |
| Request-Status | Section 18.42 | | Request-Status | Section 18.42 |
| | | | | |
| Require | Section 18.43 | | Require | Section 18.43 |
| | | | | |
| Terminate-Reason | Section 18.52 | | Terminate-Reason | Section 18.52 |
+---------------------+--------------------+ +---------------------+----------------+
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.
8. Response 8. Response
After receiving and interpreting a request message, the recipient After receiving and interpreting a request message, the recipient
responds with an RTSP response message. Normally, there is only one, responds with an RTSP response message. Normally, there is only one,
final, response. Only responses using the response code class 1xx, final, response. Responses using the response code class 1xx is the
are allowed to send one or more 1xx response messages prior to the only class for which there MAY be sent one or more responses prior to
final response message. the final response message.
The valid response codes and the methods they can be used with are The valid response codes and the methods they can be used with are
listed in Table 4. listed in Table 4.
8.1. Status-Line 8.1. Status-Line
The first line of a Response message is the Status-Line, consisting The first line of a response message is the Status-Line, consisting
of the protocol version followed by a numeric status code and the of the protocol version followed by a numeric status code and the
textual phrase associated with the status code, with each element textual phrase associated with the status code, with each element
separated by SP characters. No CR or LF is allowed except in the separated by SP characters. No CR or LF is allowed except in the
final CRLF sequence. final CRLF sequence.
<RTSP-Version> SP <Status-Code> SP <Reason-Phrase> CRLF <RTSP-Version> SP <Status-Code> SP <Reason Phrase> CRLF
8.1.1. Status Code and Reason Phrase 8.1.1. Status Code and Reason Phrase
The Status-Code element is a 3-digit integer result code of the The Status-Code element is a 3-digit integer result code of the
attempt to understand and satisfy the request. These codes are fully attempt to understand and satisfy the request. These codes are fully
defined in Section 17. The Reason-Phrase is intended to give a short defined in Section 17. The reason phrase is intended to give a short
textual description of the Status-Code. The Status-Code is intended textual description of the Status-Code. The Status-Code is intended
for use by automata and the Reason-Phrase is intended for the human for use by automata and the reason phrase is intended for the human
user. The client is not required to examine or display the Reason- user. The client is not required to examine or display the reason
Phrase. phrase.
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
values for the first digit: five 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 (3rr rather than 3xx is used as 304 is complete the request (3rr rather than 3xx is used as 304 is
excluded, see Section 17.3) 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 RTSP/ The individual values of the numeric status codes defined for RTSP
2.0, and an example set of corresponding Reason-Phrases, are 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 adopted most HTTP/1.1
[RFC2616] status codes and adds RTSP-specific status codes starting [RFC2068] status codes and then added RTSP-specific status codes
at x50 to avoid conflicts with future HTTP status codes that are starting at x50 to avoid conflicts with future HTTP status codes that
desirable to import into RTSP. All these codes are RTSP specific and are desirable to import into RTSP. All these codes are RTSP specific
RTSP has its own registry separate from HTTP for status codes. 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 an exception for unknown 3xx x00 status code of that class, with an exception for unknown 3xx
codes, which MUST be treated as a 302 (Found). The reason being that codes, which MUST be treated as a 302 (Found). The reason for that
no 300 (Multiple Choices in HTTP) is defined for RTSP. An response exception is that the status code 300 (Multiple Choices in HTTP) is
with an unrecognized status code MUST NOT be cached. For example, if not defined for RTSP. A response with an unrecognized status code
an unrecognized status code of 431 is received by the client, it can MUST NOT be cached. For example, if an unrecognized status code of
safely assume that there was something wrong with its request and 431 is received by the client, it can safely assume that there was
treat the response as if it had received a 400 status code. In such something wrong with its request and treat the response as if it had
cases, user agents SHOULD present to the user the message body received a 400 status code. In such cases, user agents SHOULD
returned with the response, since that message body is likely to present to the user the message body returned with the response,
include human-readable information which will explain the unusual since that message body is likely to include human-readable
status. information that will explain the unusual 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 | See Other | 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 |
| | | | | | | |
skipping to change at page 44, line 46 skipping to change at page 45, line 43
| | | | | | | |
| 451 | Parameter Not Understood | SET_PARAMETER, | | 451 | Parameter Not Understood | SET_PARAMETER, |
| | | GET_PARAMETER | | | | GET_PARAMETER |
| | | | | | | |
| 452 | reserved | n/a | | 452 | reserved | n/a |
| | | | | | | |
| 453 | Not Enough Bandwidth | SETUP | | 453 | Not Enough Bandwidth | SETUP |
| | | | | | | |
| 454 | Session Not Found | all | | 454 | Session Not Found | all |
| | | | | | | |
| 455 | Method Not Valid In This State | all | | 455 | Method Not Valid in This State | all |
| | | | | | | |
| 456 | Header Field Not Valid | all | | 456 | Header Field Not Valid for | all |
| | Resource | |
| | | | | | | |
| 457 | Invalid Range | PLAY, PAUSE | | 457 | Invalid Range | PLAY, PAUSE |
| | | | | | | |
| 458 | Parameter Is Read-Only | SET_PARAMETER | | 458 | Parameter Is Read-Only | SET_PARAMETER |
| | | | | | | |
| 459 | Aggregate Operation Not Allowed | all | | 459 | Aggregate Operation Not Allowed | all |
| | | | | | | |
| 460 | Only Aggregate Operation | all | | 460 | Only Aggregate Operation | all |
| | Allowed | | | | Allowed | |
| | | | | | | |
skipping to change at page 45, line 26 skipping to change at page 46, line 24
| | | | | | | |
| 464 | Data Transport Not Ready Yet | PLAY | | 464 | Data Transport Not Ready Yet | PLAY |
| | | | | | | |
| 465 | Notification Reason Unknown | PLAY_NOTIFY | | 465 | Notification Reason Unknown | PLAY_NOTIFY |
| | | | | | | |
| 466 | Key Management Error | all | | 466 | Key Management Error | all |
| | | | | | | |
| 470 | Connection Authorization | all | | 470 | Connection Authorization | all |
| | Required | | | | Required | |
| | | | | | | |
| 471 | Connection Credentials not | all | | 471 | Connection Credentials Not | all |
| | accepted | | | | Accepted | |
| | | |
| 472 | Failure to establish secure | all |
| | connection | |
| | | |
| | | | | | | |
| 472 | Failure to Establish Secure | all |
| | Connection | |
| | | | | | | |
| 500 | Internal Server Error | all | | 500 | Internal Server Error | all |
| | | | | | | |
| 501 | Not Implemented | all | | 501 | Not Implemented | all |
| | | | | | | |
| 502 | Bad Gateway | all | | 502 | Bad Gateway | all |
| | | | | | | |
| 503 | Service Unavailable | all | | 503 | Service Unavailable | all |
| | | | | | | |
| 504 | Gateway Timeout | all | | 504 | Gateway Timeout | all |
| | | | | | | |
| 505 | RTSP Version Not Supported | all | | 505 | RTSP Version Not Supported | all |
| | | | | | | |
| 551 | Option Not Supported | all | | 551 | Option Not Supported | all |
| | | | | | | |
| 553 | Proxy Unavailable | all | | 553 | 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 that 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 |
+------------------------+--------------------+ +------------------------+----------------+
| Authentication-Info | Section 18.7 | | Authentication-Info | Section 18.7 |
| | | | | |
| Connection-Credentials | Section 18.13 | | Connection-Credentials | Section 18.13 |
| | | | | |
| Location | Section 18.28 | | Location | Section 18.28 |
| | | | | |
| MTag | Section 18.31 | | MTag | Section 18.31 |
| | | | | |
| Proxy-Authenticate | Section 18.34 | | Proxy-Authenticate | Section 18.34 |
| | | | | |
| Public | Section 18.39 | | Public | Section 18.39 |
| | | | | |
| Retry-After | Section 18.44 | | Retry-After | Section 18.44 |
| | | | | |
| Unsupported | Section 18.55 | | Unsupported | Section 18.55 |
| | | | | |
| WWW-Authenticate | Section 18.58 | | 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
feature-tags in the request allows the responding party to learn the 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 can be given the semantics of response-header if all parties header can be given the semantics of response-header if all parties
in the communication recognize them to be a response-header. in the communication recognize them to be a response-header.
Unrecognized headers in responses MUST be ignored. Unrecognized headers in responses MUST be ignored.
9. Message Body 9. Message Body
Some Request and Response messages include a message body, if not Some request and response messages include 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.3). Section 5.3).
The SET_PARAMETER and GET_PARAMETER requests and responses, and the The SET_PARAMETER and GET_PARAMETER requests and responses, and the
DESCRIBE response as defined by this specification can have a message DESCRIBE response as defined by this specification, can have a
body; the purpose of the message body is defined in each case. All message body; the purpose of the message body is defined in each
4xx and 5xx responses MAY also have a message body to carry case. All 4xx and 5xx responses MAY also have a message body to
additional response information. Generally a message body MAY be carry additional response information. Generally, a message body MAY
attached to any RTSP 2.0 request or response, but the content of the be attached to any RTSP 2.0 request or response, but the content of
message body MAY be ignored by the receiver. Extensions to this the message body MAY be ignored by the receiver. Extensions to this
specification can specify the purpose and content of message bodies, specification can specify the purpose and content of message bodies,
including requiring their inclusion. 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 |
+------------------+--------------------+ +------------------+----------------+
| Allow | Section 18.6 | | Allow | Section 18.6 |
| | | | | |
| Content-Base | Section 18.14 | | Content-Base | Section 18.14 |
| | | | | |
| Content-Encoding | Section 18.15 | | Content-Encoding | Section 18.15 |
| | | | | |
| Content-Language | Section 18.16 | | Content-Language | Section 18.16 |
| | | | | |
| Content-Length | Section 18.17 | | Content-Length | Section 18.17 |
| | | | | |
| Content-Location | Section 18.18 | | Content-Location | Section 18.18 |
| | | | | |
| Content-Type | Section 18.19 | | Content-Type | Section 18.19 |
| | | | | |
| Expires | Section 18.22 | | Expires | Section 18.22 |
| | | | | |
| Last-Modified | Section 18.27 | | 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.
9.2. Message Body 9.2. Message Body
An RTSP message with a message body MUST include the Content-Type and An RTSP message with a message body MUST include the Content-Type and
Content-Length headers. When a message body is included with a Content-Length headers. When a message body is included with a
message, the data type of that content data is determined via the message, the data type of that content data is determined via the
header fields Content-Type and Content-Encoding. Content-Type and Content-Encoding header fields.
Content-Type specifies the media type of the underlying data. There Content-Type specifies the media type of the underlying data. There
is no default media format and the actual format used in the body is is no default media format and the actual format used in the body is
required to be explicitly stated in the Content-Type header. By required to be explicitly stated in the Content-Type header. By
being explicit and always require inclusion of the Content-Type being explicit and always requiring the inclusion of the Content-Type
header with accurate information one avoids the many pitfalls in header with accurate information, one avoids the many pitfalls in a
heuristic based interpretation of the body content. These are issue heuristic-based interpretation of the body content. The user
HTTP and email have suffered from. experience of HTTP and email have suffered from relying on such
heuristics.
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. The compression, that are a property of the requested resource. The
default encoding is 'identity', i.e. no transformation of the message default encoding is 'identity', i.e. no transformation of the message
body. body.
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 octets. measured in octets.
9.3. Message Body Format Negotiation 9.3. Message Body Format Negotiation
The content format of the message body is provided using the Content- 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 Type header (Section 18.19). To enable the responder of a request to
determine which media type it should use, the requestor may include determine which media type it should use, the requester may include
the Accept header (Section 18.1) in a request to identify supported the Accept header (Section 18.1) in a request to identify supported
media types or media type ranges suitable to the response. In case media types or media type ranges suitable to the response. In case
the responder is not supporting any of the specified formats, then the responder is not supporting any of the specified formats, then
the request response will be a 406 (Not Acceptable) error code. the request response will be a 406 (Not Acceptable) error code.
The media types that may be used on requests with message bodies need The media types that may be used on requests with message bodies need
to be determined through the use of feature-tags, specification to be determined through the use of feature tags, specification
requirement or trial and error. Trial and error works because when requirement, or trial and error. Trial and error works because when
the responder does not support the media type of the message body it the responder does not support the media type of the message body, it
will respond with a 415 (Unsupported Media Type). will respond with a 415 (Unsupported Media Type).
The formats supported and their negotiation is done individually on a The formats supported and their negotiation is done individually on a
per method and direction (request or response body) direction. per method and direction (request or response body) direction.
Requirements on supporting particular media types for use as message Requirements on supporting particular media types for use as message
bodies in requests and response SHALL also be specified on per method bodies in requests and response SHALL also be specified on a per-
and direction basis. method and per-direction basis.
10. Connections 10. Connections
RTSP Messages are transferred between RTSP agents and proxies using a RTSP messages are transferred between RTSP agents and proxies using a
transport connection. This transport connection uses TCP or TCP/TLS. transport connection. This transport connection uses TCP or TCP/TLS.
This transport connection is referred to as the 'connection' or 'RTSP This transport connection is referred to as the "connection" or "RTSP
connection' within this document. 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 each single request o transient - a transport connection is used for each single
/response transaction. request/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.20), 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 this
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
Since RTSP messages are transmitted using reliable transport Since RTSP messages are transmitted using reliable transport
protocols, they MUST NOT be retransmitted at the RTSP protocol level. protocols, they MUST NOT be retransmitted at the RTSP level.
Instead, the implementation must rely on the underlying transport to Instead, the implementation must rely on the underlying transport to
provide reliability. The RTSP implementation may use any indication provide reliability. The RTSP implementation may use any indication
of reception acknowledgment of the message from the underlying of reception acknowledgment of the message from the underlying
transport protocols to optimize the RTSP behavior. transport protocols to optimize the RTSP behavior.
If both the underlying reliable transport such as TCP and the RTSP If both the underlying reliable transport, such as TCP, and the
application retransmit requests, each packet loss or message loss RTSP application retransmit requests, each packet loss or message
may result in two retransmissions. The receiver typically cannot loss may result in two retransmissions. The receiver typically
take advantage of the application-layer retransmission since the cannot take advantage of the application-layer retransmission
transport stack will not deliver the application-layer since the transport stack will not deliver the application-layer
retransmission before the first attempt has reached the receiver. retransmission before the first attempt has reached the receiver.
If the packet loss is caused by congestion, multiple If the packet loss is caused by congestion, multiple
retransmissions at different layers will exacerbate the retransmissions at different layers will exacerbate the
congestion. congestion.
Lack of acknowledgment of an RTSP request should be handled within Lack of acknowledgment of an RTSP request should be handled within
the constraints of the connection timeout considerations described the constraints of the connection timeout considerations described
below (Section 10.4). below (Section 10.4).
10.2. Using Connections 10.2. Using Connections
A TCP transport can be used for both persistent connections (for A TCP transport can be used for both persistent connections (for
several message exchanges) and transient connections (for a single several message exchanges) and transient connections (for a single
message exchange). Implementations of this specification MUST message exchange). Implementations of this specification MUST
support RTSP over TCP. The scheme of the RTSP URI (Section 4.2) support RTSP over TCP. The scheme of the RTSP URI (Section 4.2)
allows the client to specify the port it will contact the server on, allows the client to specify the port it will contact the server on,
and defines the default port to use if one is not explicitly given. and defines the default port to use if one 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 is an alternative port 8554 registered. This port may (rtsps), there is an alternative port 8554 registered. This port may
provide some benefits over non-registered ports if a RTSP server is provide some benefits over non-registered ports if an RTSP server is
unable to use the default ports. The benefits may include pre- unable to use the default ports. The benefits may include
configured security policies as well as classifiers in network preconfigured security policies as well as classifiers in network
monitoring tools. monitoring tools.
A RTSP client opening a TCP connection for accessing a particular An RTSP client opening a TCP connection to access a particular
resource as identified by a URI uses the IP address and port derived 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 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 the explicit address provided in the URI or any of the addresses
provided when performing A and AAAA record DNS lookups of the host provided when performing A and AAAA record DNS lookups of the
name in the URI. hostname 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 supports 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 be
either be transient or persistent. either transient or persistent.
An RTSP agent MAY use one connection to handle multiple RTSP sessions An RTSP agent MAY use one connection to handle multiple RTSP sessions
on the same server. The RTSP agent SHALL NOT use more than one on the same server. The RTSP agent SHALL NOT use more than one
connection per RTSP session at any given point. connection per RTSP session at any given point.
Having only one connection in use at any time avoids confusion on Having only one connection in use at any time avoids confusion
which connection any server to client requests shall be sent on. regarding on which connection any server-to-client requests shall
Using a single connection for multiple RTSP session also saves be sent. Using a single connection for multiple RTSP sessions
complexity by enabling the server to maintain less state about its also saves complexity by enabling the server to maintain less
connection resources on the server. Not using more than one state about its connection resources on the server. Not using
connection at a time for a particular RTSP session avoids wasting more than one connection at a time for a particular RTSP session
connection resources and allows the server to track only the most avoids wasting connection resources and allows the server to track
recently used client to server connection for each RTSP session as only the most recently used client-to-server connection for each
being the currently valid server to client connection. 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 it may even drop an RTSP session without notifying the client.
example of such a case is when the server desires to send a REDIRECT An example of such a case is when the server desires to send a
request for an RTSP session to the client but is not able to do so REDIRECT request for an RTSP session to the client but is not able to
because it cannot reach the client. A server that attempts to send a do so because it cannot reach the client. A server that attempts to
request to a client that has no connection currently to the server send a request to a client that has no connection currently to the
SHALL discard the request. server SHALL discard the request.
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 of 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 Queuing of server-to-client requests has been considered.
a security issue exists as to how it might be possible to However, a security issue exists as to how it might be possible to
authorize a client establishing a new connection as being a authorize a client establishing a new connection as being a
legitimate receiver of a request related to a particular RTSP legitimate receiver of a request related to a particular RTSP
session, without the client first issuing requests related to the session, without the client first issuing requests related to the
pending request. Thus, it would be likely to make any such pending request. Thus, it would be likely to make any such
requests even more delayed and less useful. 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 time out despite being
processed by the peer due to the response being caught in the queue processed by the peer; this can be due to the response being caught
behind a number of requests that the RTSP agent is processing but in the queue behind a number of requests that the RTSP agent is
that take some time to complete. To avoid this problem an RTSP agent processing but that take some time to complete. To avoid this
is recommended to buffer incoming messages locally so that any problem, an RTSP agent should buffer incoming messages locally so
response messages can be processed immediately upon reception. If that any response messages can be processed immediately upon
responses are separated from requests and directly forwarded for reception. If responses are separated from requests and directly
processing, not only can the result be used immediately, the state forwarded for processing, not only can the result be used
associated with that outstanding request can also be released. immediately, the state associated with that outstanding request can
However, buffering a number of requests on the receiving RTSP agent also be released. However, buffering a number of requests on the
consumes resources and enables a resource exhaustion attack on the receiving RTSP agent consumes resources and enables a resource
agent. Therefore this buffer should be limited so that an exhaustion attack on the agent. Therefore, this buffer should be
unreasonable number of requests or total message size is not allowed limited so that an unreasonable number of requests or total message
to consume the receiving agent's resources. In most APIs, having the size is not allowed to consume the receiving agent's resources. In
receiving agent stop reading from the TCP socket will result in TCP's most APIs, having the receiving agent stop reading from the TCP
window being clamped. Thus forcing the buffering onto the sending socket will result in TCP's window being clamped, thus forcing the
agent when the load is larger than expected. However, as both RTSP buffering onto the sending agent when the load is larger than
message sizes and frequency may be changed in the future by protocol expected. However, as both RTSP message sizes and frequency may be
extensions, an agent should be careful against taking harsher changed in the future by protocol extensions, an agent should be
measurements against a potential attack. When under attack an RTSP careful about taking harsher measurements against a potential attack.
agent can close TCP connections and release state associated with When under attack, an RTSP agent can close TCP connections and
that TCP connection. release state associated with 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, RTSP agents can send requests to multiple different destinations,
either servers or client contexts over the same connection to a either server or client contexts over the same connection to a proxy.
proxy. Then the proxy forks the message to the different Then, the proxy forks the message to the different destinations over
destinations over proxy to agent connections. In these cases when proxy-to-agent connections. In these cases when multiple requests
multiple requests are outstanding the requesting agent MUST be ready are outstanding, the requesting agent MUST be ready to receive the
to receive the responses out of order compared to the order they responses out of order compared to the order they where sent on the
where sent on the connection. The order between multiple messages connection. The order between multiple messages for each destination
for each destination will be maintained, however, the order between will be maintained; however, the order between response from
response from different destinations can be different. different destinations can be different.
The reason for this is to avoid a head-of-line blocking The reason for this is to avoid a head-of-line blocking situation.
sitauation. In a sequence of requests an early outstanding In a sequence of requests, an early outstanding request may take
request may take time to be processed at one destination. time to be processed at one destination. Simultaneously, a
Simultaneously, a response from any other destination that was response from any other destination that was later in the sequence
later in the sequence of requests, may have arrived at the proxy. of requests may have arrived at the proxy; thus, allowing out-of-
Thus allowing out-of-order responses avoids forcing the proxy to order responses avoids forcing the proxy to buffer this response
buffer this response and instead deliver it as soon as possible. and instead deliver it as soon as possible. Note, this will not
Note, this will not affect the order in which the messages sent to affect the order in which the messages sent to each separate
each separate destination were processed at request destination. destination were processed at the request destination.
This scenario can occur in two cases involving proxies. The first is This scenario can occur in two cases involving proxies. The first is
a client issuing requests for sessions on different servers using a a client issuing requests for sessions on different servers using a
common client to proxy connection. The second is for server to common client-to-proxy connection. The second is for server-to-
client requests, like REDIRECT being sent by the server over a common client requests, like REDIRECT being sent by the server over a common
transport connection the proxy created for its different connecting transport connection the proxy created for its different connecting
clients. 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.49). 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, the server should wait for a reasonable the connection. Instead, the server should wait for a reasonable
amount of time for the client to receive and act upon the TEARDOWN amount of time for the client to receive and act upon the TEARDOWN
response, and initiate the connection closing. The server SHOULD response and then initiate the connection closing. The server SHOULD
wait at least 10 seconds after sending the TEARDOWN response before wait at least 10 seconds after sending the TEARDOWN response 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. Ten 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 or special types of requests or result
extra overhead for the client when testing for new features. On in extra overhead for the client when testing for new features.
the other hand, keeping connections open after sending an error On 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 (DoS) 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 wait 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 that are otherwise starved for resources during that event MAY
a shorter timeout. consider using a shorter timeout.
If a server closes a connection while the client is attempting to If a server closes a connection while the client is attempting to
send a new request, the client will have to close its current send a new request, the client will have to close its current
connection, establish a new connection and send its request over the connection, establish a new connection, and send its request over the
new connection. new connection.
An RTSP message SHOULD NOT be terminated by closing the connection. An RTSP message SHOULD NOT be terminated by closing the connection.
Such a message MAY be considered to be incomplete by the receiver and Such a message MAY be considered to be incomplete by the receiver and
discarded. An RTSP message is properly terminated as defined in discarded. An RTSP message is properly terminated as defined in
Section 5. Section 5.
10.4. Timing Out Connections and RTSP Messages 10.4. Timing Out Connections and RTSP Messages
Receivers of a request (responder) SHOULD respond to requests in a Receivers of a request (responders) SHOULD respond to requests in a
timely manner even when a reliable transport such as TCP is used. timely manner even when a reliable transport such as TCP is used.
Similarly, the sender of a request (requester) SHOULD wait for a Similarly, the sender of a request (requester) SHOULD wait for a
sufficient time for a response before concluding that the responder sufficient time for a response before concluding that the responder
will not be acting upon its request. will not be acting upon its request.
A responder SHOULD respond to all requests within 5 seconds. If the A responder SHOULD respond to all requests within 5 seconds. If the
responder recognizes that processing of a request will take longer responder recognizes that the processing of a request will take
than 5 seconds, it SHOULD send a 100 (Continue) response as soon as longer than 5 seconds, it SHOULD send a 100 (Continue) response as
possible. It SHOULD continue sending a 100 response every 5 seconds soon as possible. It SHOULD continue sending a 100 response every 5
thereafter until it is ready to send the final response to the seconds thereafter until it is ready to send the final response to
requester. After sending a 100 response, the responder MUST send a the requester. After sending a 100 response, the responder MUST send
final response indicating the success or failure of the request. a 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 elapse 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 by closing the TCP is unresponsive and abort the connection by closing the TCP
connection. connection.
In cases multiple RTSP sessions share the same transport connection, In some cases, multiple RTSP sessions share the same transport
abandoning a request and closing the connection may have significant connection; abandoning a request and closing the connection may have
impact on those other sessions. First of all, other RTSP requests significant impact on those other sessions. First of all, other RTSP
may have become queued up due to the request taking long time to requests may have become queued up due to the request taking a long
process. Secondly also those sessions loose the possibility to time to process. Secondly, those sessions also lose the possibility
receive server to client requests. To mitigate that situation the to receive server-to-client requests. To mitigate that situation,
RTSP client or server SHOULD establish a new connection and send any the RTSP client or server SHOULD establish a new connection and send
queued up and non-responded requests on this new connection. any requests that are queued up or that haven't received a response
Secondly, to ensure that the RTSP server knows which connection that on this new connection. Thirdly, to ensure that the RTSP server
is valid for a particular RTSP session, the RTSP agent SHOULD send a knows which connection is valid for a particular RTSP session, the
keep-alive request, if no other request will be sent immediately for RTSP agent SHOULD send a keep-alive request, if no other request will
that RTSP session, for each RTSP session on the old connection. The be sent immediately for that RTSP session, for each RTSP session on
keep-alive request will normally be a SET_PARAMETER with a session the old connection. The keep-alive request will normally be a
header to inform the server that this agent cares about this RTSP SET_PARAMETER with a session header to inform the server that this
session. 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 round trip responder. The requester is capable of determining the Round-Trip
time (RTT) of the request/response cycle using the Timestamp header Time (RTT) of the request/response cycle using the Timestamp header
(Section 18.53) in any RTSP request. (Section 18.53) in any RTSP request.
10 seconds was chosen for the following reasons. It gives TCP The 10-second wait was chosen for the following reasons. It gives
time to perform a couple of retransmissions, even if operating on TCP time to perform a couple of retransmissions, even if operating
default values. It is short enough that users may not abandon the on default values. It is short enough that users may not abandon
process themselves. However, it should be noted that 10 seconds the process themselves. However, it should be noted that 10
can be aggressive on certain type of networks. The 5 seconds seconds can be aggressive on certain types of networks. The
value for 1xx messages is half the timeout giving a reasonable 5-second value for 1xx messages is half the timeout giving a
chance of successful delivery before timeout happens on the reasonable chance of successful delivery before timeout happens on
requester side. the requester side.
10.5. Showing Liveness 10.5. Showing Liveness
RTSP requires the client to periodically show its liveness to the RTSP requires the client to periodically show its liveness to the
server or the server may terminate any session state. Several server or the server may terminate any session state. Several
different protocol mechanism includes in their usage a liveness proof different protocol mechanism include in their usage a liveness proof
from the client. These mechanisms are; RTSP requests with a Session from the client. These mechanisms are RTSP requests with a Session
header to the server; if RTP & RTCP is used for media data transport header to the server; if RTP & RTCP is used for media data transport
and the transport is established the RTCP message proves liveness; or and the transport is established, the RTCP message proves liveness;
through any other used media transport protocol capable of indicating or through any other used media-transport protocol capable of
liveness of the RTSP client. It is RECOMMENDED that a client does indicating liveness of the RTSP client. It is RECOMMENDED that a
not wait to the last second of the timeout before trying to send a client not wait to the last second of the timeout before trying to
liveness message. The RTSP message may take some time to arrive send a liveness message. The RTSP message may take some time to
safely at the receiver, due to packet loss and TCP retransmissions. arrive safely at the receiver, due to packet loss and TCP
To show liveness between RTSP requests being issued to accomplish retransmissions. To show liveness between RTSP requests being issued
other things, the following mechanisms can be used, in descending to accomplish other things, the following mechanisms can be used, in
order of preference: 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 will RTCP is used to report transport statistics, it will
necessarily also function as a keep-alive. The server can necessarily also function as a keep-alive. The server can
determine the client by network address and port together with determine the client by network address and port together with
the fact that the client is reporting on the server's RTP the fact that the client is reporting on the server's RTP
sender sources (SSRCs). A downside of using RTCP is that it sender sources (synchronization source (SSRCs)). A downside of
only gives statistical guarantees of reaching the server. using RTCP is that it only gives statistical guarantees of
However, the probability of a false client timeout is so low reaching the server. However, the probability of a false
that it can be ignored in most cases. For example, assume a client timeout is so low that it can be ignored in most cases.
session with 60 seconds timeout and enough bitrate assigned to For example, assume a session with a 60-second timeout and
RTCP messages to send a message from client to server on enough bitrate assigned to RTCP messages to send a message from
average every 5 seconds. That client has, for a network with client to server on average every 5 seconds. That client has,
5% packet loss, a probability of failing to confirm liveness for a network with 5% packet loss, a probability of failing to
within the timeout interval for that session of 2.4*E-16. confirm liveness within the timeout interval for that session
Sessions with shorter timeouts, or much higher packet loss, or of 2.4*E-16. Sessions with shorter timeouts, much higher
small RTCP bandwidths SHOULD also implement one or more of the packet loss, or small RTCP bandwidths SHOULD also implement one
mechanisms below. 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-alives, 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. Support of SET_PARAMETER is mandatory for RTSP Servers alives. RTSP servers MUST support the SET_PARAMETER method, so
to ensure clients can use this method. that clients can always use this mechanism.
GET_PARAMETER: When using GET_PARAMETER for keep-alive, a body GET_PARAMETER: When using GET_PARAMETER for keep-alives, a body
SHOULD NOT be included. Dependent on implementation support in SHOULD NOT be included, dependent on implementation support in
server. Use OPTIONS method to determine if there are method the server. Use the OPTIONS method to determine if there is
support or simply try. method support or simply try.
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 of the Session header (Section 18.49) MAY be The timeout parameter of the Session header (Section 18.49) MAY be
included in a SETUP response, and MUST NOT be included in requests. included in a SETUP response and MUST NOT be included in requests.
The server uses it to indicate to the client how long the server is The server uses it to indicate to the client how long the server is
prepared to wait between RTSP commands or other signs of life before prepared to wait between RTSP commands or other signs of life before
closing the session due to lack of activity (see Appendix B). The closing the session due to lack of activity (see Appendix B). The
timeout is measured in seconds, with a default of 60 seconds. The timeout is measured in seconds, with a default of 60 seconds. The
length of the session timeout MUST NOT be changed in an established length of the session timeout MUST NOT be changed in an established
session. 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. RTSP
2326). RTSP 2.0 has been updated for explicit IPv6 support. 2.0 has been updated for explicit IPv6 support. Implementations of
Implementations of RTSP 2.0 MUST understand literal IPv6 addresses in RTSP 2.0 MUST understand literal IPv6 addresses in URIs and RTSP
URIs and RTSP headers. Although the general URI format envisages headers. Although the general URI format envisages potential future
potential future new versions of the literal IP address, usage of any new versions of the literal IP address, usage of any such new version
such new version would require other modifications to the RTSP would require other modifications to the RTSP specification (e.g.,
specification (e.g. address fields in the Transport header address fields in the Transport header (Section 18.54)).
(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.44) the server or proxy can the Retry-After header (Section 18.44), the server or proxy can
indicate the time after which the requesting entity can send another indicate the time after which the requesting entity can send another
request to the proxy or server. request to the proxy or server.
There are two scopes of such 503 answers, one for established RTSP There are two scopes of such 503 answers. The first scope is for an
sessions, where the request resulting in the 503 response as well as established RTSP session, where the request resulting in the 503
the response carries a Session header identifying the session which response as well as the response itself carries a Session header
is suffering overload. This response only applies to this particular identifying the session that is suffering overload. This response
session. The other scope is the general RTSP server as identified by only applies to this particular session. The other scope is the
the host in the request URL. Such a 503 answer with any Retry-After general RTSP server as identified by the host in the Request-URI.
header applies to all non-session specific requests to that server, Such a 503 answer with any Retry-After header applies to all requests
including SETUP request intended to create a new RTSP session. that are not session specific to that server, including a SETUP
request intended to create a new RTSP session.
Another scope for overload situation exists, which is the RTSP proxy. Another scope for overload situations exists: the RTSP proxy. To
To enable an RTSP proxy to signal that it is overloaded, or otherwise enable an RTSP proxy to signal that it is overloaded, or otherwise
unavailable and can't handle the request, a 553 response code has unavailable and unable to handle the request, a 553 response code has
been defined with the meaning "Proxy Unavailable". As with servers, been defined with the meaning "Proxy Unavailable". As with servers,
there is a separation in response scopes between requests associated there is a separation in response scopes between requests associated
with existing RTSP sessions, and requests to create new sessions or with existing RTSP sessions and requests to create new sessions or
general proxy requests. general proxy requests.
Simply implementing and using the 503 (Service Unavailable) and 553 Simply implementing and using the 503 (Service Unavailable) and 553
(Proxy Unavailable) is not sufficient for properly handling overload (Proxy Unavailable) response codes is not sufficient for properly
situations. For instance, a simplistic approach would be to send the handling overload situations. For instance, a simplistic approach
503 response with a Retry-After header set to a fixed value. would be to send the 503 response with a Retry-After header set to a
However, this can cause the situation where multiple RTSP clients fixed value. However, this can cause a situation in which multiple
again send requests to a proxy or server at roughly the same time RTSP clients again send requests to a proxy or server at roughly the
which may again cause an overload situation, or if the "old" overload same time, which may again cause an overload situation. Another
situation is not yet solved, i.e., the length indicated in the Retry- situation would be if the "old" overload situation is not yet
After header was too short. resolved, i.e., the length indicated in the Retry-After header was
too short for the overload situation to subside.
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 bearing in mind its value of the Retry-After header carefully, bearing in mind its
current load situation. It is REQUIRED to increase the timeout current load situation. It is REQUIRED to increase the timeout
period in proportion to the current load on the server, i.e., an period in proportion to the current load on the server, i.e., an
increasing workload should result in an increased length of the increasing workload should result in an increased length of the
indicated unavailability. It is REQUIRED to not send the same value indicated unavailability. It is REQUIRED not to send the same value
in the Retry-After header to all requesting proxies and clients, but in the Retry-After header to all requesting proxies and clients, but
to add a variation to the mean value of the Retry-After header. to add a variation to the mean value of the Retry-After header.
A more complex case may arise when a load balancing RTSP proxy is in A more complex case may arise when a load-balancing RTSP proxy is in
use. This is the case when an RTSP proxy is used to select amongst a use. This is the case when an RTSP proxy is used to select amongst a
set of RTSP servers to handle the requests or when multiple server set of RTSP servers to handle the requests or when multiple server
addresses are available for a given server name. The proxy or client addresses are available for a given server name. The proxy or client
may receive a 503 (Service Unavailable) or 553 (Proxy Unavailable) may receive a 503 (Service Unavailable) or 553 (Proxy Unavailable)
from one of its RTSP servers or proxies, or a TCP timeout (if the response code from one of its RTSP servers or proxies, or a TCP
server is even unable to handle the request message). The proxy or timeout (if the server is even unable to handle the request message).
client simply retries the other addresses or configured proxies, but The proxy or client simply retries the other addresses or configured
may also receive a 503 (Service Unavailable) or 553 (Proxy proxies, but it may also receive a 503 (Service Unavailable) or 553
Unavailable) response or TCP timeouts from those addresses. In such (Proxy Unavailable) response or TCP timeouts from those addresses.
a situation, where none of the RTSP servers/proxies/addresses can In such a situation, where none of the RTSP servers/proxies/addresses
handle the request, the RTSP agent has to wait before it can send any can handle the request, the RTSP agent has to wait before it can send
new requests to the RTSP server. Any additional request to a any 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 until the value exceeds 30 minutes when the timers receive response until the value exceeds 30 minutes when the timer's
mean value may be set to 30 minutes. It is REQUIRED to not set the mean value may be set to 30 minutes. It is REQUIRED not to set the
same value in the timer for each scheduling, but instead to add a same value in the timer for each scheduling, but instead to add a
variation to the mean value, resulting in picking a random value variation to the mean value, resulting in picking a random value
within the range from 0.5 to 1.5 times the mean value. within the range of 0.5 to 1.5 times 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 that 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. Firstly, new headers can be
added. Secondly, new methods can be added. The capability handling added. Secondly, new methods can be added. The capability-handling
mechanism is designed to handle both cases. mechanism is designed to handle both cases.
When a method is added, the involved parties can use the OPTIONS When a method is added, the involved parties can use the OPTIONS
method to discover whether it is supported. This is done by issuing method to discover whether it is supported. This is done by issuing
an OPTIONS request to the other party. Depending on the URI it will an OPTIONS request to the other party. Depending on the URI, it will
either apply in regards to a certain media resource, the whole server either apply in regard to a certain media resource, the whole server
in general, or simply the next hop. The OPTIONS response MUST in general, or simply the next hop. The OPTIONS response MUST
contain a Public header which declares all methods supported for the contain a Public header that 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. For example, a feature tag can
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 (Section 11.1) which represents the minimal "play.basic" feature tag (Section 11.1), which represents the minimal
media delivery 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 in general and functionality that both client and server have, in general, and
is not dependent on a specific resource. The intended usage is is not dependent on a specific resource. The intended usage is
to determine before one needs to use a functionality that it is to determine before one needs to use a functionality that it is
supported. It can be used in any method, but OPTIONS is the supported. It can be used in any method, but OPTIONS is the
most suitable one as it at the same time determines all methods most suitable as it simultaneously determines all methods that
that are implemented. When sending a request the requester are implemented. When sending a request, the requester
declares all its capabilities by including all supported declares all its capabilities by including all supported
feature-tags. This results in the receiver learning the feature tags. This results in the receiver learning the
requester's feature support. The receiver then includes its requester's feature support. The receiver then includes its
set of features in the response. set of features in the response.
Proxy-Supported: This header is used similarly to the Supported Proxy-Supported: This header is used in a similar fashion as the
header, but instead of giving the supported functionality of Supported header, but instead of giving the supported
the client or server it provides both the requester and the functionality of the client or server, it provides both the
responder a view of the common functionality supported in requester and the responder a view of the common functionality
general by all members of the proxy chain between the two supported in general by all members of the proxy chain between
supports and not dependent on the resource. Proxies are the client and server; it does not depend on the resource.
required to add this header whenever the Supported header is Proxies are required to add this header whenever the Supported
present, but proxies may also add it independently of the header is present, but proxies may also add it independently of
requester. 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
point, i.e., the client or server, is required to understand endpoint, i.e., the client or server, is required to understand
the 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 endpoint
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 is 551 (Option Not Supported). Also, the
features that are not supported are given in the Unsupported features that are not supported are given in the Unsupported
header in the response. header in the response.
Proxy-Require: This header has the same purpose and workings as Proxy-Require: This header has the same purpose and behavior as
Require except that it only applies to proxies and not the end- Require except that it only applies to proxies and not the
point. Features that need to be supported by both proxies and endpoint. Features that need to be supported by both proxies
end-points need to be included in both the Require and Proxy- and endpoints need to be included in both the Require and
Require header. Proxy-Require header.
Unsupported: This header is used in a 551 error response, to Unsupported: This header is used in a 551 (Option Not Supported)
indicate which features were not supported. Such a response is error response, to indicate which features were not supported.
only the result of the usage of the Require and/or Proxy- Such a response is only the result of the usage of the Require
Require header where one or more features where not supported. or Proxy-Require headers where one or more features were not
This information allows the requester to make the best of supported. This information allows the requester to make the
situations as it knows which features are not supported. best of situations as it knows which features are not
supported.
11.1. Feature Tag: play.basic 11.1. Feature Tag: play.basic
An implementation supporting all normative parts of this An implementation supporting all normative parts of this
specification for the setup and control of playback of media uses the specification for the setup and control of playback of media uses the
feature tag "play.basic" to indicate this support. The appendices feature tag "play.basic" to indicate this support. The appendices
(starting with letters), are not part of the functionality include in (starting with letters) are not part of the functionality included in
the feature tag unless the appendix is explicitly specified in a main the feature tag unless the appendix is explicitly specified in a main
section as being a required appendix. section as being a required appendix.
Note: This feature tag does not mandate any media delivery Note: This feature tag does not mandate any media delivery
protocol, such as RTP. protocol, such as RTP.
In RTSP 1.0 there was a minimal implementation section. However, In RTSP 1.0, there was a minimal implementation section. However,
that was not consistent with the rest of the specification. So that was not consistent with the rest of the specification. So,
rather than making an attempt to explicitly enumerate the features rather than making an attempt to explicitly enumerate the features
for play.basic this specification has to be taken as a whole and for play.basic, this specification has to be taken as a whole and
the necessary features normatively defined as being required are the necessary features normatively defined as being required are
included. 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 to 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.
processing of the request MUST also have been finished before The 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 beyond the capabilities
The major improvement is to allow all requests involved in setting up in RTSP 1.0. As a major improvement, all requests involved in
and initiating media delivery to be pipelined after each other. This setting up and initiating media delivery can now be pipelined,
is accomplished by the utilization of the Pipelined-Requests header indicated by the Pipelined-Request header (see Section 18.33). This
(see Section 18.33). This header allows a client to request that two header allows a client to request that two or more requests be
or more requests are processed in the same RTSP session context which processed in the same RTSP session context that the first request
the first request creates. In other words, a client can request that creates. In other words, a client can request that two or more media
two or more media streams are set-up and then played without needing streams be set up and then played without needing to wait for a
to wait for a single response. This speeds up the initial startup single response. This speeds up the initial start-up time for an
time for an RTSP session by at least one RTT. 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 requests fails
PLAY request can still be successfully executed. However, the unexpectedly, the PLAY request can still be successfully executed.
resulting presentation will not be as expected by the requesting However, the resulting presentation will not be as expected by the
client, as only a single media instead of two will be played. In requesting client, as only a single media instead of two will be
this case the client can send a PAUSE request, correct the failing played. In this case, the client can send a PAUSE request, correct
SETUP request and then request it to be played. the failing SETUP request, and then request it be played.
13. Method Definitions 13. Method Definitions
The method indicates what is to be performed on the resource The method indicates what is to be performed on the resource
identified by the Request-URI. The method name is case-sensitive. identified by the Request-URI. The method name is case sensitive.
New methods may be defined in the future. Method names MUST NOT New methods may be defined in the future. Method names MUST NOT
start with a $ character (decimal 36) and MUST be a token as defined start with a $ character (decimal 36) and MUST be a token as defined
by the ABNF [RFC5234] in the syntax chapter Section 20. The methods by the ABNF [RFC5234] in Section 20. The methods are summarized in
are summarized in Table 7. Table 7.
+---------------+-----------+--------+-------------+-------------+ +---------------+-----------+--------+-------------+-------------+
| method | direction | object | Server req. | Client req. | | method | direction | object | Server req. | Client req. |
+---------------+-----------+--------+-------------+-------------+ +---------------+-----------+--------+-------------+-------------+
| DESCRIBE | C -> S | P,S | recommended | recommended | | DESCRIBE | C -> S | P,S | recommended | recommended |
| | | | | | | | | | | |
| GET_PARAMETER | C -> S | P,S | optional | optional | | GET_PARAMETER | C -> S | P,S | optional | optional |
| | | | | | | | | | | |
| | S -> C | P,S | optional | optional | | | S -> C | P,S | optional | optional |
| | | | | | | | | | | |
skipping to change at page 62, line 37 skipping to change at page 64, line 37
| | | | | | | | | | | |
| 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
(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: This table covers RTSP methods, their direction,
functional server can be built to deliver media without any and on what objects (P: presentation, S: stream) they operate.
parameters. However, SET_PARAMETER is required, i.e., mandatory Further, it indicates whether a server or a client implementation
to implement for the server, this is due to its usage for keep- is required (mandatory), recommended, or optional.
alive. PAUSE is required because it is the only way of leaving
the Play state without terminating the whole session. Further note on Table 7: the GET_PARAMETER is optional. For
example, a fully functional server can be built to deliver media
without any parameters. However, SET_PARAMETER is required, i.e.,
mandatory to implement for the server; this is due to its usage
for keep-alive. 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 a 501 (Not Implemented) response code and the requesting RTSP agent,
NOT try this method again for the given agent / resource combination. in turn, SHOULD NOT try this method again for the given agent/
An RTSP proxy whose main function is to log or audit and not modify resource combination. An RTSP proxy whose main function is to log or
transport or media handling in any way MAY forward RTSP messages with audit and not modify transport or media handling in any way MAY
unknown methods. Note that the proxy still needs to perform the forward RTSP messages with unknown methods. Note that the proxy
minimal required processing, like adding the Via header. still needs to perform the 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 Section 4.3.7 of [RFC7231].
bi-directional, in that a client can send the request to a server and However, in RTSP, OPTIONS is bidirectional in that a client can send
vice versa. A client MUST implement the capability to send an the request to a server and vice versa. A client MUST implement the
OPTIONS request and a server or a proxy MUST implement the capability capability to send an OPTIONS request and a server or a proxy MUST
to respond to an OPTIONS request. In addition to this "MUST implement the capability to respond to an OPTIONS request. In
implement" functionality, clients, servers and proxies MAY provide addition to this "MUST-implement" functionality, clients, servers and
support both for sending OPTIONS requests and generating responses to proxies MAY provide support both for sending OPTIONS requests and for
the requests. 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 the scope of the request, the Public header MUST always Regardless of the scope of the request, the Public header MUST always
be 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.49. 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 identifier. Such a request SHOULD also use the associated session identifier. Such a request SHOULD also use
the media 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 the "gzipped-messages" feature tag in the Proxy-Require is
fictitious features. a fictitious feature.
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 66, line 4 skipping to change at page 68, line 8
If a client obtains a valid description from an alternate source, the If a client obtains a valid description from an alternate source, the
client MAY use this description for initialization purposes without client MAY use this description for initialization purposes without
issuing a DESCRIBE request for the same media. The client should use issuing a DESCRIBE request for the same media. The client should use
any MTag to either validate the presentation description or make the any MTag to either validate the presentation description or make the
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, or other means that are appropriate to the
operating environment of the clients. operating environment of the clients.
13.3. SETUP 13.3. SETUP
The description below uses the following states in a protocol state The description below uses the following states in a protocol state
machine that is related to a specific session when that session has machine that is related to a specific session when that session has
been created. The state transitions are driven by protocol been created. The state transitions are driven by protocol
interactions. For additional information about the state machine see interactions. For additional information about the state machine,
Appendix B. see Appendix B.
Init: Initial state: no session exists. Init: Initial state. No session exists.
Ready: Session is ready to start playing. Ready: Session is ready to start playing.
Play: Session is playing, i.e., sending media stream data in the Play: Session is playing, i.e., sending media-stream data in the
direction S->C. direction S->C.
The SETUP request for a URI specifies the transport mechanism to be The SETUP request for a 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, namely, creating an RTSP session and changing the
parameters of already set up media stream(s). SETUP can be used in transport parameters of media streams that are already set up. SETUP
all three states; Init, and Ready, for both purposes and in PLAY to can be used in all three states, Init, Ready, and Play, to change the
change the transport parameters. The usage of SETUP method in the transport parameters. Additionally, Init and Ready can also be used
Play state to add a media resource to the session is unspecified for the creation of the RTSP session. The usage of the SETUP method
(Section 3.1). in the Play state to add a media resource to the session is
unspecified.
The Transport header, see Section 18.54, 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 so the server can select the most appropriate. It is expected that
that the session description format used will enable the client to the session description format used will enable the client to select
select a limited number of possible configurations that are offered a limited number of possible configurations that are offered as
to the server to choose from. All transport related parameters SHALL choices to the server. All transport-related parameters SHALL be
be included in the Transport header; the use of other headers for included in the Transport header; the use of other headers for this
this purpose is NOT RECOMMENDED due to middleboxes, such as firewalls purpose is NOT RECOMMENDED due to middleboxes, such as firewalls or
or NATs. NATs.
For the benefit of any intervening firewalls, a client MUST indicate For the benefit of any intervening firewalls, a client MUST indicate
the known transport parameters, even if it has no influence over the known transport parameters, even if it has no influence over
these parameters, for example, where the server advertises a fixed these parameters, for example, where the server advertises a fixed-
multicast address as destination. multicast address as destination.
Since SETUP includes all transport initialization information, Since SETUP includes all transport initialization information,
firewalls and other intermediate network devices (which need this firewalls and other intermediate network devices (which need this
information) are spared the more arduous task of parsing the information) are spared the more arduous task of parsing the
DESCRIBE response, which has been reserved for media DESCRIBE response, which has been reserved for media
initialization. initialization.
The client MUST include the Accept-Ranges header in the request The client MUST include the Accept-Ranges header in the request,
indicating all supported unit formats in the Range header. This indicating all supported unit formats in the Range header. This
allows the server to know which formats it may use in future session allows the server to know which formats it may use in future session-
related responses, such as a PLAY response without any range in the related responses, such as a PLAY response without any range in the
request. If the client does not support a time format necessary for request. If the client does not support a time format necessary for
the presentation, the server 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 200 OK response MUST include the Media-Properties header
(see Section 18.29 ). The combination of the parameters of the (see Section 18.29). The combination of the parameters of the Media-
Media-Properties header indicates the nature of the content present Properties header indicates the nature of the content present in the
in the session (see also Section 4.7). For example, a live stream session (see also Section 4.7). For example, a live stream with time
with time shifting is indicated by 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, and
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 200 OK response MUST include the Media-Range header (see
Section 18.30) 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, clock 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: QKyjN8nt2WqbWw4tIYof52;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
AVP/UDP transport and adds the address and ports it will send and RTP/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 that latter case, the server MUST
SETUP request into the existing session (aggregated session) or bundle this SETUP request into the existing session (aggregated
return error 459 (Aggregate Operation Not Allowed) (see session) or return a 459 (Aggregate Operation Not Allowed) error code
Section 17.4.24). An Aggregate control URI MUST be used to control (see Section 17.4.23). An aggregate control URI MUST be used to
an aggregated session. This URI MUST be different from the stream control an aggregated session. This URI MUST be different from the
control URIs of the individual media streams included in the stream 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
to not set up the session in aggregated control. If an Aggregate However, even if aggregated control is offered, the client MAY choose
not to 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.
The SETUP of media streams in an aggregate which has not been given The SETUP of media streams in an aggregate that has not been given an
an aggregated control URI is unspecified. aggregated control URI is unspecified.
While the session ID sometimes carries enough information for While the session ID sometimes carries enough information for
aggregate control of a session, the Aggregate control URI is still aggregate control of a session, the aggregate control URI is still
important for some methods such as SET_PARAMETER where the control important for some methods such as SET_PARAMETER where the control
URI enables the resource in question to be easily identified. The URI enables the resource in question to be easily identified. The
Aggregate control URI is also useful for proxies, enabling them to aggregate control URI is also useful for proxies, enabling them to
route the request to the appropriate server, and for logging, route the request to the appropriate server, and for logging,
where it is useful to note the actual resource that a request was where it is useful to note the actual resource on which a request
operating on. was operating.
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.49. Signs of liveness for an RTSP further discussion, see Section 18.49. Signs of liveness for an RTSP
session are: session include any RTSP requests from a client that contain a
Session header with the ID for that session, as well as RTCP sender
o Any RTSP request from a client which includes a Session header or receiver reports if RTP is used to transport the underlying media
with that session's ID. stream. RTCP sender reports may, for example, be received in session
where the server is invited into a conference session and are thus
o If RTP is used as a transport for the underlying media streams, an valid as a liveness indicator.
RTCP sender or receiver report from the client(s) for any of the
media streams in that RTSP session. RTCP Sender Reports may for
example be received in sessions where the server is invited into a
conference session and is valid for keep-alive.
If a SETUP request on a session fails for any reason, the session If a SETUP request on a session fails for any reason, the session
state, as well as transport and other parameters for associated state, as well as transport and other parameters for associated
streams MUST remain unchanged from their values as if the SETUP streams, MUST remain unchanged from their values as if the SETUP
request had never been received by the server. request had never been received by the server.
13.3.1. Changing Transport Parameters 13.3.1. Changing Transport Parameters
A client MAY issue a SETUP request for a stream that is already set A client MAY issue a SETUP request for a stream that is already set
up or playing in the session to change transport parameters, which a up or playing in the session to change transport parameters, which a
server MAY allow. If it does not allow changing of parameters, it server MAY allow. If it does not allow the changing of parameters,
MUST respond with error 455 (Method Not Valid In This State). The it MUST respond with error 455 (Method Not Valid in This State). The
reasons to support changing transport parameters include allowing reasons to support changing transport parameters include allowing
application layer mobility and flexibility to utilize the best application-layer mobility and flexibility to utilize the best
available transport as it becomes available. If a client receives a available transport as it becomes available. If a client receives a
455 when trying to change transport parameters while the server is in 455 error when trying to change transport parameters while the server
Play state, it MAY try to put the server in Ready state using PAUSE, is in Play state, it MAY try to put the server in Ready state using
before issuing the SETUP request again. If that also fails the PAUSE before issuing the SETUP request again. If that also fails,
changing of transport parameters will require that the client the changing of transport parameters will require that the client
performs a TEARDOWN of the affected media and then to set it up perform a TEARDOWN of the affected media and then set it up again.
again. For an aggregated session avoiding tearing down all the media For an aggregated session, not tearing down all the media at the same
at the same time will avoid the creation of a new session. time will avoid the creation of a new session.
All transport parameters MAY be changed. However, the primary usage All transport parameters MAY be changed. However, the primary usage
expected is to either change the transport protocol completely, like expected is to either change the transport protocol completely, like
switching from Interleaved TCP mode to UDP or vice versa, or to switching from Interleaved TCP mode to UDP or vice versa, or to
change the delivery address. change the delivery address.
In a SETUP response for a request to change the transport parameters In a SETUP response for a request to change the transport parameters
while in Play state, the server MUST include the Range to indicate at while in Play state, the server MUST include the Range header to
what point the new transport parameters will be used. Further, if indicate at what point the new transport parameters will be used.
RTP is used for delivery, the server MUST also include the RTP-Info Further, if RTP is used for delivery, the server MUST also include
header to indicate at what timestamp and RTP sequence number the the RTP-Info header to indicate at what timestamp and RTP sequence
change will take place. If both RTP-Info and Range are included in number the change will take place. If both RTP-Info and Range are
the response the "rtp_time" parameter and start point in the Range included in the response, the "rtp_time" parameter and start point in
header MUST be for the corresponding time, i.e., be used in the same the Range header MUST be for the corresponding time, i.e., be used in
way as for PLAY to ensure the correct synchronization information is the same way as for PLAY to ensure the correct synchronization
available. information is available.
If the transport parameters change while in Play state results in a If the transport-parameters change that happened while in Play state
change of synchronization related information, for example changing results in a change of synchronization-related information, for
RTP SSRC, the server MUST provide in the SETUP response the necessary example, changing RTP SSRC, the server MUST include the necessary
synchronization information. However, the server is RECOMMENDED to synchronization information in the SETUP response. However, the
avoid changing the synchronization information if possible. server SHOULD avoid changing the synchronization information if
possible.
13.4. PLAY 13.4. PLAY
This section describes the usage of the PLAY method in general, for This section describes the usage of the PLAY method in general, for
aggregated sessions, and in different usage scenarios. aggregated sessions, and in different usage scenarios.
13.4.1. General Usage 13.4.1. General Usage
The PLAY method tells the server to start sending data via the The PLAY method tells the server to start sending data via the
mechanism specified in SETUP and which part of the media should be mechanism specified in SETUP and which part of the media should be
played out. PLAY requests are valid when the session is in Ready or played out. PLAY requests are valid when the session is in Ready or
Play states. A PLAY request MUST include a Session header to Play state. A PLAY request MUST include a Session header to indicate
indicate which session the request applies to. to which session the request applies.
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, within the limits of the media resource and in Range header, within the limits of the media resource and in
accordance with the Seek-Style header (Section 18.47) and deliver accordance with the Seek-Style header (Section 18.47). It MUST
stream data until the end of the range if given, until a new PLAY deliver stream data until the end of the range if given, until a new
request is received, or until the end of the media is reached. If no PLAY request is received, until a PAUSE request (Section 13.5) is
Range header is present in the PLAY request the server SHALL play received, or until the end of the media is reached. If no Range
from current pause point until the end of media. The pause point header is present in the PLAY request, the server SHALL play from
defaults at session start to the beginning of the media. For media current pause point until the end of media. The pause point defaults
that is time-progressing and has no retention, the pause point will at session start to the beginning of the media. For media that is
always be set equal to NPT "now", i.e., the current delivery point. time-progressing and has no retention, the pause point will always be
The pause point may also be set to a particular point in the media by set equal to NPT "now", i.e., the current delivery point. The pause
the PAUSE method, see Section 13.6. The pause point for media that point may also be set to a particular point in the media by the PAUSE
is currently playing is equal to the current media position. For method; see Section 13.6. The pause point for media that is
time-progressing media with time-limited retention, if the pause currently playing is equal to the current media position. For time-
point represents a position that is older than what is retained by progressing media with time-limited retention, if the pause point
the server, the pause point will be moved to the oldest retained. represents a position that is older than what is retained by the
server, the pause point will be moved to the oldest retained
position.
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.30) 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 first of either the provided stop point or the end of the
prior to the specified stop point. Please note that if one simply media. Please note that if one simply wants to play from a
wants to play from a particular start point until the end of media particular start point until the end of media, using a Range header
using a Range header with an implicit stop point is RECOMMENDED. 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.30). 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.46) 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 indicate which
preference on which policy for start point selection the server shall policy for start point selection the server should use. This is done
use. This is done by including the Seek-Style header (Section 18.47) by including the Seek-Style header (Section 18.47) in the PLAY
in the PLAY request. The Seek-Style applied will affect the content request. The Seek-Style applied will affect the content of the Range
of the Range header as it will be adjusted to indicate from what header as it will be adjusted to indicate from what point the media
point the media actually is delivered. 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 returned.
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 that the server deliver media from the first random access point
to the indicated start point. prior 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
CSeq: 835 CSeq: 835
Session: 12345678 Session: ULExwZCXh2pd0xuFgkgZJW
Range: npt=10-25 Range: npt=10-25
Seek-Style: RAP Seek-Style: RAP
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Servers MUST include a "Range" header in any PLAY response, even if Servers MUST include a Range header in any PLAY response, even if no
no Range header was present in the request. The response MUST use Range header was present in the request. The response MUST use the
the same format as the request's range header contained. If no Range same format as the request's Range header contained. If no Range
header was in the request, the format used in any previous PLAY header was in the request, the format used in any previous PLAY
request within the session SHOULD be used. If no format has been request within the session SHOULD be used. If no format has been
indicated in a previous request the server MAY use any time format indicated in a previous request, the server MAY use any time format
supported by the media and indicated in the Accept-Ranges header in supported by the media and indicated in the Accept-Ranges header in
the SETUP request. It is RECOMMENDED that NPT is used if supported the SETUP request. It is RECOMMENDED that NPT is used if supported
by the media. by the media.
For any error response to a PLAY request, the server's response For any error response to a PLAY request, the server's response
depends on the current session state. If the session is in Ready depends on the current session state. If the session is in Ready
state, the current pause-point is returned using Range header with state, the current pause point is returned using a Range header with
the pause point as the explicit start-point and an implicit stop- the pause point as the explicit start point and an implicit stop
point. For time-progressing content where the pause-point moves with point. For time-progressing content, where the pause-point moves
real-time due to limited retention, the current pause point is with 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 are 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.45, 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: ULExwZCXh2pd0xuFgkgZJW
Range: npt=3.52- Range: npt=3.52-
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 836 CSeq: 836
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Range: npt=3.51-324.39 Range: npt=3.51-324.39
Seek-Style: First-Prior Seek-Style: First-Prior
Session: ULExwZCXh2pd0xuFgkgZJW
RTP-Info:url="rtsp://example.com/audio" RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545 ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTP Packet TS=2345962545 => NPT=3.51 S->C: RTP Packet TS=2345962545 => NPT=3.51
Media duration=0.16 seconds Media duration=0.16 seconds
The server replies with the actual start point that will be The server replies with the actual start point that will be
delivered. This may differ from the requested range if alignment of delivered. This may differ from the requested range if alignment of
the requested range to valid frame boundaries is required for the the requested range to valid frame boundaries is required for the
media source. Note that some media streams in an aggregate may need media source. Note that some media streams in an aggregate may need
to be delivered from even earlier points. Also, some media formats to be delivered from even earlier points. Also, some media formats
have a very long duration per individual data unit, therefore it have a very long duration per individual data unit; therefore, it
might be necessary for the client to parse the data unit, and select might be necessary for the client to parse the data unit, and select
where to start. The server SHALL also indicate which policy it uses where to start. The server SHALL also indicate which policy it uses
for selecting the actual start point by including a Seek-Style for selecting the actual start point by including a Seek-Style
header. header.
In the following example the client receives the first media packet In the following example, the client receives the first media packet
that stretches all the way up and past the requested playtime. Thus, that stretches all the way up and past the requested playtime. Thus,
it is the client's decision whether to render to the user the time it is the client's decision whether to render to the user the time
between 3.52 and 7.05, or to skip it. In most cases it is probably between 3.52 and 7.05 or to skip it. In most cases, it is probably
most suitable not to render that time period. most suitable not to render that time period.
C->S: PLAY rtsp://example.com/audio RTSP/2.0 C->S: PLAY rtsp://example.com/audio RTSP/2.0
CSeq: 836 CSeq: 836
Session: 12345678 Session: ZGGyCJOs8xaLkdNK2dmxQO
Range: npt=7.05- Range: npt=7.05-
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 836 CSeq: 836
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Session: ZGGyCJOs8xaLkdNK2dmxQO
Range: npt=3.52- Range: npt=3.52-
Seek-Style: First-Prior Seek-Style: First-Prior
RTP-Info:url="rtsp://example.com/audio" RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545 ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTP Packet TS=2345962545 => NPT=3.52 S->C: RTP Packet TS=2345962545 => NPT=3.52
Duration=4.15 seconds Duration=4.15 seconds
After playing the desired range, the presentation does NOT change to After playing the desired range, the presentation does NOT change to
the Ready state, media delivery simply stops. If it is necessary to the Ready state, media delivery simply stops. If it is necessary to
put the stream into the Ready state, a PAUSE request MUST be issued put the stream into the Ready state, a PAUSE request MUST be issued.
to do that. A PLAY request while the stream is still in the Play A PLAY request while the stream is still in the Play state is legal
state is legal, and can be issued without an intervening PAUSE and can be issued without an intervening PAUSE request. Such a
request. Such a request MUST replace the current PLAY action with request MUST replace the current PLAY action with the new one
the new one requested, i.e., being handled in the same way as if as requested, i.e., being handled in the same way as if as the request
the request was received in Ready state. In the case that the range was received in Ready state. In the case that the range in the Range
in Range header has an implicit start time ("-endtime"), the server header has an implicit start time ("-endtime"), the server MUST
MUST continue to play from where it currently was until the specified continue to play from where it currently was until the specified
end point. This is useful to change the end to at another point than endpoint. This is useful to change the end to at another point than
in the previous request. 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 have been broken into several lines, where subsequent 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: N465Wvsv0cjUy6tLqINkcf
Range: smpte=0:10:20- Range: smpte=0:10:20-
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 833 CSeq: 833
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: 12345678 Session: N465Wvsv0cjUy6tLqINkcf
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Range: smpte=0:10:22-0:15:45 Range: smpte=0:10:22-0:15:45
Seek-Style: Next Seek-Style: Next
RTP-Info:url="rtsp://example.com/twister.en" RTP-Info:url="rtsp://example.com/twister.en"
ssrc=0D12F123:seq=14783;rtptime=2345962545 ssrc=0D12F123:seq=14783;rtptime=2345962545
For playing back a recording of a live presentation, it may be For playing back a recording of a live presentation, it may be
desirable to use clock units: desirable to use clock units:
C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: N465Wvsv0cjUy6tLqINkcf
Range: clock=19961108T142300Z-19961108T143520Z Range: clock=19961108T142300Z-19961108T143520Z
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 835 CSeq: 835
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: 12345678 Session: N465Wvsv0cjUy6tLqINkcf
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Range: clock=19961108T142300Z-19961108T143520Z Range: clock=19961108T142300Z-19961108T143520Z
Seek-Style: Next Seek-Style: Next
RTP-Info:url="rtsp://example.com/meeting.en" RTP-Info:url="rtsp://example.com/meeting.en"
ssrc=0D12F123:seq=53745;rtptime=484589019 ssrc=0D12F123:seq=53745;rtptime=484589019
13.4.2. Aggregated Sessions 13.4.2. Aggregated Sessions
PLAY requests can operate on sessions controlling a single media and PLAY requests can operate on sessions controlling a single media
on aggregated sessions controlling multiple media. stream and on aggregated sessions controlling multiple media streams.
In an aggregated session the PLAY request MUST contain an aggregated In an aggregated session, the PLAY request MUST contain an aggregated
control URI. A server MUST respond with error 460 (Only Aggregate control URI. A server MUST respond with a 460 error (Only Aggregate
Operation Allowed) if the client PLAY Request-URI is for a single Operation Allowed) if the client PLAY Request-URI is for a single
media. The media in an aggregate MUST be played in sync. If a media. The media in an aggregate MUST be played in sync. If a
client wants individual control of the media, it needs to use client wants individual control of the media, it needs to use
separate RTSP sessions for each media. separate RTSP sessions for each media.
For aggregated sessions where the initial SETUP request (creating a For aggregated sessions where the initial SETUP request (creating a
session) is followed by one or more additional SETUP requests, a PLAY session) is followed by one or more additional SETUP requests, a PLAY
request MAY be pipelined after those additional SETUP requests request MAY be pipelined (Section 12) after those additional SETUP
without awaiting their responses. This procedure can reduce the requests without awaiting their responses. This procedure can reduce
delay from start of session establishment until media play-out has the delay from the start of session establishment until media playout
started with one round trip time. However, a client needs to be has started with one RTT. However, a client needs to be aware that
aware that using this procedure will result in the playout of the using this procedure will result in the playout of the server state
server state established at the time of processing the PLAY, i.e., established at the time of processing the PLAY, i.e., after the
after the processing of all the requests prior to the PLAY request in processing of all the requests prior to the PLAY request in the
the pipeline. This state may not be the intended one due to failure pipeline. This state may not be the intended one due to failure of
of any of the prior requests. A client can easily determine this any of the prior requests. A client can easily determine this based
based on the responses from those requests. In case of failure, the on the responses from those requests. In case of failure, the client
client can halt the media playout using PAUSE and try to establish can halt the media playout using PAUSE and try to establish the
the intended state again before issuing another PLAY request. intended state again before issuing another PLAY request.
13.4.3. Updating current PLAY Requests 13.4.3. Updating Current PLAY Requests
Clients can issue PLAY 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 effect 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
A total replacement is signaled by having the first range continuation. A total replacement is signaled by having the first
specification have an explicit start value, e.g., "npt=45-" or range 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 if this
the request originally played. If the current delivery point is was 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 to with a 200 OK response. A PLAY_NOTIFY with end-of-stream is also
indicate the actual stop point. The pause point is set to the sent to indicate the actual stop point. The pause point is set to
requested stop point. the requested stop point.
Following is an example of this behavior: The server has received The 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: apzA8LnjQ5KWTdw0kUkiRh
Range: npt=10-15 Range: npt=10-15
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 834 CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: 12345678 Session: apzA8LnjQ5KWTdw0kUkiRh
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Range: npt=10-15 Range: npt=10-15
Seek-Style: Next Seek-Style: Next
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921, ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792482193 ssrc=789DAF12:seq=57654;rtptime=2792482193
Session: 12345678
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: apzA8LnjQ5KWTdw0kUkiRh
Range: npt=-25 Range: npt=-25
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 835 CSeq: 835
Date: Thu, 23 Jan 1997 15:35:09 GMT Date: Thu, 23 Jan 1997 15:35:09 GMT
Session: 12345678 Session: apzA8LnjQ5KWTdw0kUkiRh
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 fast forward or fast scale of the media, i.e., entering or leaving fast forward or fast
rewind. The client can issue an updating PLAY request that is either rewind. The client can issue an updating PLAY request that is either
a continuation or a complete replacement, as discussed above this a continuation or a complete replacement, as discussed above this
section. Below is an example of a client that is requesting a fast section. Below is an example of a client that is requesting a fast
forward (scale=2) without giving a stop point and then change from forward (scale = 2) without giving a stop point and then a change
fast forward to regular playout (scale = 1). In the second PLAY from 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 wherever 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=02:17:27.144-). (npt=02: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: apzA8LnjQ5KWTdw0kUkiRh
Range: npt=now- Range: npt=now-
Scale: 2.0 Scale: 2.0
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: 2034 CSeq: 2034
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: 12345678 Session: apzA8LnjQ5KWTdw0kUkiRh
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Range: npt=02:17:21.394- Range: npt=02:17:21.394-
Seek-Style: Next Seek-Style: Next
Scale: 2.0 Scale: 2.0
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921, ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792482193 ssrc=789DAF12:seq=57654;rtptime=2792482193
[playing in fast forward and now returning to scale = 1] [playing in fast forward and now returning to scale = 1]
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2035 CSeq: 2035
Session: 12345678 Session: apzA8LnjQ5KWTdw0kUkiRh
Range: npt=now- Range: npt=now-
Scale: 1.0 Scale: 1.0
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: 2035 CSeq: 2035
Date: Thu, 23 Jan 1997 15:35:09 GMT Date: Thu, 23 Jan 1997 15:35:09 GMT
Session: 12345678 Session: apzA8LnjQ5KWTdw0kUkiRh
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Range: npt=02:17:27.144- Range: npt=02:17:27.144-
Seek-Style: Next Seek-Style: Next
Scale: 1.0 Scale: 1.0
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.29): header in the SETUP response when (see also Section 18.29):
o Random Access property is set to Random-Access; o the Random Access property is set to Random-Access;
o Content Modifications set to Immutable; o the Content Modifications property is set to Immutable;
o Retention set to Unlimited or Time-Limited. o the Retention property is 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.29): Properties header in the SETUP response when (see also
Section 18.29):
o Random Access set to Random-Access; o the Random Access property is set to Random-Access;
o Content Modifications set to Dynamic; o the Content Modifications property is set to Dynamic;
o Retention set to Unlimited or Time-Limited. o the Retention property is 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 first being that the client will
request with Notify-Reason header set to media-properties-update (see receive a PLAY_NOTIFY request with the Notify-Reason header set to
Section 13.5.2. The client can use the value of the Media-Range to media-properties-update (see Section 13.5.2). The client can use the
decide further actions, if the Media-Range header is present in the value of the Media-Range header to decide further actions, if the
PLAY_NOTIFY request. The second way is that the client issues a Media-Range header is present in the PLAY_NOTIFY request. The second
GET_PARAMETER request without a body but including a Media-Range way is that the client issues a GET_PARAMETER request without a body
header. The 200 OK response MUST include the current Media-Range but including a Media-Range header. The 200 OK response MUST include
header (see Section 18.30). the current Media-Range 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.29): in the SETUP response when (see also Section 18.29):
o Random-Access set to No-Seeking;
o Content Modifications set to Time-Progressing; o the Random Access property is set to No-Seeking;
o Retention with Time-Duration set to 0.0. o the Content Modifications property is set to Time-Progressing;
o the Retention property's Time-Duration is set to 0.0.
For live media, the SETUP response 200 OK MUST include the Media- For live media, the SETUP 200 OK response MUST include the Media-
Range header (see Section 18.30). 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-" cannot be used in the response. Instead, the time
the time since session start is recommended expressed as an open since session start is recommended, expressed as an open interval,
interval, e.g., "npt=96.23-". An absolute time value (clock) for the e.g., "npt=96.23-". An absolute time value (clock) for the
corresponding time MAY be given, i.e., "clock=20030213T143205Z-". corresponding time MAY be given, i.e., "clock=20030213T143205Z-".
The Absolute Time format can only be used if client has shown support The Absolute Time format can only be used if the client has shown
for it using the Accept-Ranges header. support 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.29): Properties header in the SETUP response when (see also
Section 18.29):
o Random Access set to Random-Access; o the Random Access property is set to Random-Access;
o Content Modifications set to Time-Progressing; o the Content Modifications property is set to Time-Progressing;
o Retention set to Time-Limited or Unlimited o the Retention property is set to Time-Limited or Unlimited
The SETUP response 200 OK MUST include the Media-Range header (see The SETUP 200 OK response MUST include the Media-Range header (see
Section 18.30) 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 border of the window. If the client requests a delivery point that
is located outside the recording window, e.g., if the requested point is located outside the recording window, e.g., if the requested point
is too far in the past, the server selects the oldest point in the is too far in the past, the server selects the oldest point in the
recording. The considerations in Section 13.5.3 apply if a client recording. The considerations in Section 13.5.3 apply if a client
requests delivery with Scale (Section 18.46) values other than 1.0 requests delivery with scale (Section 18.46) values other than 1.0
(Normal playback 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.29): Properties header in the SETUP response when (see also
Section 18.29):
o Random Access set to Random-Access; o the Random Access property is set to Random-Access;
o Content Modifications set to Time-Progressing; o the Content Modifications property is set to Time-Progressing;
o Retention set to Time-Duration and a value indicating the o the Retention property is set to Time-Duration and a value
recording interval (>0). indicating the recording interval (>0).
The SETUP response 200 OK MUST include the Media-Range header (see The SETUP 200 OK response MUST include the Media-Range header (see
Section 18.30) for this type of media. For live media with recording Section 18.30) for this type of media. For live media with
the Range header indicates the current time in the media and the recording, the Range header indicates the current time in the media
Media Range indicates a window around the current time. This window and the Media-Range header indicates a window around the current
can cover recorded content in the past (seen from current time in the time. This window can cover recorded content in the past (seen from
media) or recorded content in the future (seen from current time in current time in the media) or recorded content in the future (seen
the media). The server adjusts the play point to the requested from current time in the media). The server adjusts the play point
border of the window, if the client requests a play point that is to the requested border of the window, if the client requests a play
located outside the recording windows, e.g., if requested too far in point that is located outside the recording windows, e.g., if
the past, the server selects the oldest range in the recording. The requested too far in the past, the server selects the oldest range in
considerations in Section 13.5.3 apply, if a client requests delivery the recording. The considerations in Section 13.5.3 apply if a
using a Scale (Section 18.46) value other than 1.0 (Normal playback client requests delivery using a scale (Section 18.46) value other
rate) while delivering live media with time-shift. than 1.0 (normal playback 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 PLAY_NOTIFY requests MAY use both an aggregate control URI and
individual media resource URIs depending on the scope of the individual media resource URIs, depending on the scope of the
notification. This scope may have important distinctions for notification. This scope may have important distinctions for
aggregated sessions, and each reason for a PLAY_NOTIFY request needs aggregated sessions, and each reason for a PLAY_NOTIFY request needs
to specify the interpretation and if aggregated control URIs or to specify the interpretation as well as if aggregated control URIs
individual URIs may be used in requests. or individual URIs may be used in requests.
PLAY_NOTIFY requests can be used with a message body, depending on PLAY_NOTIFY requests can 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 the use of 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.32) 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 can be added in the future (see Section 22.8). In case the reasons can 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. This document defines how servers can send PLAY_NOTIFY
with Notify-Reason values of 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 the Notify-Reason header set to end-of-
indicates the completion or near completion of the PLAY request and stream indicates the completion or near completion of the PLAY
the ending delivery of the media stream(s). The request MUST NOT be request and the ending delivery of the media stream(s). The request
issued unless the server is in the Play state. The end of the media MUST NOT be issued unless the server is in the Play state. The end
stream delivery notification may be used to indicate either a of the media stream delivery notification may be used either to
successful completion of the PLAY request currently being served, or indicate a successful completion of the PLAY request currently being
to indicate some error resulting in failure to complete the request. served or to indicate some error resulting in failure to complete the
The Request-Status header (Section 18.42) MUST be included to request. The Request-Status header (Section 18.42) MUST be included
indicate which request the notification is for and its completion to 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 MAY issue an updated PLAY_NOTIFY, in the case of a
PLAY_NOTIFY sent with wrong information. For instance, a PLAY_NOTIFY PLAY_NOTIFY sent with wrong information. For instance, a PLAY_NOTIFY
was issued before reaching the end-of-stream, but some error occurred was issued before reaching the end-of-stream, but some error occurred
resulting in that the previously sent PLAY_NOTIFY contained a wrong resulting in that the previously sent PLAY_NOTIFY contained a wrong
time when the stream will end. In this case a new PLAY_NOTIFY MUST time when the stream will end. In this case, a new PLAY_NOTIFY MUST
be sent including the correct status for the completion and all be sent including the correct status for the completion and all
additional information. additional information.
PLAY_NOTIFY requests with Notify-Reason header set to end-of-stream PLAY_NOTIFY requests with the Notify-Reason header set to end-of-
MUST include a Range header and the Scale header if the scale value stream MUST include a Range header and the Scale header if the scale
is not 1. The Range header indicates the point in the stream or value is not 1. The Range header indicates the point in the stream
streams where delivery is ending with the timescale that was used by or streams where delivery is ending with the timescale that was used
the server in the PLAY response for the request being fulfilled. The by the server in the PLAY response for the request being fulfilled.
server MUST NOT use the "now" constant in the Range header; it MUST The server MUST NOT use the "now" constant in the Range header; it
use the actual numeric end position in the proper timescale. When MUST use the actual numeric end position in the proper timescale.
end-of-stream notifications are issued prior to having sent the last When end-of-stream notifications are issued prior to having sent the
media packets, this is evident as the end time in the Range header is last media packets, this is made evident because the end time in the
beyond the current time in the media being received by the client, Range header is beyond the current time in the media being received
e.g., "npt=-15", if npt is currently at 14.2 seconds. The Scale by the client, e.g., "npt=-15", if npt is currently at 14.2 seconds.
header is to be included so that it is evident if the media time The Scale header is to be included so that it is evident if the media
scale is moving backwards and/or have a non-default pace. The end- timescale is moving backwards or has a non-default pace. The end-of-
of-stream notification does not prevent the client from sending a new 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, an 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 sequence parameter.
For an RTSP Session where media resources are under aggregated For an RTSP Session where media resources are under aggregated
control the media resources will normally end at approximately the control, the media resources will normally end at approximately the
same time, although some small differences may exist, on the scale of same time, although some small differences may exist, on the scale of
a few hundred of milliseconds. In those cases a RTSP session under a few hundred milliseconds. In those cases, an RTSP session under
aggregated control SHOULD send only a single PLAY_NOTIFY request. By aggregated control SHOULD send only a single PLAY_NOTIFY request. By
using the aggregate control URI in the PLAY_NOTIFY request the RTSP using the aggregate control URI in the PLAY_NOTIFY request, the RTSP
server indicates that this applies to all media resources within the server indicates that this applies to all media resources within the
session. In cases RTP is used for media delivery corresponding RTP- session. In cases in which RTP is used for media delivery,
Info needs to be included for all media resources. In cases where corresponding RTP-Info needs to be included for all media resources.
one or more media resource has significantly shorter duration than In cases where one or more media resources have a significantly
some other resources in the aggregated session the server MAY send shorter duration than some other resources in the aggregated session,
end-of-stream notifications using individual media resource URIs to the server MAY send end-of-stream notifications using individual
indicate to agents that there will be no more media for this media resource URIs to indicate to agents that there will be no more
particular media resource related to the current active PLAY request. media for this particular media resource related to the current
In such cases when the remaining media resources comes to end-of- active PLAY request. In such cases, when the remaining media
stream they MUST send a PLAY_NOTIFY request using the aggregate resources come to the end of the stream, they MUST send a PLAY_NOTIFY
control URI to indicate that no more resources remain. request using the aggregate control URI to indicate that no more
resources remain.
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/fizzle/foo/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" url="rtsp://example.com/fizzle/video"
ssrc=789DAF12:seq=57654;rtptime=2792482193 ssrc=789DAF12:seq=57654;rtptime=2792482193
Session: CDtUJfDQXJWtJ7Iqua2xOi
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: CDtUJfDQXJWtJ7Iqua2xOi
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 a 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.29) and/or the available media range given session (see Section 18.29) or the available media range that
that can be played as indicated by Media-Range (Section 18.30). can be played as indicated by the Media-Range header (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. The Media-Properties header has SHOULD include a Media-Range header. The Media-Properties header has
session scope, thus for aggregated sessions the PLAY_NOTIFY request session scope; thus, for aggregated sessions, the PLAY_NOTIFY request
MUST be using the aggregated control URI. MUST use 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 available for play-back media range will estimates on how the available for play-back media range will
progress with wall clock time. In addition it is RECOMMENDED that progress with wall clock time. In addition, it is RECOMMENDED that
the server sends these notifications approximately every 5 minutes the server send these notifications approximately every 5 minutes for
for time-progressing content to ensure the long-term stability of the time-progressing content to ensure the long-term stability of the
client estimation and allowing for clock skew detection by the client estimation and allow for clock skew detection by the client.
client. The time between notifications should be greater than 1 The time between notifications should be greater than 1 minute and
minute and less than 2 hours. For the reasons just explained, less than 2 hours. For the reasons just explained, requests MUST
requests MUST include a Media-Range header to provide current Media include a Media-Range header to provide current Media duration and a
duration and a Range header to indicate the current playing point and Range header to indicate the current playing point and any remaining
any remaining parts of the requested range. 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, it is only for determining which content is
to the user. available to the user.
A PLAY_NOTIFY request with Notify-Reason header set to media- A PLAY_NOTIFY request with Notify-Reason header set to media-
properties-update MUST NOT carry a message body. properties-update MUST NOT carry a message body.
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
Date: Tue, 14 Apr 2008 15:48:06 GMT Date: Tue, 14 Apr 2008 15:48:06 GMT
CSeq: 854 CSeq: 854
Notify-Reason: media-properties-update Notify-Reason: media-properties-update
Session: uZ3ci0K+Ld-M Session: CDtUJfDQXJWtJ7Iqua2xOi
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=00:00:00-01:37:21.394 Media-Range: npt=00:00:00-01:37:21.394
Range: npt=01:15:49.873- Range: npt=01: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: CDtUJfDQXJWtJ7Iqua2xOi
13.5.3. Scale-Change 13.5.3. Scale-Change
The server may be forced to change the rate of media time per The server may be forced to change the rate of media time per
playback time when a client requests delivery using a Scale playback time when a client requests delivery using a scale
(Section 18.46) value other than 1.0 (normal playback rate). For (Section 18.46) value other than 1.0 (normal playback rate). For
time progressing media with some retention, i.e., the server stores time-progressing media with some retention, i.e., the server stores
already sent content, a client requesting to play with Scale values already-sent content, a client requesting to play with scale values
larger than 1 may catch up with the front end of the media. The larger than 1 may catch up with the front end of the media. The
server will then be unable to continue to provide content at Scale server will then be unable to continue to provide content at scale
larger than 1 as content is only made available by the server at larger than 1 as content is only made available by the server at
Scale=1. Another case is when Scale < 1 and the media retention is scale = 1. Another case is when scale < 1 and the media retention is
time-duration limited. In this case the delivery point can reach the Time-Duration limited. In this case, the delivery point can reach
oldest media unit available, and further playback at this scale the oldest media unit available, and further playback at this scale
becomes impossible as there will be no media available. To avoid becomes impossible as there will be no media available. To avoid
having the client lose any media, the scale will need to be adjusted having the client lose any media, the scale will need to be adjusted
to the same rate at which the media is removed from the storage to the same rate at which the media is removed from the storage
buffer, commonly Scale = 1.0. 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
change from one supported scale value (different than Scale=1.0) to to change from one supported scale value (different than scale = 1.0)
another. In this case the server will pick the closest value and to 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 Scale value used. 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, 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 when the change took effect, a Scale Range header with the media time when the change took effect, a Scale
header with the new value in use, Session header with the identifier header with the new value in use, a Session header with the
for the session it applies to and a Date header with the server identifier for the session to which it applies, and a Date header
wallclock time of the change. For time progressing content also the with the server wallclock time of the change. For time-progressing
Media-Range and the Media-Properties at this point in time MUST be content, the Media-Range and the Media-Properties headers at this
included. The Media-Properties header MUST be included if the scale point in time also MUST be included. The Media-Properties header
change was due to the content changing what scale values that is MUST be included if the scale change was due to the content changing
supported. what scale values ("Scales") are supported.
For media streams being delivered using RTP also a RTP-Info header For media streams delivered using RTP, an RTP-Info header MUST also
MUST be included. It MUST contain the rtptime parameter with a value 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 the
also the sequence number. sequence number.
PLAY_NOTIFY requests for aggregated sessions MUST use the aggregated PLAY_NOTIFY requests for aggregated sessions MUST use the aggregated
control URI in the request. The scale change for any aggregated control URI in the request. The scale change for any aggregated
session applies to all media streams part of the aggregate. session applies to all media streams that are 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: CDtUJfDQXJWtJ7Iqua2xOi
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=00:00:00-01:37:21.394 Media-Range: npt=00:00:00-01:37:21.394
Range: npt=01:37:21.394- Range: npt=01: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" url="rtsp://example.com/fizzle/foo/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792482193 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: CDtUJfDQXJWtJ7Iqua2xOi
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 made either with the
aggregated control URI for aggregated sessions, resulting in all aggregated control URI for aggregated sessions, resulting in all
media being halted, or the media URI for non-aggregated sessions. media being halted, or with the media URI for non-aggregated
sessions. Any attempt to mute a single media with a PAUSE request in
Any attempt to do muting of a single media with a PAUSE request in an an aggregated session MUST be responded to with a 460 (Only Aggregate
aggregated session MUST be responded to with error 460 (Only Operation Allowed) error. After resuming playback, synchronization
Aggregate Operation Allowed). After resuming playback, of the tracks MUST be maintained. Any server resources are kept,
synchronization of the tracks MUST be maintained. Any server though servers MAY close the session and free resources after being
resources are kept, though servers MAY close the session and free paused for the duration specified with the timeout parameter of the
resources after being paused for the duration specified with the Session header in the SETUP message.
timeout parameter of the Session header in the SETUP message.
Example: Example:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: OoOUPyUwt0VeY9fFRHuZ6L
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 834 CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: OoOUPyUwt0VeY9fFRHuZ6L
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 a
Range header resumes 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, MUST use "npt=now-" and not request to start media delivery again MUST use "npt=now-" and not the
the answer given in the response to PAUSE. 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: OccldOFFq23KwjYpAnBbUr
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: OccldOFFq23KwjYpAnBbUr
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: OccldOFFq23KwjYpAnBbUr
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
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
If a client issues a PAUSE request and the server acknowledges and If a client issues a PAUSE request and the server acknowledges and
enters the Ready state, the proper server response, if the player enters the Ready state, the proper server response, if the player
issues another PAUSE, is still 200 OK. The 200 OK response MUST issues another PAUSE, is still 200 OK. The 200 OK response MUST
include the Range header with the current pause point. See examples include the Range header with the current pause point. See examples
below: below:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 834 CSeq: 834
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Range: npt=45.76-98.36 Range: npt=45.76-98.36
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 835 CSeq: 835
Session: 12345678 Session: OccldOFFq23KwjYpAnBbUr
Date: 23 Jan 1997 15:35:07 GMT Date: 23 Jan 1997 15:35:07 GMT
Range: npt=45.76-98.36 Range: npt=45.76-98.36
13.7. TEARDOWN 13.7. TEARDOWN
13.7.1. Client to Server 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 can be performed on either an aggregated or a media control request can 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. The TEARDOWN request MUST NOT to what session the request applies. The TEARDOWN request MUST NOT
include a Terminate-Reason header. 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 can only be A TEARDOWN using a media URI in an aggregated session can 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
a session returning to non-aggregated control, because it only a session returning to non-aggregated control, because it only
contains a single media after the request's 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.
the presence of the Session header indicates to the receiver of the
response if the session is still extant or has been removed. Thus, the presence of the Session header indicates to the receiver of
the response if the session is still extant 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: OccldOFFq23KwjYpAnBbUr
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 892 CSeq: 892
Server: PhonyServer/1.0 Server: PhonyServer/1.0
13.7.2. Server to Client 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.52). in the Terminate-Reason header (Section 18.52).
When a RTSP client has maintained a RTSP session that otherwise is When an RTSP client has maintained an 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.49). However, the server is Session Timeout period (Section 18.49). However, the server is NOT
RECOMMENDED to not perform this operation until an extended period of RECOMMENDED to perform this operation until an extended period of
inactivity of 10 times the Session Timeout period has passed. It is inactivity of 10 times the Session-Timeout period has passed. It is
up to the operator of the RTSP server to actually configure how long up to the operator of the RTSP server to actually configure how long
this extended period of inactivity is. An operator should take into this extended period of inactivity is. An operator should take into
account when doing this configuration what the served content is and account, when doing this configuration, what the served content is
what this means for the extended period of inactivity. 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 than to terminate the sessions.
The TEARDOWN request MUST be done only on the session aggregate The TEARDOWN request MUST be made 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 it MUST include the
headers; Session and