draft-ietf-mmusic-rfc2326bis-06.txt   draft-ietf-mmusic-rfc2326bis-07.txt 
Internet Engineering Task Force MMUSIC WG Internet Engineering Task Force MMUSIC WG
Internet Draft H. Schulzrinne/Columbia U. Internet Draft H. Schulzrinne
draft-ietf-mmusic-rfc2326bis-06.txt A. Rao/Cisco draft-ietf-mmusic-rfc2326bis-07.txt Columbia U.
February 16, 2004 R. Lanphier/RealNetworks July 19, 2004 A. Rao
Expires: August, 2004 M. Westerlund/Ericsson Expires: January, 2005 Cisco
A. Narasimhan/Sun R. Lanphier
RealNetworks
M. Westerlund
Ericsson
A. Narasimhan
Princeton
Real Time Streaming Protocol (RTSP) Real Time Streaming Protocol (RTSP)
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I (we) certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am (we are) aware have been
disclosed, and any of which I (we) become aware will be disclosed, in
accordance with RFC 3668 (BCP 79).
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
skipping to change at page 3, line 7 skipping to change at page 3, line 7
properties. RTSP provides an extensible framework to enable properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and controlled, on-demand delivery of real-time data, such as audio and
video. Sources of data can include both live data feeds and stored video. Sources of data can include both live data feeds and stored
clips. This protocol is intended to control multiple data delivery clips. This protocol is intended to control multiple data delivery
sessions, provide a means for choosing delivery channels such as UDP, sessions, provide a means for choosing delivery channels such as UDP,
multicast UDP and TCP, and provide a means for choosing delivery multicast UDP and TCP, and provide a means for choosing delivery
mechanisms based upon RTP (RFC 3550). mechanisms based upon RTP (RFC 3550).
Table of Contents Table of Contents
1 Introduction ........................................ 8 1 Introduction ........................................ 9
1.1 The Update of the RTSP Specification ................ 8 1.1 RTSP Specification Update ........................... 9
1.2 Purpose ............................................. 9 1.2 Purpose ............................................. 10
1.3 Notational Conventions .............................. 11 1.3 Notational Conventions .............................. 11
1.4 Terminology ......................................... 11 1.4 Terminology ......................................... 12
1.5 Protocol Properties ................................. 14 1.5 Protocol Properties ................................. 15
1.6 Extending RTSP ...................................... 16 1.6 Extending RTSP ...................................... 17
1.7 Overall Operation ................................... 17 1.7 Overall Operation ................................... 18
1.8 RTSP States ......................................... 18 1.8 RTSP States ......................................... 19
1.9 Relationship with Other Protocols ................... 19 1.9 Relationship with Other Protocols ................... 20
2 RTSP Use Cases ...................................... 19 2 RTSP Use Cases ...................................... 20
2.1 On-demand Playback of Stored Content ................ 20 2.1 On-demand Playback of Stored Content ................ 20
2.2 Unicast distribution of Live Content ................ 20 2.2 Unicast distribution of Live Content ................ 22
2.3 Inviting RTSP on-demand servers into a multicast 2.3 On-demand Playback using Multicast .................. 22
group ............................................... 20 2.4 Inviting a RTSP server into a conference ............ 23
2.4 On-demand Playback using Multicast .................. 20 2.5 Live Content using Multicast ........................ 24
3 Protocol Parameters ................................. 20 3 Protocol Parameters ................................. 25
3.1 RTSP Version ........................................ 20 3.1 RTSP Version ........................................ 25
3.2 RTSP URL ............................................ 20 3.2 RTSP URL ............................................ 25
3.3 Session Identifiers ................................. 22 3.3 Session Identifiers ................................. 26
3.4 SMPTE Relative Timestamps ........................... 22 3.4 SMPTE Relative Timestamps ........................... 27
3.5 Normal Play Time .................................... 22 3.5 Normal Play Time .................................... 27
3.6 Absolute Time ....................................... 23 3.6 Absolute Time ....................................... 28
3.7 Feature-tags ........................................ 23 3.7 Feature-tags ........................................ 28
4 RTSP Message ........................................ 24 3.8 Entity Tags ......................................... 29
4.1 Message Types ....................................... 24 4 RTSP Message ........................................ 29
4.2 Message Headers ..................................... 24 4.1 Message Types ....................................... 29
4.3 Message Body ........................................ 25 4.2 Message Headers ..................................... 30
4.4 Message Length ...................................... 25 4.3 Message Body ........................................ 30
5 General Header Fields ............................... 25 4.4 Message Length ...................................... 30
6 Request ............................................. 25 5 General Header Fields ............................... 30
6.1 Request Line ........................................ 26 6 Request ............................................. 30
6.2 Request Header Fields ............................... 27 6.1 Request Line ........................................ 31
7 Response ............................................ 27 6.2 Request Header Fields ............................... 32
7.1 Status-Line ......................................... 28 7 Response ............................................ 32
7.1.1 Status Code and Reason Phrase ....................... 28 7.1 Status-Line ......................................... 33
7.1.2 Response Header Fields .............................. 29 7.1.1 Status Code and Reason Phrase ....................... 33
8 Entity .............................................. 30 7.1.2 Response Header Fields .............................. 35
8.1 Entity Header Fields ................................ 32 8 Entity .............................................. 35
8.2 Entity Body ......................................... 32 8.1 Entity Header Fields ................................ 35
9 Connections ......................................... 32 8.2 Entity Body ......................................... 35
9.1 Pipelining .......................................... 33 9 Connections ......................................... 36
9.2 Reliability and Acknowledgements .................... 33 9.1 Pipelining .......................................... 36
9.3 Unreliable Transport ................................ 34 9.2 Reliability and Acknowledgements .................... 36
9.4 The usage of connections ............................ 34 9.3 Unreliable Transport ................................ 39
9.5 Timing Out RTSP messages ............................ 36 9.4 The usage of connections ............................ 39
9.6 Use of IPv6 ......................................... 36 9.5 Timing Out RTSP messages ............................ 41
10 Capability Handling ................................. 37 9.6 Use of IPv6 ......................................... 41
11 Method Definitions .................................. 38 10 Capability Handling ................................. 42
11.1 OPTIONS ............................................. 39 11 Method Definitions .................................. 43
11.2 DESCRIBE ............................................ 40 11.1 OPTIONS ............................................. 44
11.3 SETUP ............................................... 42 11.2 DESCRIBE ............................................ 45
11.4 PLAY ................................................ 44 11.3 SETUP ............................................... 47
11.5 PAUSE ............................................... 48 11.4 PLAY ................................................ 50
11.6 TEARDOWN ............................................ 51 11.5 PAUSE ............................................... 54
11.7 GET_PARAMETER ....................................... 52 11.6 TEARDOWN ............................................ 58
11.8 SET_PARAMETER ....................................... 53 11.7 GET_PARAMETER ....................................... 58
11.9 REDIRECT ............................................ 55 11.8 SET_PARAMETER ....................................... 59
11.10 PING ................................................ 56 11.9 REDIRECT ............................................ 61
12 Embedded (Interleaved) Binary Data .................. 57 11.10 PING ................................................ 63
13 Status Code Definitions ............................. 59 12 Embedded (Interleaved) Binary Data .................. 64
13.1 Success 1xx ......................................... 59 13 Status Code Definitions ............................. 65
13.1.1 100 Continue ........................................ 59 13.1 Success 1xx ......................................... 66
13.2 Success 2xx ......................................... 59 13.1.1 100 Continue ........................................ 66
13.3 Redirection 3xx ..................................... 59 13.2 Success 2xx ......................................... 66
13.3.1 TBW ................................................. 60 13.3 Redirection 3xx ..................................... 66
13.3.2 301 Moved Permanently ............................... 60 13.3.1 TBW ................................................. 66
13.3.3 302 Found ........................................... 60 13.3.2 301 Moved Permanently ............................... 66
13.3.4 303 See Other ....................................... 60 13.3.3 302 Found ........................................... 66
13.3.5 304 Not Modified .................................... 60 13.3.4 303 See Other ....................................... 67
13.3.6 305 Use Proxy ....................................... 61 13.3.5 304 Not Modified .................................... 67
13.4 Client Error 4xx .................................... 61 13.3.6 305 Use Proxy ....................................... 67
13.4.1 400 Bad Request ..................................... 61 13.4 Client Error 4xx .................................... 67
13.4.2 405 Method Not Allowed .............................. 61 13.4.1 400 Bad Request ..................................... 67
13.4.3 451 Parameter Not Understood ........................ 61 13.4.2 405 Method Not Allowed .............................. 68
13.4.4 452 reserved ........................................ 61 13.4.3 451 Parameter Not Understood ........................ 68
13.4.5 453 Not Enough Bandwidth ............................ 61 13.4.4 452 reserved ........................................ 68
13.4.6 454 Session Not Found ............................... 62 13.4.5 453 Not Enough Bandwidth ............................ 68
13.4.7 455 Method Not Valid in This State .................. 62 13.4.6 454 Session Not Found ............................... 68
13.4.8 456 Header Field Not Valid for Resource ............. 62 13.4.7 455 Method Not Valid in This State .................. 68
13.4.9 457 Invalid Range ................................... 62 13.4.8 456 Header Field Not Valid for Resource ............. 68
13.4.10 458 Parameter Is Read-Only .......................... 62 13.4.9 457 Invalid Range ................................... 69
13.4.11 459 Aggregate Operation Not Allowed ................. 62 13.4.10 458 Parameter Is Read-Only .......................... 69
13.4.12 460 Only Aggregate Operation Allowed ................ 62 13.4.11 459 Aggregate Operation Not Allowed ................. 69
13.4.13 461 Unsupported Transport ........................... 62 13.4.12 460 Only Aggregate Operation Allowed ................ 69
13.4.14 462 Destination Unreachable ......................... 63 13.4.13 461 Unsupported Transport ........................... 69
13.5 Server Error 5xx .................................... 63 13.4.14 462 Destination Unreachable ......................... 69
13.5.1 551 Option not supported ............................ 63 13.4.15 470 Connection Authorization Required ............... 69
14 Header Field Definitions ............................ 63 13.4.16 471 Connection Credentials not accepted ............. 69
14.1 Accept .............................................. 65 13.5 Server Error 5xx .................................... 69
14.2 Accept-Encoding ..................................... 65 13.5.1 551 Option not supported ............................ 70
14.3 Accept-Language ..................................... 66 14 Header Field Definitions ............................ 70
14.4 Accept-Ranges ....................................... 66 14.1 Accept .............................................. 72
14.5 Allow ............................................... 66 14.2 Accept-Credentials .................................. 72
14.6 Authorization ....................................... 66 14.3 Accept-Encoding ..................................... 77
14.7 Bandwidth ........................................... 66 14.4 Accept-Language ..................................... 77
14.8 Blocksize ........................................... 68 14.5 Accept-Ranges ....................................... 77
14.9 Cache-Control ....................................... 70 14.6 Allow ............................................... 77
14.10 Connection .......................................... 72 14.7 Authorization ....................................... 77
14.11 Content-Base ........................................ 73 14.8 Bandwidth ........................................... 78
14.12 Content-Encoding .................................... 73 14.9 Blocksize ........................................... 78
14.13 Content-Language .................................... 73 14.10 Cache-Control ....................................... 78
14.14 Content-Length ...................................... 73 14.11 Connection .......................................... 81
14.15 Content-Location .................................... 73 14.12 Content-Base ........................................ 81
14.16 Content-Type ........................................ 73 14.13 Content-Encoding .................................... 81
14.17 CSeq ................................................ 73 14.14 Content-Language .................................... 81
14.18 Date ................................................ 74 14.15 Content-Length ...................................... 81
14.19 Expires ............................................. 74 14.16 Content-Location .................................... 81
14.20 From ................................................ 75 14.17 Content-Type ........................................ 81
14.21 Host ................................................ 75 14.18 CSeq ................................................ 82
14.22 If-Match ............................................ 75 14.19 Date ................................................ 82
14.23 If-Modified-Since ................................... 75 14.20 ETag ................................................ 82
14.24 Last-Modified ....................................... 76 14.21 Expires ............................................. 83
14.25 Location ............................................ 76 14.22 From ................................................ 83
14.26 Proxy-Authenticate .................................. 76 14.23 Host ................................................ 84
14.27 Proxy-Require ....................................... 76 14.24 If-Match ............................................ 84
14.28 Public .............................................. 77 14.25 If-Modified-Since ................................... 84
14.29 Range ............................................... 77 14.26 If-None-Match ....................................... 84
14.30 Referer ............................................. 79 14.27 Last-Modified ....................................... 85
14.31 Retry-After ......................................... 79 14.28 Location ............................................ 85
14.32 Require ............................................. 79 14.29 Proxy-Authenticate .................................. 85
14.33 RTP-Info ............................................ 80 14.30 Proxy-Require ....................................... 85
14.34 Scale ............................................... 82 14.31 Public .............................................. 85
14.35 Speed ............................................... 82 14.32 Range ............................................... 86
14.36 Server .............................................. 83 14.33 Referer ............................................. 88
14.37 Session ............................................. 83 14.34 Retry-After ......................................... 88
14.38 Supported ........................................... 85 14.35 Require ............................................. 88
14.39 Timestamp ........................................... 86 14.36 RTP-Info ............................................ 89
14.40 Transport ........................................... 86 14.37 Scale ............................................... 91
14.41 Unsupported ......................................... 92 14.38 Speed ............................................... 92
14.42 User-Agent .......................................... 92 14.39 Server .............................................. 92
14.43 Vary ................................................ 93 14.40 Session ............................................. 92
14.44 Via ................................................. 93 14.41 Supported ........................................... 94
14.45 WWW-Authenticate .................................... 93 14.42 Timestamp ........................................... 95
15 Caching ............................................. 93 14.43 Transport ........................................... 95
16 Examples ............................................ 94 14.44 Unsupported ......................................... 101
16.1 Media on Demand (Unicast) ........................... 94 14.45 User-Agent .......................................... 102
16.2 Streaming of a Container file ....................... 97 14.46 Vary ................................................ 102
16.3 Single Stream Container Files ....................... 100 14.47 Via ................................................. 102
16.4 Live Media Presentation Using Multicast ............. 101 14.48 WWW-Authenticate .................................... 102
16.5 Capability Negotiation .............................. 103 15 Caching ............................................. 102
17 Syntax .............................................. 104 16 Examples ............................................ 103
17.1 Base Syntax ......................................... 104 16.1 Media on Demand (Unicast) ........................... 103
17.2 RTSP Protocol Definition ............................ 105 16.2 Streaming of a Container file ....................... 106
17.2.1 Generic Protocol elements ........................... 105 16.3 Single Stream Container Files ....................... 109
17.2.2 Message Syntax ...................................... 106 16.4 Live Media Presentation Using Multicast ............. 111
17.2.3 Header Syntax ....................................... 110 16.5 Capability Negotiation .............................. 112
18 Security Considerations ............................. 112 17 Security Framework .................................. 113
19 IANA Considerations ................................. 115 17.1 RTSP and HTTP Authentication ........................ 113
19.1 Feature-tags ........................................ 115 17.2 RTSP over TLS ....................................... 114
19.1.1 Description ......................................... 115 17.3 Security and Proxies ................................ 114
19.1.2 Registering New Feature-tags with IANA .............. 116 17.3.1 Accept-Credentials .................................. 115
19.1.3 Registered entries .................................. 116 17.3.2 User approved TLS procedure ......................... 116
19.2 RTSP Methods ........................................ 116 18 Syntax .............................................. 118
19.2.1 Description ......................................... 116 18.1 Base Syntax ......................................... 118
19.2.2 Registering New Methods with IANA ................... 116 18.2 RTSP Protocol Definition ............................ 119
19.2.3 Registered Entries .................................. 117 18.2.1 Generic Protocol elements ........................... 119
19.3 RTSP Status Codes ................................... 117 18.2.2 Message Syntax ...................................... 120
19.3.1 Description ......................................... 117 18.2.3 Header Syntax ....................................... 124
19.3.2 Registering New Status Codes with IANA .............. 117 19 Security Considerations ............................. 126
19.3.3 Registered Entries .................................. 117 20 IANA Considerations ................................. 128
19.4 RTSP Headers ........................................ 117 20.1 Feature-tags ........................................ 129
19.4.1 Description ......................................... 117 20.1.1 Description ......................................... 129
19.4.2 Registering New Headers with IANA ................... 118 20.1.2 Registering New Feature-tags with IANA .............. 129
19.4.3 Registered entries .................................. 118 20.1.3 Registered entries .................................. 130
19.5 Transport Header registries ......................... 118 20.2 RTSP Methods ........................................ 130
19.5.1 Transport Protocols ................................. 119 20.2.1 Description ......................................... 130
19.5.2 Profile ............................................. 119 20.2.2 Registering New Methods with IANA ................... 130
19.5.3 Lower Transport ..................................... 119 20.2.3 Registered Entries .................................. 131
19.5.4 Transport modes ..................................... 120 20.3 RTSP Status Codes ................................... 131
19.6 Cache Directive Extensions .......................... 120 20.3.1 Description ......................................... 131
19.7 SDP attributes ...................................... 121 20.3.2 Registering New Status Codes with IANA .............. 131
A RTSP Protocol State Machine ......................... 122 20.3.3 Registered Entries .................................. 131
A.1 States .............................................. 122 20.4 RTSP Headers ........................................ 131
A.2 State variables ..................................... 122 20.4.1 Description ......................................... 131
A.3 Abbreviations ....................................... 122 20.4.2 Registering New Headers with IANA ................... 131
A.4 State Tables ........................................ 123 20.4.3 Registered entries .................................. 132
B Media Transport Alternatives ........................ 125 20.5 Transport Header registries ......................... 132
B.1 RTP ................................................. 126 20.5.1 Transport Protocols ................................. 132
B.1.1 AVP ................................................. 126 20.5.2 Profile ............................................. 133
B.1.2 AVP/UDP ............................................. 127 20.5.3 Lower Transport ..................................... 133
B.1.3 AVP/TCP ............................................. 128 20.5.4 Transport modes ..................................... 134
B.1.4 Handling NPT Jumps in the RTP Media Layer ........... 129 20.6 Cache Directive Extensions .......................... 134
B.1.5 Handling RTP Timestamps after PAUSE ................. 131 20.7 Accept-Credentials policies ......................... 135
B.1.6 RTSP / RTP Integration .............................. 133 20.8 SDP attributes ...................................... 135
B.1.7 Scaling with RTP .................................... 133 A RTSP Protocol State Machine ......................... 136
A.1 States .............................................. 137
A.2 State variables ..................................... 137
A.3 Abbreviations ....................................... 137
A.4 State Tables ........................................ 137
B Media Transport Alternatives ........................ 141
B.1 RTP ................................................. 141
B.1.1 AVP ................................................. 141
B.1.2 AVP/UDP ............................................. 141
B.1.3 AVP/TCP ............................................. 143
B.1.4 Handling NPT Jumps in the RTP Media Layer ........... 143
B.1.5 Handling RTP Timestamps after PAUSE ................. 145
B.1.6 RTSP / RTP Integration .............................. 148
B.1.7 Scaling with RTP .................................... 148
B.1.8 Maintaining NPT synchronization with RTP B.1.8 Maintaining NPT synchronization with RTP
timesatmps .......................................... 133 timestamps .......................................... 148
B.1.9 Continuous Audio .................................... 134 B.1.9 Continuous Audio .................................... 148
B.1.10 Multiple Sources in an RTP Session .................. 134 B.1.10 Multiple Sources in an RTP Session .................. 148
B.1.11 Usage of SSRCs and the RTCP BYE Message During a B.1.11 Usage of SSRCs and the RTCP BYE Message During a
RTSP Session ........................................ 134 RTSP Session ........................................ 148
B.2 Future Additions .................................... 134 B.2 Future Additions .................................... 149
C Use of SDP for RTSP Session Descriptions ............ 135 C Use of SDP for RTSP Session Descriptions ............ 150
C.1 Definitions ......................................... 135 C.1 Definitions ......................................... 150
C.1.1 Control URL ......................................... 135 C.1.1 Control URL ......................................... 150
C.1.2 Media Streams ....................................... 136 C.1.2 Media Streams ....................................... 151
C.1.3 Payload Type(s) ..................................... 137 C.1.3 Payload Type(s) ..................................... 152
C.1.4 Format-Specific Parameters .......................... 137 C.1.4 Format-Specific Parameters .......................... 152
C.1.5 Range of Presentation ............................... 137 C.1.5 Range of Presentation ............................... 152
C.1.6 Time of Availability ................................ 138 C.1.6 Time of Availability ................................ 153
C.1.7 Connection Information .............................. 138 C.1.7 Connection Information .............................. 153
C.1.8 Entity Tag .......................................... 139 C.1.8 Entity Tag .......................................... 153
C.2 Aggregate Control Not Available ..................... 139 C.2 Aggregate Control Not Available ..................... 154
C.3 Aggregate Control Available ......................... 140 C.3 Aggregate Control Available ......................... 155
C.4 RTSP external SDP delivery .......................... 141 C.4 RTSP external SDP delivery .......................... 156
D Minimal RTSP implementation ......................... 141 D Minimal RTSP implementation ......................... 156
D.1 Client .............................................. 141 D.1 Client .............................................. 156
D.1.1 Basic Playback ...................................... 142 D.1.1 Basic Playback ...................................... 157
D.1.2 Authentication-enabled .............................. 142 D.1.2 Authentication-enabled .............................. 157
D.2 Server .............................................. 143 D.2 Server .............................................. 157
D.2.1 Basic Playback ...................................... 143 D.2.1 Basic Playback ...................................... 158
D.2.2 Authentication-enabled .............................. 144 D.2.2 Authentication-enabled .............................. 159
E Open Issues ......................................... 144 E Open Issues ......................................... 159
F Changes ............................................. 145 F Changes ............................................. 160
G Author Addresses .................................... 151 G Author Addresses .................................... 166
H Contributors ........................................ 152 H Contributors ........................................ 167
I Acknowledgements .................................... 152 I Acknowledgements .................................... 167
J Normative References ................................ 152 J Normative References ................................ 168
K Informative References .............................. 154 K Informative References .............................. 169
1 Introduction 1 Introduction
1.1 The Update of the RTSP Specification 1.1 RTSP Specification Update
This is the draft to an update of RTSP which is currently a proposed | This document is a draft to an update of RTSP, a proposed standard |
standard defined in RFC 2326 [1]. Many flaws have been found in RTSP | defined in RFC 2326 [1]. The goal the update is to progress RTSP to |
since it was published. While this draft tries to address the flaws, | draft standard status. Many flaws have been identified in RTSP since |
not all known issues have been resolved. However in this version only | its publication. While this draft tries to address these flaws, not |
a few remains, please see Open Issues in section E. all known issues have been resolved. Appendix F catalogs the issues |
that have already been addressed. Known open issues are listed in |
appendix E. |
The goal of the current work on RTSP is to progress it to draft The possibility of progressing RTSP to draft standard without |
standard status. Whether this is possible without first republishing republishing RTSP as a proposed standard depends on the changes |
RTSP as a proposed standard depends on the changes necessary to make necessary to make the protocol work. |
the protocol work. The list of changes in appendix F indicates the
issues that have already been addressed. The currently open issues
are listed in appendix E.
There is also a list of reported bugs available at A list of bugs against the specification is available at |
"http://rtspspec.sourceforge.net". These bugs should be taken into "http://rtspspec.sourceforge.net". These bugs should be taken into |
account when reading this specification. While a lot of these bugs account when reading this specification. Input on the unresolved bugs |
are addressed, not all are yet accounted for in this specification. and other issues can be sent via e-mail to the MMUSIC WG's mailing |
Input on the unresolved bugs and other issues can be sent via e-mail list mmusic@ietf.org and the authors.
to the MMUSIC WG's mailing list mmusic@ietf.org and the authors.
Not all of the contents of RFC 2326 are part of this draft. In an | Not all of the contents of RFC 2326 are part of this draft. In an |
attempt to prevent the draft from exploding in size, the | attempt to prevent bloat, the specification has been reduced and |
specification has been reduced and split. The content of this draft | split. The content of this draft is the core specification of the
is the core specification of the protocol. It contains the general | protocol. It contains the general idea behind RTSP and the basic
idea behind RTSP and the basic functionality necessary to establish | functionality necessary to establish an on-demand play-back session.
an on-demand play-back session. It also contains the mechanisms for | It also contains the mechanisms for extending the protocol. Any other
extending the protocol. Any other functionality will be published as | functionality will be published as extension documents. The Working |
extension documents. The Working group currently is working on: | group is currently working on:
o NAT and FW traversal mechanisms for RTSP are described in a | o NAT and FW traversal mechanisms for RTSP are described in a
document called "How to make Real-Time Streaming Protocol | document called "How to make Real-Time Streaming Protocol
(RTSP) traverse Network Address Translators (NAT) and interact | (RTSP) traverse Network Address Translators (NAT) and interact
with Firewalls." [20]. | with Firewalls." [24].
There have also been discussion or proposals about the following | There have also been discussion or proposals about the following
extensions to RTSP: | extensions to RTSP:
o Mute and Unmute Extension [21]. | o Mute and Unmute Extension [25].
o RTSP Stream Switching [22]. | o RTSP Stream Switching [26].
o Live Streaming Relays [23]. | o Live Streaming Relays [27].
o Transport security for RTSP messages (rtsps). | o Unreliable transport of RTSP messages (rtspu).
o Unreliable transport of RTSP messages (rtspu). |
o The Record functionality. | o The Record functionality.
o A text body type with suitable syntax for basic parameters to | o A text body type with suitable syntax for basic parameters to
be used in SET_PARAMETER, and GET_PARAMETER. Including IANA | be used in SET_PARAMETER, and GET_PARAMETER. Including IANA
registry within the defined name space. | registry within the defined name space.
o A RTSP MIB. | o A RTSP MIB.
1.2 Purpose 1.2 Purpose
The Real-Time Streaming Protocol (RTSP) establishes and controls The Real-Time Streaming Protocol (RTSP) establishes and controls
single or several time-synchronized streams of continuous media such single or several time-synchronized streams of continuous media such
as audio and video. Put simply, RTSP acts as a "network remote as audio and video. Put simply, RTSP acts as a "network remote
control" for multimedia servers. control" for multimedia servers.
There is no notion of a RTSP connection in the protocol. Instead, a There is no notion of a RTSP connection in the protocol. Instead, a
RTSP server maintains a session labelled by an identifier to RTSP server maintains a session labelled by an identifier to
skipping to change at page 9, line 41 skipping to change at page 10, line 38
While nothing in RTSP precludes this, additional definition of this While nothing in RTSP precludes this, additional definition of this
problem area must be handled as an extension to the core problem area must be handled as an extension to the core
specification. specification.
The mechanisms of RTSP's operation over UDP were left out The mechanisms of RTSP's operation over UDP were left out
of this spec. because they were poorly defined in RFC 2326 of this spec. because they were poorly defined in RFC 2326
[1] and the tradeoff in size and complexity of this spec. [1] and the tradeoff in size and complexity of this spec.
for a small gain in a targeted problem space was not deemed for a small gain in a targeted problem space was not deemed
justifiable. justifiable.
The set of streams to be controlled is defined by a presentation | The set of streams to be controlled in a RTSP session is defined by a |
description. This memorandum does not define a format for the | presentation description. This memorandum does not define a format
presentation description. However appendix C defines how SDP [2] is | for the presentation description. However appendix C defines how SDP
used for this purpose. The streams controlled by RTSP may use RTP [3] | [2] is used for this purpose. The streams controlled by RTSP may use
for their data transport, but the operation of RTSP does not depend | RTP [3] for their data transport, but the operation of RTSP does not
on the transport mechanism used to carry continuous media. The | depend on the transport mechanism used to carry continuous media. |
protocol is intentionally similar in syntax and operation to HTTP/1.1 | RTSP is intentionally similar in syntax and operation to HTTP/1.1 [4]
[4] so that extension mechanisms to HTTP can in most cases also be | so that extension mechanisms to HTTP can in most cases also be added
added to RTSP. However, RTSP differs in a number of important aspects | to RTSP. However, RTSP differs in a number of important aspects from
from HTTP: HTTP:
o RTSP introduces a number of new methods and has a different o RTSP introduces a number of new methods and has a different
protocol identifier. protocol identifier.
o RTSP has the notion of a session built into the protocol. o RTSP has the notion of a session built into the protocol.
o A RTSP server needs to maintain state by default in almost all o A RTSP server needs to maintain state by default in almost all
cases, as opposed to the stateless nature of HTTP. cases, as opposed to the stateless nature of HTTP.
o Both a RTSP server and client can issue requests. o Both a RTSP server and client can issue requests.
o Data is usually carried out-of-band by a different protocol. o Data is usually carried out-of-band by a different protocol.
Session descriptions returned in a DESCRIBE response (see Session descriptions returned in a DESCRIBE response (see
Section 11.2) and interleaving of RTP with RTSP over TCP are Section 11.2) and interleaving of RTP with RTSP over TCP are
exceptions to this rule (see Section 12). | exceptions to this rule (see Section 12).
o RTSP is defined to use ISO 10646 (UTF-8) rather than ISO | o RTSP is defined to use ISO 10646 (UTF-8) rather than ISO
8859-1, consistent with HTML internationalization efforts | 8859-1, consistent with HTML internationalization efforts
[24]. [28].
o The Request-URL always contains the absolute URL. Because of o The Request-URL always contains the absolute URL. Because of
backward compatibility with a historical blunder, HTTP/1.1 [4] backward compatibility with a historical blunder, HTTP/1.1 [4]
carries only the absolute path in the request and puts the carries only the absolute path in the request and puts the
host name in a separate header field. host name in a separate header field.
This makes "virtual hosting" easier, where a single This makes "virtual hosting" easier, where a single
host with one IP address hosts several document trees. host with one IP address hosts several document trees.
The protocol supports the following operations: The protocol supports the following operations:
Retrieval of media from media server: The client can either | Retrieval of media from media server: The client can either
request a presentation description via RTSP DESCRIBE, HTTP | request a presentation description via RTSP DESCRIBE, HTTP
or some other method. If the presentation is being | or some other method. If the presentation is being
multicast, the presentation description contains the | multicast, the presentation description contains the
multicast addresses and ports to be used for the continuous | multicast addresses and ports to be used for the continuous
media. If the presentation is to be sent only to the client | media. If the presentation is to be sent only to the client
via unicast, the client provides the destination for | via unicast, the client provides the destination for
security reasons. security reasons.
Invitation of a media server to a conference: A media server can Invitation of a media server to a conference: A media server can
be "invited" to join an existing conference to play back be "invited" to join an existing conference to play back
media into the presentation. This mode is useful for media into the presentation. This mode is useful for
distributed teaching applications. Several parties in the distributed teaching applications. Several parties in the
conference may take turns "pushing the remote control conference may take turns "pushing the remote control
buttons". buttons".
RTSP requests may be handled by proxies, tunnels and caches as in RTSP requests may be handled by proxies, tunnels and caches as in
HTTP/1.1 [4]. HTTP/1.1 [4].
1.3 Notational Conventions | 1.3 Notational Conventions
Since many of the definitions and syntax are identical to HTTP/1.1,
Since many of the definitions and syntax are identical to HTTP/1.1, | this specification only points to the section where they are defined
this specification only points to the section where they are defined | rather than copying it. For brevity, [HX.Y] is to be taken to refer
rather than copying it. For brevity, [HX.Y] is to be taken to refer | to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [4]).
to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [4]). |
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 (BNF) described in detail in | prose and the augmented Backus-Naur form (BNF) described in detail in
RFC 2234 [5]. | RFC 2234 [5].
In this specification, we use indented and smaller-type paragraphs to | Indented and smaller-type paragraphs are used to provide background |
provide background and motivation. This is intended to give readers | and motivation. This is intended to give readers who were not |
who were not involved with the formulation of the specification an | involved with the formulation of the specification an understanding |
understanding of why things are the way that they are in RTSP. | of why things are the way they are in RTSP.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [6]. | document are to be interpreted as described in RFC 2119 [6].
This specification uses the word "Unspecified" to indicate | The word, unspecified, is used to indicate functionality or features |
functionality or features that are not defined in this specification, | that are not defined in this specification. Such functionality cannot |
and therefore can't be used. Any such functionality or feature can in | be used in a standardized manner without further definition and |
the future be evaluated and if technical sound be defined in | review in an extension specification to RTSP.
specification extending RTSP.
1.4 Terminology 1.4 Terminology
Some of the terminology has been adopted from HTTP/1.1 [4]. Terms not Some of the terminology has been adopted from HTTP/1.1 [4]. Terms not
listed here are defined as in HTTP/1.1. listed here are defined as in HTTP/1.1.
Aggregate control: The concept of controlling multiple streams Aggregate control: The concept of controlling multiple streams
using a single timeline, generally maintained by the using a single timeline, generally maintained by the
server. A client, for example, uses aggregate control when server. A client, for example, uses aggregate control when
it issues a single play or pause message to simultaneously it issues a single play or pause message to simultaneously
control both the audio and video in a movie. control both the audio and video in a movie.
Aggregate control URL: The URL used in a RTSP request to refer | Aggregate control URL: The URL used in a RTSP request to refer
to and control an aggregated session. It normally, but not | to and control an aggregated session. It normally, but not
always, corresponds to the presentation URL specified in | always, corresponds to the presentation URL specified in
the session description. See Section 11.3 for more | the session description. See Section 11.3 for more
information. information.
Conference: a multiparty, multimedia presentation, where "multi" Conference: a multiparty, multimedia presentation, where "multi"
implies greater than or equal to one. implies greater than or equal to one.
Client: The client requests media service from the media server. Client: The client requests media service from the media server.
Connection: A transport layer virtual circuit established Connection: A transport layer virtual circuit established
between two programs for the purpose of communication. between two programs for the purpose of communication.
Container file: A file which may contain multiple media streams Container file: A file which may contain multiple media streams |
which often comprise a presentation when played together. which often constitutes a presentation when played |
RTSP servers may offer aggregate control on these files, together. The concept of a container file is not embedded |
though the concept of a container file is not embedded in in the protocol. However, RTSP servers may offer aggregate |
the protocol. control on the media streams within these files.
Continuous media: Data where there is a timing relationship Continuous media: Data where there is a timing relationship
between source and sink; that is, the sink must reproduce between source and sink; that is, the sink must reproduce
the timing relationship that existed at the source. The the timing relationship that existed at the source. The
most common examples of continuous media are audio and most common examples of continuous media are audio and
motion video. Continuous media can be real-time motion video. Continuous media can be real-time
(interactive), where there is a "tight" timing relationship (interactive), where there is a "tight" timing relationship
between source and sink, or streaming (playback), where the between source and sink, or streaming (playback), where the
relationship is less strict. relationship is less strict.
Entity: The information transferred as the payload of a request Entity: The information transferred as the payload of a request
or response. An entity consists of meta-information in the or response. An entity consists of meta-information in the
form of entity-header fields and content in the form of an form of entity-header fields and content in the form of an
entity-body, as described in Section 8. entity-body, as described in Section 8.
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.
Live: Normally used to describe a presentation or session with | Live: Normally used to describe a presentation or session with
media coming from ongoing event. This generally results in | media coming from ongoing event. This generally results in
that the session has a unbound or only loosely defined | that the session has a unbound or only loosely defined
duration, and that no seek operations are possible. duration, and that no seek operations are possible.
Media initialization: Datatype/codec specific initialization. Media initialization: Datatype/codec specific initialization.
This includes such things as clockrates, color tables, etc. This includes such things as clock rates, color tables,
Any transport-independent information which is required by etc. Any transport-independent information which is
a client for playback of a media stream occurs in the media required by a client for playback of a media stream occurs
initialization phase of stream setup. in the media initialization phase of stream setup.
Media parameter: Parameter specific to a media type that may be Media parameter: Parameter specific to a media type that may be
changed before or during stream playback. changed before or during stream playback.
Media server: The server providing playback services for one or Media server: The server providing playback services for one or
more media streams. Different media streams within a more media streams. Different media streams within a
presentation may originate from different media servers. A presentation may originate from different media servers. A |
media server may reside on the same or a different host as media server may reside on the same host or on a different |
the web server the presentation is invoked from. host from which the presentation is invoked.
Media server indirection: Redirection of a media client to a Media server indirection: Redirection of a media client to a
different media server. different media server.
(Media) stream: A single media instance, e.g., an audio stream (Media) stream: A single media instance, e.g., an audio stream
or a video stream as well as a single whiteboard or shared or a video stream as well as a single whiteboard or shared
application group. When using RTP, a stream consists of all application group. When using RTP, a stream consists of all
RTP and RTCP packets created by a source within an RTP RTP and RTCP packets created by a source within an RTP
session. This is equivalent to the definition of a DSM-CC session. This is equivalent to the definition of a DSM-CC
stream([25]). stream([29]).
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 structured sequence of octets matching the syntax defined
in Section 17 and transmitted via a connection or a in Section 18 and transmitted over a connection or a |
connectionless protocol. connectionless transport.
Non-Aggregated Control: Control of a single media stream. Only Non-Aggregated Control: Control of a single media stream. Only
possible in RTSP sessions with a single media. possible in RTSP sessions with a single media.
Participant: Member of a conference. A participant may be a Participant: Member of a conference. A participant may be a
machine, e.g., a playback server. machine, e.g., a playback server.
Presentation: A set of one or more streams presented to the Presentation: A set of one or more streams presented to the
client as a complete media feed, using a presentation client as a complete media feed and described by a |
description as defined below. In most cases in the RTSP presentation description as defined below. In the RTSP |
context, this implies aggregate control of those streams, context, this generally implies aggregate control over the |
but does not have to. streams, but does not necessarily have to.
Presentation description: A presentation description contains Presentation description: A presentation description contains
information about one or more media streams within a information about one or more media streams within a
presentation, such as the set of encodings, network presentation, such as the set of encodings, network
addresses and information about the content. Other IETF addresses and information about the content. Other IETF
protocols such as SDP (RFC 2327 [2]) use the term "session" protocols such as SDP (RFC 2327 [2]) use the term "session"
for a presentation. The presentation description may take for a presentation. The presentation description may take
several different formats, including but not limited to the several different formats, including but not limited to the
session description format SDP. session description protocol format, SDP. |
Response: A RTSP response. If an HTTP response is meant, that is Response: A RTSP response. If an HTTP response is meant, that is
indicated explicitly. indicated explicitly.
Request: A RTSP request. If an HTTP request is meant, that is Request: A RTSP request. If an HTTP request is meant, that is
indicated explicitly. indicated explicitly.
Request URL: The URL used in a request to indicate the resource | Request URL: The URL used in a request to indicate the resource |
which the request shall be performed on. on which the request shall be performed.
RTSP agent: Refers to either a RTSP client, a RTSP server, or a |
RTSP Proxy. In this specification, there are many |
capabilities that are common to these three entities such |
as the capability to send requests or receive responses. |
This term will be used when describing functionality that |
is applicable to all three of these 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. A RTSP session is a server entity; methods of RTSP operate. A RTSP session is a server entity;
it is created, maintained and destroyed by the server. It it is created, maintained and destroyed by the server. It
is established by a RTSP server upon the completion of a is established by a RTSP server upon the completion of a
successful SETUP request (when 200 OK response is sent) and successful SETUP request (when 200 OK response is sent) and
is labelled by a session identifier at that time. The is labelled by a session identifier at that time. The
session exists until timed out by the server or explicitly session exists until timed out by the server or explicitly
removed by a TEARDOWN request. A RTSP session is also a removed by a TEARDOWN request. A RTSP session is a stateful |
stateful entity; a RTSP server maintains an explicit entity; a RTSP server maintains an explicit session state
session state machine (see Appendix A) where most state machine (see Appendix A) where most state transitions are
transitions are triggered by client requests. The existence triggered by client requests. The existence of a session
of a session implies the existence of state about the implies the existence of state about the session's media
session's media streams and their respective transport streams and their respective transport mechanisms. A given
mechanisms. A given session can have zero or more media session can have zero or more media streams associated with
streams associated with it. A RTSP server uses the session it. A RTSP server uses the session to aggregate control
to aggregate control over multiple media streams. over multiple media streams.
Transport initialization: The negotiation of transport Transport initialization: The negotiation of transport
information (e.g., port numbers, transport protocols) information (e.g., port numbers, transport protocols)
between the client and the server. between the client and the server.
URI: Universal Resource Identifier, see RFC 2396 [12]. In RTSP | URI: Universal Resource Identifier, see RFC 2396 [13]. In RTSP
the used URIs are as general rule in fact URL's as they | the used URIs are as general rule in fact URL's as they
gives an location for the resource. Therefore although RTSP | gives an location for the resource. Therefore although RTSP
URLs are a subset of URIs, they will be refered as URLs. | URLs are a subset of URIs, they will be refered as URLs.
URL: Universal Resource Locator, is an URI which identifies the | URL: Universal Resource Locator, is an URI which identifies the
resource through its primary access mechanism, rather than | resource through its primary access mechanism, rather than
identifying the resource by name or by some other | identifying the resource by name or by some other
attribute(s) of that resource. attribute(s) of that resource.
1.5 Protocol Properties 1.5 Protocol Properties
RTSP has the following properties: RTSP has the following properties:
Extendable: New methods and parameters can be easily added to Extendable: New methods and parameters can be easily added to
RTSP. RTSP.
Easy to parse: RTSP can be parsed by standard HTTP or MIME Easy to parse: RTSP can be parsed by standard HTTP or MIME
parsers. parsers.
Secure: RTSP re-uses web security mechanisms, either at the Secure: RTSP re-uses web security mechanisms, either at the
transport level (TLS, RFC 2246 [26]) or within the protocol transport level (TLS, RFC 2246 [7]) or within the protocol
itself. All HTTP authentication mechanisms such as basic itself. All HTTP authentication mechanisms such as basic
(RFC 2616 [4]) and digest authentication (RFC 2617 [7]) are (RFC 2616 [4]) and digest authentication (RFC 2617 [8]) are
directly applicable. directly applicable.
Transport-independent: RTSP does not preclude the use of an | Transport-independent: RTSP does not preclude the use of an
unreliable datagram protocol (UDP) (RFC 768 [8]), a | unreliable datagram protocol (UDP) (RFC 768 [9]), a
reliable datagram protocol (RDP, RFC 1151, not widely used | reliable datagram protocol (RDP, RFC 1151, not widely used
[27]) as it would be possible to implement application- | [30]) as it would be possible to implement application-
level reliability. The use of a connectionless datagram | level reliability. The use of a connectionless datagram
protocol such as UDP or RDP requires additional definition | protocol such as UDP or RDP requires additional definition
that may be provided as extensions to the core RTSP | that may be provided as extensions to the core RTSP
specification. The usage of the reliable stream protocol | specification. The usage of the reliable stream protocol
TCP (RFC 793 [9]) is what is currently defined as transport | TCP (RFC 793 [10]) is what is currently defined as
protocol of RTSP messages. transport protocol of RTSP messages.
Multi-server capable: Each media stream within a presentation Multi-server capable: Each media stream within a presentation
can reside on a different server. The client automatically can reside on a different server. The client automatically
establishes several concurrent control sessions with the establishes several concurrent control sessions with the
different media servers. Media synchronization is different media servers. Media synchronization is
performed at the transport level. performed at the transport level.
Separation of stream control and conference initiation: Stream Separation of stream control and conference initiation: Stream
control is divorced from inviting a media server to a control is divorced from inviting a media server to a
conference. In particular, SIP [28] or H.323 [29] may be conference. In particular, SIP [31] or H.323 [32] may be
used to invite a server to a conference. used to invite a server to a conference.
Suitable for professional applications: RTSP supports frame- Suitable for professional applications: RTSP supports frame-
level accuracy through SMPTE time stamps to allow remote level accuracy through SMPTE time stamps to allow remote
digital editing. digital editing.
Presentation description neutral: The protocol does not impose a Presentation description neutral: The protocol does not impose a
particular presentation description or metafile format and particular presentation description or metafile format and
can convey the type of format to be used. However, the can convey the type of format to be used. However, the
presentation description must contain at least one RTSP presentation description must contain at least one RTSP
URL. URL.
Proxy and firewall friendly: The protocol should be readily | Proxy and firewall friendly: The protocol should be readily
handled by both application and transport-layer (SOCKS | handled by both application and transport-layer (SOCKS
[30]) firewalls. A firewall may need to understand the | [33]) firewalls. A firewall may need to understand the
SETUP method to open a "hole" for the media stream. SETUP method to open a "hole" for the media stream.
HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so
that the existing infrastructure can be reused. This that the existing infrastructure can be reused. This
infrastructure includes PICS (Platform for Internet Content infrastructure includes PICS (Platform for Internet Content
Selection [31,32]) for associating labels with content. Selection [34,35]) for associating labels with content.
However, RTSP does not just add methods to HTTP since the However, RTSP does not just add methods to HTTP since the
controlling continuous media requires server state in most controlling continuous media requires server state in most
cases. cases.
Appropriate server control: If a client can start a stream, it Appropriate server control: If a client can start a stream, it
must be able to stop a stream. Servers should not start must be able to stop a stream. Servers should not start
streaming to clients in such a way that clients cannot stop streaming to clients in such a way that clients cannot stop
the stream. the stream.
Transport negotiation: The client can negotiate the transport Transport negotiation: The client can negotiate the transport
method prior to actually needing to process a continuous method prior to actually needing to process a continuous
media stream. media stream.
Capability negotiation: If basic features are disabled, there
must be some clean mechanism for the client to determine
which methods are not going to be implemented. This allows
clients to present the appropriate user interface. For
example, if seeking is not allowed, the user interface must
be able to disallow moving a sliding position indicator.
An earlier requirement in RTSP was multi-client capability. An earlier requirement in RTSP was multi-client capability.
However, it was determined that a better approach was to However, it was determined that a better approach was to
make sure that the protocol is easily extensible to the make sure that the protocol is easily extensible to the
multi-client scenario. Stream identifiers can be used by multi-client scenario. Stream identifiers can be used by
several control streams, so that "passing the remote" would several control streams, so that "passing the remote" would
be possible. The protocol would not address how several be possible. The protocol would not address how several
clients negotiate access; this is left to either a "social clients negotiate access; this is left to either a "social
protocol" or some other floor control mechanism. protocol" or some other floor control mechanism.
1.6 Extending RTSP 1.6 Extending RTSP
skipping to change at page 17, line 5 skipping to change at page 17, line 40
A server SHOULD implement all header fields described in Section 14. A server SHOULD implement all header fields described in Section 14.
It is up to the creators of presentation descriptions not to ask the It is up to the creators of presentation descriptions not to ask the
impossible of a server. This situation is similar in HTTP/1.1 [4], impossible of a server. This situation is similar in HTTP/1.1 [4],
where the methods described in [H19.5] are not likely to be supported where the methods described in [H19.5] are not likely to be supported
across all servers. across all servers.
RTSP can be extended in three ways, listed here in order of the RTSP can be extended in three ways, listed here in order of the
magnitude of changes supported: magnitude of changes supported:
o Existing methods can be extended with new parameters, e.g. | o Existing methods can be extended with new parameters, e.g.
headers, as long as these parameters can be safely ignored by | headers, as long as these parameters can be safely ignored by
the recipient. (This is equivalent to adding new parameters to | the recipient. If the client needs negative acknowledgement |
an HTML tag.) If the client needs negative acknowledgement | when a method extension is not supported, a tag corresponding
when a method extension is not supported, a tag corresponding | to the extension may be added in the Require: field (see
to the extension may be added in the Require: field (see | Section 14.35).
Section 14.32).
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 responds with error code 501 not understand the request, it responds with error code 501
(Not Implemented) and the sender should not attempt to use (Not Implemented) and the sender should not attempt to use
this method again. A client may also use the OPTIONS method this method again. A client may also use the OPTIONS method to
to inquire about methods supported by the server. The server inquire about methods supported by the server. The server MUST
SHOULD list the methods it supports using the Public response list the methods it supports using the Public response header.
header.
o A new version of the protocol can be defined, allowing almost o A new version of the protocol can be defined, allowing almost
all aspects (except the position of the protocol version all aspects (except the position of the protocol version
number) to change. number) to change.
The basic capability discovery mechanism can be used to both discover The basic capability discovery mechanism can be used to both discover
support for a certain feature and to ensure that a feature is support for a certain feature and to ensure that a feature is
available when performing a request. For detailed explanation of this available when performing a request. For detailed explanation of this
see chapter 10. see chapter 10.
skipping to change at page 19, line 15 skipping to change at page 19, line 49
REDIRECT: Indicates that the session should be moved to new REDIRECT: Indicates that the session should be moved to new
server / location server / location
PING: Prevents the identified session from being timed out. PING: Prevents the identified session from being timed out.
TEARDOWN: Frees resources associated with the stream. The RTSP TEARDOWN: Frees resources associated with the stream. The RTSP
session ceases to exist on the server. session ceases to exist on the server.
RTSP methods that contribute to state use the Session header field RTSP methods that contribute to state use the Session header field
(Section 14.37) to identify the RTSP session whose state is being (Section 14.40) to identify the RTSP session whose state is being
manipulated. The server generates session identifiers in response to manipulated. The server generates session identifiers in response to
SETUP requests (Section 11.3). SETUP requests (Section 11.3).
1.9 Relationship with Other Protocols 1.9 Relationship with Other Protocols
RTSP has some overlap in functionality with HTTP. It also may RTSP has some overlap in functionality with HTTP. It also may
interact with HTTP in that the initial contact with streaming content interact with HTTP in that the initial contact with streaming content
is often to be made through a web page. The current protocol is often to be made through a web page. The current protocol
specification aims to allow different hand-off points between a web specification aims to allow different hand-off points between a web
server and the media server implementing RTSP. For example, the server and the media server implementing RTSP. For example, the
skipping to change at page 20, line 4 skipping to change at page 20, line 37
RTSP assumes the existence of a presentation description format that RTSP assumes the existence of a presentation description format that
can express both static and temporal properties of a presentation can express both static and temporal properties of a presentation
containing several media streams. Session Description Protocol (SDP) containing several media streams. Session Description Protocol (SDP)
[2] is generally the format of choice; however, RTSP is not bound to [2] is generally the format of choice; however, RTSP is not bound to
it. For data delivery, most real-time media will use RTP as a it. For data delivery, most real-time media will use RTP as a
transport protocol. While RTSP works well with RTP, it is not tied to transport protocol. While RTSP works well with RTP, it is not tied to
RTP. RTP.
2 RTSP Use Cases 2 RTSP Use Cases
This section describes some of the use cases RTSP can be used for. |
They are listed in descending order of importance in regards to |
ensuring that all necessary functionality is present. |
TODO: Fill this headings with descriptions of the use cases. | This section describes some of the use cases for RTSP. They are |
listed in descending order of importance in regards to ensuring that |
all necessary functionality is present. This specification does only |
fully support usage of the two first. Also in these first two cases |
are there special cases that will not be supported without |
extensions, e.g. the redirection of media to another address than the |
controlling entity. |
2.1 On-demand Playback of Stored Content | 2.1 On-demand Playback of Stored Content |
An RTSP capable server stores content suitable for being streamed to |
a client. A client desiring playback of any of the stored content |
uses RTSP to set up the media transport required for the desired |
content. Then RTSP is used to initiate, halt and manipulate the |
transmission of the content. There are also requirement on being able |
to use RTSP to carry necessary description and synchronization |
information for the content. |
The above high level description can be broken down into a number of |
functionalities that RTSP needs to be capable of. |
Presentation Description: The possibility to carry |
initialization information about the presentation |
(content), for example, which media codec(s) that are |
needed for the content. Other information that are |
important; how many media stream that the presentation |
contains; what transport protocols to use for the media |
streams; and identifiers for these media streams. This |
information is required before setup of the content is |
possible. The information is also needed by the client to |
determine if it is capable at all to support the content. |
This information is not required to be sent using RTSP, |
instead other external protocols can be utilized to |
transport presentation descriptions. Two good examples are |
the use of HTTP [4] or email to fetch or receive |
presentation descriptions like SDP [2]. |
Setup: Performing setup of some or all of the media streams in a |
presentation. The setup itself consist of determining which |
protocols for media transport to use; the necessary |
parameters for the protocol, like addresses and ports. |
Control of Transmission: After the necessary media streams has |
been established the client can request the server to start |
transmitting the content. There is need to allow the client |
to arbitrary times start or stop the transmission of the |
content. There are also exist need to be able to start the |
transmission at an any point in the timeline of the |
presentation. |
Synchronization: For media transport protocols like RTP [18] it |
might be beneficial to carry synchronization information |
within RTSP. Either due to the lack of inter media |
synchronization within the protocol itself, or the |
potential delay before the synchronization is established |
(which is the case for RTP when using RTCP). |
Termination There is also need to be able to terminate the |
established contexts. |
For this use cases there is a number of assumption about how it |
works. These are listed below: |
On-Demand content: The content available is stored at the server |
and can be accessed at any time during a time period when |
it is intended to be available. |
Independent sessions: A server is capable of serving a number of |
clients simultaneously, including from the same piece of |
content at different points in that presentations time- |
line. |
Unicast Transport: Content for each individual client is |
transmitted to them using unicast traffic. |
It is also possible to redirect the media traffic to another |
destination than where the entity controlling traffic uses. However |
allowing this without appropriate mechanisms for checking that the |
destination approves of this is a denial of service threat. |
2.2 Unicast distribution of Live Content | 2.2 Unicast distribution of Live Content |
2.3 Inviting RTSP on-demand servers into a multicast group | This use cases is not that different from the above on-demand content |
case (see section 2.1. The difference is really the restriction the |
content itself establish. Live content is continuously distributed |
as it becomes available from a source, i.e. the main difference to |
on-demand is that one starts distributing content before the end of |
it has become available to the server. |
2.4 On-demand Playback using Multicast | In many cases the consumer of live content is only interested in |
consuming what is actually happens "now", i.e. very similar to |
broadcast TV. However in this case it is assumed that there exist no |
broadcast or multicast channel to the users, and instead the server |
functions as a distribution node, sending the same content to |
multiple receivers, using unicast traffic between server and client. |
This unicast traffic and the transport parameters are individually |
negotiated for each receiving client. |
Another aspect of live content is that it has often very limited time |
of availability, as it is only is available for the duration of the |
event the content covers. A example of such a live content could for |
example be a music concert, which lasts 2 hour and starts at a |
predetermined time. Thus there is need to announce when and for how |
long the live content is available. |
2.3 On-demand Playback using Multicast |
It is possible to use RTSP to request that media is delivered to a |
multicast group. The entity setting up the session (the controller) |
will then control when and what media that is delivered to the group. |
Also this use case has some potential for denial of service attacks, |
in this case flooding any multicast group. Therefore there is need |
for a mechanism indicating that the group actually accepts the |
traffic from the RTSP server. |
An open issue in this use case is how one ensures that all receivers |
listening to the multicast or broadcast receives the session |
presentation configuring the receivers. |
2.4 Inviting a RTSP server into a conference |
If one has an established conference or group session, it is possible |
to have a RTSP server distribute media to the whole group. The |
transmission to the group is simplest controlled by a single |
participant or leader of the conference. Shared control might be |
possible, but would require further investigation and possibly |
extensions. There are some protocol mechanisms missing for this |
scenario. |
For reasonable complexity in the media transmission stage, this use |
case assumes that there exist either multicast or a conference focus |
that redistribute media to all participants. |
In some more detail, this use case is intended to be able to handle |
the following scenario: A conference leader or participant (from here |
called the controller) has some pre-stored content on a RTSP server |
that he likes to share with the group. The controller sets up a RTSP |
session at the streaming server for the content the controller likes |
to share. The session description for the content is retrieved to the |
controller. The media destination for the media content is set to the |
shared multicast group or conference focus. When desired by the |
controller, he/she can start and stop the transmission of the media |
to the conference group. |
There are several issues with this use case that is not solved by |
this core specification for RTSP: |
o Denial of service threat, to avoid a RTSP server from being a |
unknowing participant of a denial of service attack the server |
must be able to verify the destinations acceptance for the |
media. Such a mechanism does not yet exist that can be used to |
verify the approval to received media, instead only policies |
can be used, which can be made to work in controlled |
environments. |
o The problem of distributing the presentation description to |
all participants in the group. To enable a media receiver to |
decode the content correctly the media configuration |
information will need to be distributed reliable to all |
participants. This will most likely require support from an |
external protocol. |
o Passing the control. If it is desired to be able to pass the |
control of the RTSP session between the participants some |
support will be required by an external protocol for the |
necessary exchange of state information and possibly floor |
control of who is controlling the RTSP session. |
So if there interest in this use case further work on the necessary |
extensions has to be performed. |
2.5 Live Content using Multicast |
This use case does in its simplest form not require any use of RTSP |
at all. This is what multicast conferences being announce with SAP |
and SDP are intended to handle. However in use cases where more |
advance features like access control to the multicast session is |
desired, RTSP could be used for session establishment. |
A client desiring to join a live multicasted media session with |
cryptographic (encryption) access control could use RTSP in the |
following way. The source of the session, announces the session and |
gives all interested to join, a RTSP URI. The client connects to the |
server and requests the presentation description allowing for |
configuration the reception. In this step it is possible to use |
secured transport for the client, and also desired levels of |
authentication, for example for charging purposes or simply access |
control. An RTSP link also allows for load balancing between multiple |
servers. However if this the only thing that occurs it can probably |
be solved as simple using HTTP. |
However for session where the sender likes to keep track of each |
individual receiver during the session, and possibly use this side |
channel for pushing out key-updates or other side information that is |
desirable to be done on a per receiver basis, and the receivers are |
not know prior to the session start, the state establishment that |
RTSP provides can be beneficial. In this case a client would |
establish a RTSP session to the multicast group. The RTSP server will |
not transmit any media, instead it will simply point to the multicast |
group. However the client and server will be able to keep the session |
alive for as long as the receiver participates in the session. Thus |
enabling for example server to client pushes of updates. |
This use cases will most likely not be able to actually implement |
some extensions in relation to the server to client push mechanism. |
Here a method like ANNOUNCE might be suitable, however it will |
require a RTSP extension to revive the method.
3 Protocol Parameters 3 Protocol Parameters
3.1 RTSP Version 3.1 RTSP Version
HTTP Specification Section [H3.1] applies, with HTTP replaced by HTTP Specification Section [H3.1] applies, with HTTP replaced by
RTSP. This specification defines version 1.0 of RTSP. RTSP. This specification defines version 1.0 of RTSP.
3.2 RTSP URL 3.2 RTSP URL
The "rtsp", "rtsps" and "rtspu" schemes are used to refer to network The "rtsp", "rtsps" and "rtspu" schemes are used to refer to network
resources via the RTSP protocol. This section defines the scheme- resources via the RTSP protocol. This section defines the scheme-
specific syntax and semantics for RTSP URLs. The RTSP URL is case specific syntax and semantics for RTSP URLs. The RTSP URL is case
sensitive. sensitive.
Informative RTSP URL syntax: Informative RTSP URL syntax:
rtsp[u|s]://host[:port]/abspath[?query]#fragment rtsp[u|s]://host[:port]/abspath[?query]#fragment
See section 17.2.1 for the formal definition of the RTSP URL syntax. See section 18.2.1 for the formal definition of the RTSP URL syntax.
Note that fragment and query identifiers do not have a Note that fragment and query identifiers do not have a
well-defined meaning at this time, i.e. their usage is well-defined meaning at this time, i.e. their usage is
unspecified, with the interpretation left to the RTSP unspecified, with the interpretation left to the RTSP
server. server.
The URL scheme rtsp requires that commands are issued via a reliable The URL scheme rtsp requires that commands are issued via a reliable |
protocol (within the Internet, TCP), while the scheme rtspu is protocol (within the Internet, TCP), while the scheme rtspu is |
intended to identify RTSP over an unreliable protocol (within the intended to identify RTSP over an unreliable protocol (within the |
Internet, UDP). The scheme rtsps is intended to identify a reliable Internet, UDP). The scheme rtsps identifies a reliable transport |
transport using secure transport, perhaps TLS [26]. The rtspu and using secure transport (TLS [7]). The rtspu is not defined in this |
rtsps is not defined in this specification, and are for future specification, and are for future extensions of the protocol to |
extensions of the protocol to define how to use. define how to use.
If the port is empty or not given, port 554 SHALL be assumed. The | If the port is empty or not given, port 554 SHALL be assumed. The
semantics are that the identified resource can be controlled by RTSP | semantics are that the identified resource can be controlled by RTSP
at the server listening for TCP (scheme "rtsp") connections or UDP | at the server listening for TCP (scheme "rtsp") connections or UDP
(scheme "rtspu") packets on that port of host, and the Request-URL | (scheme "rtspu") packets on that port of host, and the Request-URL
for the resource is rtsp_URL. For the scheme rtsps the TCP and UDP | for the resource is rtsp_URL. For the scheme rtsps the TCP and UDP
port 322 is registered and SHALL be assumed. port 322 is registered and SHALL be assumed.
The use of IP addresses in URLs SHOULD be avoided whenever possible The use of IP addresses in URLs SHOULD be avoided whenever possible
(see RFC 1924 [10]). Note: Using qualified domain names in any URL is (see RFC 1924 [11]). Note: Using qualified domain names in any URL is
one requirement for making it possible for RFC 2326 implementations one requirement for making it possible for RFC 2326 implementations
of RTSP to use IPv6. This specification is updated to allow for of RTSP to use IPv6. This specification is updated to allow for
literal IPv6 addresses in RTSP URLs using the host specification in literal IPv6 addresses in RTSP URLs using the host specification in
RFC 2732 [11]. RFC 2732 [12].
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 [H3.2] of identifier, using the character set and escape conventions [H3.2] of
URLs (RFC 2396 [12]). URLs may refer to a stream or an aggregate of URLs (RFC 2396 [13]). URLs may refer to a stream or an aggregate of
streams, i.e., a presentation. Accordingly, requests described in streams, i.e., a presentation. Accordingly, requests described in
Section 11 can apply to either the whole presentation or an Section 11 can apply to either the whole presentation or an
individual stream within the presentation. Note that some request individual stream within the presentation. Note that some request
methods can only be applied to streams, not presentations and vice methods can only be applied to streams, not presentations and vice
versa. versa.
For example, the RTSP URL: For example, the RTSP URL:
rtsp://media.example.com:554/twister/audiotrack rtsp://media.example.com:554/twister/audiotrack
skipping to change at page 22, line 13 skipping to change at page 27, line 4
stream "a.mov" and the whole presentation "b.mov". stream "a.mov" and the whole presentation "b.mov".
The path components of the RTSP URL are opaque to the client and do The path components of the RTSP URL 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 This decoupling also allows presentation descriptions to be
used with non-RTSP media control protocols simply by used with non-RTSP media control protocols simply by
replacing the scheme in the URL. replacing the scheme in the URL.
3.3 Session Identifiers 3.3 Session Identifiers
Session identifiers are strings of any arbitrary length. A session Session identifiers are strings of any arbitrary length. A session
identifier MUST be chosen randomly and MUST be at least eight identifier MUST be chosen randomly and MUST be at least eight
characters long to make guessing it more difficult. (See Section 18.) characters long to make guessing it more difficult. (See Section 19.)
3.4 SMPTE Relative Timestamps 3.4 SMPTE Relative Timestamps
A SMPTE relative timestamp expresses time relative to the start of A SMPTE relative timestamp expresses time relative to the start of
the clip. Relative timestamps are expressed as SMPTE time codes for the clip. Relative timestamps are expressed as SMPTE time codes for
frame-level access accuracy. The time code has the format frame-level access accuracy. The time code has the format
hours:minutes:seconds:frames.subframes, hours:minutes:seconds:frames.subframes,
with the origin at the start of the clip. The default smpte format with the origin at the start of the clip. The default smpte format
is"SMPTE 30 drop" format, with frame rate is 29.97 frames per second. is"SMPTE 30 drop" format, with frame rate is 29.97 frames per second.
Other SMPTE codes MAY be supported (such as "SMPTE 25") through the Other SMPTE codes MAY be supported (such as "SMPTE 25") through the
skipping to change at page 23, line 16 skipping to change at page 28, line 5
values are not defined. The special constant now is defined as the values are not defined. The special constant now is defined as the
current instant of a live type event. It MAY only be used for live current instant of a live type event. It MAY only be used for live
type events, and SHALL NOT be used for on-demand content. type events, and SHALL NOT be used for on-demand content.
NPT is defined as in DSM-CC: "Intuitively, NPT is the clock the NPT is defined as in DSM-CC: "Intuitively, NPT is the clock the
viewer associates with a program. It is often digitally displayed on viewer associates with a program. It is often digitally displayed on
a VCR. NPT advances normally when in normal play mode (scale = 1), a VCR. NPT advances normally when in normal play mode (scale = 1),
advances at a faster rate when in fast scan forward (high positive advances at a faster rate when in fast scan forward (high positive
scale ratio), decrements when in scan reverse (high negative scale scale ratio), decrements when in scan reverse (high negative scale
ratio) and is fixed in pause mode. NPT is (logically) equivalent to ratio) and is fixed in pause mode. NPT is (logically) equivalent to
SMPTE time codes." [25] SMPTE time codes." [29]
Examples: Examples:
npt=123.45-125 npt=123.45-125
npt=12:05:35.3- npt=12:05:35.3-
npt=now- npt=now-
The syntax conforms to ISO 8601. The npt-sec notation is The syntax conforms to ISO 8601. The npt-sec notation is
optimized for automatic generation, the ntp-hhmmss notation optimized for automatic generation, the ntp-hhmmss notation
for consumption by human readers. The "now" constant allows for consumption by human readers. The "now" constant allows
skipping to change at page 23, line 45 skipping to change at page 28, line 34
Fractions of a second may be indicated. Fractions of a second may be indicated.
Example for November 8, 1996 at 14h37 and 20 and a quarter seconds Example for November 8, 1996 at 14h37 and 20 and a quarter seconds
UTC: UTC:
19961108T143720.25Z 19961108T143720.25Z
3.7 Feature-tags 3.7 Feature-tags
Feature-tags are unique identifiers used to designate features in Feature-tags are unique identifiers used to designate features in
RTSP. These tags are used in Require (Section 14.32), Proxy-Require RTSP. These tags are used in Require (Section 14.35), Proxy-Require
(Section 14.27), Unsupported (Section 14.41), and Supported (Section (Section 14.30), Unsupported (Section 14.44), and Supported (Section
14.38) header fields. 14.41) header fields.
Feature tag needs to indicate if they apply to servers only, proxies Feature tag needs to indicate if they apply to servers only, proxies
only, or both server and proxies. only, or both server and proxies.
The creator of a new RTSP feature-tag should either prefix the | The creator of a new RTSP feature-tag should either prefix the
feature-tag with a reverse domain name (e.g., | feature-tag with a reverse domain name (e.g.,
"com.example.mynewfeature" is an apt name for a feature whose | "com.example.mynewfeature" is an apt name for a feature whose
inventor can be reached at "example.com"), or register the new | inventor can be reached at "example.com"), or register the new
feature-tag with the Internet Assigned Numbers Authority (IANA), see | feature-tag with the Internet Assigned Numbers Authority (IANA), see
IANA Section 19. IANA Section 20.
The usage of feature tags are further described in section 10 that |
deals with capability handling. |
3.8 Entity Tags |
Entity tags opaque strings that are used to compare two entities from |
the same resource, for example in caches or to optimize setup after a |
redirect. Further explanation is present in [H3.11]. For explanation |
on how to compare Entity tags see [H13.3]. Entity tags can be carried |
in the ETag header (see section 14.20) or in SDP (see section C.1.8). |
Entity tags are used in RTSP to make some methods conditional. The |
methods are made conditional through the inclusion of headers, see |
14.24 and 14.26.
4 RTSP Message 4 RTSP Message
RTSP is a text-based protocol and uses the ISO 10646 character set in RTSP is a text-based protocol and uses the ISO 10646 character set in
UTF-8 encoding (RFC 2279 [13]). Lines are terminated by CRLF, but UTF-8 encoding (RFC 2279 [14]). Lines are terminated by CRLF, but
receivers should be prepared to also interpret CR and LF by receivers should be prepared to also interpret CR and LF by
themselves as line terminators. themselves as line terminators.
Text-based protocols make it easier to add optional Text-based protocols make it easier to add optional
parameters in a self-describing manner. Since the number of parameters in a self-describing manner. Since the number of
parameters and the frequency of commands is low, processing parameters and the frequency of commands is low, processing
efficiency is not a concern. Text-based protocols, if done efficiency is not a concern. Text-based protocols, if done
carefully, also allow easy implementation of research carefully, also allow easy implementation of research
prototypes in scripting languages such as Tcl, Visual Basic prototypes in scripting languages such as Tcl, Visual Basic
and Perl. and Perl.
The 10646 character set avoids tricky character set switching, but is The 10646 character set avoids tricky 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. ISO 8859-1 translates directly is also the encoding used for RTCP. ISO 8859-1 translates directly
into Unicode with a high-order octet of zero. ISO 8859-1 characters into Unicode with a high-order octet of zero. ISO 8859-1 characters
with the most-significant bit set are represented as 1100001x with the most-significant bit set are represented as 1100001x
10xxxxxx. (See RFC 2279 [13]) 10xxxxxx. (See RFC 2279 [14])
RTSP messages can be carried over any lower-layer transport protocol RTSP messages can be carried over any lower-layer transport protocol
that is 8-bit clean. RTSP messages are vulnerable to bit errors and that is 8-bit clean. RTSP messages are vulnerable to bit errors and
SHOULD NOT be subjected to them. SHOULD NOT be subjected to them.
Requests contain methods, the object the method is operating upon and Requests contain methods, the object the method is operating upon and
parameters to further describe the method. Methods are idempotent, parameters to further describe the method. Methods are idempotent,
unless otherwise noted. Methods are also designed to require little unless otherwise noted. Methods are also designed to require little
or no state maintenance at the media server. or no state maintenance at the media server.
skipping to change at page 25, line 21 skipping to change at page 30, line 25
When a message body is included with a message, the length of that When a message body is included with a message, the length of that
body is determined by one of the following (in order of precedence): body is determined by one of the following (in order of precedence):
1. Any response message which MUST NOT include a message body 1. Any response message which MUST NOT include a message body
(such as the 1xx, 204, and 304 responses) is always (such as the 1xx, 204, and 304 responses) is always
terminated by the first empty line after the header fields, terminated by the first empty line after the header fields,
regardless of the entity-header fields present in the regardless of the entity-header fields present in the
message. (Note: An empty line consists of only CRLF.) message. (Note: An empty line consists of only CRLF.)
2. If a Content-Length header field (section 14.14) is 2. If a Content-Length header field (section 14.15) is
present, its value in bytes represents the length of the present, its value in bytes represents the length of the
message-body. If this header field is not present, a value message-body. If this header field is not present, a value
of zero is assumed. of zero is assumed.
Note that RTSP does not (at present) support the HTTP/1.1 "chunked" Note that RTSP does not (at present) support the HTTP/1.1 "chunked"
transfer coding(see [H3.6.1]) and requires the presence of the transfer coding(see [H3.6.1]) and requires the presence of the
Content-Length header field. Content-Length header field.
Given the moderate length of presentation descriptions Given the moderate length of presentation descriptions
returned, the server should always be able to determine its returned, the server should always be able to determine its
skipping to change at page 25, line 46 skipping to change at page 31, line 4
See [H4.5], except that Pragma, Trailer, Transfer-Encoding, Upgrade, See [H4.5], except that Pragma, Trailer, Transfer-Encoding, Upgrade,
and Warning headers are not defined. RTSP further defines the CSeq, and Warning headers are not defined. RTSP further defines the CSeq,
and Timestamp. The general headers are listed in table 1: and Timestamp. The general headers are listed in table 1:
6 Request 6 Request
A request message from a client to a server or vice versa includes, | A request message from a client to a server or vice versa includes, |
within the first line (Request Line) of that message, the method to | within the first line (Request Line) of that message, the method to |
be applied to the resource, the identifier of the resource, and the | be applied to the resource, the identifier of the resource, and the |
protocol version in use. Then follows zero or more headers that can |
be of general (Section 5), request (Section 6.2), or entity (Section |
8.1) type. Then an empty line, i.e. a line with only the two |
characters Carriage Return (CR) and Line Feed (LF), indicates the end |
Header Name Comment Header Name Comment
_________________________________ _________________________________
Cache-Control See section 14.9 Cache-Control See section 14.10
Connection See section 14.10 Connection See section 14.11
CSeq See section 14.17 CSeq See section 14.18
Date See section 14.18 Date See section 14.19
Supported See section 14.38 Supported See section 14.41
Timestamp See section 14.39 Timestamp See section 14.42
Via See section 14.44 Via See section 14.47
Table 1: The General headers used in RTSP. Table 1: The General headers used in RTSP.
protocol version in use. Then follows zero or more headers that can |
be of general (Section 5), request (Section 6.2), or entity (Section |
8.1) type. Then an empty line, i.e. a line with only the two |
characters Carriage Return (CR) and Line Feed (LF), indicates the end |
of the header part. Optionally a message body (entity) follows to the | of the header part. Optionally a message body (entity) follows to the |
end of the message. The length of the message body is indicated | end of the message. The length of the message body is indicated |
through the entity headers. | through the Content-Length entity header.
6.1 Request Line | 6.1 Request Line
The request line, provides the most important things about the | The request line, provides the most important things about the
request: What method, on what resources and using which RTSP version. | request: What method, on what resources and using which RTSP version.
The methods that is defined by this specification can be seen in | The methods that is defined by this specification can be seen in
Table 6.1. The resource is identified through an absolute RTSP URL | Table 6.1. The resource is identified through an absolute RTSP URL
(see section 3.2. (see section 3.2.
<Method> SP <Request-URL> SP <RTSP-Version> CRLF <Method> SP <Request-URL> SP <RTSP-Version> CRLF
Please note: The request line's syntax can't be changed in future Please note: The request line's syntax can't be freely changed in |
versions of RTSP, as this line indicates the version of the messages future versions of RTSP, as this line indicates the version of the |
and need to be parsable also by older versions. messages and need to be parsable also by older versions.
Note that in contrast to HTTP/1.1 [4], RTSP requests always contain Note that in contrast to HTTP/1.1 [4], RTSP requests always contain
the absolute URL (that is, including the scheme, host and port) the absolute URL (that is, including the scheme, host and port)
rather than just the absolute path. rather than just the absolute path.
HTTP/1.1 requires servers to understand the absolute URL, HTTP/1.1 requires servers to understand the absolute URL,
but clients are supposed to use the Host request header. but clients are supposed to use the Host request header.
This is purely needed for backward-compatibility with This is purely needed for backward-compatibility with
HTTP/1.0 servers, a consideration that does not apply to HTTP/1.0 servers, a consideration that does not apply to
RTSP. RTSP.
The asterisk "*" in the Request-URL means that the request does not
apply to a particular resource, but to the server or proxy itself,
and is only allowed when the method used does not necessarily apply
Method Defined In Section Method Defined In Section
_________________________________ _________________________________
DESCRIBE Section 11.2 DESCRIBE Section 11.2
GET_PARAMETER Section 11.7 GET_PARAMETER Section 11.7
OPTIONS Section 11.1 OPTIONS Section 11.1
PAUSE Section 11.5 PAUSE Section 11.5
PLAY Section 11.4 PLAY Section 11.4
PING Section 11.10 PING Section 11.10
REDIRECT Section 11.9 REDIRECT Section 11.9
SETUP Section 11.3 SETUP Section 11.3
SET_PARAMETER Section 11.8 SET_PARAMETER Section 11.8
TEARDOWN Section 11.6 TEARDOWN Section 11.6
Table 2: The RTSP Methods Table 2: The RTSP Methods
The asterisk "*" in the Request-URL means that the request does not
apply to a particular resource, but to the server or proxy itself,
and is only allowed when the method used does not necessarily apply
to a resource. to a resource.
One example would be as follows: One example would be as follows:
OPTIONS * RTSP/1.0 OPTIONS * RTSP/1.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 one needs to address or the proxy that first receives the request. If one needs to address
the server explicitly, then one should use an absolute URL with the the server explicitly, then one should use an absolute URL with the
server's address. server's address.
OPTIONS rtsp://example.com RTSP/1.0 OPTIONS rtsp://example.com RTSP/1.0
6.2 Request Header Fields 6.2 Request Header Fields
The RTSP headers in Table 6.2 can be included in a request with the The RTSP headers in Table 3 can be included in a request with the
purpose to give further define how the request should be fulfilled. A purpose to give further define how the request should be fulfilled. A
request header MAY also be response header, see section 7.1.2. request header MAY also be response header, see section 7.1.2.
7 Response 7 Response
[H6] applies except that HTTP-Version is replaced by RTSP-Version. |
Also, RTSP defines additional status codes and does not define some |
Header Defined in Section Header Defined in Section
_____________________________________ _____________________________________
Accept Section 14.1 Accept Section 14.1
Accept-Encoding Section 14.2 Accept-Encoding Section 14.3
Accept-Language Section 14.3 Accept-Language Section 14.4
Authorization Section 14.6 Authorization Section 14.7
Bandwidth Section 14.7 Bandwidth Section 14.8
Blocksize Section 14.8 Blocksize Section 14.9
From Section 14.20 From Section 14.22
If-Match Section 14.22 If-Match Section 14.24
If-Modified-Since Section 14.23 If-Modified-Since Section 14.25
Proxy-Require Section 14.27 If-None-Match Section 14.26
Range Section 14.29 Proxy-Require Section 14.30
Referer Section 14.30 Range Section 14.32
Require Section 14.32 Referer Section 14.33
Scale Section 14.34 Require Section 14.35
Session Section 14.37 Scale Section 14.37
Speed Section 14.35 Session Section 14.40
Supported Section 14.38 Speed Section 14.38
Transport Section 14.40 Supported Section 14.41
User-Agent Section 14.42 Transport Section 14.43
User-Agent Section 14.45
Table 3: The RTSP request headers Table 3: The RTSP request headers
HTTP codes. The valid response codes and the methods they can be used | [H6] applies except that HTTP-Version is replaced by RTSP-Version.
with are defined in Table 4. | Also, RTSP defines additional status codes and does not define some
HTTP codes. The valid response codes and the methods they can be used
After receiving and interpreting a request message, the recipient | with are defined in Table 4.
responds with an RTSP response message. |
7.1 Status-Line |
The first line of a Response message is the Status-Line, consisting | After receiving and interpreting a request message, the recipient
of the protocol version followed by a numeric status code, and the | responds with an RTSP response message.
textual phrase associated with the status code, with each element |
separated by SP characters. No CR or LF is allowed except in the |
final CRLF sequence. |
<RTSP-Version> SP <Status-Code> SP <Reason-Phrase> CRLF | 7.1 Status-Line
7.1.1 Status Code and Reason Phrase | The first line of a Response message is the Status-Line, consisting
of the protocol version followed by a numeric status code, and the
textual phrase associated with the status code, with each element
separated by SP characters. No CR or LF is allowed except in the
final CRLF sequence.
The Status-Code element is a 3-digit integer result code of the | <RTSP-Version> SP <Status-Code> SP <Reason-Phrase> CRLF
attempt to understand and satisfy the request. These codes are fully |
defined in Section 13. The Reason-Phrase is intended to give a short |
textual description of the Status-Code. The Status-Code is intended |
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- |
Phrase. |
The first digit of the Status-Code defines the class of response. The | 7.1.1 Status Code and Reason Phrase
last two digits do not have any categorization role. There are 5 | The Status-Code element is a 3-digit integer result code of the
values for the first digit: | attempt to understand and satisfy the request. These codes are fully
defined in Section 13. The Reason-Phrase is intended to give a short
textual description of the Status-Code. The Status-Code is intended
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-
Phrase.
o 1xx: Informational - Request received, continuing process | 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
values for the first digit:
o 2xx: Success - The action was successfully received, | o 1xx: Informational - Request received, continuing process
understood, and accepted |
o 3rr: Redirection - Further action must be taken in order to | o 2xx: Success - The action was successfully received,
complete the request | understood, and accepted
o 4xx: Client Error - The request contains bad syntax or cannot | o 3rr: Redirection - Further action must be taken in order to
be fulfilled | complete the request
o 5xx: Server Error - The server failed to fulfill an apparently | o 4xx: Client Error - The request contains bad syntax or cannot
valid request | be fulfilled
The individual values of the numeric status codes defined for | o 5xx: Server Error - The server failed to fulfill an apparently
RTSP/1.0, and an example set of corresponding Reason-Phrase's, are | valid request
presented in table 4. The reason phrases listed here are only |
recommended they may be replaced by local equivalents without |
affecting the protocol. Note that RTSP adopts most HTTP/1.1 [4] |
status codes and adds RTSP-specific status codes starting at x50 to |
avoid conflicts with newly defined HTTP status codes. |
RTSP status codes are extensible. RTSP applications are not required | The individual values of the numeric status codes defined for
to understand the meaning of all registered status codes, though such | RTSP/1.0, and an example set of corresponding Reason-Phrase's, are
understanding is obviously desirable. However, applications MUST | presented in table 4. The reason phrases listed here are only
understand the class of any status code, as indicated by the first | recommended they may be replaced by local equivalents without
digit, and treat any unrecognized response as being equivalent to the | affecting the protocol. Note that RTSP adopts most HTTP/1.1 [4]
x00 status code of that class, with the exception that an | status codes and adds RTSP-specific status codes starting at x50 to
unrecognized response MUST NOT be cached. For example, if an | avoid conflicts with newly defined HTTP status codes.
unrecognized status code of 431 is received by the client, it can |
safely assume that there was something wrong with its request and |
treat the response as if it had received a 400 status code. In such |
cases, user agents SHOULD present to the user the entity returned |
with the response, since that entity is likely to include human- |
readable information which will explain the unusual status. |
7.1.2 Response Header Fields | RTSP status codes are extensible. RTSP applications are not required
The response-header fields allow the request recipient to pass | to understand the meaning of all registered status codes, though such
additional information about the response which cannot be placed in | understanding is obviously desirable. However, applications MUST
the Status-Line. These header fields give information about the | understand the class of any status code, as indicated by the first
server and about further access to the resource identified by the | digit, and treat any unrecognized response as being equivalent to the
Request-URL. All headers currently being classified as response | x00 status code of that class, with the exception that an
headers are listed in table 7.1.2. unrecognized response MUST NOT be cached. For example, if an
unrecognized status code of 431 is received by the client, it can
safely assume that there was something wrong with its request and
treat the response as if it had received a 400 status code. In such
cases, user agents SHOULD present to the user the entity returned
with the response, since that entity is likely to include human-
readable information which will explain the unusual status.
Header Defined in Section 7.1.2 Response Header Fields
______________________________________
Accept-Ranges Section 14.4
Location Section 14.25
Proxy-Authenticate Section 14.26
Public Section 14.28
Range Section 14.29
Retry-After Section 14.31
RTP-Info Section 14.33
Scale Section 14.34
Session Section 14.37
Server Section 14.36
Speed Section 14.35
Transport Section 14.40
Unsupported Section 14.41
Vary Section 14.43
WWW-Authenticate Section 14.45
Table 5: The RTSP response headers The response-header fields allow the request recipient to pass
additional information about the response which cannot be placed in
the Status-Line. These header fields give information about the
server and about further access to the resource identified by the
Request-URL. All headers currently being classified as response
headers are listed in table 5.
Response-header field names can be extended reliably only in Response-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or combination with a change in the protocol version. However, new or
experimental header fields MAY be given the semantics of response- experimental header fields MAY be given the semantics of response-
header fields if all parties in the communication recognize them to header fields if all parties in the communication recognize them to
be response-header fields. Unrecognized header fields are treated as be response-header fields. Unrecognized header fields are treated as
entity-header fields. entity-header fields.
8 Entity 8 Entity
Request and Response messages MAY transfer an entity if not otherwise | Request and Response messages MAY transfer an entity if not otherwise
restricted by the request method or response status code. An entity | restricted by the request method or response status code. An entity
consists of entity-header fields and an entity-body, although some | consists of entity-header fields and an entity-body, although some
responses will only include the entity-headers. | responses will only include the entity-headers.
The SET_PARAMETER, and GET_PARAMETER request and response, and | The SET_PARAMETER, and GET_PARAMETER request and response, and
DESCRIBE response MAY have an entity. All 4xx and 5xx responses MAY | DESCRIBE response MAY have an entity. All 4xx and 5xx responses MAY
also have an entity. | also have an entity.
In this section, both sender and recipient refer to either the client
or the server, depending on who sends and who receives the entity.
8.1 Entity Header Fields
Entity-header fields define optional meta-information about the
entity-body or, if no body is present, about the resource identified
by the request. The entity header fields are listed in table 8.1.
The extension-header mechanism allows additional entity-header fields
to be defined without changing the protocol, but these fields cannot
be assumed to be recognizable by the recipient. Unrecognized header
fields SHOULD be ignored by the recipient and forwarded by proxies.
8.2 Entity Body
See [H7.2] with the addition that a RTSP message with an entity body
MUST include the Content-Type and Content-Length headers.
9 Connections
RTSP requests can be transmitted in several different ways:
o persistent transport connections used for several request-
response transactions;
o one connection per request/response transaction;
o connectionless mode.
The type of transport is defined by the RTSP URL (Section 3.2). For
the scheme "rtsp", a connection is assumed, while the scheme "rtspu"
calls for RTSP requests to be sent without setting up a connection.
Unlike HTTP, RTSP allows the media server to send requests to the
media client. However, this is only supported for persistent
connections, as the media server otherwise has no reliable way of
reaching the client. Also, this is the only way that requests from
media server to client are likely to traverse firewalls.
9.1 Pipelining
A client that supports persistent connections or connectionless mode
MAY "pipeline" its requests (i.e., send multiple requests without
waiting for each response). A server MUST send its responses to those
requests in the same order that the requests were received.
9.2 Reliability and Acknowledgements
The transmission of RTSP over UDP was optionally to implement and
specified in RFC 2326. However that definition was not satisfactory
for interoperable implementations. Due to lack of interest, this
specification does not specify how RTSP over UDP shall be
implemented. However to maintain backwards compatibility in the
message format certain RTSP headers must be maintained. These
mechanism are described below. The next section Unreliable Transport
(section 9.3) provides documentation of certain features that are
necessary for transport protocols like UDP.
Any RTSP request according to this specification SHALL NOT be sent to
a multicast address. Any RTSP request SHALL be acknowledged. If a
reliable transport protocol is used to carry RTSP, requests MUST NOT
be retransmitted; the RTSP application MUST instead rely on the
underlying transport to provide reliability.
If both the underlying reliable transport such as TCP and
Code Reason Method Code Reason Method
_______________________________________________________ __________________________________________________________
100 Continue all 100 Continue all
_______________________________________________________ __________________________________________________________
200 OK all 200 OK all
201 Created RECORD 201 Created RECORD
250 Low on Storage Space RECORD 250 Low on Storage Space RECORD
_______________________________________________________ __________________________________________________________
300 Multiple Choices all 300 Multiple Choices all
301 Moved Permanently all 301 Moved Permanently all
302 Found all 302 Found all
303 See Other all 303 See Other all
305 Use Proxy all 305 Use Proxy all
350 Going Away all
351 Load Balancing all
_______________________________________________________ __________________________________________________________
400 Bad Request all 400 Bad Request all
401 Unauthorized all 401 Unauthorized all
402 Payment Required all 402 Payment Required all
403 Forbidden all 403 Forbidden all
404 Not Found all 404 Not Found all
405 Method Not Allowed all 405 Method Not Allowed all
406 Not Acceptable all 406 Not Acceptable all
407 Proxy Authentication Required all 407 Proxy Authentication Required all
408 Request Timeout all 408 Request Timeout all
410 Gone all 410 Gone all
skipping to change at page 31, line 49 skipping to change at page 37, line 47
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 all
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 Allowed all 460 Only Aggregate Operation Allowed all
461 Unsupported Transport all 461 Unsupported Transport all
462 Destination Unreachable all 462 Destination Unreachable all
_______________________________________________________ 470 Connection Authorization Required all
471 Connection Credentials not accepted all
__________________________________________________________
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
Table 4: Status codes and their usage with RTSP methods Table 4: Status codes and their usage with RTSP methods
In this section, both sender and recipient refer to either the client | Header Defined in Section
or the server, depending on who sends and who receives the entity. | ______________________________________
Accept-Ranges Section 14.5
8.1 Entity Header Fields | ETag Section 14.20
Location Section 14.28
Proxy-Authenticate Section 14.29
Public Section 14.31
Range Section 14.32
Retry-After Section 14.34
RTP-Info Section 14.36
Scale Section 14.37
Session Section 14.40
Server Section 14.39
Speed Section 14.38
Transport Section 14.43
Unsupported Section 14.44
Vary Section 14.46
WWW-Authenticate Section 14.48
Entity-header fields define optional meta-information about the | Table 5: The RTSP response headers
entity-body or, if no body is present, about the resource identified |
by the request. The entity header fields are listed in table 8.1. |
Header Defined in Section Header Defined in Section
____________________________________ ____________________________________
Allow Section 14.5 Allow Section 14.6
Content-Base Section 14.11 Content-Base Section 14.12
Content-Encoding Section 14.12 Content-Encoding Section 14.13
Content-Language Section 14.13 Content-Language Section 14.14
Content-Length Section 14.14 Content-Length Section 14.15
Content-Location Section 14.15 Content-Location Section 14.16
Content-Type Section 14.16 Content-Type Section 14.17
Expires Section 14.19 Expires Section 14.21
Last-Modified Section 14.24 Last-Modified Section 14.27
Table 6: The RTSP entity headers Table 6: The RTSP entity headers
The extension-header mechanism allows additional entity-header fields |
to be defined without changing the protocol, but these fields cannot |
be assumed to be recognizable by the recipient. Unrecognized header |
fields SHOULD be ignored by the recipient and forwarded by proxies. |
8.2 Entity Body |
See [H7.2] with the addition that a RTSP message with an entity body |
MUST include the Content-Type and Content-Length headers. |
9 Connections
RTSP requests can be transmitted in several different ways:
o persistent transport connections used for several request-
response transactions;
o one connection per request/response transaction;
o connectionless mode.
The type of transport is defined by the RTSP URL (Section 3.2). For |
the scheme "rtsp", a connection is assumed, while the scheme "rtspu" |
calls for RTSP requests to be sent without setting up a connection.
Unlike HTTP, RTSP allows the media server to send requests to the
media client. However, this is only supported for persistent
connections, as the media server otherwise has no reliable way of
reaching the client. Also, this is the only way that requests from
media server to client are likely to traverse firewalls.
9.1 Pipelining
A client that supports persistent connections or connectionless mode
MAY "pipeline" its requests (i.e., send multiple requests without
waiting for each response). A server MUST send its responses to those
requests in the same order that the requests were received.
9.2 Reliability and Acknowledgements
The transmission of RTSP over UDP was optionally to implement and
specified in RFC 2326. However that definition was not satisfactory
for interoperable implementations. Due to lack of interest, this
specification does not specify how RTSP over UDP shall be
implemented. However to maintain backwards compatibility in the
message format certain RTSP headers must be maintained. These
mechanism are described below. The next section Unreliable Transport
(section 9.3) provides documentation of certain features that are
necessary for transport protocols like UDP.
Any RTSP request according to this specification SHALL NOT be sent to
a multicast address. Any RTSP request SHALL be acknowledged. If a
reliable transport protocol is used to carry RTSP, requests MUST NOT
be retransmitted; the RTSP application MUST instead rely on the
underlying transport to provide reliability.
If both the underlying reliable transport such as TCP and
the RTSP application retransmit requests, it is possible the RTSP application retransmit requests, it is possible
that each packet loss results in two retransmissions. The that each packet loss results in two retransmissions. The
receiver cannot typically take advantage of the receiver cannot typically take advantage of the
application-layer retransmission since the transport stack application-layer retransmission since the transport stack
will not deliver the application-layer retransmission will not deliver the application-layer retransmission
before the first attempt has reached the receiver. If the before the first attempt has reached the receiver. If the
packet loss is caused by congestion, multiple packet loss is caused by congestion, multiple
retransmissions at different layers will exacerbate the retransmissions at different layers will exacerbate the
congestion. congestion.
Each request carries a sequence number in the CSeq header (Section Each request carries a sequence number in the CSeq header (Section
14.17), which MUST be incremented by one for each distinct request 14.18), which MUST be incremented by one for each distinct request
transmitted to the destination end-point. The initial sequence transmitted to the destination end-point. The initial sequence
number MAY be chosen arbitrary, but is RECOMMENDED to begin with 0. number MAY be chosen arbitrary, but is RECOMMENDED to begin with 0.
If a request is repeated because of lack of acknowledgement, the If a request is repeated because of lack of acknowledgement, the
request MUST carry the original sequence number (i.e., the sequence request MUST carry the original sequence number (i.e., the sequence
number is not incremented). number is not incremented).
9.3 Unreliable Transport 9.3 Unreliable Transport
This section provides some information to future specification of This section provides some information to future specification of
RTSP over unreliable transport. RTSP over unreliable transport.
Requests shall be acknowledged by the receiver. If there is no | Requests shall be acknowledged by the receiver. If there is no
acknowledgement, the sender may resend the same message after a | acknowledgement, the sender may resend the same message after a
timeout of one round-trip time (RTT). The round-trip time is | timeout of one round-trip time (RTT). The round-trip time is
estimated as in TCP (RFC 1123) [14], with an initial round-trip value | estimated as in TCP (RFC 1123) [15], with an initial round-trip value
of 500 ms. An implementation MAY cache the last RTT measurement as | of 500 ms. An implementation MAY cache the last RTT measurement as
the initial value for future connections. the initial value for future connections.
If RTSP is used over a small-RTT LAN, standard procedures for If RTSP is used over a small-RTT LAN, standard procedures for
optimizing initial TCP round trip estimates, such as those used in optimizing initial TCP round trip estimates, such as those used in
T/TCP (RFC 1644) [33], can be beneficial. T/TCP (RFC 1644) [36], can be beneficial.
The Timestamp header (Section 14.39) is used to avoid the The Timestamp header (Section 14.42) is used to avoid the
retransmission ambiguity problem [34] and obviates the need for retransmission ambiguity problem [37] and obviates the need for
Karn's algorithm. Karn's algorithm.
If a request is repeated because of lack of acknowledgement, the If a request is repeated because of lack of acknowledgement, the
request must carry the original sequence number (i.e., the sequence request must carry the original sequence number (i.e., the sequence
number is not incremented). number is not incremented).
A number of RTSP messages destined for the same control end point may | A number of RTSP messages destined for the same control end point may
be packed into a single lower-layer PDU. be packed into a single lower-layer PDU.
The default port for the RTSP server is 554 for UDP. The default port for the RTSP server is 554 for UDP.
9.4 The usage of connections 9.4 The usage of connections
Systems implementing RTSP MUST support carrying RTSP over TCP. The | Systems implementing RTSP MUST support carrying RTSP over TCP. The
default port for the RTSP server is 554 for TCP. A number of RTSP | default port for the RTSP server is 554 for TCP. A number of RTSP
packets destined for the same control end point may be encapsulated | packets destined for the same control end point may be encapsulated
into a TCP stream. RTSP data MAY be interleaved with RTP and RTCP | into a TCP stream. RTSP data MAY be interleaved with RTP and RTCP
packets, see section 12. Unlike HTTP, an RTSP message MUST contain a | packets, see section 12. Unlike HTTP, an RTSP message MUST contain a
Content-Length header field whenever that message contains a payload | Content-Length header field whenever that message contains a payload
(entity). Otherwise, an RTSP packet is terminated with an empty line | (entity). Otherwise, an RTSP packet is terminated with an empty line
immediately following the last message header. immediately following the last message header.
TCP can be used for both persistent connections and for one message TCP can be used for both persistent connections and for one message
exchange per connection, as presented above. This section gives exchange per connection, as presented above. This section gives
further rules and recommendations on how to handle these connections further rules and recommendations on how to handle these connections
so maximum interoperability and flexibility can be achieved. so maximum interoperability and flexibility can be achieved.
A server SHALL handle both persistent connections and one A server SHALL handle both persistent connections and one
request/response transaction per connection. A persistent connection request/response transaction per connection. A persistent connection
MAY be used for all transactions between the server and client, MAY be used for all transactions between the server and client,
skipping to change at page 35, line 28 skipping to change at page 40, line 29
message exchange or can be kept open for several messages, i.e. message exchange or can be kept open for several messages, i.e.
persistent. persistent.
A major motivation for allowing non-persistent connections are that A major motivation for allowing non-persistent connections are that
they ensure fault tolerance. A second one is to allow for application they ensure fault tolerance. A second one is to allow for application
layer mobility. A server and client supporting non-persistent layer mobility. A server and client supporting non-persistent
connection can survive a loss of a TCP connection, e.g. due to a NAT connection can survive a loss of a TCP connection, e.g. due to a NAT
timeout. When the client has discovered that the TCP connection has timeout. When the client has discovered that the TCP connection has
been lost, it can set up a new one when there is need to communicate. been lost, it can set up a new one when there is need to communicate.
The client MAY close the connection at any time when no outstanding | The client MAY close the connection at any time when no outstanding
request/response transactions exist. The server SHOULD NOT close the | request/response transactions exist. The server SHOULD NOT close the
connection unless at least one RTSP session timeout period has passed | connection unless at least one RTSP session timeout period has passed
without data traffic. A server SHOULD NOT initiate a close of a | without data traffic. A server SHOULD NOT initiate a close of a
connection directly after responding to a TEARDOWN request for the | connection directly after responding to a TEARDOWN request for the
whole session. A server SHOULD NOT close the connection as a result | whole session. A server SHOULD NOT close the connection as a result
of responding to a request with an error code. Doing this would | of responding to a request with an error code. Doing this would
prevent or result in extra overhead for the client when testing | prevent or result in extra overhead for the client when testing
advanced or special types of requests. advanced or special types of requests.
The client SHOULD NOT have more than one connection to the server at The client SHOULD NOT have more than one connection to the server at
any given point. If a client or proxy handles multiple RTSP sessions any given point. If a client or proxy handles multiple RTSP sessions
on the same server, it is RECOMMENDED to use only a single on the same server, it is RECOMMENDED to use only a single
connection. connection.
Older services which was implemented according to RFC 2326 sometimes Older services which was implemented according to RFC 2326 sometimes
requires the client to use persistent connection. The client closing requires the client to use persistent connection. The client closing
the connection may result in that the server removes the session. To the connection may result in that the server removes the session. To
skipping to change at page 36, line 17 skipping to change at page 41, line 19
A server implemented according to this specification MUST respond A server implemented according to this specification MUST respond
that it supports the "play.basic" feature-tag above. A client MAY that it supports the "play.basic" feature-tag above. A client MAY
send a request including the Supported header in a request to send a request including the Supported header in a request to
determine support of non-persistent connections. A server supporting determine support of non-persistent connections. A server supporting
non-persistent connections will return the "play.basic" feature-tag non-persistent connections will return the "play.basic" feature-tag
in its response. If the client receives the feature-tag in the in its response. If the client receives the feature-tag in the
response, it can be certain that the server handles non-persistent response, it can be certain that the server handles non-persistent
connections. connections.
9.5 Timing Out RTSP messages | 9.5 Timing Out RTSP messages
Receivers of a request (responder) SHOULD respond to requests in a | Receivers of a request (responder) SHOULD respond to requests in a
timely manner even when a reliable transport such as TCP is used. | timely manner even when a reliable transport such as TCP is used.
Similarly, the sender of a request (requestor) SHOULD wait for a | Similarly, the sender of a request (requestor) SHOULD wait for a
sufficient time for a response before concluding that the responder | sufficient time for a response before concluding that the responder
will not be acting upon its request. | will not be acting upon its request.
A responder SHOULD respond to all requests within 5 seconds. If the | A responder SHOULD respond to all requests within 5 seconds. If the
responder recognizes that processing of a request will take longer | responder recognizes that processing of a request will take longer
than 5 seconds, it SHOULD send a 100 response as soon as possible. It | than 5 seconds, it SHOULD send a 100 response as soon as possible. It
SHOULD continue sending a 100 response every 5 seconds thereafter | SHOULD continue sending a 100 response every 5 seconds thereafter
until it is ready to send the final response to the requestor. After | until it is ready to send the final response to the requestor. After
sending a 100 response, the receiver MUST send a final response | sending a 100 response, the receiver MUST send a final response
indicating the success or failure of the request. | indicating the success or failure of the request.
A requestor SHOULD wait at least 10 seconds for a response before | A requestor SHOULD wait at least 10 seconds for a response before
concluding that the responder will not be responding to its request. | concluding that the responder will not be responding to its request.
After receiving a 100 response, the requestor SHOULD continue waiting | After receiving a 100 response, the requestor SHOULD continue waiting
for further responses. If more than 10 seconds elapses without | for further responses. If more than 10 seconds elapses without
receiving any response, the requestor MAY assume the responder is | receiving any response, the requestor MAY assume the responder is
unresponsive and abort the connection. | unresponsive and abort the connection.
A requestor SHOULD wait longer than 10 seconds for a response if it | A requestor SHOULD wait longer than 10 seconds for a response if it
is experiencing significant transport delays on its connection to the | is experiencing significant transport delays on its connection to the
responder. The requestor is capable of determining the RTT using the | responder. The requestor is capable of determining the RTT using the
Timestamp header (section 14.39) in any RTSP request. Timestamp header (section 14.42) in any RTSP request.
9.6 Use of IPv6 9.6 Use of IPv6
This specification has been updated so that it supports IPv6. This specification has been updated so that it supports IPv6.
However this support was not present in RFC 2326 therefore some However this support was not present in RFC 2326 therefore some
interoperability issues exist. A RFC 2326 implementation can support interoperability issues exist. A RFC 2326 implementation can support
IPv6 as long as no explicit IPv6 addresses are used within RTSP IPv6 as long as no explicit IPv6 addresses are used within RTSP
messages. This require that any RTSP URL pointing at a IPv6 host must messages. This require that any RTSP URL pointing at a IPv6 host must
use fully qualified domain name and not a IPv6 address. Further the use fully qualified domain name and not a IPv6 address. Further the
Transport header must not use the parameters source and destination. Transport header must not use the parameters source and destination.
skipping to change at page 38, line 44 skipping to change at page 43, line 45
Unsupported: This header is used in 551 error response to tell Unsupported: This header is used in 551 error response to tell
which feature(s) that was not supported. Such a response is which feature(s) that was not supported. Such a response is
only the result of the usage of the Require and/or Proxy- only the result of the usage of the Require and/or Proxy-
Require header where one or more feature where not Require header where one or more feature where not
supported. This information allows the requestor to make supported. This information allows the requestor to make
the best of situations as it knows which features that was the best of situations as it knows which features that was
not supported. not supported.
11 Method Definitions 11 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-URL. The method name is case-sensitive. | identified by the Request-URL. The method name is case-sensitive.
New methods may be defined in the future. Method names may not start | New methods may be defined in the future. Method names may not start
with a $ character (decimal 24) and must be a token as defined by the | with a $ character (decimal 24) and must be a token as defined by the
ABNF. Methods are summarized in Table 7. ABNF. Methods are summarized in Table 11.
Notes on Table 7: PAUSE is recommended, but not required in that a |
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, S -> C P,S optional optional GET_PARAMETER C -> S, S -> C P,S optional optional
OPTIONS C -> S, S -> C P,S R=Req, Sd=Opt Sd=Req, R=Opt OPTIONS C -> S, S -> C P,S R=Req, Sd=Opt Sd=Req, R=Opt
PAUSE C -> S P,S recommended recommended PAUSE C -> S P,S recommended recommended
PING C -> S, S -> C P,S recommended optional PING C -> S, S -> C P,S recommended optional
PLAY C -> S P,S required required PLAY C -> S P,S required required
REDIRECT S -> C P,S optional optional REDIRECT S -> C P,S optional optional
SETUP C -> S S required required SETUP C -> S S required required
SET_PARAMETER C -> S, S -> C P,S optional optional SET_PARAMETER C -> S, S -> C P,S optional optional
TEARDOWN C -> S P,S required required TEARDOWN C -> S P,S required required
Table 7: Overview of RTSP methods, their direction, and what objects Table 7: Overview of RTSP methods, their direction, and what objects |
(P: presentation, S: stream) they operate on. Legend: R=Responde to, (P: presentation, S: stream) they operate on. Legend: R=Respond, |
Sd=Send, Opt: Optional, Req: Required, Rec: Recommended Sd=Send, Opt: Optional, Req: Required, Rec: Recommended
fully functional server can be built that does not support this | Notes on Table 11: PAUSE is recommended, but not required. For |
method, for example, for live feeds. If a server does not support a | example, a fully functional server can be built to deliver live feeds |
particular method, it MUST return 501 (Not Implemented) and a client | that does not support this method. If a RTSP agent does not support a |
SHOULD NOT try this method again for this server and resource. particular method, it MUST return 501 (Not Implemented) and the |
requesting RTSP agent, in turn, SHOULD NOT try this method again for |
the given agent / resource combination.
11.1 OPTIONS 11.1 OPTIONS
The behavior is equivalent to that described in [H9.2]. An OPTIONS The semantics of the RTSP OPTIONS method is equivalent to that of the |
request may be issued at any time, e.g., if the client is about to HTTP OPTIONS method described in [H9.2]. In, RTSP, however, OPTIONS |
try a nonstandard request. It does not influence the session state. is bi-directional, where a client can request it to a server and vice |
The Public header MUST be included in responses to indicate which versa. A client MUST implement the capability to send an OPTIONS |
methods that are supported by the server. To specify which methods request and a server or a proxy MUST implement the capability to |
that are possible to use for the specified resource, the Allow MAY be respond to an OPTIONS request. The client, server or proxy MAY also |
used. By including in the OPTIONS request a Supported header, the implement the converse of their required capability. |
requester can determine which features the other part supports.
The request URL determines which scope the OPTIONS request has. By An OPTIONS request may be issued at any time. Such a request does not |
giving the URL of a certain media the capabilities regarding this modify the session state. However, it may prolong the session |
media will be responded. By using the "*" URL the request regards the lifespan (see below). The URL in an OPTIONS request determines the |
next hop only, while having a URL with only the host address regards scope of the request and the corresponding response. If the request |
the server without any media relevance. URL 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 |
the indicated RTSP agent. A request URL with only the host address |
limits the scope to the specified RTSP agent's general capabilities |
without regard to any specific media. If the request URL is an |
asterisk ("*"), the scope is limited to the general capabilities of |
the next hop (i.e. the RTSP agent in direct communication with the |
request sender). |
Regardless of scope of the request, the Public header MUST always be |
included in the OPTIONS response listing the methods that are |
supported by the responding RTSP agent. In addition, if the scope of |
the request is limited to a media resource, the Allow header MAY be |
included in the response to enumerate the set of methods that are |
allowed for that resource. If the given resource is not available, |
the RTSP agent SHOULD return an appropriate response code such as 3rr |
or 4xx. The Supported header can be included in the request to query |
the set of features that are supported by the responding RTSP agent. |
The OPTIONS method can be used for RTSP session keep alive | The OPTIONS method can be used to keep an RTSP session alive. |
signalling, however this method is not the most recommended one, see | However, it is not the preferred means of session keep-alive |
section 14.37 for a preference list. A keep alive OPTIONS request | signalling, see section 14.40. An OPTIONS request intended for |
SHOULD use the media or aggregated control URL. For options to | keeping alive a RTSP session MUST include the Session header with the |
function as session state keep-alive, it is REQUIRED that the session | associated session ID. Such a request SHOULD also use the media or |
ID is included in the Session header. the aggregated control URL as the request URL.
Example: Example:
C->S: OPTIONS * RTSP/1.0 C->S: OPTIONS * RTSP/1.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Require: Require:
Proxy-Require: gzipped-messages Proxy-Require: gzipped-messages
Supported: play-basic Supported: play.basic
S->C: RTSP/1.0 200 OK S->C: RTSP/1.0 200 OK
CSeq: 1 CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
Supported: play-basic, implicit-play, gzipped-messages Supported: play.basic, implicit-play, gzipped-messages
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Note that some of the feature-tags in Require and Proxy-Require are Note that some of the feature-tags in Require and Proxy-Require are
necessarily fictional features (one would hope that we would not necessarily fictional features (one would hope that we would not
purposefully overlook a truly useful feature just so that we could purposefully overlook a truly useful feature just so that we could
have a strong example in this section). have a strong example in this section).
11.2 DESCRIBE 11.2 DESCRIBE
The DESCRIBE method retrieves the description of a presentation or | The DESCRIBE method is used to retrieve the description of a |
media object identified by the request URL from a server. The request | presentation or media object from a server. The request URL of the |
MAY use the Accept header to specify the description formats that the | DESCRIBE request identifies the media resource of interest. The |
client understands. The server responds with a description of the | client MAY include the Accept header in the request to list the |
requested resource. The DESCRIBE reply-response pair constitutes the | description formats that it understands. The server SHALL respond |
media initialization phase of RTSP. with a description of the requested resource and return the |
description in the entity of the response. The DESCRIBE reply-
response pair constitutes the media initialization phase of RTSP.
Example: Example:
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312 CSeq: 312
User-Agent: PhonyClient 1.2 User-Agent: PhonyClient 1.2
Accept: application/sdp, application/rtsl, application/mheg Accept: application/sdp, application/rtsl, application/mheg
S->C: RTSP/1.0 200 OK S->C: RTSP/1.0 200 OK
CSeq: 312 CSeq: 312
skipping to change at page 41, line 18 skipping to change at page 46, line 36
e=mjh@isi.edu (Mark Handley) e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127 c=IN IP4 224.2.17.12/127
t=2873397496 2873404696 t=2873397496 2873404696
a=recvonly a=recvonly
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31 m=video 2232 RTP/AVP 31
m=application 32416 UDP WB m=application 32416 UDP WB
a=orient:portrait a=orient:portrait
The DESCRIBE response MUST contain all media initialization The DESCRIBE response MUST contain all media initialization
information for the resource(s) that it describes. If a media client information for the resource(s) that it describes. Servers SHOULD NOT |
obtains a presentation description from a source other than DESCRIBE use the DESCRIBE response as a means of media indirection. |
and that description contains a complete set of media initialization
parameters, the client SHOULD use those parameters and not then
request a description for the same media via RTSP.
Additionally, servers SHOULD NOT use the DESCRIBE response as a means By forcing a DESCRIBE response to contain all media |
of media indirection. initialization for the set of streams that it describes, |
and discouraging use of DESCRIBE for media indirection, we |
avoid looping problems that might result from other |
approaches. |
By forcing a DESCRIBE response to contain all media Media initialization is a requirement for any RTSP-based system, but |
initialization for the set of streams that it describes, the RTSP specification does not dictate that this must be done via |
and discouraging use of DESCRIBE for media indirection, we the DESCRIBE method. There are four ways that an RTSP client may |
avoid looping problems that might result from other receive initialization information: |
approaches.
Media initialization is a requirement for any RTSP-based system, but o via a RTSP DESCRIBE method |
the RTSP specification does not dictate that this must be done via
the DESCRIBE method. There are three ways that an RTSP client may
receive initialization information:
o via RTSP's DESCRIBE method; o via some other protocol (HTTP, email attachment, etc.) |
o via some other protocol (HTTP, email attachment, etc.); o via the command line or standard input |
o via the command line or standard input (thus working as a If a client obtains a valid description from an alternate source, the
browser helper application launched with an SDP file or other client MAY use this description for initialization purposes without
media initialization format). issuing a DESCRIBE request for the same media.
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 a "helper application" that accepts a media initialization act as "helper applications" that accept a media initialization file |
file from standard input, command line, and/or other means that are from standard input, command line, and/or other means that are |
appropriate to the operating environment of the client. appropriate to the operating environment of the clients.
11.3 SETUP 11.3 SETUP
The SETUP request for a URL specifies the transport mechanism to be The SETUP request for a URL 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 three |
different cases; Create a RTSP session or add a media to a session, different cases; Create a RTSP session, add a media to a session, and |
and change the transport parameters of already set up media stream. change the transport parameters of already set up media stream. Using |
Using SETUP to create or add media to a session when in PLAY state is SETUP to create or add media to a session when in PLAY state is |
unspecified. Otherwise SETUP can be used in all three states; INIT, unspecified. Otherwise SETUP can be used in all three states; INIT, |
and READY, for both purposes and in PLAY to change the transport and READY, for both purposes and in PLAY to change the transport |
parameters. parameters.
The Transport header, see section 14.40, specifies the transport | The Transport header, see section 14.43, specifies the transport
parameters acceptable to the client for data transmission; the | parameters acceptable to the client for data transmission; the
response will contain the transport parameters selected by the | response will contain the transport parameters selected by the
server. This allows the client to enumerate in priority order the | server. This allows the client to enumerate in priority order the
transport mechanisms and parameters acceptable to it, while the | transport mechanisms and parameters acceptable to it, while the
server can select the most appropriate. It is expected that the | server can select the most appropriate. It is expected that the
session description format used will enable the client to select a | session description format used will enable the client to select a
limited number possible configurations that are offered to the server | limited number possible configurations that are offered to the server
to choose from. All transport parameters SHOULD be included in the | to choose from. All transport parameters SHOULD be included in the
Transport header, the use of other headers for this purpose is | Transport header, the use of other headers for this purpose is
discouraged due to middle boxes. discouraged due to middle boxes.
For the benefit of any intervening firewalls, a client SHOULD For the benefit of any intervening firewalls, a client SHOULD
indicate the transport parameters even if it has no influence over indicate the 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. multicast address.
Since SETUP includes all transport initialization Since SETUP includes all transport initialization
information, firewalls and other intermediate network information, firewalls and other intermediate network
devices (which need this information) are spared the more devices (which need this information) are spared the more
arduous task of parsing the DESCRIBE response, which has arduous task of parsing the DESCRIBE response, which has
been reserved for media initialization. been reserved for media initialization.
In a SETUP response the server SHOULD include the Accept-Ranges In a SETUP response the server SHOULD include the Accept-Ranges
header (see section 14.4 to indicate which time formats that are header (see section 14.5 to indicate which time formats that are
acceptable to use for this media resource. acceptable to use for this media resource.
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
CSeq: 302 CSeq: 302
Transport: RTP/AVP;unicast;client_port=4588-4589, Transport: RTP/AVP;unicast;client_port=4588-4589,
RTP/AVP/TCP;unicast;interleave=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
S->C: RTSP/1.0 200 OK S->C: RTSP/1.0 200 OK
CSeq: 302 CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Session: 47112344 Session: 47112344;timeout=60
Transport: RTP/AVP;unicast;client_port=4588-4589; Transport: RTP/AVP;unicast;client_port=4588-4589;
server_port=6256-6257;ssrc=2A3F93ED server_port=6256-6257;ssrc=2A3F93ED
Accept-Ranges: NPT Accept-Ranges: NPT
In the above example the client want to create a RTSP session In the above example the client want to create a RTSP session
containing the media resource "rtsp://example.com/foo/bar/baz.rm". containing the media resource "rtsp://example.com/foo/bar/baz.rm".
The transport parameters acceptable to the client is either The transport parameters acceptable to the client is either
RTP/AVP/UDP (UDP per default) to be received on client port 4588 and RTP/AVP/UDP (UDP per default) to be received on client port 4588 and
4589 or RTP/AVP interleaved on the RTSP control channel. The server 4589 or RTP/AVP interleaved on the RTSP control channel. The server
selects the RTP/AVP/UDP transport and adds the ports it will send and selects the RTP/AVP/UDP transport and adds the ports it will send and
skipping to change at page 43, line 35 skipping to change at page 49, line 5
request into the existing session (aggregated session) or return request into the existing session (aggregated session) or return
error 459 (Aggregate Operation Not Allowed) (see Section 13.4.11). error 459 (Aggregate Operation Not Allowed) (see Section 13.4.11).
An Aggregate control URL MUST be used to control an aggregated An Aggregate control URL MUST be used to control an aggregated
session. This URL MUST be different from the stream control URLs of session. This URL MUST be different from the stream control URLs of
the individual media streams included in the aggregate. The Aggregate the individual media streams included in the aggregate. The Aggregate
control URL is to be specified by the session description if the control URL is to be specified by the session description if the
server supports aggregated control and aggregated control is desired server supports aggregated control and aggregated control is desired
for the session. However even if aggregated control is offered the for the session. However even if aggregated control is offered the
client MAY chose to not set up the session in aggregated control. If client MAY chose to not set up the session in aggregated control. If
an Aggregate control URL is not specified in the session description, an Aggregate control URL is not specified in the session description,
it is normally an indication that non-aggregated control should be | it is normally an indication that non-aggregated control should be
used. The SETUP of media streams in an aggregate which has not been | used. The SETUP of media streams in an aggregate which has not been
given an aggregated control URL is unspecified. given an aggregated control URL is unspecified.
While the session ID sometimes has enough information for While the session ID sometimes has enough information for
aggregate control of a session, the Aggregate control URL aggregate control of a session, the Aggregate control URL
is still important for some methods such as SET_PARAMETER is still important for some methods such as SET_PARAMETER
where the control URL enables the resource in question to where the control URL enables the resource in question to
be easily identified. The Aggregate control URL is also be easily identified. The Aggregate control URL is also
useful for proxies, enabling them to route the request to useful for proxies, enabling them to route the request to
the appropriate server, and for logging, where it is useful the appropriate server, and for logging, where it is useful
to note the actual resource that a request was operating to note the actual resource that a request was operating
on. Finally, presence of the Aggregate control URL allows on. Finally, presence of the Aggregate control URL allows
for backwards compatibility with RFC 2326 [1]. for backwards compatibility with RFC 2326 [1].
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 within a certain has not demonstrated liveness signs from the client within a certain
timeout period. The default timeout value is 60 seconds; the server timeout period. The default timeout value is 60 seconds; the server
MAY set this to a different value and indicate so in the timeout MAY set this to a different value and indicate so in the timeout
field of the Session header in the SETUP response. For further field of the Session header in the SETUP response. For further
discussion see chapter 14.37. Signs of liveness for a RTSP session discussion see chapter 14.40. Signs of liveness for a RTSP session
are: are:
o Any RTSP request from a client which includes a Session header o Any RTSP request from a client which includes a Session header
with that session's ID. with that session's ID.
o If RTP is used as a transport for the underlying media o If RTP is used as a transport for the underlying media
streams, an RTCP sender or receiver report from the client for streams, an RTCP sender or receiver report from the client for
any of the media streams in that RTSP session. any of the media streams in that RTSP session.
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
skipping to change at page 45, line 44 skipping to change at page 51, line 14
Range: npt=10-15, npt=20-25, npt=30- Range: npt=10-15, npt=20-25, npt=30-
See the description of the PAUSE request for further examples. See the description of the PAUSE request for further examples.
A PLAY request without a Range header is legal. It SHALL start A PLAY request without a Range header is legal. It SHALL start
playing a stream from the beginning (npt=0-) unless the stream has playing a stream from the beginning (npt=0-) unless the stream has
been paused. If a stream has been paused via PAUSE, stream delivery been paused. If a stream has been paused via PAUSE, stream delivery
resumes at the pause point. The stream SHALL play until the end of resumes at the pause point. The stream SHALL play until the end of
the media. the media.
The Range header MUST NOT contain a time parameter. The usage of time | The Range header MUST NOT contain a time parameter. The usage of time
in PLAY method has been deprecated. If a request with time parameter | in PLAY method has been deprecated. If a request with time parameter
is received the server SHOULD respond with a 457 (Invalid Range) to | is received the server SHOULD respond with a 457 (Invalid Range) to
indicate that the time parameter is not supported. | indicate that the time parameter is not supported.
Server MUST include a "Range" header in any PLAY response. The |
response MUST use the same format as the request's range header | Server MUST include a "Range" header in any PLAY response. The
contained. If no Range header was in the request, the NPT time format | response MUST use the same format as the request's range header
SHOULD be used unless the client showed support for an other format | contained. If no Range header was in the request, the NPT time format
more appropriate. Also for a session with live media streams the | SHOULD be used unless the client showed support for an other format
Range header MUST indicate a valid time. It is RECOMMENDED that | more appropriate. Also for a session with live media streams the
normal play time is used, either the "now" indicator, for example | Range header MUST indicate a valid time. It is RECOMMENDED that
"npt=now-", or the time since session start as an open interval, e.g. | normal play time is used, either the "now" indicator, for example
"npt=96.23-". An absolute time value (clock) for the corresponding | "npt=now-", or the time since session start as an open interval, e.g.
time MAY be given, i.e. "clock=20030213T143205Z-". The UTC clock | "npt=96.23-". An absolute time value (clock) for the corresponding
time MAY be given, i.e. "clock=20030213T143205Z-". The UTC clock
format SHOULD only be used if client has shown support for it. format SHOULD only be used if client has shown support for it.
A media server only supporting playback MUST support the npt format A media server only supporting playback MUST support the npt format
and MAY support the clock and smpte formats. and MAY support the clock and smpte formats.
For a on-demand stream, the server MUST reply with the actual range For a on-demand stream, the server MUST reply with the actual range |
that will be played back. This may differ from the requested range if that will be played back, i.e. for which duration all media having |
alignment of the requested range to valid frame boundaries is content at this time is delivered. This may differ from the requested |
required for the media source. If no range is specified in the range if alignment of the requested range to valid frame boundaries |
request, the start position SHALL still be returned in the reply. If is required for the media source. Note that some media streams in an |
the medias that are part of an aggregate has different lengths, the aggregate may need to be delivered from even earlier points. Also |
PLAY request SHALL be performed as long as the given range is valid some media format has very long duration per individual data unit, |
for any media, for example the longest media. Media will be sent therefore it might be necessary for the client to parse the data |
whenever it is available for the given play-out point. unit, and select where to start. |
After playing the desired range, the presentation is NOT | Example: Single audio stream (MIDI) |
automatically paused, media delivery simply stops. A PAUSE request |
MUST be issued before another PLAY request can be issued. Note: This | C->S: PLAY rtsp://example.com/audio RTSP/1.0 |
is one change resulting in a non-operability with RFC 2326 | CSeq: 836 |
implementations. A client not issuing a PAUSE request before a new | Session: 12345678 |
PLAY will be stuck in PLAY state. To mitigate this backwards | Range: npt=7.05- |
compatibility issue the following behavior is recommended. If a |
server receives a PLAY request when in play state and all media has | S->C: RTSP/1.0 200 OK |
finished the requested playout, the server MAY interpret this as a | CSeq: 836 |
PLAY request received in ready state. However the server SHALL NOT do | Date: 23 Jan 1997 15:35:06 GMT |
this if the client has shown any support for this specification, for | Server: PhonyServer 1.0 |
example by sending a Supported header with the play.basic feature | Range: npt=3.52- |
RTP-Info:url=rtsp://example.com/audio; |
seq=14783;rtptime=2345962545 |
S->C: RTP Packet TS=2345962545 => NPT=3.52 |
Duration: 4.15 seconds |
In this example the client receives the first media packet that |
stretches all the way up and past the requested playtime. Thus it is |
a client decision if it desires to render to the user the time |
between 3.52 and 7.05 that the user requested. In most cases it is |
probably suitable to not render that time period. |
For live media sources it might be impossible to specify from which |
point in time all media streams that has active content can actually |
be delivered. Therefore a server MAY specify a start time (or now-) |
in the range header, for which not all media will be available from.
If no range is specified in the request, the start position SHALL
still be returned in the reply. If the medias that are part of an
aggregate has different lengths, the PLAY request SHALL be performed
as long as the given range is valid for any media, for example the
longest media. Media will be sent whenever it is available for the
given play-out point.
A PLAY response MAY include a header(s) carrying synchronization |
information. As the information necessary is dependent on the media |
transport format, further rules specifying the header and its usage |
is needed. For RTP the RTP-Info header is specified, see section |
14.36.
After playing the desired range, the presentation is NOT
automatically paused, media delivery simply stops. A PAUSE request
MUST be issued before another PLAY request can be issued. Note: This
is one change resulting in a non-operability with RFC 2326
implementations. A client not issuing a PAUSE request before a new
PLAY will be stuck in PLAY state. To mitigate this backwards
compatibility issue the following behavior is recommended. If a
server receives a PLAY request when in play state and all media has
finished the requested play out, the server MAY interpret this as a
PLAY request received in ready state. However the server SHALL NOT do
this if the client has shown any support for this specification, for
example by sending a Supported header with the play.basic feature
tag. tag.
A client desiring to play the media from the beginning MUST send a A client desiring to play the media from the beginning MUST send a
PLAY request with a Range header pointing at the beginning, e.g. PLAY request with a Range header pointing at the beginning, e.g.
npt=0-. If a PLAY request is received without a Range header when npt=0-. If a PLAY request is received without a Range header when
media delivery has stopped at the end, the server SHOULD respond with media delivery has stopped at the end, the server SHOULD respond with
a 457 "Invalid Range" error response. In that response the current a 457 "Invalid Range" error response. In that response the current
pause point in a Range header SHALL be included. pause point in a Range header SHALL be included.
The following example plays the whole presentation starting at SMPTE The following example plays the whole presentation starting at SMPTE
time code 0:10:20 until the end of the clip. Note: The RTP-Info time code 0:10:20 until the end of the clip. Note: The RTP-Info
headers has been broken into several lines to fit the page. headers has been broken into several lines to fit the page.
C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0 | C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0
CSeq: 833 | CSeq: 833
Session: 12345678 | Session: 12345678
Range: smpte=0:10:20- | Range: smpte=0:10:20-
S->C: RTSP/1.0 200 OK | S->C: RTSP/1.0 200 OK
CSeq: 833 | CSeq: 833
Date: 23 Jan 1997 15:35:06 GMT | Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 | Server: PhonyServer 1.0
Range: smpte=0:10:22-0:15:45 | Range: smpte=0:10:22-0:15:45
RTP-Info:url=rtsp://example.com/twister.en; | RTP-Info:url=rtsp://example.com/twister.en;
seq=14783;rtptime=2345962545 | 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/1.0 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Range: clock=19961108T142300Z-19961108T143520Z Range: clock=19961108T142300Z-19961108T143520Z
S->C: RTSP/1.0 200 OK S->C: RTSP/1.0 200 OK
skipping to change at page 47, line 34 skipping to change at page 54, line 4
Session: 12345678 Session: 12345678
Range: clock=19961108T142300Z-19961108T143520Z Range: clock=19961108T142300Z-19961108T143520Z
S->C: RTSP/1.0 200 OK S->C: RTSP/1.0 200 OK
CSeq: 835 CSeq: 835
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server:PhonyServer 1.0 Server:PhonyServer 1.0
Range: clock=19961108T142300Z-19961108T143520Z Range: clock=19961108T142300Z-19961108T143520Z
RTP-Info:url=rtsp://example.com/meeting.en; RTP-Info:url=rtsp://example.com/meeting.en;
seq=53745;rtptime=484589019 seq=53745;rtptime=484589019
All range specifiers in this specification allow for ranges with All range specifiers in this specification allow for ranges with
unspecified begin times (e.g. "npt=-30"). When used in a PLAY unspecified begin times (e.g. "npt=-30"). When used in a PLAY
request, the server treats this as a request to start/resume playback request, the server treats this as a request to start/resume playback
from the current pause point, ending at the end time specified in the from 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 SHALL be given. value, a 457 (Invalid Range) response SHALL be given.
The queued play functionality described in RFC 2326 [1] is removed | The queued play functionality described in RFC 2326 [1] is removed
and multiple ranges can be used to achieve a similar functionality. | and multiple ranges can be used to achieve a similar functionality.
If a server receives a PLAY request while in the PLAY state, the | If a server receives a PLAY request while in the PLAY state, the
server SHALL responde using the error code 455 (Method Not Valid In | server SHALL responde using the error code 455 (Method Not Valid In
This State). This will signal the client that queued play are not | This State). This will signal the client that queued play are not
supported. supported.
The use of PLAY for keep-alive signaling, i.e. PLAY request without a The use of PLAY for keep-alive signaling, i.e. PLAY request without a
range header in PLAY state, has also been depreciated. Instead a range header in PLAY state, has also been depreciated. Instead a
client can use, PING, SET_PARAMETER or OPTIONS for keep alive. A client can use, PING, SET_PARAMETER or OPTIONS for keep alive. A
server receiving a PLAY keep alive SHALL respond with the 455 error server receiving a PLAY keep alive SHALL respond with the 455 error
code. code.
11.5 PAUSE 11.5 PAUSE
skipping to change at page 51, line 20 skipping to change at page 57, line 31
Range: npt=14-15, npt=13-20 Range: npt=14-15, npt=13-20
Session: 12345678 Session: 12345678
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, even if the include the Range header with the current pause point, even if the
PAUSE request is asking for some other pause point. See examples PAUSE request is asking for some other pause point. See examples
below: below:
Examples: | Examples:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 | C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 834 | CSeq: 834
Session: 12345678 | Session: 12345678
S->C: RTSP/1.0 200 OK | S->C: RTSP/1.0 200 OK
CSeq: 834 | CSeq: 834
Session: 12345678 | Session: 12345678
Date: 23 Jan 1997 15:35:06 GMT | Date: 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/1.0 | C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 835 | CSeq: 835
Session: 12345678 | Session: 12345678
Range: 86- | Range: 86-
S->C: RTSP/1.0 200 OK | S->C: RTSP/1.0 200 OK
CSeq: 835 | CSeq: 835
Session: 12345678 | Session: 12345678
Date: 23 Jan 1997 15:35:07 GMT | Date: 23 Jan 1997 15:35:07 GMT
Range: npt=45.76-98.36 | Range: npt=45.76-98.36
11.6 TEARDOWN 11.6 TEARDOWN
The TEARDOWN client to server request stops the stream delivery for The TEARDOWN client to server request stops the stream delivery for
the given URL, freeing the resources associated with it. TEARDOWN the given URL, freeing the resources associated with it. TEARDOWN
MAY be done using either an aggregated or a media control URL. MAY be done using either an aggregated or a media control URL.
However some restrictions apply depending on the current state. The However some restrictions apply depending on the current state. The
TEARDOWN request SHALL contain a Session header indicating what TEARDOWN request SHALL contain a Session header indicating what
session the request applies to. session the request applies to.
A TEARDOWN using the aggregated control URL or the media URL in a A TEARDOWN using the aggregated control URL or the media URL in a
session under non-aggregated control MAY be done in any state (Ready, session under non-aggregated control MAY be done in any state (Ready,
and Play). A successful request SHALL result in that media delivery and Play). A successful request SHALL result in that media delivery
is immediately halted and the session state is destroyed. This SHALL is immediately halted and the session state is destroyed. This SHALL
be indicated through the lack of a Session header in the response. be indicated through the lack of a Session header in the response.
skipping to change at page 52, line 19 skipping to change at page 58, line 27
A TEARDOWN using the aggregated control URL or the media URL in a A TEARDOWN using the aggregated control URL or the media URL in a
session under non-aggregated control MAY be done in any state (Ready, session under non-aggregated control MAY be done in any state (Ready,
and Play). A successful request SHALL result in that media delivery and Play). A successful request SHALL result in that media delivery
is immediately halted and the session state is destroyed. This SHALL is immediately halted and the session state is destroyed. This SHALL
be indicated through the lack of a Session header in the response. be indicated through the lack of a Session header in the response.
A TEARDOWN using a media URL in an aggregated session MAY only be | A TEARDOWN using a media URL in an aggregated session MAY only be |
done in Ready state. Such a request only removes the indicated media | done in Ready state. Such a request only removes the indicated media |
stream and associated resources from the session. This may result in | stream and associated resources from the session. This may result in |
that a session returns to non-aggregated control, due to that it only | that a session returns to non-aggregated control, due to that it only |
contains a single media. In the response to TEARDOWN request | contains a single media after the requests completion. In the |
resulting in that the session still exist SHALL contain a Session | response to TEARDOWN request resulting in that the session still |
header to indicate this. exist SHALL contain a Session header to indicate this.
Note, the indication with the session header if sessions state remain Note, the indication with the session header if sessions state remain
may not be done correctly by a RFC 2326 client, but will be for any may not be done correctly by a RFC 2326 client, but will be for any
server signalling the "play.basic" tag. server signalling the "play.basic" tag.
Example: Example:
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 892 CSeq: 892
Session: 12345678 Session: 12345678
S->C: RTSP/1.0 200 OK S->C: RTSP/1.0 200 OK
CSeq: 892 CSeq: 892
Server: PhonyServer 1.0 Server: PhonyServer 1.0
11.7 GET_PARAMETER 11.7 GET_PARAMETER
The GET_PARAMETER request retrieves the value of a parameter or
parameters for a presentation or stream specified in the URL. If the
Session header is present in a request, the value of a parameter MUST
be retrieved in the specified session context. The content of the
reply and response is left to the implementation.
The GET_PARAMETER request retrieves the value of a parameter or | The method MAY also be used without a body (entity). If the this
parameters for a presentation or stream specified in the URL. If the | request is successful, i.e. a 200 OK response is received, then the
Session header is present in a request, the value of a parameter MUST | keep-alive time has been updated. Any non-required header present in
be retrieved in the specified session context. The content of the | such a request, may or may not been processed. The allow a client to
reply and response is left to the implementation. | determine if any such header has been processed, it is necessary to
use a feature tag and the Require header. Due to this reason it is
The method MAY also be used without a body (entity). If the this | RECOMMENDED that any parameters to be retrieved are sent in the body,
request is successful, i.e. a 200 OK response is received, then the |
keep-alive time has been updated. Any non-required header present in |
such a request, may or may not been processed. The allow a client to |
determine if any such header has been processed, it is necessary to |
use a feature tag and the Require header. Due to this reason it is |
RECOMMENDED that any parameters to be retrieved are sent in the body, |
rather than using any header. rather than using any header.
Example: Example:
S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 431 CSeq: 431
Content-Type: text/parameters Content-Type: text/parameters
Session: 12345678 Session: 12345678
Content-Length: 15 Content-Length: 15
skipping to change at page 53, line 34 skipping to change at page 59, line 45
packets_received: 10 packets_received: 10
jitter: 0.3838 jitter: 0.3838
The "text/parameters" section is only an example type for The "text/parameters" section is only an example type for
parameter. This method is intentionally loosely defined parameter. This method is intentionally loosely defined
with the intention that the reply content and response with the intention that the reply content and response
content will be defined after further experimentation. content will be defined after further experimentation.
11.8 SET_PARAMETER 11.8 SET_PARAMETER
This method requests to set the value of a parameter or a set of | This method requests to set the value of a parameter or a set of
parameters for a presentation or stream specified by the URL. The | parameters for a presentation or stream specified by the URL. The
method MAY also be used without a body (entity). If the this request | method MAY also be used without a body (entity). If the this request
is successful, i.e. a 200 OK response is received, then the keep- | is successful, i.e. a 200 OK response is received, then the keep-
alive time has been updated. Any non-required header present in such | alive time has been updated. Any non-required header present in such
a request, may or may not been processed. The allow a client to | a request, may or may not been processed. The allow a client to
determine if any such header has been processed, it is necessary to | determine if any such header has been processed, it is necessary to
use a feature tag and the Require header. Due to this reason it is | use a feature tag and the Require header. Due to this reason it is
RECOMMENDED that any parameters are sent in the body, rather than | RECOMMENDED that any parameters are sent in the body, rather than
using any header. using any header.
A request is RECOMMENDED to only contain a single parameter to allow A request is RECOMMENDED to only contain a single parameter to allow
the client to determine why a particular request failed. If the the client to determine why a particular request failed. If the
request contains several parameters, the server MUST only act on the request contains several parameters, the server MUST only act on the
request if all of the parameters can be set successfully. A server request if all of the parameters can be set successfully. A server
MUST allow a parameter to be set repeatedly to the same value, but it MUST allow a parameter to be set repeatedly to the same value, but it
MAY disallow changing parameter values. If the receiver of the MAY disallow changing parameter values. If the receiver of the
request does not understand or can locate a parameter error 451 request does not understand or can locate a parameter error 451
(Parameter Not Understood) SHALL be used. In the case a parameter is (Parameter Not Understood) SHALL be used. In the case a parameter is
skipping to change at page 54, line 39 skipping to change at page 61, line 4
CSeq: 421 CSeq: 421
Content-length: 20 Content-length: 20
Content-type: text/parameters Content-type: text/parameters
barparam: barstuff barparam: barstuff
S->C: RTSP/1.0 451 Parameter Not Understood S->C: RTSP/1.0 451 Parameter Not Understood
CSeq: 421 CSeq: 421
Content-length: 10 Content-length: 10
Content-type: text/parameters Content-type: text/parameters
barparam barparam
The "text/parameters" section is only an example type for The "text/parameters" section is only an example type for
parameter. This method is intentionally loosely defined parameter. This method is intentionally loosely defined
with the intention that the reply content and response with the intention that the reply content and response
content will be defined after further experimentation. content will be defined after further experimentation.
11.9 REDIRECT 11.9 REDIRECT
A redirect request informs the client that it MUST connect to another The REDIRECT method is issued by a server to inform a client that it |
server location. The REDIRECT request MAY contain the header MUST connect to another server location to access the resource |
Location, which indicates that the client should issue requests for indicated by the Request URL. The presence of the Session header in a |
that URL. The lack of a Location header in the response SHALL be REDIRECT request indicates the scope of the request, and determines |
interpreted as that the server can't any longer fulfill the current the specific semantics of the request. |
request, but has no alternative at the present where the client can
continue.
If a REDIRECT request contains a Session header, it is end-to-end and A REDIRECT request with a Session header has end-to-end (i.e. server |
applies only to the given session. If there are proxies in the to client) scope and applies only to the given session. Any |
request chain, they SHOULD NOT disconnect the control channel unless intervening proxies SHOULD NOT disconnect the control channel while |
there are no remaining sessions. If the Location header is included there are other remaining end-to-end sessions. The OPTIONAL Location |
it SHALL contain a full absolute URL pointing out the resource to header, if included in such a request, SHALL contain a complete |
reconnect too, i.e. the Location SHALL NOT contain only host and absolute URL pointing to the resource to which the client SHOULD |
port. reconnect. Specifically, the Location SHALL NOT contain just the host |
and port. A client may receive a REDIRECT request with a Session |
header, if and only if, an end-to-end session has been established. |
If a REDIRECT request does not contain a Session header, it is next- A client may receive a REDIRECT request without a Session header at |
hop and applies also to the control connection. If the Location any time when it has communication or a connection established with a |
header is included it SHOULD only contain an absolute URL containing server. The scope of such a request is limited to the next-hop (i.e. |
the host address and OPTIONAL the port number. If there are proxies the RTSP agent in direct communication with the server) and applies, |
in the request chain, they SHOULD do all of the following: (1) as well, to the control connection between the next-hop RTSP agent |
respond to the REDIRECT request, (2) disconnect the control channel and the server. A REDIRECT request without a Session header indicates |
from the requestor, (3) reconnect to the given host address, and (4) that all sessions and pending requests being managed via the control |
pass the request to each applicable client (typically those clients connection MUST be redirected. The OPTIONAL Location header, if |
with an active session or unanswered request from the requestor). included in such a request, SHOULD contain an absolute URL with only |
Note that the proxy is responsible for accepting the REDIRECT the host address and the OPTIONAL port number of the server to which |
response from its clients and these responses MUST NOT be passed on the RTSP agent SHOULD reconnect. Any intervening proxies SHOULD do |
to either the requesting or the destination server. all of the following in the order listed: |
A REDIRECT request with a Session header MAY only be received by a | 1. respond to the REDIRECT request |
client when it has the established session. A REDIRECT request |
without a Session MAY be received at any time communication is |
established with the server.
The redirect request MAY contain the header Range, which indicates 2. disconnect the control channel from the requesting server |
when the redirection takes effect. If the Range contains a "time="
value that is the wall clock time that the redirection MUST at the
latest take place. When the "time=" parameter is present the range
value MUST be ignored. However the range entered MUST be syntactical
correct and SHALL point at the beginning of any on-demand content. If
no time parameter is part of the Range header then redirection SHALL
take place when the media playout from the server reaches the given
time. The range value MUST be a single value in the open ended form,
e.g. npt=59-.
A server upon receiving a successful (2xx) response for a REDIRECT 3. connect to the server at the given host address |
request without any Range header SHALL consider the session as 4. pass the REDIRECT request to each applicable client |
removed and can free any session state. For this type of requests (typically those clients with an active session or an |
the rest of this paragraph applies. The server MAY close the unanswered request) |
signalling connection upon receiving the response for REDIRECT
requests without a Session header. The client SHOULD close the
signaling connection after having given the 2xx response to a
REDIRECT response, unless it has several sessions on the server. If
the client has multiple session on the server it SHOULD close the
connection when it has received and responded to REDIRECT requests
for all sessions.
A client receiving a REDIRECT request with a Range header SHALL issue Note: The proxy is responsible for accepting REDIRECT responses from |
a TEARDOWN request when the in indicated redirect point is reached. its clients; these responses MUST NOT be passed on to either the |
The client SHOULD for REDIRECT requests with Range header close the original server or the redirected server. |
signalling connection after a 2xx response on its TEARDOWN request.
The normal connection considerations apply for the server. This
differentiation from REDIRECT requests without range headers is to
allow clear an explicit state handling. As the state in the server
needs to be kept until the point of redirection, the handling becomes
more clear if the client is required to tear down the session at that
point.
If the client wants to continue to send or receive media for this The lack of a Location header in any REDIRECT request is indicative |
resource, the client will have to establish a new session with the of the server no longer being able to fulfill the current request and |
designated host. A client SHOULD issue a new DESCRIBE request with having no alternatives for the client to continue with its normal |
the URL given in the Location header, unless the URL only contains a operation. It is akin to a server initiated TEARDOWN that applies |
host address. In the cases the Location only contains a host address both to sessions as well as the general connection associated with |
the client MAY assume that the media on the server it is redirected that client. |
to is identical. Identical media means that all media configuration
information from the old session still is valid except for the host When the Range header is not included in a REDIRECT request, the |
address. In the case of absolute URLs in the location header the client SHOULD perform the redirection immediately and return a |
media redirected to can be either identical, slightly different or response to the server. The server can consider the session as |
totally different. This is the reason why a new DESCRIBE request terminated and can free any associated state after it receives the |
SHOULD be issued. successful (2xx) response. The server MAY close the signalling |
connection upon receiving the response and the client SHOULD close |
the signalling connection after sending the 2xx response. The |
exception to this is when the client has several sessions on the |
server being managed by the given signalling connection. In this |
case, the client SHOULD close the connection when it has received and |
responded to REDIRECT requests for all the sessions managed by the |
signalling connection. |
If the OPTIONAL Range header is included in a REDIRECT request, it |
indicates when the redirection shall take effect. The range value |
MUST be an open ended single value, e.g. npt=59-, indicating the |
play out time when redirection SHALL occur. Alternatively, a range |
with a time= parameter indicates the wall clock time by when the |
redirection MUST take place. When the time= parameter is present in |
the range, any range value MUST be ignored even though it MUST be |
syntactically correct. When the indicated redirect point is reached, |
a client MUST issue a TEARDOWN request and SHOULD close the |
signalling connection after receiving a 2xx response. The normal |
connection considerations apply for the server. |
The differentiation of REDIRECT requests with and without |
range headers is to allow for clear and explicit state |
handling. As the state in the server needs to be kept until |
the point of redirection, the handling becomes more clear |
if the client is required to TEARDOWN the session at the |
redirect point. |
After a REDIRECT request has been processed, a client that wants to |
continue to send or receive media for the resource identified by the |
request URL will have to establish a new session with the designated |
host. If the URL given in the Location header is a valid resource |
URL, a client SHOULD issue a DESCRIBE request for the URL. |
Note: The media resource indicated by the Location header |
can be either identical, slightly different or totally |
different. This is the reason why a new DESCRIBE request |
SHOULD be issued. If the Location header contains only a |
host address, the client MAY assume that the media on the |
new server is identical to the media on the old server, |
i.e. all media configuration information from the old |
session is still valid except for the host address.
This example request redirects traffic for this session to the new This example request redirects traffic for this session to the new
server at the given absolute time: server at the given absolute time:
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 732 CSeq: 732
Location: rtsp://s2.example.com:8001 Location: rtsp://s2.example.com:8001
Range: npt=0- ;time=19960213T143205Z Range: npt=0- ;time=19960213T143205Z
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
skipping to change at page 58, line 12 skipping to change at page 64, line 36
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "$" = 24 | Channel ID | Length in bytes | | "$" = 24 | Channel ID | Length in bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Length number of bytes of binary data : : Length number of bytes of binary data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The channel identifier is defined in the Transport header with the The channel identifier is defined in the Transport header with the
interleaved parameter(Section 14.40). interleaved parameter(Section 14.43).
When the transport choice is RTP, RTCP messages are also interleaved When the transport choice is RTP, RTCP messages are also interleaved
by the server over the TCP connection. The usage of RTCP messages is by the server over the TCP connection. The usage of RTCP messages is
indicated by including a range containing a second channel in the indicated by including a range containing a second channel in the
interleaved parameter of the Transport header, see section 14.40. If interleaved parameter of the Transport header, see section 14.43. If
RTCP is used, packets SHALL be sent on the first available channel RTCP is used, packets SHALL be sent on the first available channel
higher than the RTP channel. The channels are bi-directional and higher than the RTP channel. The channels are bi-directional and
therefore RTCP traffic are sent on the second channel in both therefore RTCP traffic are sent on the second channel in both
directions. directions.
RTCP is needed for synchronization when two or more streams RTCP is needed for synchronization when two or more streams
are interleaved in such a fashion. Also, this provides a are interleaved in such a fashion. Also, this provides a
convenient way to tunnel RTP/RTCP packets through the TCP convenient way to tunnel RTP/RTCP packets through the TCP
control connection when required by the network control connection when required by the network
configuration and transfer them onto UDP when possible. configuration and transfer them onto UDP when possible.
C->S: SETUP rtsp://example.com/bar.file RTSP/1.0 | C->S: SETUP rtsp://example.com/bar.file RTSP/1.0
CSeq: 2 | CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1 | Transport: RTP/AVP/TCP;unicast;interleaved=0-1
S->C: RTSP/1.0 200 OK | S->C: RTSP/1.0 200 OK
CSeq: 2 | CSeq: 2
Date: 05 Jun 1997 18:57:18 GMT | Date: 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;unicast;interleaved=5-6 | Transport: RTP/AVP/TCP;unicast;interleaved=5-6
Session: 12345678 | Session: 12345678
C->S: PLAY rtsp://example.com/bar.file RTSP/1.0 | C->S: PLAY rtsp://example.com/bar.file RTSP/1.0
CSeq: 3 | CSeq: 3
Session: 12345678 | Session: 12345678
S->C: RTSP/1.0 200 OK | S->C: RTSP/1.0 200 OK
CSeq: 3 | CSeq: 3
Session: 12345678 | Session: 12345678
Date: 05 Jun 1997 18:59:15 GMT | Date: 05 Jun 1997 18:59:15 GMT
RTP-Info: url=rtsp://example.com/bar.file; | RTP-Info: url=rtsp://example.com/bar.file;
seq=232433;rtptime=972948234 | seq=232433;rtptime=972948234
S->C: $005{2 byte length}{"length" bytes data, w/RTP header} | S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
S->C: $005{2 byte length}{"length" bytes data, w/RTP header} | S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
S->C: $006{2 byte length}{"length" bytes RTCP packet} | S->C: $006{2 byte length}{"length" bytes RTCP packet}
13 Status Code Definitions 13 Status Code Definitions
Where applicable, HTTP status [H10] codes are reused. Status codes Where applicable, HTTP status [H10] codes are reused. Status codes
that have the same meaning are not repeated here. See Table 4 for a that have the same meaning are not repeated here. See Table 4 for a
listing of which status codes may be returned by which requests. All listing of which status codes may be returned by which requests. All
error messages, 4xx and 5xx MAY return a body containing further error messages, 4xx and 5xx MAY return a body containing further
information about the error. information about the error.
13.1 Success 1xx 13.1 Success 1xx
skipping to change at page 59, line 43 skipping to change at page 66, line 27
from this set, as it is not used for redirection. from this set, as it is not used for redirection.
See [H10.3] for definition of status code 300 to 305. However See [H10.3] for definition of status code 300 to 305. However
comments are given for some to how they apply to RTSP. comments are given for some to how they apply to RTSP.
Within RTSP, redirection may be used for load balancing or Within RTSP, redirection may be used for load balancing or
redirecting stream requests to a server topologically closer to the redirecting stream requests to a server topologically closer to the
client. Mechanisms to determine topological proximity are beyond the client. Mechanisms to determine topological proximity are beyond the
scope of this specification. scope of this specification.
A 3rr code MAY be used to respond to any request. It is RECOMMENDED | A 3rr code MAY be used to respond to any request. It is RECOMMENDED
that they are used if necessary before a session is established, i.e. | that they are used if necessary before a session is established, i.e.
in response to DESCRIBE or SETUP. However in cases where a server is | in response to DESCRIBE or SETUP. However in cases where a server is
not able to send a REDIRECT request to the client, the server MAY | not able to send a REDIRECT request to the client, the server MAY
need to resort to using 3rr responses to inform a client with a | need to resort to using 3rr responses to inform a client with a
established session about the need for redirecting the session. If an | established session about the need for redirecting the session. If an
3rr response is received for an request in relation to a established | 3rr response is received for an request in relation to a established
session, the client SHOULD send a TEARDOWN request for the session, | session, the client SHOULD send a TEARDOWN request for the session,
and MAY reestablish the session using the resource indicated by the | and MAY reestablish the session using the resource indicated by the
Location. Location.
If the the Location header is used in a response it SHALL contain an If the the Location header is used in a response it SHALL contain an
absolute URL pointing out the media resource the client is redirected absolute URL pointing out the media resource the client is redirected
to, the URL SHALL NOT only contain the host name. to, the URL SHALL NOT only contain the host name.
13.3.1 300 Multiple Choices 13.3.1 300 Multiple Choices
13.3.2 301 Moved Permanently 13.3.2 301 Moved Permanently
skipping to change at page 60, line 33 skipping to change at page 67, line 14
The requested resource reside temporarily at the URL given by the The requested resource reside temporarily at the URL given by the
Location header. The Location header MUST be included in the Location header. The Location header MUST be included in the
response. Is intended to be used for many types of temporary response. Is intended to be used for many types of temporary
redirects, e.g. load balancing. It is RECOMMENDED that one set the redirects, e.g. load balancing. It is RECOMMENDED that one set the
reason phrase to something more meaningful than "Found" in these reason phrase to something more meaningful than "Found" in these
cases. The user client SHOULD redirect automatically to the given cases. The user client SHOULD redirect automatically to the given
URL. This response MUST NOT contain a message-body. URL. This response MUST NOT contain a message-body.
13.3.4 303 See Other 13.3.4 303 See Other
This status code SHALL NOT be used in RTSP. However as it was allowed | This status code SHALL NOT be used in RTSP. However as it was allowed
to use in RFC 2326 it is possible that such response may be received, | to use in RFC 2326 it is possible that such response may be received,
in which case the behavior is undefined. in which case the behavior is undefined.
13.3.5 304 Not Modified 13.3.5 304 Not Modified
If the client has performed a conditional DESCRIBE or SETUP (see If the client has performed a conditional DESCRIBE or SETUP (see
12.23) and the requested resource has not been modified, the server 12.23) and the requested resource has not been modified, the server
SHOULD send a 304 response. This response MUST NOT contain a SHOULD send a 304 response. This response MUST NOT contain a
message-body. message-body.
The response MUST include the following header fields: The response MUST include the following header fields:
skipping to change at page 63, line 12 skipping to change at page 69, line 40
The Transport field did not contain a supported transport The Transport field did not contain a supported transport
specification. specification.
13.4.14 462 Destination Unreachable 13.4.14 462 Destination Unreachable
The data transmission channel could not be established because the The data transmission channel could not be established because the
client address could not be reached. This error will most likely be client address could not be reached. This error will most likely be
the result of a client attempt to place an invalid Destination the result of a client attempt to place an invalid Destination
parameter in the Transport field. parameter in the Transport field.
13.4.15 470 Connection Authorization Required
The secured connection attempt need user or client authorization
before proceeding. The next hops certificate is included in this
response in the Accept-Credentials header.
13.4.16 471 Connection Credentials not accepted
When performing a secure connection over multiple connections, a
intermediary has refused to connect to the next hop and carry out the
request due to unacceptable credentials for the used policy.
13.5 Server Error 5xx 13.5 Server Error 5xx
13.5.1 551 Option not supported 13.5.1 551 Option not supported
An feature-tag given in the Require or the Proxy-Require fields was An feature-tag given in the Require or the Proxy-Require fields was
not supported. The Unsupported header SHOULD be returned stating the not supported. The Unsupported header SHOULD be returned stating the
feature for which there is no support. feature for which there is no support.
14 Header Field Definitions 14 Header Field Definitions
skipping to change at page 63, line 45 skipping to change at page 70, line 36
Table 8: Overview of RTSP methods, their direction, and what objects Table 8: Overview of RTSP methods, their direction, and what objects
(P: presentation, S: stream) they operate on. Body notes if a method (P: presentation, S: stream) they operate on. Body notes if a method
is allowed to carry body and in which direction, R = Request, is allowed to carry body and in which direction, R = Request,
r=response. Note: It is allowed for all error messages 4xx and 5xx to r=response. Note: It is allowed for all error messages 4xx and 5xx to
have a body have a body
The general syntax for header fields is covered in Section 4.2 This The general syntax for header fields is covered in Section 4.2 This
section lists the full set of header fields along with notes on section lists the full set of header fields along with notes on
meaning, and usage. The syntax definition for headers are present in meaning, and usage. The syntax definition for headers are present in
section 17.2.3. Throughout this section, we use [HX.Y] to refer to section 18.2.3. Throughout this section, we use [HX.Y] to refer to
Section X.Y of the current HTTP/1.1 specification RFC 2616 [4]. Section X.Y of the current HTTP/1.1 specification RFC 2616 [4].
Examples of each header field are given. Examples of each header field are given.
Information about header fields in relation to methods and proxy Information about header fields in relation to methods and proxy
processing is summarized in Table 9 and Table 10. processing is summarized in Tables 9, 10, 11, and 12.
The "where" column describes the request and response types in which The "where" column describes the request and response types in which
the header field can be used. Values in this column are: the header field can be used. Values in this column are:
R: header field may only appear in requests; R: header field may only appear in requests;
r: header field may only appear in responses; r: header field may only appear in responses;
2xx, 4xx, etc.: A numerical value or range indicates response 2xx, 4xx, etc.: A numerical value or range indicates response
codes with which the header field can be used; codes with which the header field can be used;
c: header field is copied from the request to the response. c: header field is copied from the request to the response.
An empty entry in the "where" column indicates that the header field An empty entry in the "where" column indicates that the header field
may be present in all requests and responses. may be present in all requests and responses.
The "proxy" column describes the operations a proxy may perform on a The "proxy" column describes the operations a proxy may perform on a
header field: header field:
skipping to change at page 64, line 47 skipping to change at page 71, line 39
context of the message. context of the message.
m: The header field is mandatory. m: The header field is mandatory.
m*: The header field SHOULD be sent, but clients/servers need to m*: The header field SHOULD be sent, but clients/servers need to
be prepared to receive messages without that header field. be prepared to receive messages without that header field.
o: The header field is optional. o: The header field is optional.
*: The header field is required if the message body is not *: The header field is required if the message body is not
empty. See sections 14.14, 14.16 and 4.3 for details. empty. See sections 14.15, 14.17 and 4.3 for details.
-: The header field is not applicable. -: The header field is not applicable.
"Optional" means that a Client/Server MAY include the header |
field in a request or response. The Client/Server behavior when | "Optional" means that a Client/Server MAY include the header field in
receiving such headers varies, for some it may ignore the header | a request or response. The Client/Server behavior when receiving such
field, in other case it is request to process the header. This | headers varies, for some it may ignore the header field, in other
is regulated by the method and header descriptions. Example of | case it is request to process the header. This is regulated by the
such headers that require processing are the Require and Proxy- | method and header descriptions. Example of such headers that require
Require header fields discussed in 14.32 and 14.27. A | processing are the Require and Proxy-Require header fields discussed
"mandatory" header field MUST be present in a request, and MUST | in 14.35 and 14.30. A "mandatory" header field MUST be present in a
be understood by the Client/Server receiving the request. A | request, and MUST be understood by the Client/Server receiving the
mandatory response header field MUST be present in the response, | request. A mandatory response header field MUST be present in the
and the header field MUST be understood by the Client/Server | response, and the header field MUST be understood by the
processing the response. "Not applicable" means that the header | Client/Server processing the response. "Not applicable" means that
field MUST NOT be present in a request. If one is placed in a | the header field MUST NOT be present in a request. If one is placed
request by mistake, it MUST be ignored by the Client/Server | in a request by mistake, it MUST be ignored by the Client/Server
receiving the request. Similarly, a header field labeled "not | receiving the request. Similarly, a header field labeled "not
applicable" for a response means that the Client/Server MUST NOT | applicable" for a response means that the Client/Server MUST NOT
place the header field in the response, and the Client/Server | place the header field in the response, and the Client/Server MUST
MUST ignore the header field in the response. ignore the header field in the response.
A Client/Server SHOULD ignore extension header parameters that are A Client/Server SHOULD ignore extension header parameters that are
not understood. not understood.
The From, Location, and RTP-Info header fields contain a URL. If the The From, Location, and RTP-Info header fields contain a URL. If the
URL contains a comma, or semicolon, the URL MUST be enclosed in URL contains a comma, or semicolon, the URL MUST be enclosed in
double quotas ("). Any URL parameters are contained within these double quotas ("). Any URL parameters are contained within these
quotas. If the URL is not enclosed in double quotas, any semicolon- quotas. If the URL is not enclosed in double quotas, any semicolon-
delimited parameters are header-parameters, not URL parameters. delimited parameters are header-parameters, not URL parameters.
skipping to change at page 65, line 41 skipping to change at page 72, line 34
The Accept request-header field can be used to specify certain The Accept request-header field can be used to specify certain
presentation description content types which are acceptable for the presentation description content types which are acceptable for the
response. response.
The "level" parameter for presentation descriptions is The "level" parameter for presentation descriptions is
properly defined as part of the MIME type registration, not properly defined as part of the MIME type registration, not
here. here.
See [H14.1] for syntax. See [H14.1] for syntax.
Example of use: |
Accept: application/rtsl q=1.0, application/sdp |
14.2 Accept-Encoding
See [H14.3]
14.3 Accept-Language
See [H14.4]. Note that the language specified applies to the
presentation description and any reason phrases, not the media
content.
14.4 Accept-Ranges
The Accept-Ranges response-header field allows the server to indicate
its acceptance of range requests and possible formats for a resource:
Accept-Ranges: NPT, SMPTE
This header has the same syntax as [H14.5] and the syntax is defined
in 17.2.3. However new range-units are defined. Inclusion of any of
the time formats indicates acceptance by the server for PLAY and
PAUSE requests with this format. The headers value is valid for the
resource specified by the URL in the request, this response
corresponds to. A server SHOULD use this header in SETUP responses to
indicate to the client which range time formats the media supports.
The header SHOULD also be included in "456" responses which is a
result of use of unsupported range formats.
14.5 Allow
The Allow entity-header field lists the methods supported by the
resource identified by the request-URL. The purpose of this field is
to strictly inform the recipient of valid methods associated with the
resource. An Allow header field MUST be present in a 405 (Method Not
Allowed) response. See [H14.7] for syntax definition.
Example of use: Example of use:
Allow: SETUP, PLAY, SET_PARAMETER Accept: application/rtsl q=1.0, application/sdp
14.6 Authorization
See [H14.8] 14.2 Accept-Credentials
14.7 Bandwidth The Accept-Credentials header has different usage in RTSP requests |
and responses. In a request it is used to indicate to any trusted |
intermediary how to handle further secured connections to proxies or |
servers. In responses the header is used to carry the credentials of |
Header Where Proxy DES OPT SETUP PLAY PAUSE TRD Header Where Proxy DES OPT SETUP PLAY PAUSE TRD
_____________________________________________________________ _____________________________________________________________
Accept R o - - - - - Accept R o - - - - -
Accept-Credentials R r o o o o o o
Accept-Credentials 470,407 ar o o o o o o
Accept-Encoding R r o - - - - - Accept-Encoding R r o - - - - -
Accept-Language R r o - - - - - Accept-Language R r o - - - - -
Accept-Ranges r r - - o - - - Accept-Ranges r r - - o - - -
Accept-Ranges 456 r - - - o o - Accept-Ranges 456 r - - - o o -
Allow r - o - - - - Allow r - o - - - -
Allow 405 m m m m m m Allow 405 m m m m m m
Authorization R o o o o o o Authorization R o o o o o o
Bandwidth R o o o o - - Bandwidth R o o o o - -
Blocksize R o - o o - - Blocksize R o - o o - -
Cache-Control r - - o - - - Cache-Control r - - o - - -
skipping to change at page 67, line 34 skipping to change at page 73, line 36
Content-Language r r o - - - - - Content-Language r r o - - - - -
Content-Language 4xx r o o o o o o Content-Language 4xx r o o o o o o
Content-Length r r * - - - - - Content-Length r r * - - - - -
Content-Length 4xx r * * * * * * Content-Length 4xx r * * * * * *
Content-Location r o - - - - - Content-Location r o - - - - -
Content-Location 4xx o o o o o o Content-Location 4xx o o o o o o
Content-Type r * - - - - - Content-Type r * - - - - -
Content-Type 4xx * * * * * * Content-Type 4xx * * * * * *
CSeq Rc m m m m m m CSeq Rc m m m m m m
Date am o o o o o o Date am o o o o o o
ETag r r o - o - - -
Expires r r o - - - - - Expires r r o - - - - -
From R r o o o o o o From R r o o o o o o
Host - - - - - - Host - - - - - -
If-Match R r - - o - - - If-Match R r - - o - - -
If-Modified-Since R r o - o - - - If-Modified-Since R r o - o - - -
If-None-Match R r o - - - - -
Last-Modified r r o - - - - - Last-Modified r r o - - - - -
Location 3rr o o o o o o Location 3rr o o o o o o
Table 9: Overview of RTSP header fields (A-L) related to methods
DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.
Header Where Proxy DES OPT SETUP PLAY PAUSE TRD
_____________________________________________________________
Proxy-Authenticate 407 amr m m m m m m Proxy-Authenticate 407 amr m m m m m m
Proxy-Require R ar o o o o o o Proxy-Require R ar o o o o o o
Public r admr - m* - - - - Public r admr - m* - - - -
Public 501 admr m* m* m* m* m* m* Public 501 admr m* m* m* m* m* m*
Range R - - - o o - Range R - - - o o -
Range r - - c m* m* - Range r - - c m* m* -
Referer R o o o o o o Referer R o o o o o o
Require R o o o o o o Require R o o o o o o
Retry-After 3rr,503 o o o - - - Retry-After 3rr,503 o o o - - -
Header Where Proxy DES OPT SETUP PLAY PAUSE TRD RTP-Info r - - o c - -
_________________________________________________________
Scale - - - o - - Scale - - - o - -
Session R - o o m m m Session R - o o m m m
Session r - c m m m o Session r - c m m m o
Server R - o - - - - Server R - o - - - -
Server r o o o o o o Server r o o o o o o
Speed - - - o - - Speed - - - o - -
Supported R o o o o o o Supported R o o o o o o
Supported r c c c c c c Supported r c c c c c c
Timestamp R o o o o o o Timestamp R o o o o o o
Timestamp c m m m m m m Timestamp c m m m m m m
Transport - - m - - - Transport - - m - - -
Unsupported r c c c c c c Unsupported r c c c c c c
User-Agent R m* m* m* m* m* m* User-Agent R m* m* m* m* m* m*
Vary r c c c c c c Vary r c c c c c c
Via R amr o o o o o o Via R amr o o o o o o
Via c dr m m m m m m Via c dr m m m m m m
WWW-Authenticate 401 m m m m m m WWW-Authenticate 401 m m m m m m
_________________________________________________________ _____________________________________________________________
Header Where Proxy DES OPT SETUP PLAY PAUSE TRD Header Where Proxy DES OPT SETUP PLAY PAUSE TRD
Table 9: Overview of RTSP header fields related to methods DESCRIBE, Table 10: Overview of RTSP header fields (P-W) related to methods
OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.
The Bandwidth request-header field describes the estimated bandwidth
available to the client, expressed as a positive integer and measured
in bits per second. The bandwidth available to the client may change
during an RTSP session, e.g., due to modem retraining.
Example:
Bandwidth: 4000
14.8 Blocksize any next hop that need to be approved by the requestor. See section |
17 for the usage of this header. It SHALL only be included in client |
to server requests, and server to client responses. |
The Blocksize request-header field is sent from the client to the In a request the header SHALL contain the method (User, Proxy, or |
media server asking the server for a particular media packet size. Any) for approving credentials selected by the requestor. The method |
This packet size does not include lower-layer headers such as IP, SHALL NOT be changed by any proxy. If the method is "User" the header |
UDP, or RTP. The server is free to use a blocksize which is lower contains zero or more of credentials that the client accept. Each |
than the one requested. The server MAY truncate this packet size to credential SHALL consist of one URI identifying the proxy or server, |
the closest multiple of the minimum, media-specific block size, or
override it with the media-specific size if necessary. The block size
MUST be a positive decimal number, measured in octets. The server
Header Where Proxy GPR SPR RDR PNG Header Where Proxy GPR SPR RDR PNG
__________________________________________________ __________________________________________________
Accept-Credentials R r o o o o
Accept-Credentials 470,407 ar o o o o
Allow 405 m m m m Allow 405 m m m m
Authorization R o o o o Authorization R o o o o
Bandwidth R - o - - Bandwidth R - o - -
Blocksize R - o - - Blocksize R - o - -
Connection o o o - Connection o o o -
Content-Base R o o - - Content-Base R o o - -
Content-Base r o o - - Content-Base r o o - -
Content-Base 4xx o o o - Content-Base 4xx o o o -
Content-Encoding R r o o - - Content-Encoding R r o o - -
Content-Encoding r r o o - - Content-Encoding r r o o - -
skipping to change at page 69, line 40 skipping to change at page 75, line 42
Date am o o o o Date am o o o o
From R r o o o o From R r o o o o
Host - - - - Host - - - -
Last-Modified R r - - - - Last-Modified R r - - - -
Last-Modified r r o - - - Last-Modified r r o - - -
Location 3rr o o o o Location 3rr o o o o
Location R - - m - Location R - - m -
Proxy-Authenticate 407 amr m m m m Proxy-Authenticate 407 amr m m m m
Proxy-Require R ar o o o o Proxy-Require R ar o o o o
Public 501 admr m* m* m* m* Public 501 admr m* m* m* m*
__________________________________________________
Header Where Proxy GPR SPR RDR PNG
Table 11: Overview of RTSP header fields (A-P) related to methods
GET_PARAMETER, SET_PARAMETER, REDIRECT, and PING.
Header Where Proxy GPR SPR RDR PNG
________________________________________________
Range R - - o - Range R - - o -
Referer R o o o - Referer R o o o -
Require R o o o o Require R o o o o
Retry-After 3rr,503 o o - - Retry-After 3rr,503 o o - -
Scale - - - - Scale - - - -
Session R o o o m Session R o o o m
Session r c c o m Session r c c o m
Server R o o o o Server R o o o o
Server r o o - o Server r o o - o
Supported R o o o o Supported R o o o o
Supported r c c c c
Timestamp R o o o o
Timestamp c m m m m Timestamp c m m m m
Unsupported r c c c c Unsupported r c c c c
User-Agent R m* m* - m* User-Agent R m* m* - m*
User-Agent r - - m* - User-Agent r - - m* -
Vary r c c - - Vary r c c - -
Via R amr o o o o Via R amr o o o o
Via c dr m m m m Via c dr m m m m
WWW-Authenticate 401 m m m m WWW-Authenticate 401 m m m m
__________________________________________________
________________________________________________
Header Where Proxy GPR SPR RDR PNG Header Where Proxy GPR SPR RDR PNG
Table 10: Overview of RTSP header fields related to methods Table 12: Overview of RTSP header fields (R-W) related to methods
GET_PARAMETER, SET_PARAMETER, REDIRECT, and PING. GET_PARAMETER, SET_PARAMETER, REDIRECT, and PING.
and the SHA-1 [16] hash computed over that entity's DER encoded |
certificate [17] in Base64 [38]. |
The Accept-Credentials header in a RTSP response SHALL, if included, |
contain the credentials information of the next hop that an |
intermediary needs to securely connect to. The credential MUST |
include the URI of the next proxy or server and the DER encoded |
X.509v3 [17] certificate in base64 [38]. |
Request Example: |
Accept-Credentials:User, |
"rtsps://proxy2.example.com/";exaIl9VMbQMOFGClx5rXnPJKVNI=, |
"rtsps://server.example.com/";lurbjj5khhB0NhIuOXtt4bBRH1M= |
Response Example: |
Accept-Credentials:"rtsps://proxy2.example.com/";XmW+39x4XdTLp... |
14.3 Accept-Encoding
See [H14.3]
14.4 Accept-Language
See [H14.4]. Note that the language specified applies to the
presentation description and any reason phrases, not the media
content.
14.5 Accept-Ranges
The Accept-Ranges response-header field allows the server to indicate
its acceptance of range requests and possible formats for a resource:
Accept-Ranges: NPT, SMPTE
This header has the same syntax as [H14.5] and the syntax is defined
in 18.2.3. However new range-units are defined. Inclusion of any of
the time formats indicates acceptance by the server for PLAY and
PAUSE requests with this format. The headers value is valid for the
resource specified by the URL in the request, this response
corresponds to. A server SHOULD use this header in SETUP responses to
indicate to the client which range time formats the media supports.
The header SHOULD also be included in "456" responses which is a
result of use of unsupported range formats.
14.6 Allow
The Allow entity-header field lists the methods supported by the
resource identified by the request-URL. The purpose of this field is
to strictly inform the recipient of valid methods associated with the
resource. An Allow header field MUST be present in a 405 (Method Not
Allowed) response. See [H14.7] for syntax definition.
Example of use:
Allow: SETUP, PLAY, SET_PARAMETER
14.7 Authorization
See [H14.8]
14.8 Bandwidth
The Bandwidth request-header field describes the estimated bandwidth
available to the client, expressed as a positive integer and measured
in bits per second. The bandwidth available to the client may change
during an RTSP session, e.g., due to modem retraining.
Example:
Bandwidth: 4000
14.9 Blocksize
The Blocksize request-header field is sent from the client to the
media server asking the server for a particular media packet size.
This packet size does not include lower-layer headers such as IP,
UDP, or RTP. The server is free to use a blocksize which is lower
than the one requested. The server MAY truncate this packet size to
the closest multiple of the minimum, media-specific block size, or
override it with the media-specific size if necessary. The block size
MUST be a positive decimal number, measured in octets. The server
only returns an error (4xx) if the value is syntactically invalid. only returns an error (4xx) if the value is syntactically invalid.
14.9 Cache-Control 14.10 Cache-Control
The Cache-Control general-header field is used to specify directives The Cache-Control general-header field is used to specify directives
that MUST be obeyed by all caching mechanisms along the that MUST be obeyed by all caching mechanisms along the
request/response chain. request/response chain.
Cache directives must be passed through by a proxy or gateway Cache directives must be passed through by a proxy or gateway
application, regardless of their significance to that application, application, regardless of their significance to that application,
since the directives may be applicable to all recipients along the since the directives may be applicable to all recipients along the
request/response chain. It is not possible to specify a cache- request/response chain. It is not possible to specify a cache-
directive for a specific cache. directive for a specific cache.
Cache-Control should only be specified in a SETUP request and its | Cache-Control should only be specified in a SETUP request and its
response. Note: Cache-Control does not govern the caching of | response. Note: Cache-Control does not govern the caching of
responses as for HTTP, instead it applies to the media stream | responses as for HTTP, instead it applies to the media stream
identified by the SETUP request. The caching of RTSP requests are | identified by the SETUP request. The caching of RTSP requests are
generally not cacheable, for further information see 15. Below is the | generally not cacheable, for further information see 15. Below is the
description of the cache directives that can be included in the | description of the cache directives that can be included in the
Cache-Control header. Cache-Control header.
no-cache: Indicates that the media stream MUST NOT be cached no-cache: Indicates that the media stream MUST NOT be cached
anywhere. This allows an origin server to prevent caching anywhere. This allows an origin server to prevent caching
even by caches that have been configured to return stale even by caches that have been configured to return stale
responses to client requests. responses to client requests.
public: Indicates that the media stream is cacheable by any public: Indicates that the media stream is cacheable by any
cache. cache.
skipping to change at page 72, line 45 skipping to change at page 81, line 5
its now validated copy to the client with a 200 (OK) its now validated copy to the client with a 200 (OK)
response. If the server replies with a new entity and cache response. If the server replies with a new entity and cache
validator, however, the intermediate cache can compare the validator, however, the intermediate cache can compare the
returned validator with the one provided in the client's returned validator with the one provided in the client's
request, using the strong comparison function. If the request, using the strong comparison function. If the
client's validator is equal to the origin server's, then client's validator is equal to the origin server's, then
the intermediate cache simply returns 304 (Not Modified). the intermediate cache simply returns 304 (Not Modified).
Otherwise, it returns the new entity with a 200 (OK) Otherwise, it returns the new entity with a 200 (OK)
response. response.
14.10 Connection 14.11 Connection
See [H14.10]. The use of the connection option "close" in RTSP See [H14.10]. The use of the connection option "close" in RTSP
messages SHOULD be limited to error messages when the server is messages SHOULD be limited to error messages when the server is
unable to recover and therefore see it necessary to close the unable to recover and therefore see it necessary to close the
connection. The reason is that the client shall have the choice of connection. The reason is that the client shall have the choice of
continue using a connection indefinitely as long as it sends valid continue using a connection indefinitely as long as it sends valid
messages. messages.
14.11 Content-Base 14.12 Content-Base
The Content-Base entity-header field may be used to specify the base The Content-Base entity-header field may be used to specify the base
URL for resolving relative URLs within the entity. URL for resolving relative URLs within the entity.
Content-Base: rtsp://media.example.com/movie/twister Content-Base: rtsp://media.example.com/movie/twister
If no Content-Base field is present, the base URL of an entity is If no Content-Base field is present, the base URL of an entity is
defined either by its Content-Location (if that Content-Location URL defined either by its Content-Location (if that Content-Location URL
is an absolute URL) or the URL used to initiate the request, in that is an absolute URL) or the URL used to initiate the request, in that
order of precedence. Note, however, that the base URL of the contents order of precedence. Note, however, that the base URL of the contents
within the entity-body may be redefined within that entity-body. within the entity-body may be redefined within that entity-body.
14.12 Content-Encoding 14.13 Content-Encoding
See [H14.11] See [H14.11]
14.13 Content-Language 14.14 Content-Language
See [H14.12] See [H14.12]
14.14 Content-Length 14.15 Content-Length
The Content-Length general-header field contains the length of the The Content-Length general-header field contains the length of the
content of the method (i.e. after the double CRLF following the last content of the method (i.e. after the double CRLF following the last
header). Unlike HTTP, it MUST be included in all messages that carry header). Unlike HTTP, it MUST be included in all messages that carry
content beyond the header portion of the message. If it is missing, a content beyond the header portion of the message. If it is missing, a
default value of zero is assumed. It is interpreted according to default value of zero is assumed. It is interpreted according to
[H14.13]. [H14.13].
14.15 Content-Location 14.16 Content-Location
See [H14.14] See [H14.14]
14.16 Content-Type 14.17 Content-Type
See [H14.17]. Note that the content types suitable for RTSP are See [H14.17]. Note that the content types suitable for RTSP are
likely to be restricted in practice to presentation descriptions and likely to be restricted in practice to presentation descriptions and
parameter-value types. parameter-value types.
14.17 CSeq 14.18 CSeq
The CSeq general-header field specifies the sequence number for an | The CSeq general-header field specifies the sequence number for an
RTSP request-response pair. This field MUST be present in all | RTSP request-response pair. This field MUST be present in all
requests and responses. For every RTSP request containing the given | requests and responses. For every RTSP request containing the given
sequence number, the corresponding response will have the same | sequence number, the corresponding response will have the same
number. Any retransmitted request must contain the same sequence | number. Any retransmitted request must contain the same sequence
number as the original (i.e. the sequence number is not incremented | number as the original (i.e. the sequence number is not incremented
for retransmissions of the same request). For each new RTSP request | for retransmissions of the same request). For each new RTSP request
the CSeq value SHALL be incremented by one. The initial sequence | the CSeq value SHALL be incremented by one. The initial sequence
number MAY be any number, however it is RECOMMENDED to start at 1. | number MAY be any number, however it is RECOMMENDED to start at 1.
Each sequence number series is unique between each requester and | Each sequence number series is unique between each requester and
responder, i.e. the client has one series for its request to a server | responder, i.e. the client has one series for its request to a server
and the server has another when sending request to the client. Each | and the server has another when sending request to the client. Each
requester and responder is identified with its network address. requester and responder is identified with its network address.
Example: Example:
CSeq: 239 CSeq: 239
14.18 Date 14.19 Date
See [H14.18]. An RTSP message containing a body MUST include a Date See [H14.18]. An RTSP message containing a body MUST include a Date
header if the sending host has a clock. Servers SHOULD include a Date header if the sending host has a clock. Servers SHOULD include a Date
header in all other RTSP messages. header in all other RTSP messages.
14.19 Expires 14.20 ETag |
The ETag response header MAY be included in DESCRIBE or SETUP |
responses. The entity tag returned in a DESCRIBE response is for the |
included entity, while for SETUP it refers to the media resource just |
set up. This differentiation allows for cache validation of both |
session description and the media resource associated with the |
description. If the ETag is provided both inside the entity, e.g. |
within the "a=etag" attribute in SDP, and in the response message, |
then both tags SHALL be identical. It is RECOMMENDED that the ETag is |
primarily given in the RTSP response message, to ensure that caches |
can use the ETag without requiring content inspection. |
SETUP and DESCRIBE requests can be made conditional upon the ETag |
using the headers If-Match (Section 14.24) and If-None-Match (Section |
14.26). |
14.21 Expires
The Expires entity-header field gives a date and time after which the The Expires entity-header field gives a date and time after which the
description or media-stream should be considered stale. The description or media-stream should be considered stale. The
interpretation depends on the method: interpretation depends on the method:
DESCRIBE response: The Expires header indicates a date and time DESCRIBE response: The Expires header indicates a date and time
after which the description SHOULD be considered stale. after which the description SHOULD be considered stale.
SETUP response: The Expires header indicate a date and time SETUP response: The Expires header indicate a date and time
after which the media stream SHOULD be considered stale. after which the media stream SHOULD be considered stale.
skipping to change at page 75, line 23 skipping to change at page 83, line 48
To mark a response as "already expired," an origin server should use To mark a response as "already expired," an origin server should use
an Expires date that is equal to the Date header value. To mark a an Expires date that is equal to the Date header value. To mark a
response as "never expires," an origin server SHOULD use an Expires response as "never expires," an origin server SHOULD use an Expires
date approximately one year from the time the response is sent. date approximately one year from the time the response is sent.
RTSP/1.0 servers SHOULD NOT send Expires dates more than one year in RTSP/1.0 servers SHOULD NOT send Expires dates more than one year in
the future. the future.
The presence of an Expires header field with a date value of some The presence of an Expires header field with a date value of some
time in the future on a media stream that otherwise would by default time in the future on a media stream that otherwise would by default
be non-cacheable indicates that the media stream is cacheable, unless be non-cacheable indicates that the media stream is cacheable, unless
indicated otherwise by a Cache-Control header field (Section 14.9). indicated otherwise by a Cache-Control header field (Section 14.10).
14.20 From
14.22 From
See [H14.22]. See [H14.22].
14.21 Host 14.23 Host
The Host HTTP request header field [H14.23] is not needed for RTSP, The Host HTTP request header field [H14.23] is not needed for RTSP,
and SHALL NOT be sent. It SHALL be silently ignored if received. and SHALL NOT be sent. It SHALL be silently ignored if received.
14.22 If-Match 14.24 If-Match
See [H14.24].
The If-Match request-header field is especially useful for ensuring See [H14.24]. The If-Match request-header field is especially useful |
the integrity of the presentation description, in both the case where for ensuring the integrity of the presentation description, in both |
it is fetched via means external to RTSP (such as HTTP), or in the the case where it is fetched via means external to RTSP (such as |
case where the server implementation is guaranteeing the integrity of HTTP), or in the case where the server implementation is guaranteeing |
the description between the time of the DESCRIBE message and the the integrity of the description between the time of the DESCRIBE |
SETUP message. message and the SETUP message. By including the ETag given in or with |
the session description in a SETUP request, the client ensures that |
resources set up are matching the description. A SETUP request for |
which the ETag validation check fails, SHALL responde using 412 |
(Precondition Failed). |
The identifier is an opaque identifier, and thus is not specific to This validation check is also very useful if a session has been |
any particular session description language. redirected from one server to another. |
14.23 If-Modified-Since 14.25 If-Modified-Since
The If-Modified-Since request-header field is used with the DESCRIBE The If-Modified-Since request-header field is used with the DESCRIBE
and SETUP methods to make them conditional. If the requested variant and SETUP methods to make them conditional. If the requested variant
has not been modified since the time specified in this field, a has not been modified since the time specified in this field, a
description will not be returned from the server (DESCRIBE) or a description will not be returned from the server (DESCRIBE) or a
stream will not be set up (SETUP). Instead, a 304 (Not Modified) stream will not be set up (SETUP). Instead, a 304 (Not Modified)
response SHALL be returned without any message-body. response SHALL be returned without any message-body.
An example of the field is: An example of the field is:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
14.24 Last-Modified 14.26 If-None-Match
See [H14.26].
This request header can be used with entity tags to make DESCRIBE
requests conditional. A new session description is retrieved only if
another entity than the already available would be included. If the
entity available for delivery is matching the one the client already
has, then a 304 (Not Modified) response is given.
14.27 Last-Modified
The Last-Modified entity-header field indicates the date and time at The Last-Modified entity-header field indicates the date and time at
which the origin server believes the presentation description or which the origin server believes the presentation description or
media stream was last modified. See [H14.29]. For the methods media stream was last modified. See [H14.29]. For the methods
DESCRIBE, the header field indicates the last modification date and DESCRIBE, the header field indicates the last modification date and
time of the description, for SETUP that of the media stream. time of the description, for SETUP that of the media stream.
14.25 Location 14.28 Location
See [H14.30]. See [H14.30].
14.26 Proxy-Authenticate 14.29 Proxy-Authenticate
See [H14.33]. See [H14.33].
14.27 Proxy-Require 14.30 Proxy-Require
The Proxy-Require request-header field is used to indicate proxy- The Proxy-Require request-header field is used to indicate proxy-
sensitive features that MUST be supported by the proxy. Any Proxy- sensitive features that MUST be supported by the proxy. Any Proxy-
Require header features that are not supported by the proxy MUST be Require header features that are not supported by the proxy MUST be
negatively acknowledged by the proxy to the client using the negatively acknowledged by the proxy to the client using the
Unsupported header. The proxy SHALL use the 551 (Option Not Unsupported header. The proxy SHALL use the 551 (Option Not
Supported) status code in the response. Any feature tag included in Supported) status code in the response. Any feature tag included in
the Proxy-Require does not apply to the server. To ensure that a the Proxy-Require does not apply to the server. To ensure that a
feature is supported by both proxies and servers the tag must be feature is supported by both proxies and servers the tag must be
included in also a Require header. included in also a Require header.
See Section 14.32 for more details on the mechanics of this message See Section 14.35 for more details on the mechanics of this message
and a usage example. and a usage example.
Example of use: Example of use:
Proxy-Require: play.basic Proxy-Require: play.basic
14.28 Public 14.31 Public
The Public response-header field lists the set of methods supported The Public response header field lists the set of methods supported |
by the server. The purpose of this field is strictly to inform the by the response sender. This header applies to the general |
recipient of the capabilities of the server regarding unusual capabilities of the sender and its only purpose is to indicate the |
methods. The methods listed may or may not be applicable to the sender's capabilities to the recipient. The methods listed may or may
Request-URL; the Allow header field (section 14.7) MAY be used to not be applicable to the Request-URL; the Allow header field (section
indicate methods allowed for a particular URL. 14.7) MAY be used to indicate methods allowed for a particular URL.
Example of use: Example of use:
Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
This header field applies only to the server directly connected to In the event that there are proxies between the sender and the |
the client (i.e., the nearest neighbor in a chain of connections). recipient of a response, each intervening proxy MUST modify the |
If the response passes through a proxy, the proxy MUST either remove Public header field to remove any methods that are not supported via |
the Public header field or replace it with one applicable to its own that proxy. The resulting Public header field will contain an |
capabilities. intersection of the sender's methods and the methods allowed through |
by the intervening proxies. |
14.29 Range In general proxies should allow all methods to |
transparently pass through from the sending RTSP agent to |
the receiving RTSP agent, but there may be cases where this |
is not desirable for a given proxy. Modification of the |
Public response header field by the intervening proxies |
ensures that the request sender gets an accurate response |
indicating the methods that can be used on the target agent |
via the proxy chain.
The Range request and response header field specifies a range of | 14.32 Range
time. The header is used in PLAY request to indicate the range of |
time the client desires the server to play back. The Range header in |
a PLAY indicates what range of time that is actually being played. In |
a SETUP response the header MAY be used, to ensure correct |
synchronization information after changes of transport parameters. |
The range can be specified in a number of units. This specification | The Range request and response header field specifies a range of
defines the smpte (Section 3.4), npt (Section 3.5), and clock | time. The header is used in PLAY request to indicate the range of
(Section 3.6) range units. Within RTSP, byte ranges [H14.35.1] are | time the client desires the server to play back. The Range header in
normally not meaningful, and the behavior is unspecified, but they | a PLAY indicates what range of time that is actually being played. In
and other extended units MAY be used. Servers supporting the Range | a SETUP response the header MAY be used, to ensure correct
header MUST understand the NPT range format and SHOULD understand the | synchronization information after changes of transport parameters.
SMPTE range format. If the Range header is given in a time format |
that is not understood, the recipient should return 456 (Header Field | The range can be specified in a number of units. This specification
Not Valid for Resource) and include a Accept-Ranges header indicating | defines the smpte (Section 3.4), npt (Section 3.5), and clock
(Section 3.6) range units. Within RTSP, byte ranges [H14.35.1] are
normally not meaningful, and the behavior is unspecified, but they
and other extended units MAY be used. Servers supporting the Range
header MUST understand the NPT range format and SHOULD understand the
SMPTE range format. If the Range header is given in a time format
that is not understood, the recipient should return 456 (Header Field
Not Valid for Resource) and include a Accept-Ranges header indicating
which time format that is supported for this resource. which time format that is supported for this resource.
The header MAY contain a time parameter in UTC, specifying the time The header MAY contain a time parameter in UTC, specifying the time
at which the operation is to be made effective. This functionality at which the operation is to be made effective. This functionality
SHALL only be used with the REDIRECT method. SHALL only be used with the REDIRECT method.
Ranges are half-open intervals, including the first point, but Ranges are half-open intervals, including the first point, but
excluding the second point. In other words, a range of A-B starts excluding the second point. In other words, a range of A-B starts
exactly at time A, but stops just before B. Only the start time of a exactly at time A, but stops just before B. Only the start time of a
media unit such as a video or audio frame is relevant. As an example, media unit such as a video or audio frame is relevant. As an example,
skipping to change at page 78, line 31 skipping to change at page 87, line 30
resources for extended idle periods. resources for extended idle periods.
By default, range intervals increase, where the second point is By default, range intervals increase, where the second point is
larger than the first point. larger than the first point.
Example: Example:
Range: npt=10-15 Range: npt=10-15
However, range intervals can also decrease if the Scale header (see However, range intervals can also decrease if the Scale header (see
section 14.34) indicates a negative scale value. For example, this section 14.37) indicates a negative scale value. For example, this
would be the case when a playback in reverse is desired. would be the case when a playback in reverse is desired.
Example: Example:
Scale: -1 Scale: -1
Range: npt=15-10 Range: npt=15-10
Decreasing ranges are still half open intervals as described above. Decreasing ranges are still half open intervals as described above.
Thus, For range A-B, A is closed and B is open. In the above example, Thus, For range A-B, A is closed and B is open. In the above example,
15 is closed and 10 is open. An exception to this rule is the case 15 is closed and 10 is open. An exception to this rule is the case
skipping to change at page 79, line 15 skipping to change at page 88, line 13
Example: Example:
Scale: -1 Scale: -1
Range: npt=15-0 Range: npt=15-0
In this range both 15 and 0 are closed. In this range both 15 and 0 are closed.
A decreasing range interval without a corresponding negative Scale A decreasing range interval without a corresponding negative Scale
header is not valid. header is not valid.
14.30 Referer 14.33 Referer
See [H14.36]. The URL refers to that of the presentation description, See [H14.36]. The URL refers to that of the presentation description,
typically retrieved via HTTP. typically retrieved via HTTP.
14.31 Retry-After 14.34 Retry-After
See [H14.37]. See [H14.37].
14.32 Require 14.35 Require
The Require request-header field is used by clients or servers to The Require request-header field is used by clients or servers to
ensure that the other end-point supports features that are required ensure that the other end-point supports features that are required
in respect to this request. It can also be used to query if the other in respect to this request. It can also be used to query if the other
end-point supports certain features, however the use of the Supported end-point supports certain features, however the use of the Supported
(Section 14.38) is much more effective in this purpose. The server (Section 14.41) is much more effective in this purpose. The server
MUST respond to this header by using the Unsupported header to MUST respond to this header by using the Unsupported header to
negatively acknowledge those feature-tags which are NOT supported. negatively acknowledge those feature-tags which are NOT supported.
The response SHALL use the error code 551 (Option Not Supported). The response SHALL use the error code 551 (Option Not Supported).
This header does not apply to proxies, for the same functionality in This header does not apply to proxies, for the same functionality in
respect to proxies see, header Proxy-Require (Section 14.27). respect to proxies see, header Proxy-Require (Section 14.30).
This is to make sure that the client-server interaction This is to make sure that the client-server interaction
will proceed without delay when all features are understood will proceed without delay when all features are understood
by both sides, and only slow down if features are not by both sides, and only slow down if features are not
understood (as in the example below). For a well-matched understood (as in the example below). For a well-matched
client-server pair, the interaction proceeds quickly, client-server pair, the interaction proceeds quickly,
saving a round-trip often required by negotiation saving a round-trip often required by negotiation
mechanisms. In addition, it also removes state ambiguity mechanisms. In addition, it also removes state ambiguity
when the client requires features that the server does not when the client requires features that the server does not
understand. understand.
skipping to change at page 80, line 22 skipping to change at page 89, line 20
In this example, "funky-feature" is the feature-tag which indicates In this example, "funky-feature" is the feature-tag which indicates
to the client that the fictional Funky-Parameter field is required. to the client that the fictional Funky-Parameter field is required.
The relationship between "funky-feature" and Funky-Parameter is not The relationship between "funky-feature" and Funky-Parameter is not
communicated via the RTSP exchange, since that relationship is an communicated via the RTSP exchange, since that relationship is an
immutable property of "funky-feature" and thus should not be immutable property of "funky-feature" and thus should not be
transmitted with every exchange. transmitted with every exchange.
Proxies and other intermediary devices SHOULD ignore features that Proxies and other intermediary devices SHOULD ignore features that
are not understood in this field. If a particular extension requires are not understood in this field. If a particular extension requires
that intermediate devices support it, the extension should be tagged that intermediate devices support it, the extension should be tagged
in the Proxy-Require field instead (see Section 14.27). in the Proxy-Require field instead (see Section 14.30).
14.33 RTP-Info 14.36 RTP-Info
The RTP-Info response-header field is used to set RTP-specific | The RTP-Info response-header field is used to set RTP-specific |
parameters in the PLAY response. These parameters correspond to the | parameters in the PLAY response. These parameters correspond to the |
synchronization source identified by the ssrc parameter of the | synchronization source identified by the first value of the ssrc |
Transport response header in the SETUP reponse. For streams using RTP | parameter of the Transport response header in the SETUP response. For |
as transport protocol the RTP-Info header SHOULD be part of a 200 | streams using RTP as transport protocol the RTP-Info header SHOULD be |
response to PLAY. | part of a 200 response to PLAY.
The exclusion of the RTP-Info in a PLAY response for RTP | The exclusion of the RTP-Info in a PLAY response for RTP
transported media will result in that a client needs to | transported media will result in that a client needs to
synchronize the media streams using RTCP. This may have | synchronize the media streams using RTCP. This may have
negative impact as the RTCP can be lost, and does not need | negative impact as the RTCP can be lost, and does not need
to be particulary timely in their arrival. Also | to be particulary timely in their arrival. Also
functionality as informing the client from which packet a | functionality as informing the client from which packet a
seek has occurred is affected. | seek has occurred is affected.
The RTP-Info MAY also be included in SETUP responses to provide | The RTP-Info MAY also be included in SETUP responses to provide
synchronization information when changing transport parameters, see | synchronization information when changing transport parameters, see
11.3. | 11.3.
The header can carry the following parameters: The header can carry the following parameters:
url: Indicates the stream URL which for which the following RTP url: Indicates the stream URL which for which the following RTP
parameters correspond, this URL MUST be the same used in parameters correspond, this URL MUST be the same used in
the SETUP request for this media stream. Any relative URL the SETUP request for this media stream. Any relative URL
SHALL use the request URL as base URL. SHALL use the request URL as base URL.
seq: Indicates the sequence number of the first packet of the seq: Indicates the sequence number of the first packet of the |
stream. This allows clients to gracefully deal with packets stream that is direct result of the request. This allows |
when seeking. The client uses this value to differentiate clients to gracefully deal with packets when seeking. The |
packets that originated before the seek from packets that client uses this value to differentiate packets that |
originated after the seek. originated before the seek from packets that originated |
after the seek. Note that a client may not receive the |
packet with the expressed sequence number, and instead |
packets with a higher sequence number, due to packet loss |
or reordering.
rtptime: Indicates the RTP timestamp corresponding to the time rtptime: Indicates the RTP timestamp corresponding to the time
value in the Range response header. (Note: For aggregate value in the Range response header. (Note: For aggregate
control, a particular stream may not actually generate a control, a particular stream may not actually generate a
packet for the Range time value returned or implied. Thus, packet for the Range time value returned or implied. Thus,
there is no guarantee that the packet with the sequence there is no guarantee that the packet with the sequence
number indicated by seq actually has the timestamp number indicated by seq actually has the timestamp
indicated by rtptime.) The client uses this value to indicated by rtptime.) The client uses this value to
calculate the mapping of RTP time to NPT. calculate the mapping of RTP time to NPT.
skipping to change at page 81, line 38 skipping to change at page 90, line 40
necessary time (immediately at startup or after a necessary time (immediately at startup or after a
seek), and that it is delivered reliably, this mapping seek), and that it is delivered reliably, this mapping
is placed in the RTSP control channel. is placed in the RTSP control channel.
In order to compensate for drift for long, uninterrupted In order to compensate for drift for long, uninterrupted
presentations, RTSP clients should additionally map NPT to presentations, RTSP clients should additionally map NPT to
NTP, using initial RTCP sender reports to do the mapping, NTP, using initial RTCP sender reports to do the mapping,
and later reports to check drift against the mapping. and later reports to check drift against the mapping.
Additionally, the RTP-Info header parameter fields only apply to a | Additionally, the RTP-Info header parameter fields only apply to a |
single SSRC within a stream (the SSRC reported in the transport | single SSRC within a stream (the first SSRC reported in the transport |
response header; see section 14.40). If there are multiple | response header; see section 14.43). If there are multiple |
synchronization sources (SSRCs) present within a RTP session | synchronization sources (SSRCs) present within a RTP session |
transmitting media, RTCP must be used to map RTP and NTP timestamps | transmitting media, RTCP must be used to map RTP and NTP timestamps |
for those sources, for both synchronization and drift-checking. Due | for those sources, for both synchronization and drift-checking. Due |
to backwards compatibility reasons these shortcomings can't be fixed | to backwards compatibility reasons these shortcomings can't be fixed |
without defining a new header, which is for future work if needed. without defining a new header, which is for future work if needed.
Additional constraint: The syntax element "safe-url" (see section Additional constraint: The syntax element "safe-url" (see section
17.2.3) MUST NOT contain the semicolon (";") or comma (",") 18.2.3) MUST NOT contain the semicolon (";") or comma (",")
characters. The quoted-url form SHOULD only be used when a URL does characters. The quoted-url form SHOULD only be used when a URL does
not meet the safe-url constraint, in order to ensure compatibility not meet the safe-url constraint, in order to ensure compatibility
with implementations conformant to RFC 2326 [1]. with implementations conformant to RFC 2326 [1].
Example: | Example:
RTP-Info: url=rtsp://example.com/bar.avi/streamid=0;seq=45102, | RTP-Info: url=rtsp://example.com/bar.avi/streamid=0;seq=45102,
url=rtsp://example.com/bar.avi/streamid=1;seq=30211 | url=rtsp://example.com/bar.avi/streamid=1;seq=30211
14.34 Scale 14.37 Scale
A scale value of 1 indicates normal play at the normal forward | A scale value of 1 indicates normal play at the normal forward
viewing rate. If not 1, the value corresponds to the rate with | viewing rate. If not 1, the value corresponds to the rate with
respect to normal viewing rate. For example, a ratio of 2 indicates | respect to normal viewing rate. For example, a ratio of 2 indicates
twice the normal viewing rate ("fast forward") and a ratio of 0.5 | twice the normal viewing rate ("fast forward") and a ratio of 0.5
indicates half the normal viewing rate. In other words, a ratio of 2 | indicates half the normal viewing rate. In other words, a ratio of 2
has normal play time increase at twice the wallclock rate. For every | has normal play time increase at twice the wallclock rate. For every
second of elapsed (wallclock) time, 2 seconds of content will be | second of elapsed (wallclock) time, 2 seconds of content will be
delivered. A negative value indicates reverse direction. For certain | delivered. A negative value indicates reverse direction. For certain
media transports this may require certain considerations to work | media transports this may require certain considerations to work
consistent, see section B.1 for description on how RTP handles this. consistent, see section B.1 for description on how RTP handles this.
Unless requested otherwise by the Speed parameter, the data rate Unless requested otherwise by the Speed parameter, the data rate
SHOULD not be changed. Implementation of scale changes depends on the SHOULD not be changed. Implementation of scale changes depends on the
server and media type. For video, a server may, for example, deliver server and media type. For video, a server may, for example, deliver
only key frames or selected key frames. For audio, it may time-scale only key frames or selected key frames. For audio, it may time-scale
the audio while preserving pitch or, less desirably, deliver the audio while preserving pitch or, less desirably, deliver
fragments of audio. fragments of audio.
The server should try to approximate the viewing rate, but may The server should try to approximate the viewing rate, but may
restrict the range of scale values that it supports. The response restrict the range of scale values that it supports. The response
MUST contain the actual scale value chosen by the server. MUST contain the actual scale value chosen by the server.
If the server does not implement the possibility to scale, it will If the server does not implement the possibility to scale, it will
not return a Scale header. A server supporting Scale operations for not return a Scale header. A server supporting Scale operations for
PLAY SHALL indicate this with the use of the "play.scale" feature- PLAY SHALL indicate this with the use of the "play.scale" feature-
tags. tags.
When indicating a negative scale for a reverse playback, the Range When indicating a negative scale for a reverse playback, the Range
header must indicate a decreasing range as described in section header must indicate a decreasing range as described in section
14.29. 14.32.
Example of playing in reverse at 3.5 times normal rate: Example of playing in reverse at 3.5 times normal rate:
Scale: -3.5 Scale: -3.5
Range: npt=15-10 Range: npt=15-10
14.35 Speed 14.38 Speed
The Speed request-header field requests the server to deliver data to The Speed request-header field requests the server to deliver data to
the client at a particular speed, contingent on the server's ability the client at a particular speed, contingent on the server's ability
and desire to serve the media stream at the given speed. and desire to serve the media stream at the given speed.
Implementation by the server is OPTIONAL. The default is the bit rate Implementation by the server is OPTIONAL. The default is the bit rate
of the stream. of the stream.
The parameter value is expressed as a decimal ratio, e.g., a value of The parameter value is expressed as a decimal ratio, e.g., a value of
2.0 indicates that data is to be delivered twice as fast as normal. A 2.0 indicates that data is to be delivered twice as fast as normal. A
speed of zero is invalid. All speeds may not be possible to support. speed of zero is invalid. All speeds may not be possible to support.
Therefore the actual used speed MUST be included in the response. The Therefore the actual used speed MUST be included in the response. The
skipping to change at page 83, line 34 skipping to change at page 92, line 37
presentation at a higher or lower rate is necessary. Implementors presentation at a higher or lower rate is necessary. Implementors
should keep in mind that bandwidth for the session may be negotiated should keep in mind that bandwidth for the session may be negotiated
beforehand (by means other than RTSP), and therefore re-negotiation beforehand (by means other than RTSP), and therefore re-negotiation
may be necessary. When data is delivered over UDP, it is highly may be necessary. When data is delivered over UDP, it is highly
recommended that means such as RTCP be used to track packet loss recommended that means such as RTCP be used to track packet loss
rates. If the data transport is performed over public best-effort rates. If the data transport is performed over public best-effort
networks the sender SHOULD perform congestion control of the networks the sender SHOULD perform congestion control of the
stream(s). This can result in that the communicated speed is stream(s). This can result in that the communicated speed is
impossible to maintain. impossible to maintain.
14.36 Server 14.39 Server
See [H14.38], however the header syntax is corrected in section See [H14.38], however the header syntax is corrected in section
17.2.3. 18.2.3.
14.37 Session 14.40 Session
The Session request-header and response-header field identifies an The Session request-header and response-header field identifies an
RTSP session. An RTSP session is created by the server as a result of RTSP session. An RTSP session is created by the server as a result of
a successful SETUP request and in the response the session identifier a successful SETUP request and in the response the session identifier
is given to the client. The RTSP session exist until destroyed by a is given to the client. The RTSP session exist until destroyed by a
TEARDOWN or timed out by the server. TEARDOWN or timed out by the server.
The session identifier is chosen by the server (see Section 3.3) and The session identifier is chosen by the server (see Section 3.3) and
MUST be returned in the SETUP response. Once a client receives a MUST be returned in the SETUP response. Once a client receives a
session identifier, it SHALL be included in any request related to session identifier, it SHALL be included in any request related to
skipping to change at page 84, line 20 skipping to change at page 93, line 22
TEARDOWN, and REDIRECT, and if included in the request of the TEARDOWN, and REDIRECT, and if included in the request of the
following methods it SHALL also be included in the response, OPTIONS, following methods it SHALL also be included in the response, OPTIONS,
GET_PARAMETER, and SET_PARAMETER, and SHALL NOT be included in GET_PARAMETER, and SET_PARAMETER, and SHALL NOT be included in
DESCRIBE. DESCRIBE.
Note that RFC 2326 servers and client may in some cases not include Note that RFC 2326 servers and client may in some cases not include
or return a Session header when expected according to the above text. or return a Session header when expected according to the above text.
Any client or server is RECOMMENDED to be forgiving of this error if Any client or server is RECOMMENDED to be forgiving of this error if
possible (which it is in many cases). possible (which it is in many cases).
The timeout parameter MAY be included in a SETUP response, and SHALL | The timeout parameter MAY be included in a SETUP response, and SHALL
NOT be included in requests. The server uses it to indicate to the | NOT be included in requests. The server uses it to indicate to the
client how long the server is prepared to wait between RTSP commands | client how long the server is prepared to wait between RTSP commands
or other signs of life before closing the session due to lack of | or other signs of life before closing the session due to lack of
activity (see below and Section A). The timeout is measured in | activity (see below and Section A). The timeout is measured in
seconds, with a default of 60 seconds (1 minute). The length of the | seconds, with a default of 60 seconds (1 minute). The length of the
session timeout SHALL NOT be changed in a established session. session timeout SHALL NOT be changed in a established session.
The mechanisms for showing liveness of the client is, any RTSP The mechanisms for showing liveness of the client is, any RTSP
request with a Session header, if RTP & RTCP is used an RTCP message, request with a Session header, if RTP & RTCP is used an RTCP message,
or through any other used media protocol capable of indicating or through any other used media protocol capable of indicating
liveness of the RTSP client. It is RECOMMENDED that a client does not liveness of the RTSP client. It is RECOMMENDED that a client does not
wait to the last second of the timeout before trying to send a wait to the last second of the timeout before trying to send a
liveness message. The RTSP message may be lost or when using reliable liveness message. The RTSP message may be lost or when using reliable
protocols, such as TCP, the message may take some time to arrive protocols, such as TCP, the message may take some time to arrive
safely at the receiver. To show liveness between RTSP request issued safely at the receiver. To show liveness between RTSP request issued
skipping to change at page 85, line 49 skipping to change at page 94, line 51
the same URL from the same client will require use of different the same URL from the same client will require use of different
session identifiers. session identifiers.
The session identifier is needed to distinguish several The session identifier is needed to distinguish several
delivery requests for the same URL coming from the same delivery requests for the same URL coming from the same
client. client.
The response 454 (Session Not Found) SHALL be returned if the session The response 454 (Session Not Found) SHALL be returned if the session
identifier is invalid. identifier is invalid.
14.38 Supported 14.41 Supported
The Supported header field enumerates all the extensions supported by |
The Supported header field enumerates all the extensions supported by the client or server using feature tags. The header carries the |
the client or server. When offered in a request, the receiver MUST extensions supported by the message sending entity. The Supported |
respond with its corresponding Supported header. header MAY be included in any request. When present in a request, |
the receiver MUST respond with its corresponding Supported header. |
Note, also in 4xx and 5xx responses shall the supported header be |
included.
The Supported header field contains a list of feature-tags, described The Supported header field contains a list of feature-tags, described
in Section 3.7, that are understood by the client or server. in Section 3.7, that are understood by the client or server.
Example: Example:
C->S: OPTIONS rtsp://example.com/ RTSP/1.0 C->S: OPTIONS rtsp://example.com/ RTSP/1.0
Supported: foo, bar, blech Supported: foo, bar, blech
S->C: RTSP/1.0 200 OK S->C: RTSP/1.0 200 OK
Supported: bar, blech, baz Supported: bar, blech, baz
14.39 Timestamp 14.42 Timestamp
The Timestamp general-header field describes when the client sent the The Timestamp general-header field describes when the client sent the
request to the server. The value of the timestamp is of significance request to the server. The value of the timestamp is of significance
only to the client and may use any timescale. The server MUST echo only to the client and may use any timescale. The server MUST echo
the exact same value and MAY, if it has accurate information about the exact same value and MAY, if it has accurate information about
this, add a floating point number indicating the number of seconds this, add a floating point number indicating the number of seconds
that has elapsed since it has received the request. The timestamp is that has elapsed since it has received the request. The timestamp is
used by the client to compute the round-trip time to the server so used by the client to compute the round-trip time to the server so
that it can adjust the timeout value for retransmissions. It also that it can adjust the timeout value for retransmissions. It also
resolves retransmission ambiguities for unreliable transport of RTSP. resolves retransmission ambiguities for unreliable transport of RTSP.
14.40 Transport 14.43 Transport
The Transport request and response header field indicates which The Transport request and response header field indicates which
transport protocol is to be used and configures its parameters such transport protocol is to be used and configures its parameters such
as destination address, compression, multicast time-to-live and as destination address, compression, multicast time-to-live and
destination port for a single stream. It sets those values not destination port for a single stream. It sets those values not
already determined by a presentation description. already determined by a presentation description.
Transports are comma separated, listed in order of preference. | Transports are comma separated, listed in order of preference.
Parameters may be added to each transport, separated by a semicolon. | Parameters may be added to each transport, separated by a semicolon.
The server SHOULD return a Transport response-header field in the | The server SHOULD return a Transport response-header field in the
response to indicate the values actually chosen. The Transport header | response to indicate the values actually chosen. The Transport header
field MAY also be used to change certain transport parameters. A | field MAY also be used to change certain transport parameters. A
server MAY refuse to change parameters of an existing stream. | server MAY refuse to change parameters of an existing stream.
A Transport request header field MAY contain a list of transport | A Transport request header field MAY contain a list of transport
options acceptable to the client, in the form of multiple | options acceptable to the client, in the form of multiple
transportspec entries. In that case, the server MUST return the | transportspec entries. In that case, the server MUST return the
single option (transport-spec) which was actually chosen. The number | single option (transport-spec) which was actually chosen. The number
of transportspec entries is expected to be limited as the client will | of transportspec entries is expected to be limited as the client will
get guidance on what configurations that are possible from the | get guidance on what configurations that are possible from the
presentation description. presentation description.
A transport-spec transport option may only contain one of any given | A transport-spec transport option may only contain one of any given
parameter within it. Parameters may be given in any order. | parameter within it. Parameters may be given in any order.
Additionally, it may only contain the unicast or multicast transport | Additionally, it may only contain the unicast or multicast transport
parameter. Unknown transport parameters SHALL be ignored. The | parameter. Unknown transport parameters SHALL be ignored. The
requester need to ensure that the responder understands the | requester need to ensure that the responder understands the
parameters through the use of feature tags and the Require header. | parameters through the use of feature tags and the Require header.
The usage of any parameter that was not defined in RFC 2326 or in an | The usage of any parameter that was not defined in RFC 2326 or in an
extended way requires that request or response contains a Require | extended way requires that request or response contains a Require
header with the "play.basic" feature tag. header with the "play.basic" feature tag.
The Transport header field is restricted to describing a The Transport header field is restricted to describing a
single media stream. (RTSP can also control multiple single media stream. (RTSP can also control multiple
streams as a single entity.) Making it part of RTSP rather streams as a single entity.) Making it part of RTSP rather
than relying on a multitude of session description formats than relying on a multitude of session description formats
greatly simplifies designs of firewalls. greatly simplifies designs of firewalls.
The syntax for the transport specifier is The syntax for the transport specifier is
transport/profile/lower-transport. transport/profile/lower-transport.
The default value for the "lower-transport" parameters is specific to The default value for the "lower-transport" parameters is specific to
the profile. For RTP/AVP, the default is UDP. the profile. For RTP/AVP, the default is UDP.
There is three different methods for how to specify where the media | There is three different methods for how to specify where the media
should be delivered: | should be delivered:
o The presence of this parameter and its values indicates | o The presence of this parameter and its values indicates
address and port pairs for one or more IP flow necessary for | address and port pairs for one or more IP flow necessary for
the media transport. This is an improved version of the | the media transport. This is an improved version of the
Destination parameter. | Destination parameter.
o The presence of this parameter and its value indicates what IP | o The presence of this parameter and its value indicates what IP
address the media shall be delivered to. This method is kept | address the media shall be delivered to. This method is kept
for backwards compatibility reasons, dest_addr is a better | for backwards compatibility reasons, dest_addr is a better
choice. | choice.
o The lack of of both of the above parameters indicates that the | o The lack of of both of the above parameters indicates that the
server SHALL send media to same address for which the RTSP | server SHALL send media to same address for which the RTSP
messages originates. | messages originates.
The choice of method for indicating where the media shall be | The choice of method for indicating where the media shall be
delivered depends on the use case. In many case the only allowed | delivered depends on the use case. In many case the only allowed
method will be to use no explicit indication and have the server | method will be to use no explicit indication and have the server
deliver media to the source of the RTSP messages. | deliver media to the source of the RTSP messages.
An RTSP proxy will also need to take care. If the media is not | An RTSP proxy will also need to take care. If the media is not
desired to be routed through the proxy, the proxy will need to | desired to be routed through the proxy, the proxy will need to
introduce the destination indication. introduce the destination indication.
Below are the configuration parameters associated with transport: Below are the configuration parameters associated with transport:
General parameters: General parameters:
unicast / multicast: This parameter is a mutually exclusive unicast / multicast: This parameter is a mutually exclusive
indication of whether unicast or multicast delivery will be indication of whether unicast or multicast delivery will be
attempted. One of the two values MUST be specified. Clients attempted. One of the two values MUST be specified. Clients
that are capable of handling both unicast and multicast that are capable of handling both unicast and multicast
skipping to change at page 89, line 28 skipping to change at page 98, line 32
This information may also be available through SDP. This information may also be available through SDP.
However, since this is more a feature of transport However, since this is more a feature of transport
than media initialization, the authoritative source than media initialization, the authoritative source
for this information should be in the SETUP response. for this information should be in the SETUP response.
layers: The number of multicast layers to be used for this media layers: The number of multicast layers to be used for this media
stream. The layers are sent to consecutive addresses stream. The layers are sent to consecutive addresses
starting at the destination address. starting at the destination address.
dest_addr: A general destination address parameter that can | dest_addr: A general destination address parameter that can
contain one or more address and port pair. For each | contain one or more address and port pair. For each
combination of Protocol/Profile/Lower Transport the | combination of Protocol/Profile/Lower Transport the
interpretation of the address or addresses needs to be | interpretation of the address or addresses needs to be
defined. The host address part of the tuple MAY be empty, | defined. The host address part of the tuple MAY be empty,
for example ":8000", in cases when only destination port is | for example ":8000", in cases when only destination port is
desired to be specified. desired to be specified.
The client or server SHALL NOT use this parameter unless The client or server SHALL NOT use this parameter unless
both client and server has shown support. This parameter both client and server has shown support. This parameter
MUST be supported by client and servers that implements MUST be supported by client and servers that implements
this specification. Support is indicated by the use of the this specification. Support is indicated by the use of the
feature-tag "play.basic". This parameter SHALL NOT be used feature-tag "play.basic". This parameter SHALL NOT be used
in the same transport specification as any of the in the same transport specification as any of the
parameters "destination", "source", "port", "client_port", parameters "destination", "source", "port", "client_port",
and "server_port". and "server_port".
skipping to change at page 90, line 16 skipping to change at page 99, line 20
address or addresses needs to be defined. The client or address or addresses needs to be defined. The client or
server SHALL NOT use this parameter unless both client and server SHALL NOT use this parameter unless both client and
server has shown support. This parameter MUST be supported server has shown support. This parameter MUST be supported
by client and servers that implements this specification. by client and servers that implements this specification.
Support is indicated by the use the feature-tag Support is indicated by the use the feature-tag
"play.basic". This parameter SHALL NOT be used in the same "play.basic". This parameter SHALL NOT be used in the same
transport specification as any of the parameters transport specification as any of the parameters
"destination", "source", "port", "client_port", and "destination", "source", "port", "client_port", and
"server_port". "server_port".
This parameter MUST be specified by the server if it | This parameter MUST be specified by the server if it
transmits media packets from another address than the one | transmits media packets from another address than the one
RTSP messages are sent to. This will allow the client to | RTSP messages are sent to. This will allow the client to
verify source address and give it a destination address for | verify source address and give it a destination address for
its RTCP feedback packets if RTP is used. The address or | its RTCP feedback packets if RTP is used. The address or
addresses indicated in the src_addr parameter SHOULD be | addresses indicated in the src_addr parameter SHOULD be
used both for sending and receiving of the media streams | used both for sending and receiving of the media streams
data packets. The main reasons are three: First by sending | data packets. The main reasons are three: First by sending
from the indicated ports the source address will be known | from the indicated ports the source address will be known
by the receiver of the packet. Secondly, in the presence of | by the receiver of the packet. Secondly, in the presence of
NATs some traversal mechanism requires either knowledge | NATs some traversal mechanism requires either knowledge
from which address and port a packet flow is coming, or | from which address and port a packet flow is coming, or
having the possibility to send data to the sender port. having the possibility to send data to the sender port.
mode: The mode parameter indicates the methods to be supported mode: The mode parameter indicates the methods to be supported
for this session. Valid values are PLAY and RECORD. If not for this session. Valid values are PLAY and RECORD. If not
provided, the default is PLAY. The RECORD value was provided, the default is PLAY. The RECORD value was
defined in RFC 2326 and is deprecated in this defined in RFC 2326 and is deprecated in this
specification. specification.
append: The append parameter was used together with RECORD and append: The append parameter was used together with RECORD and
is now deprecated. is now deprecated.
skipping to change at page 91, line 37 skipping to change at page 100, line 41
is to be sent. It is specified as a range, e.g., is to be sent. It is specified as a range, e.g.,
port=3456-3457. This parameter SHALL NOT be used when port=3456-3457. This parameter SHALL NOT be used when
src_addr and dest_addr is used in a transport declaration. src_addr and dest_addr is used in a transport declaration.
server_port: This parameter provides the unicast RTP/RTCP port server_port: This parameter provides the unicast RTP/RTCP port
pair on the server where media data and control information pair on the server where media data and control information
is to be sent. It is specified as a range, e.g., is to be sent. It is specified as a range, e.g.,
port=3456-3457. This parameter SHALL NOT be used when port=3456-3457. This parameter SHALL NOT be used when
src_addr and dest_addr is used in a transport declaration. src_addr and dest_addr is used in a transport declaration.
ssrc: The ssrc parameter, if included in a SETUP response, ssrc: The ssrc parameter, if included in a SETUP response, |
indicates the RTP SSRC [15] value that will be used by the indicates the RTP SSRC [18] value(s) that will be used by |
media server for RTP packets within the stream. It is the media server for RTP packets within the stream. It is |
expressed as an eight digit hexadecimal value. If the expressed as an eight digit hexadecimal value. Multiple |
server does not act as a synchronization source for stream values MAY only be specified if the cl¨ent has indicated |
data (for instance, server is a translator, reflector, support for this specification, i.e. if including multiple |
etc.) the value will be the "packet sender's SSRC" that SSRC values, the request must have include "Require: |
would have been used in the RTCP Receiver Reports generated play.basic" or "Supported: play.basic". If no such support |
by the server, regardless of whether the server actually is present only a single value SHALL be included. |
generates RTCP RRs. If there are multiple sources within If the server does not act as a synchronization source for |
the stream, the ssrc parameter only indicates the value for stream data (for instance, server is a translator, |
a single synchronization source. Other sources must be reflector, etc.), and only a single value can be specified, |
deduced from the actual RTP/RTCP stream. the value will be the "packet sender's SSRC" that would |
have been used in the RTCP Receiver Reports generated by |
the server, regardless of whether the server actually |
generates RTCP RRs. |
The first SSRC value is the one that RTP-Info |
synchronization information relates to, see section 14.36.
The functionality of specifying the ssrc parameter in a The functionality of specifying the ssrc parameter in a
SETUP request is deprecated as it is incompatible with the SETUP request is deprecated as it is incompatible with the
specification of RTP in RFC 3550 [15]. If the parameter is specification of RTP in RFC 3550 [18]. If the parameter is
included in the transport header of a SETUP request, the included in the transport header of a SETUP request, the
server MAY ignore it, and choose an appropriate SSRC for server MAY ignore it, and choose an appropriate SSRC for
the stream. The server MAY set the ssrc parameter in the the stream. The server MAY set the ssrc parameter in the
transport header of the response. transport header of the response.
The combination of transport protocol, profile and lower transport The combination of transport protocol, profile and lower transport
needs to be defined. A number of combinations are defined in the needs to be defined. A number of combinations are defined in the
appendix B. appendix B.
Below is a usage example, showing a client advertising the capability Below is a usage example, showing a client advertising the capability
skipping to change at page 92, line 34 skipping to change at page 101, line 44
Transport: RTP/AVP;multicast;mode="PLAY", Transport: RTP/AVP;multicast;mode="PLAY",
RTP/AVP;unicast;client_port=3456-3457;mode="PLAY" RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"
S->C: RTSP/1.0 200 OK S->C: RTSP/1.0 200 OK
CSeq: 302 CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344 Session: 47112344
Transport: RTP/AVP;unicast;client_port=3456-3457; Transport: RTP/AVP;unicast;client_port=3456-3457;
server_port=6256-6257;mode="PLAY" server_port=6256-6257;mode="PLAY"
14.41 Unsupported 14.44 Unsupported
The Unsupported response-header field lists the features not The Unsupported response-header field lists the features not
supported by the server. In the case where the feature was specified supported by the server. In the case where the feature was specified
via the Proxy-Require field (Section 14.27), if there is a proxy on via the Proxy-Require field (Section 14.30), if there is a proxy on
the path between the client and the server, the proxy MUST send a the path between the client and the server, the proxy MUST send a
response message with a status code of 551 (Option Not Supported). response message with a status code of 551 (Option Not Supported).
The request SHALL NOT be forwarded. The request SHALL NOT be forwarded.
See Section 14.32 for a usage example. See Section 14.35 for a usage example.
14.42 User-Agent 14.45 User-Agent
See [H14.43] for explanation, however the syntax is clarified due to See [H14.43] for explanation, however the syntax is clarified due to
an error in RFC 2616. A Client SHOULD include this header in all RTSP an error in RFC 2616. A Client SHOULD include this header in all RTSP
messages it sends. messages it sends.
14.43 Vary 14.46 Vary
See [H14.44] See [H14.44]
14.44 Via 14.47 Via
See [H14.45]. See [H14.45].
14.45 WWW-Authenticate 14.48 WWW-Authenticate
See [H14.47]. See [H14.47].
15 Caching 15 Caching
In HTTP, response-request pairs are cached. RTSP differs In HTTP, response-request pairs are cached. RTSP differs
significantly in that respect. Responses are not cacheable, with the significantly in that respect. Responses are not cacheable, with the
exception of the presentation description returned by DESCRIBE. exception of the presentation description returned by DESCRIBE.
(Since the responses for anything but DESCRIBE and GET_PARAMETER do (Since the responses for anything but DESCRIBE and GET_PARAMETER do
not return any data, caching is not really an issue for these not return any data, caching is not really an issue for these
skipping to change at page 93, line 39 skipping to change at page 102, line 50
has an up-to-date copy of the continuous media content and its has an up-to-date copy of the continuous media content and its
description. It can determine whether the copy is up-to-date by description. It can determine whether the copy is up-to-date by
issuing a SETUP or DESCRIBE request, respectively, and comparing the issuing a SETUP or DESCRIBE request, respectively, and comparing the
Last-Modified header with that of the cached copy. If the copy is not Last-Modified header with that of the cached copy. If the copy is not
up-to-date, it modifies the SETUP transport parameters as appropriate up-to-date, it modifies the SETUP transport parameters as appropriate
and forwards the request to the origin server. Subsequent control and forwards the request to the origin server. Subsequent control
commands such as PLAY or PAUSE then pass the proxy unmodified. The commands such as PLAY or PAUSE then pass the proxy unmodified. The
proxy delivers the continuous media data to the client, while proxy delivers the continuous media data to the client, while
possibly making a local copy for later reuse. The exact behavior possibly making a local copy for later reuse. The exact behavior
allowed to the cache is given by the cache-response directives allowed to the cache is given by the cache-response directives
described in Section 14.9. A cache MUST answer any DESCRIBE requests described in Section 14.10. A cache MUST answer any DESCRIBE requests
if it is currently serving the stream to the requestor, as it is if it is currently serving the stream to the requestor, as it is
possible that low-level details of the stream description may have possible that low-level details of the stream description may have
changed on the origin-server. changed on the origin-server.
Note that an RTSP cache, unlike the HTTP cache, is of the "cut- Note that an RTSP cache, unlike the HTTP cache, is of the "cut-
through" variety. Rather than retrieving the whole resource from the through" variety. Rather than retrieving the whole resource from the
origin server, the cache simply copies the streaming data as it origin server, the cache simply copies the streaming data as it
passes by on its way to the client. Thus, it does not introduce passes by on its way to the client. Thus, it does not introduce
additional latency. additional latency.
skipping to change at page 94, line 15 skipping to change at page 103, line 27
description. Typically, a cache eliminates all transport-references description. Typically, a cache eliminates all transport-references
(that is, multicast information) from the presentation description, (that is, multicast information) from the presentation description,
since these are independent of the data delivery from the cache to since these are independent of the data delivery from the cache to
the client. Information on the encodings remains the same. If the the client. Information on the encodings remains the same. If the
cache is able to translate the cached media data, it would create a cache is able to translate the cached media data, it would create a
new presentation description with all the encoding possibilities it new presentation description with all the encoding possibilities it
can offer. can offer.
16 Examples 16 Examples
This section contains several different examples trying to illustrate | This section contains several different examples trying to illustrate
possible ways of using RTSP. The examples can also help with the | possible ways of using RTSP. The examples can also help with the
understanding of how functions of RTSP work. However remember that | understanding of how functions of RTSP work. However remember that
this is examples and the normative and syntax description in the | this is examples and the normative and syntax description in the
other chapters takes precedence. Please also note that many of the | other chapters takes precedence. Please also note that many of the
example MAY contain syntax illegal line breaks to accommodate the | example MAY contain syntax illegal line breaks to accommodate the
formatting restriction that the RFC series impose. | formatting restriction that the RFC series impose.
16.1 Media on Demand (Unicast) | 16.1 Media on Demand (Unicast)
Client C requests a movie distributed from two different media | Client C requests a movie distributed from two different media
servers A (audio.example.com ) and V (video.example.com ). The media | servers A (audio.example.com ) and V (video.example.com ). The media
description is stored on a web server W. The media description | description is stored on a web server W. The media description
contains descriptions of the presentation and all its streams, | contains descriptions of the presentation and all its streams,
including the codecs that are available, dynamic RTP payload types, | including the codecs that are available, dynamic RTP payload types,
the protocol stack, and content information such as language or | the protocol stack, and content information such as language or
copyright restrictions. It may also give an indication about the | copyright restrictions. It may also give an indication about the
timeline of the movie. | timeline of the movie.
In this example, the client is only interested in the last part of | In this example, the client is only interested in the last part of
the movie. | the movie.
C->W: GET /twister.sdp HTTP/1.1 | C->W: GET /twister.sdp HTTP/1.1
Host: www.example.com | Host: www.example.com
Accept: application/sdp | Accept: application/sdp
W->C: HTTP/1.0 200 OK | W->C: HTTP/1.0 200 OK
Date: 23 Jan 1997 15:35:06 GMT | Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp | Content-Type: application/sdp
Content-Length: 255 | Content-Length: 255
Expires: 23 Jan 1998 15:35:06 GMT | Expires: 23 Jan 1998 15:35:06 GMT
v=0 | v=0
o=- 2890844526 2890842807 IN IP4 192.16.24.202 | o=- 2890844526 2890842807 IN IP4 192.16.24.202
s=RTSP Session | s=RTSP Session
e=adm@example.com | e=adm@example.com
a=range:npt=0-1:49:34 | a=range:npt=0-1:49:34
t=0 0 | t=0 0
m=audio 0 RTP/AVP 0 | m=audio 0 RTP/AVP 0
a=control:rtsp://audio.example.com/twister/audio.en | a=control:rtsp://audio.example.com/twister/audio.en
m=video 0 RTP/AVP 31 | m=video 0 RTP/AVP 31
a=control:rtsp://video.example.com/twister/video | a=control:rtsp://video.example.com/twister/video
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0 | C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 1 | CSeq: 1
User-Agent: PhonyClient/1.2 | User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;client_port=3056-3057, | Transport: RTP/AVP/UDP;unicast;client_port=3056-3057,
RTP/AVP/TCP;unicast;interleave=0-1 | RTP/AVP/TCP;unicast;interleaved=0-1
A->C: RTSP/1.0 200 OK | A->C: RTSP/1.0 200 OK
CSeq: 1 | CSeq: 1
Session: 12345678 | Session: 12345678
Transport: RTP/AVP/UDP;unicast;client_port=3056-3057; | Transport: RTP/AVP/UDP;unicast;client_port=3056-3057;
server_port=5000-5001 | server_port=5000-5001
Date: 23 Jan 1997 15:35:12 GMT | Date: 23 Jan 1997 15:35:12 GMT
Server: PhonyServer/1.0 | Server: PhonyServer/1.0
Expires: 24 Jan 1997 15:35:12 GMT | Expires: 24 Jan 1997 15:35:12 GMT
Cache-Control: public | Cache-Control: public
Accept-Ranges: NPT, SMPTE | Accept-Ranges: NPT, SMPTE
C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0 | C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 1 | CSeq: 1
User-Agent: PhonyClient/1.2 | User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;client_port=3058-3059, | Transport: RTP/AVP/UDP;unicast;client_port=3058-3059,
RTP/AVP/TCP;unicast;interleave=0-1 | RTP/AVP/TCP;unicast;interleaved=0-1
V->C: RTSP/1.0 200 OK | V->C: RTSP/1.0 200 OK
CSeq: 1 | CSeq: 1
Session: 23456789 | Session: 23456789
Transport: RTP/AVP/UDP;unicast;client_port=3058-3059; | Transport: RTP/AVP/UDP;unicast;client_port=3058-3059;
server_port=5002-5003 | server_port=5002-5003
Date: 23 Jan 1997 15:35:12 GMT | Date: 23 Jan 1997 15:35:12 GMT
Server: PhonyServer/1.0 | Server: PhonyServer/1.0
Cache-Control: public | Cache-Control: public
Expires: 24 Jan 1997 15:35:12 GMT | Expires: 24 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT, SMPTE | Accept-Ranges: NPT, SMPTE
C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0 | C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 2 | CSeq: 2
User-Agent: PhonyClient/1.2 | User-Agent: PhonyClient/1.2
Session: 23456789 | Session: 23456789
Range: smpte=0:10:00- | Range: smpte=0:10:00-
V->C: RTSP/1.0 200 OK |
CSeq: 2 |
Session: 23456789 |
Range: smpte=0:10:00-1:49:23 |
RTP-Info: url=rtsp://video.example.com/twister/video; |
seq=12312232;rtptime=78712811 |
Server: PhonyServer/2.0 |
Date: 23 Jan 1997 15:35:13 GMT |