draft-ietf-mmusic-rfc2326bis-07.txt   draft-ietf-mmusic-rfc2326bis-08.txt 
Internet Engineering Task Force MMUSIC WG Internet Engineering Task Force MMUSIC WG
Internet Draft H. Schulzrinne Internet Draft H. Schulzrinne
draft-ietf-mmusic-rfc2326bis-07.txt Columbia U. draft-ietf-mmusic-rfc2326bis-08.txt Columbia U.
July 19, 2004 A. Rao October 25, 2004 A. Rao
Expires: January, 2005 Cisco Expires: April, 2005 Cisco
R. Lanphier R. Lanphier
RealNetworks RealNetworks
M. Westerlund M. Westerlund
Ericsson Ericsson
A. Narasimhan A. Narasimhan
Princeton Princeton
Real Time Streaming Protocol (RTSP) Real Time Streaming Protocol (RTSP)
STATUS OF THIS MEMO STATUS OF THIS MEMO
By submitting this Internet-Draft, I (we) certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am (we are) aware have been applicable patent or other IPR claims of which he or she is aware
disclosed, and any of which I (we) become aware will be disclosed, in have been or will be disclosed, and any of which he or she becomes?
accordance with RFC 3668 (BCP 79). aware will be disclosed, in accordance with( Section 6 of) RFC 3668.
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 16 skipping to change at page 3, line 16
1 Introduction ........................................ 9 1 Introduction ........................................ 9
1.1 RTSP Specification Update ........................... 9 1.1 RTSP Specification Update ........................... 9
1.2 Purpose ............................................. 10 1.2 Purpose ............................................. 10
1.3 Notational Conventions .............................. 11 1.3 Notational Conventions .............................. 11
1.4 Terminology ......................................... 12 1.4 Terminology ......................................... 12
1.5 Protocol Properties ................................. 15 1.5 Protocol Properties ................................. 15
1.6 Extending RTSP ...................................... 17 1.6 Extending RTSP ...................................... 17
1.7 Overall Operation ................................... 18 1.7 Overall Operation ................................... 18
1.8 RTSP States ......................................... 19 1.8 RTSP States ......................................... 19
1.9 Relationship with Other Protocols ................... 20 1.9 Relationship with Other Protocols ................... 19
2 RTSP Use Cases ...................................... 20 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 ................ 22 2.2 Unicast distribution of Live Content ................ 22
2.3 On-demand Playback using Multicast .................. 22 2.3 On-demand Playback using Multicast .................. 22
2.4 Inviting a RTSP server into a conference ............ 23 2.4 Inviting a RTSP server into a conference ............ 22
2.5 Live Content using Multicast ........................ 24 2.5 Live Content using Multicast ........................ 23
3 Protocol Parameters ................................. 25 3 Protocol Parameters ................................. 24
3.1 RTSP Version ........................................ 25 3.1 RTSP Version ........................................ 24
3.2 RTSP URL ............................................ 25 3.2 RTSP URI ............................................ 24
3.3 Session Identifiers ................................. 26 3.3 Session Identifiers ................................. 26
3.4 SMPTE Relative Timestamps ........................... 27 3.4 SMPTE Relative Timestamps ........................... 26
3.5 Normal Play Time .................................... 27 3.5 Normal Play Time .................................... 27
3.6 Absolute Time ....................................... 28 3.6 Absolute Time ....................................... 27
3.7 Feature-tags ........................................ 28 3.7 Feature-tags ........................................ 28
3.8 Entity Tags ......................................... 29 3.8 Entity Tags ......................................... 28
4 RTSP Message ........................................ 29 4 RTSP Message ........................................ 28
4.1 Message Types ....................................... 29 4.1 Message Types ....................................... 29
4.2 Message Headers ..................................... 30 4.2 Message Headers ..................................... 29
4.3 Message Body ........................................ 30 4.3 Message Body ........................................ 29
4.4 Message Length ...................................... 30 4.4 Message Length ...................................... 29
5 General Header Fields ............................... 30 5 General Header Fields ............................... 30
6 Request ............................................. 30 6 Request ............................................. 30
6.1 Request Line ........................................ 31 6.1 Request Line ........................................ 30
6.2 Request Header Fields ............................... 32 6.2 Request Header Fields ............................... 32
7 Response ............................................ 32 7 Response ............................................ 32
7.1 Status-Line ......................................... 33 7.1 Status-Line ......................................... 33
7.1.1 Status Code and Reason Phrase ....................... 33 7.1.1 Status Code and Reason Phrase ....................... 33
7.1.2 Response Header Fields .............................. 35 7.1.2 Response Header Fields .............................. 34
8 Entity .............................................. 35 8 Entity .............................................. 34
8.1 Entity Header Fields ................................ 35 8.1 Entity Header Fields ................................ 35
8.2 Entity Body ......................................... 35 8.2 Entity Body ......................................... 35
9 Connections ......................................... 36 9 Connections ......................................... 35
9.1 Pipelining .......................................... 36 9.1 Pipelining .......................................... 37
9.2 Reliability and Acknowledgements .................... 36 9.2 Reliability and Acknowledgements .................... 37
9.3 Unreliable Transport ................................ 39 9.3 The usage of connections ............................ 38
9.4 The usage of connections ............................ 39 9.4 Timing Out RTSP messages ............................ 39
9.5 Timing Out RTSP messages ............................ 41 9.5 Use of IPv6 ......................................... 40
9.6 Use of IPv6 ......................................... 41 10 Capability Handling ................................. 40
10 Capability Handling ................................. 42 11 Method Definitions .................................. 42
11 Method Definitions .................................. 43 11.1 OPTIONS ............................................. 43
11.1 OPTIONS ............................................. 44 11.2 DESCRIBE ............................................ 44
11.2 DESCRIBE ............................................ 45 11.3 SETUP ............................................... 46
11.3 SETUP ............................................... 47 11.4 PLAY ................................................ 49
11.4 PLAY ................................................ 50 11.5 PAUSE ............................................... 53
11.5 PAUSE ............................................... 54 11.6 TEARDOWN ............................................ 57
11.6 TEARDOWN ............................................ 58 11.7 GET_PARAMETER ....................................... 57
11.7 GET_PARAMETER ....................................... 58 11.8 SET_PARAMETER ....................................... 58
11.8 SET_PARAMETER ....................................... 59 11.9 REDIRECT ............................................ 60
11.9 REDIRECT ............................................ 61 11.10 PING ................................................ 62
11.10 PING ................................................ 63 12 Embedded (Interleaved) Binary Data .................. 63
12 Embedded (Interleaved) Binary Data .................. 64 13 Status Code Definitions ............................. 64
13 Status Code Definitions ............................. 65 13.1 Success 1xx ......................................... 64
13.1 Success 1xx ......................................... 66 13.1.1 100 Continue ........................................ 64
13.1.1 100 Continue ........................................ 66 13.2 Success 2xx ......................................... 64
13.2 Success 2xx ......................................... 66 13.3 Redirection 3xx ..................................... 65
13.3 Redirection 3xx ..................................... 66 13.3.1 300 Multiple Choices ................................ 65
13.3.1 TBW ................................................. 66 13.3.2 301 Moved Permanently ............................... 65
13.3.2 301 Moved Permanently ............................... 66 13.3.3 302 Found ........................................... 65
13.3.3 302 Found ........................................... 66 13.3.4 303 See Other ....................................... 66
13.3.4 303 See Other ....................................... 67 13.3.5 304 Not Modified .................................... 66
13.3.5 304 Not Modified .................................... 67 13.3.6 305 Use Proxy ....................................... 66
13.3.6 305 Use Proxy ....................................... 67 13.4 Client Error 4xx .................................... 66
13.4 Client Error 4xx .................................... 67 13.4.1 400 Bad Request ..................................... 66
13.4.1 400 Bad Request ..................................... 67 13.4.2 405 Method Not Allowed .............................. 66
13.4.2 405 Method Not Allowed .............................. 68 13.4.3 451 Parameter Not Understood ........................ 67
13.4.3 451 Parameter Not Understood ........................ 68 13.4.4 452 reserved ........................................ 67
13.4.4 452 reserved ........................................ 68 13.4.5 453 Not Enough Bandwidth ............................ 67
13.4.5 453 Not Enough Bandwidth ............................ 68 13.4.6 454 Session Not Found ............................... 67
13.4.6 454 Session Not Found ............................... 68 13.4.7 455 Method Not Valid in This State .................. 67
13.4.7 455 Method Not Valid in This State .................. 68 13.4.8 456 Header Field Not Valid for Resource ............. 67
13.4.8 456 Header Field Not Valid for Resource ............. 68 13.4.9 457 Invalid Range ................................... 67
13.4.9 457 Invalid Range ................................... 69 13.4.10 458 Parameter Is Read-Only .......................... 68
13.4.10 458 Parameter Is Read-Only .......................... 69 13.4.11 459 Aggregate Operation Not Allowed ................. 68
13.4.11 459 Aggregate Operation Not Allowed ................. 69 13.4.12 460 Only Aggregate Operation Allowed ................ 68
13.4.12 460 Only Aggregate Operation Allowed ................ 69 13.4.13 461 Unsupported Transport ........................... 68
13.4.13 461 Unsupported Transport ........................... 69 13.4.14 462 Destination Unreachable ......................... 68
13.4.14 462 Destination Unreachable ......................... 69 13.4.15 470 Connection Authorization Required ............... 68
13.4.15 470 Connection Authorization Required ............... 69 13.4.16 471 Connection Credentials not accepted ............. 68
13.4.16 471 Connection Credentials not accepted ............. 69 13.5 Server Error 5xx .................................... 68
13.5 Server Error 5xx .................................... 69 13.5.1 551 Option not supported ............................ 68
13.5.1 551 Option not supported ............................ 70 14 Header Field Definitions ............................ 69
14 Header Field Definitions ............................ 70 14.1 Accept .............................................. 71
14.1 Accept .............................................. 72 14.2 Accept-Credentials .................................. 71
14.2 Accept-Credentials .................................. 72 14.3 Accept-Encoding ..................................... 75
14.3 Accept-Encoding ..................................... 77 14.4 Accept-Language ..................................... 75
14.4 Accept-Language ..................................... 77 14.5 Accept-Ranges ....................................... 75
14.5 Accept-Ranges ....................................... 77 14.6 Allow ............................................... 76
14.6 Allow ............................................... 77 14.7 Authorization ....................................... 76
14.7 Authorization ....................................... 77 14.8 Bandwidth ........................................... 76
14.8 Bandwidth ........................................... 78 14.9 Blocksize ........................................... 77
14.9 Blocksize ........................................... 78 14.10 Cache-Control ....................................... 77
14.10 Cache-Control ....................................... 78 14.11 Connection .......................................... 79
14.11 Connection .......................................... 81 14.12 Connection-Credentials .............................. 79
14.12 Content-Base ........................................ 81 14.13 Content-Base ........................................ 80
14.13 Content-Encoding .................................... 81 14.14 Content-Encoding .................................... 80
14.14 Content-Language .................................... 81 14.15 Content-Language .................................... 80
14.15 Content-Length ...................................... 81 14.16 Content-Length ...................................... 80
14.16 Content-Location .................................... 81 14.17 Content-Location .................................... 80
14.17 Content-Type ........................................ 81 14.18 Content-Type ........................................ 81
14.18 CSeq ................................................ 82 14.19 CSeq ................................................ 81
14.19 Date ................................................ 82 14.20 Date ................................................ 81
14.20 ETag ................................................ 82 14.21 ETag ................................................ 81
14.21 Expires ............................................. 83 14.22 Expires ............................................. 82
14.22 From ................................................ 83 14.23 From ................................................ 83
14.23 Host ................................................ 84 14.24 Host ................................................ 83
14.24 If-Match ............................................ 84 14.25 If-Match ............................................ 83
14.25 If-Modified-Since ................................... 84 14.26 If-Modified-Since ................................... 83
14.26 If-None-Match ....................................... 84 14.27 If-None-Match ....................................... 83
14.27 Last-Modified ....................................... 85 14.28 Last-Modified ....................................... 84
14.28 Location ............................................ 85 14.29 Location ............................................ 84
14.29 Proxy-Authenticate .................................. 85 14.30 Proxy-Authenticate .................................. 84
14.30 Proxy-Require ....................................... 85 14.31 Proxy-Require ....................................... 84
14.31 Public .............................................. 85 14.32 Proxy-Supported ..................................... 84
14.32 Range ............................................... 86 14.33 Public .............................................. 85
14.33 Referer ............................................. 88 14.34 Range ............................................... 86
14.34 Retry-After ......................................... 88 14.35 Referer ............................................. 88
14.35 Require ............................................. 88 14.36 Retry-After ......................................... 88
14.36 RTP-Info ............................................ 89 14.37 Require ............................................. 88
14.37 Scale ............................................... 91 14.38 RTP-Info ............................................ 89
14.38 Speed ............................................... 92 14.39 Scale ............................................... 91
14.39 Server .............................................. 92 14.40 Speed ............................................... 92
14.40 Session ............................................. 92 14.41 Server .............................................. 92
14.41 Supported ........................................... 94 14.42 Session ............................................. 92
14.42 Timestamp ........................................... 95 14.43 Supported ........................................... 95
14.43 Transport ........................................... 95 14.44 Timestamp ........................................... 95
14.44 Unsupported ......................................... 101 14.45 Transport ........................................... 95
14.45 User-Agent .......................................... 102 14.46 Unsupported ......................................... 102
14.46 Vary ................................................ 102 14.47 User-Agent .......................................... 102
14.47 Via ................................................. 102 14.48 Vary ................................................ 102
14.48 WWW-Authenticate .................................... 102 14.49 Via ................................................. 102
14.50 WWW-Authenticate .................................... 102
15 Caching ............................................. 102 15 Caching ............................................. 102
16 Examples ............................................ 103 16 Examples ............................................ 103
16.1 Media on Demand (Unicast) ........................... 103 16.1 Media on Demand (Unicast) ........................... 103
16.2 Streaming of a Container file ....................... 106 16.2 Streaming of a Container file ....................... 106
16.3 Single Stream Container Files ....................... 109 16.3 Single Stream Container Files ....................... 109
16.4 Live Media Presentation Using Multicast ............. 111 16.4 Live Media Presentation Using Multicast ............. 111
16.5 Capability Negotiation .............................. 112 16.5 Capability Negotiation .............................. 112
17 Security Framework .................................. 113 17 Security Framework .................................. 113
17.1 RTSP and HTTP Authentication ........................ 113 17.1 RTSP and HTTP Authentication ........................ 114
17.2 RTSP over TLS ....................................... 114 17.2 RTSP over TLS ....................................... 114
17.3 Security and Proxies ................................ 114 17.3 Security and Proxies ................................ 115
17.3.1 Accept-Credentials .................................. 115 17.3.1 Accept-Credentials .................................. 116
17.3.2 User approved TLS procedure ......................... 116 17.3.2 User approved TLS procedure ......................... 117
18 Syntax .............................................. 118 18 Syntax .............................................. 118
18.1 Base Syntax ......................................... 118 18.1 Base Syntax ......................................... 118
18.2 RTSP Protocol Definition ............................ 119 18.2 RTSP Protocol Definition ............................ 119
18.2.1 Generic Protocol elements ........................... 119 18.2.1 Generic Protocol elements ........................... 119
18.2.2 Message Syntax ...................................... 120 18.2.2 Message Syntax ...................................... 120
18.2.3 Header Syntax ....................................... 124 18.2.3 Header Syntax ....................................... 124
19 Security Considerations ............................. 126 19 Security Considerations ............................. 127
20 IANA Considerations ................................. 128 20 IANA Considerations ................................. 129
20.1 Feature-tags ........................................ 129 20.1 Feature-tags ........................................ 130
20.1.1 Description ......................................... 129 20.1.1 Description ......................................... 130
20.1.2 Registering New Feature-tags with IANA .............. 129 20.1.2 Registering New Feature-tags with IANA .............. 130
20.1.3 Registered entries .................................. 130 20.1.3 Registered entries .................................. 130
20.2 RTSP Methods ........................................ 130 20.2 RTSP Methods ........................................ 130
20.2.1 Description ......................................... 130 20.2.1 Description ......................................... 130
20.2.2 Registering New Methods with IANA ................... 130 20.2.2 Registering New Methods with IANA ................... 131
20.2.3 Registered Entries .................................. 131 20.2.3 Registered Entries .................................. 131
20.3 RTSP Status Codes ................................... 131 20.3 RTSP Status Codes ................................... 131
20.3.1 Description ......................................... 131 20.3.1 Description ......................................... 131
20.3.2 Registering New Status Codes with IANA .............. 131 20.3.2 Registering New Status Codes with IANA .............. 131
20.3.3 Registered Entries .................................. 131 20.3.3 Registered Entries .................................. 132
20.4 RTSP Headers ........................................ 131 20.4 RTSP Headers ........................................ 132
20.4.1 Description ......................................... 131 20.4.1 Description ......................................... 132
20.4.2 Registering New Headers with IANA ................... 131 20.4.2 Registering New Headers with IANA ................... 132
20.4.3 Registered entries .................................. 132 20.4.3 Registered entries .................................. 132
20.5 Transport Header registries ......................... 132 20.5 Transport Header registries ......................... 133
20.5.1 Transport Protocols ................................. 132 20.5.1 Transport Protocols ................................. 133
20.5.2 Profile ............................................. 133 20.5.2 Profile ............................................. 133
20.5.3 Lower Transport ..................................... 133 20.5.3 Lower Transport ..................................... 134
20.5.4 Transport modes ..................................... 134 20.5.4 Transport modes ..................................... 134
20.6 Cache Directive Extensions .......................... 134 20.6 Cache Directive Extensions .......................... 135
20.7 Accept-Credentials policies ......................... 135 20.7 Accept-Credentials policies ......................... 135
20.8 SDP attributes ...................................... 135 20.8 URI Schemes ......................................... 136
A RTSP Protocol State Machine ......................... 136 20.9 SDP attributes ...................................... 136
A RTSP Protocol State Machine ......................... 137
A.1 States .............................................. 137 A.1 States .............................................. 137
A.2 State variables ..................................... 137 A.2 State variables ..................................... 138
A.3 Abbreviations ....................................... 137 A.3 Abbreviations ....................................... 138
A.4 State Tables ........................................ 137 A.4 State Tables ........................................ 138
B Media Transport Alternatives ........................ 141 B Media Transport Alternatives ........................ 141
B.1 RTP ................................................. 141 B.1 RTP ................................................. 142
B.1.1 AVP ................................................. 141 B.1.1 AVP ................................................. 142
B.1.2 AVP/UDP ............................................. 141 B.1.2 AVP/UDP ............................................. 142
B.1.3 AVP/TCP ............................................. 143 B.1.3 AVP/TCP ............................................. 144
B.1.4 Handling NPT Jumps in the RTP Media Layer ........... 143 B.1.4 Handling NPT Jumps in the RTP Media Layer ........... 144
B.1.5 Handling RTP Timestamps after PAUSE ................. 145 B.1.5 Handling RTP Timestamps after PAUSE ................. 147
B.1.6 RTSP / RTP Integration .............................. 148 B.1.6 RTSP / RTP Integration .............................. 149
B.1.7 Scaling with RTP .................................... 148 B.1.7 Scaling with RTP .................................... 149
B.1.8 Maintaining NPT synchronization with RTP B.1.8 Maintaining NPT synchronization with RTP
timestamps .......................................... 148 timestamps ..................................................... 150
B.1.9 Continuous Audio .................................... 148 B.1.9 Continuous Audio .................................... 150
B.1.10 Multiple Sources in an RTP Session .................. 148 B.1.10 Multiple Sources in an RTP Session .................. 150
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 an
RTSP Session ........................................ 148 RTSP Session ................................................... 150
B.2 Future Additions .................................... 149 B.2 Future Additions .................................... 151
C Use of SDP for RTSP Session Descriptions ............ 150 C Use of SDP for RTSP Session Descriptions ............ 151
C.1 Definitions ......................................... 150 C.1 Definitions ......................................... 151
C.1.1 Control URL ......................................... 150 C.1.1 Control URI ......................................... 152
C.1.2 Media Streams ....................................... 151 C.1.2 Media Streams ....................................... 153
C.1.3 Payload Type(s) ..................................... 152 C.1.3 Payload Type(s) ..................................... 153
C.1.4 Format-Specific Parameters .......................... 152 C.1.4 Format-Specific Parameters .......................... 154
C.1.5 Range of Presentation ............................... 152 C.1.5 Range of Presentation ............................... 154
C.1.6 Time of Availability ................................ 153 C.1.6 Time of Availability ................................ 154
C.1.7 Connection Information .............................. 153 C.1.7 Connection Information .............................. 155
C.1.8 Entity Tag .......................................... 153 C.1.8 Entity Tag .......................................... 155
C.2 Aggregate Control Not Available ..................... 154 C.2 Aggregate Control Not Available ..................... 156
C.3 Aggregate Control Available ......................... 155 C.3 Aggregate Control Available ......................... 156
C.4 RTSP external SDP delivery .......................... 156 C.4 RTSP external SDP delivery .......................... 157
D Minimal RTSP implementation ......................... 156 D Minimal RTSP implementation ......................... 158
D.1 Client .............................................. 156 D.1 Client .............................................. 158
D.1.1 Basic Playback ...................................... 157 D.1.1 Basic Playback ...................................... 159
D.1.2 Authentication-enabled .............................. 157 D.1.2 Authentication-enabled .............................. 159
D.2 Server .............................................. 157 D.2 Server .............................................. 159
D.2.1 Basic Playback ...................................... 158 D.2.1 Basic Playback ...................................... 160
D.2.2 Authentication-enabled .............................. 159 D.2.2 Authentication-enabled .............................. 161
E Open Issues ......................................... 159 E Requirements for Unreliable Transport of RTSP
F Changes ............................................. 160 messages ....................................................... 161
G Author Addresses .................................... 166 F Backwards Compatibility Considerations .............. 162
H Contributors ........................................ 167 F.1 Requirement on Pause before Play in Play mode ....... 162
I Acknowledgements .................................... 167 F.2 Usage of persistent connections ..................... 163
J Normative References ................................ 168 G Open Issues ......................................... 163
K Informative References .............................. 169 H Changes ............................................. 164
H.1 Issues Addressed .................................... 164
H.2 Changes made to the protocol and specification ...... 165
I Author Addresses .................................... 170
J Contributors ........................................ 171
K Acknowledgements .................................... 171
L Normative References ................................ 172
M Informative References .............................. 173
1 Introduction 1 Introduction
1.1 RTSP Specification Update 1.1 RTSP Specification Update
This document is a draft to an update of RTSP, a proposed standard | This document is a draft to an update of RTSP, a proposed standard
defined in RFC 2326 [1]. The goal the update is to progress RTSP to | defined in RFC 2326 [1]. The goal the update is to progress RTSP to
draft standard status. Many flaws have been identified in RTSP since | draft standard status. Many flaws have been identified in RTSP since
its publication. While this draft tries to address these flaws, not | its publication. While this draft tries to address these flaws, not
all known issues have been resolved. Appendix F catalogs the issues | all known issues have been resolved. Appendix H catalogs the issues
that have already been addressed. Known open issues are listed in | that have already been addressed. Known open issues are listed in
appendix E. | appendix G.
The possibility of progressing RTSP to draft standard without | The possibility of progressing RTSP to draft standard without
republishing RTSP as a proposed standard depends on the changes | republishing RTSP as a proposed standard depends on the changes
necessary to make the protocol work. | necessary to make the protocol work.
A list of bugs against the specification is 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. Input on the unresolved bugs | account when reading this specification. Input on the unresolved bugs
and other issues can be sent via e-mail to the MMUSIC WG's mailing | and other issues can be sent via e-mail to the MMUSIC WG's mailing
list mmusic@ietf.org and the authors. 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 bloat, the specification has been reduced and | attempt to prevent bloat, the specification has been reduced and
split. The content of this draft is the core specification of the split. The content of this draft is the core specification of the
protocol. It contains the general idea behind RTSP and the basic protocol. It contains the general idea behind RTSP and the basic
functionality necessary to establish an on-demand play-back session. functionality necessary to establish an on-demand play-back session.
It also contains the mechanisms for extending the protocol. Any other It also contains the mechanisms for extending the protocol. Any other
functionality will be published as extension documents. The Working | functionality will be published as extension documents. The Working
group is currently 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." [24]. with Firewalls." [23].
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 [25]. o Mute and Unmute Extension [24].
o RTSP Stream Switching [26]. o RTSP Stream Switching [25].
o Live Streaming Relays [27]. o Live Streaming Relays [26].
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 An 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 an RTSP connection in the protocol. Instead, an
RTSP server maintains a session labelled by an identifier to RTSP server maintains a session labelled by an identifier to
associate groups of media streams and their states. A RTSP session is associate groups of media streams and their states. An RTSP session
not tied to a transport-level connection such as a TCP connection. is not tied to a transport-level connection such as a TCP connection.
During a session, a client may open and close many reliable transport During a session, a client may open and close many reliable transport
connections to the server to issue RTSP requests for that session. connections to the server to issue RTSP requests for that session.
This memorandum describes the use of RTSP over a reliable connection This memorandum describes the use of RTSP over a reliable connection
based transport level protocol such as TCP. RTSP may be implemented based transport level protocol such as TCP. RTSP may be implemented
over an unreliable connectionless transport protocol such as UDP. over an unreliable connectionless transport protocol such as UDP.
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 needs to 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 in a RTSP session is defined by a | The set of streams to be controlled in an RTSP session is defined by
presentation description. This memorandum does not define a format a presentation description. This memorandum does not define a format
for the presentation description. However appendix C defines how SDP for the presentation description. However appendix C defines how SDP
[2] is used for this purpose. The streams controlled by RTSP may use [2] is used for this purpose. The streams controlled by RTSP may use
RTP [3] for their data transport, but the operation of RTSP does not RTP [3] for their data transport, but the operation of RTSP does not
depend on the transport mechanism used to carry continuous media. | depend on the transport mechanism used to carry continuous media.
RTSP is intentionally similar in syntax and operation to HTTP/1.1 [4] RTSP is intentionally similar in syntax and operation to HTTP/1.1 [4]
so that extension mechanisms to HTTP can in most cases also be added so that extension mechanisms to HTTP can in most cases also be added
to RTSP. However, RTSP differs in a number of important aspects from to RTSP. However, RTSP differs in a number of important aspects 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 An RTSP server needs to maintain state by default in almost
cases, as opposed to the stateless nature of HTTP. all cases, as opposed to the stateless nature of HTTP.
o Both a RTSP server and client can issue requests. o Both an 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
[28]. [27].
o The Request-URL always contains the absolute URL. Because of o The Request-URI always contains the absolute URI. 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
skipping to change at page 11, line 43 skipping to change at page 11, line 43
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 example distributed teaching applications. Several parties
conference may take turns "pushing the remote control in the conference may take turns "pushing the remote
buttons". control 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].
Indented and smaller-type paragraphs are used to provide background | Indented and smaller-type paragraphs are used to provide informative
and motivation. This is intended to give readers who were not | background and motivation. This is intended to give readers who were
involved with the formulation of the specification an understanding | not involved with the formulation of the specification an
of why things are the way they are in RTSP. understanding 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].
The word, unspecified, is used to indicate functionality or features | The word, "unspecified" is used to indicate functionality or features
that are not defined in this specification. Such functionality cannot | that are not defined in this specification. Such functionality cannot
be used in a standardized manner without further definition and | be used in a standardized manner without further definition and
review in an extension specification to RTSP. review in an extension specification to 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 URI: The URI used in an 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 URI 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 constitutes a presentation when played | which often constitutes a presentation when played
together. The concept of a container file is not embedded | together. The concept of a container file is not embedded
in the protocol. However, RTSP servers may offer aggregate | in the protocol. However, RTSP servers may offer aggregate
control on the media streams within these files. 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 needs to
the timing relationship that existed at the source. The reproduce the timing relationship that existed at the
most common examples of continuous media are audio and source. The most common examples of continuous media are
motion video. Continuous media can be real-time audio and motion video. Continuous media can be real-time
(interactive), where there is a "tight" timing relationship (interactive or conversational), where there is a "tight"
between source and sink, or streaming (playback), where the timing relationship between source and sink, or streaming
relationship is less strict. (playback), where the 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
skipping to change at page 13, line 44 skipping to change at page 13, line 44
This includes such things as clock rates, color tables, This includes such things as clock rates, color tables,
etc. Any transport-independent information which is etc. Any transport-independent information which is
required by a client for playback of a media stream occurs required by a client for playback of a media stream occurs
in the media 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 host or on a different | media server may reside on the same host or on a different
host from which the presentation is invoked. 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.
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 18 and transmitted over a connection or a | in Section 18 and transmitted over a connection or a
connectionless transport. 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 and described by a | client as a complete media feed and described by a
presentation description as defined below. In the RTSP | presentation description as defined below. Presentations
context, this generally implies aggregate control over the | with more than one media stream is often handled in RTSP
streams, but does not necessarily have to. under aggregate control.
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 protocol format, SDP. | session description protocol format, SDP.
Response: A RTSP response. If an HTTP response is meant, that is Response: An RTSP response. If an HTTP response is meant, that
indicated explicitly. is indicated explicitly.
Request: A RTSP request. If an HTTP request is meant, that is Request: An 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-URI: The URI used in a request to indicate the resource
on which the request shall be performed. on which the request is to be performed.
RTSP agent: Refers to either a RTSP client, a RTSP server, or a | RTSP agent: Refers to either an RTSP client, an RTSP server, or
RTSP Proxy. In this specification, there are many | an RTSP Proxy. In this specification, there are many
capabilities that are common to these three entities such | capabilities that are common to these three entities such
as the capability to send requests or receive responses. | as the capability to send requests or receive responses.
This term will be used when describing functionality that | This term will be used when describing functionality that
is applicable to all three of these entities. 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. An RTSP session is a server
it is created, maintained and destroyed by the server. It entity; it is created, maintained and destroyed by the
is established by a RTSP server upon the completion of a server. It is established by an RTSP server upon the
successful SETUP request (when 200 OK response is sent) and completion of a successful SETUP request (when 200 OK
is labelled by a session identifier at that time. The response is sent) and is labelled by a session identifier
session exists until timed out by the server or explicitly at that time. The session exists until timed out by the
removed by a TEARDOWN request. A RTSP session is a stateful | server or explicitly removed by a TEARDOWN request. An RTSP
entity; a RTSP server maintains an explicit session state session is a stateful entity; an RTSP server maintains an
machine (see Appendix A) where most state transitions are explicit session state machine (see Appendix A) where most
triggered by client requests. The existence of a session state transitions are triggered by client requests. The
implies the existence of state about the session's media existence of a session implies the existence of state about
streams and their respective transport mechanisms. A given the session's media streams and their respective transport
session can have zero or more media streams associated with mechanisms. A given session can have zero or more media
it. A RTSP server uses the session to aggregate control streams associated with it. An RTSP server uses the session
over multiple media streams. to aggregate control 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 [13]. 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 URI'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. URIs are a subset of URIs, they will be refered as URIs.
URL: Universal Resource Locator, is an URI which identifies the URI: 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.
skipping to change at page 16, line 4 skipping to change at page 16, line 6
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 [7]) 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 [8]) 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 [9]), a unreliable datagram protocol (UDP) (RFC 768 [9]) as it
reliable datagram protocol (RDP, RFC 1151, not widely used would be possible to implement application-level
[30]) as it would be possible to implement application- reliability. The use of a connectionless datagram protocol
level reliability. The use of a connectionless datagram such as UDP requires additional definition that may be
protocol such as UDP or RDP requires additional definition provided as extensions to the core RTSP specification. The
that may be provided as extensions to the core RTSP usage of the reliable stream protocol TCP (RFC 793 [10])
specification. The usage of the reliable stream protocol and secured reliable stream protocol TLS over TCP [7] is
TCP (RFC 793 [10]) is what is currently defined as what is currently defined as transport protocol of RTSP
transport protocol of RTSP messages. 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 [31] or H.323 [32] may be conference. In particular, SIP [28] or H.323 [29] 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 is required to contain at least
URL. one RTSP URI.
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
[33]) firewalls. A firewall may need to understand the [30]) 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 [34,35]) for associating labels with content. Selection [31,32]) 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 needs to 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.
An earlier requirement in RTSP was multi-client capability.
However, it was determined that a better approach was to
make sure that the protocol is easily extensible to the
multi-client scenario. Stream identifiers can be used by
several control streams, so that "passing the remote" would
be possible. The protocol would not address how several
clients negotiate access; this is left to either a "social
protocol" or some other floor control mechanism.
1.6 Extending RTSP 1.6 Extending RTSP
Since not all media servers have the same functionality, media Since not all media servers have the same functionality, media
servers by necessity will support different sets of requests. For servers by necessity will support different sets of requests. For
example: example:
o A server may not be capable of seeking (absolute positioning) o A server may not be capable of seeking (absolute positioning)
if it is to support live events only. if it is to support live events only.
o Some servers may not support setting stream parameters and o Some servers may not support setting stream parameters and
thus not support GET_PARAMETER and SET_PARAMETER. thus not support GET_PARAMETER and SET_PARAMETER.
o Some server may support an RTSP extension, for example the
currently proposed "end of stream" indication.
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. If the client needs negative acknowledgement | the recipient. 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.37).
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 to this method again. A client may also use the OPTIONS method to
inquire about methods supported by the server. The server MUST inquire about methods supported by the server. The server MUST
list the methods it supports using the Public response header. list the methods it supports using the Public response 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 section 10.
1.7 Overall Operation 1.7 Overall Operation
Each presentation and media stream is identified by an RTSP URL. The Each presentation and media stream is identified by an RTSP URI. The
overall presentation and the properties of the media the presentation overall presentation and the properties of the media the presentation
is made up of are defined by a presentation description file, the is made up of are defined by a presentation description file, the
format of which is outside the scope of this specification. The format of which is outside the scope of this specification. The
presentation description file may be obtained by the client using presentation description file may be obtained by the client using
HTTP or other means such as email and may not necessarily be stored HTTP or other means such as email and may not necessarily be stored
on the media server. on the media server.
For the purposes of this specification, a presentation description is For the purposes of this specification, a presentation description is
assumed to describe one or more presentations, each of which assumed to describe one or more presentations, each of which
maintains a common time axis. For simplicity of exposition and maintains a common time axis. For simplicity of exposition and
without loss of generality, it is assumed that the presentation without loss of generality, it is assumed that the presentation
description contains exactly one such presentation. A presentation description contains exactly one such presentation. A presentation
may contain several media streams. may contain several media streams.
The presentation description file contains a description of the media The presentation description file contains a description of the media
streams making up the presentation, including their encodings, streams making up the presentation, including their encodings,
language, and other parameters that enable the client to choose the language, and other parameters that enable the client to choose the
most appropriate combination of media. In this presentation most appropriate combination of media. In this presentation
description, each media stream that is individually controllable by description, each media stream that is individually controllable by
RTSP is identified by a RTSP URL, which points to the media server RTSP is identified by an RTSP URI, which points to the media server
handling that particular media stream and names the stream stored on handling that particular media stream and names the stream stored on
that server. Several media streams can be located on different that server. Several media streams can be located on different
servers; for example, audio and video streams can be split across servers; for example, audio and video streams can be split across
servers for load sharing. The description also enumerates which servers for load sharing. The description also enumerates which
transport methods the server is capable of. transport methods the server is capable of.
Besides the media parameters, the network destination address and Besides the media parameters, the network destination address and
port need to be determined. Several modes of operation can be port need to be determined. Several modes of operation can be
distinguished: distinguished:
skipping to change at page 19, line 13 skipping to change at page 19, line 9
reliable stream as RTSP. reliable stream as RTSP.
Multicast, server chooses address: The media server picks the Multicast, server chooses address: The media server picks the
multicast address and port. This is the typical case for a multicast address and port. This is the typical case for a
live or near-media-on-demand transmission. live or near-media-on-demand transmission.
Multicast, client chooses address: If the server is to Multicast, client chooses address: If the server is to
participate in an existing multicast conference, the participate in an existing multicast conference, the
multicast address, port and encryption key are given by the multicast address, port and encryption key are given by the
conference description, established by means outside the conference description, established by means outside the
scope of this specification. scope of this specification, for example by a SIP created
conference.
1.8 RTSP States 1.8 RTSP States
RTSP controls a stream which may be sent via a separate protocol, RTSP controls a stream which may be sent via a separate protocol,
independent of the control channel. For example, RTSP control may independent of the control channel. For example, RTSP control may be
occur on a TCP connection while the data flows via UDP. Thus, data transported on a TCP connection while the media data is conveyed via
delivery continues even if no RTSP requests are received by the media UDP. Thus, data delivery continues even if no RTSP requests are
server. Also, during its lifetime, a single media stream may be received by the media server. Also, during its lifetime, a single
controlled by RTSP requests issued sequentially on different TCP media stream may be controlled by RTSP requests issued sequentially
connections. Therefore, the server needs to maintain "session state" on different TCP connections. Therefore, the server needs to maintain
to be able to correlate RTSP requests with a stream. The state "session state" to be able to correlate RTSP requests with a stream.
transitions are described in Appendix A. The state transitions are described in Appendix A.
Many methods in RTSP do not contribute to state. However, the Many methods in RTSP do not contribute to state. However, the
following play a central role in defining the allocation and usage of following play a central role in defining the allocation and usage of
stream resources on the server: SETUP, PLAY, PAUSE, REDIRECT, PING stream resources on the server: SETUP, PLAY, PAUSE, REDIRECT, PING
and TEARDOWN. and TEARDOWN.
SETUP: Causes the server to allocate resources for a stream and SETUP: Causes the server to allocate resources for a stream and
create a RTSP session. create an RTSP session.
PLAY: Starts data transmission on a stream allocated via SETUP. PLAY: Starts data transmission on a stream allocated via SETUP.
PAUSE: Temporarily halts a stream without freeing server PAUSE: Temporarily halts a stream without freeing server
resources. resources.
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.40) to identify the RTSP session whose state is being (Section 14.42) 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 38 skipping to change at page 20, line 34
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 for RTSP. They are | This section describes some of the use cases for RTSP. They are
listed in descending order of importance in regards to ensuring that | listed in descending order of importance in regards to ensuring that
all necessary functionality is present. This specification does only | all necessary functionality is present. This specification does only
fully support usage of the two first. Also in these first two cases | fully support usage of the two first. Also in these first two cases
are there special cases that will not be supported without | are there special cases that will not be supported without
extensions, e.g. the redirection of media to another address than the | extensions, e.g. the redirection of media to another address than the
controlling entity. | controlling entity.
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 |
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. |
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 | 2.1 On-demand Playback of Stored Content
If one has an established conference or group session, it is possible | An RTSP capable server stores content suitable for being streamed to
to have a RTSP server distribute media to the whole group. The | a client. A client desiring playback of any of the stored content
transmission to the group is simplest controlled by a single | uses RTSP to set up the media transport required for the desired
participant or leader of the conference. Shared control might be | content. Then RTSP is used to initiate, halt and manipulate the
possible, but would require further investigation and possibly | transmission of the content. There are also requirement on being able
extensions. There are some protocol mechanisms missing for this | to use RTSP to carry necessary description and synchronization
scenario. | 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.
For reasonable complexity in the media transmission stage, this use | Presentation Description: The possibility to carry
case assumes that there exist either multicast or a conference focus | initialization information about the presentation
that redistribute media to all participants. | (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]. .XP 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. .XP
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. .XP Synchronization: For media transport
protocols like RTP [17] 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).
.XP 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:
In some more detail, this use case is intended to be able to handle | On-Demand content: The content available is stored at the server
the following scenario: A conference leader or participant (from here | and can be accessed at any time during a time period when
called the controller) has some pre-stored content on a RTSP server | it is intended to be available. .XP Independent sessions: A
that he likes to share with the group. The controller sets up a RTSP | server is capable of serving a number of clients
session at the streaming server for the content the controller likes | simultaneously, including from the same piece of content at
to share. The session description for the content is retrieved to the | different points in that presentations time-line. .XP
controller. The media destination for the media content is set to the | Unicast Transport: Content for each individual client is
shared multicast group or conference focus. When desired by the | transmitted to them using unicast traffic.
controller, he/she can start and stop the transmission of the media | It is also possible to redirect the media traffic to another
to the conference group. | 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.
There are several issues with this use case that is not solved by | 2.2 Unicast distribution of Live Content
this core specification for RTSP: |
o Denial of service threat, to avoid a RTSP server from being a | This use cases is not that different from the above on-demand content
unknowing participant of a denial of service attack the server | case (see section 2.1. The difference is really the restriction the
must be able to verify the destinations acceptance for the | content itself establish. Live content is continuously distributed as
media. Such a mechanism does not yet exist that can be used to | it becomes available from a source, i.e. the main difference to on-
verify the approval to received media, instead only policies | demand is that one starts distributing content before the end of it
can be used, which can be made to work in controlled | has become available to the server. In many cases the consumer of
environments. | 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.
o The problem of distributing the presentation description to | 2.3 On-demand Playback using Multicast
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 | It is possible to use RTSP to request that media is delivered to a
control of the RTSP session between the participants some | multicast group. The entity setting up the session (the controller)
support will be required by an external protocol for the | will then control when and what media that is delivered to the group.
necessary exchange of state information and possibly floor | Also this use case has some potential for denial of service attacks,
control of who is controlling the RTSP session. | 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.
So if there interest in this use case further work on the necessary | 2.4 Inviting a RTSP server into a conference
extensions has to be performed. |
2.5 Live Content using Multicast | 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:
This use case does in its simplest form not require any use of RTSP | o Denial of service threat, to avoid a RTSP server from being a
at all. This is what multicast conferences being announce with SAP | unknowing participant of a denial of service attack the server
and SDP are intended to handle. However in use cases where more | needs to be able to verify the destinations acceptance for the
advance features like access control to the multicast session is | media. Such a mechanism does not yet exist that can be used to
desired, RTSP could be used for session establishment. | verify the approval to received media, instead only policies
can be used, which can be made to work in controlled
environments. .IP o 2 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. .IP o 2 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.
A client desiring to join a live multicasted media session with | So if there interest in this use case further work on the necessary
cryptographic (encryption) access control could use RTSP in the | extensions has to be performed.
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 | 2.5 Live Content using Multicast
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 | This use case does in its simplest form do not require any use of
some extensions in relation to the server to client push mechanism. | RTSP at all. This is what multicast conferences being announce with
Here a method like ANNOUNCE might be suitable, however it will | SAP and SDP are intended to handle. However in use cases where more
require a RTSP extension to revive the method. 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 URI
The "rtsp", "rtsps" and "rtspu" schemes are used to refer to network The "rtsp", "rtsps" schemes are used to refer to network resources
resources via the RTSP protocol. This section defines the scheme- via the RTSP protocol. This section defines the scheme-specific
specific syntax and semantics for RTSP URLs. The RTSP URL is case syntax and semantics for RTSP URIs. The RTSP URI is case sensitive.
sensitive. An URI scheme "rtspu" was defined in RFC 2326 for transport of RTSP
messages over unreliable transport (UDP) and is currently deprecated
and reserved, and MUST NOT be used . See Appendix E for further
information.
Informative RTSP URL syntax: Informative RTSP URI syntax:
rtsp[u|s]://host[:port]/abspath[?query]#fragment rtsp[u|s]://host[:port]/abspath[?query]#fragment
See section 18.2.1 for the formal definition of the RTSP URL syntax. See section 18.2.1 for the formal definition of the RTSP URI syntax.
Note that fragment and query identifiers do not have a The fragment identifier is used as defined in section 4.1 of [13],
well-defined meaning at this time, i.e. their usage is i.e. the fragment is to be stripped from the URI by the requestor and
unspecified, with the interpretation left to the RTSP not included in the request. The user agent also needs to interpret
server. the value of the fragment based on the media type the request relates
to, i.e. the media type indicated in Content-Type header in the
response to DESCRIBE.
The URL scheme rtsp requires that commands are issued via a reliable | The syntax of any URI query string is unspecified and responder
protocol (within the Internet, TCP), while the scheme rtspu is | (usually the server) specific. As it is from the requestor an opaque
intended to identify RTSP over an unreliable protocol (within the | string, it needs to be handled as such.
Internet, UDP). The scheme rtsps identifies a reliable transport |
using secure transport (TLS [7]). The rtspu is not defined in this |
specification, and are for future extensions of the protocol to |
define how to use.
If the port is empty or not given, port 554 SHALL be assumed. The The URI scheme rtsp requires that commands are issued via a reliable
semantics are that the identified resource can be controlled by RTSP protocol (within the Internet, TCP), while the scheme rtsps
at the server listening for TCP (scheme "rtsp") connections or UDP identifies a reliable transport using secure transport (TLS [7]).
(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
port 322 is registered and SHALL be assumed.
The use of IP addresses in URLs SHOULD be avoided whenever possible If the no port number is provided in the URI, port number 554 SHALL
(see RFC 1924 [11]). Note: Using qualified domain names in any URL is be used. The semantics are that the identified resource can be
controlled by RTSP at the server listening for TCP (scheme "rtsp")
connections on that port of host, and the Request-URI for the
resource is rtsp_URI. For the scheme rtsps the TCP and UDP port 322
is registered and SHALL be assumed.
The use of IP addresses in URIs SHOULD be avoided whenever possible
(see RFC 1924 [11]). Note: Using qualified domain names in any URI 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 URIs using the host specification in
RFC 2732 [12]. 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 [13]). URLs may refer to a stream or an aggregate of URIs (RFC 2396 [13]). URIs 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 URI:
rtsp://media.example.com:554/twister/audiotrack rtsp://media.example.com:554/twister/audiotrack
identifies the audio stream within the presentation "twister", which identifies the audio stream within the presentation "twister", which
can be controlled via RTSP requests issued over a TCP connection to can be controlled via RTSP requests issued over a TCP connection to
port 554 of host media.example.com port 554 of host media.example.com
Also, the RTSP URL: Also, the RTSP URI:
rtsp://media.example.com:554/twister rtsp://media.example.com:554/twister
identifies the presentation "twister", which may be composed of audio identifies the presentation "twister", which may be composed of audio
and video streams. and video streams.
This does not imply a standard way to reference streams in This does not imply a standard way to reference streams in
URLs. The presentation description defines the hierarchical URIs. The presentation description defines the hierarchical
relationships in the presentation and the URLs for the relationships in the presentation and the URIs for the
individual streams. A presentation description may name a individual streams. A presentation description may name a
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 URI are opaque to the client and do
not imply any particular file system structure for the server. not imply any particular file system structure for the server.
This decoupling also allows presentation descriptions to be 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 URI.
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 19.) 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,
skipping to change at page 27, line 35 skipping to change at page 27, line 9
smpte=10:12:33:20- smpte=10:12:33:20-
smpte=10:07:33- smpte=10:07:33-
smpte=10:07:00-10:07:33:05.01 smpte=10:07:00-10:07:33:05.01
smpte-25=10:07:00-10:07:33:05.01 smpte-25=10:07:00-10:07:33:05.01
3.5 Normal Play Time 3.5 Normal Play Time
Normal play time (NPT) indicates the stream absolute position Normal play time (NPT) indicates the stream absolute position
relative to the beginning of the presentation, not to be confused relative to the beginning of the presentation, not to be confused
with the Network Time Protocol (NTP). The timestamp consists of a with the Network Time Protocol (NTP) [33]. The timestamp consists of
decimal fraction. The part left of the decimal may be expressed in a decimal fraction. The part left of the decimal may be expressed in
either seconds or hours, minutes, and seconds. The part right of the either seconds or hours, minutes, and seconds. The part right of the
decimal point measures fractions of a second. decimal point measures fractions of a second.
The beginning of a presentation corresponds to 0.0 seconds. Negative The beginning of a presentation corresponds to 0.0 seconds. Negative
values are not defined. 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 [34]: "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." [29] SMPTE time codes."
Examples: Examples:
npt=123.45-125 npt=123.45-125
npt=12:05:35.3- npt=12:05:35.3-
npt=now- npt=now-
The syntax conforms to ISO 8601. The npt-sec notation is The syntax conforms to ISO 8601 [35]. The npt-sec notation
optimized for automatic generation, the ntp-hhmmss notation is optimized for automatic generation, the ntp-hhmmss
for consumption by human readers. The "now" constant allows notation for consumption by human readers. The "now"
clients to request to receive the live feed rather than the constant allows clients to request to receive the live feed
stored or time-delayed version. This is needed since rather than the stored or time-delayed version. This is
neither absolute time nor zero time are appropriate for needed since neither absolute time nor zero time are
this case. appropriate for this case.
3.6 Absolute Time 3.6 Absolute Time
Absolute time is expressed as ISO 8601 timestamps, using UTC (GMT). Absolute time is expressed as ISO 8601 [35] timestamps, using UTC
Fractions of a second may be indicated. (GMT). Fractions of a second may be indicated.
Example for November 8, 1996 at 14h37 and 20 and a quarter seconds Example for November 8, 1996 at 14h37 and 20 and a quarter seconds
UTC: UTC:
19961108T143720.25Z 19961108T143720.25Z
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.35), Proxy-Require RTSP. These tags are used in Require (Section 14.37), Proxy-Require
(Section 14.30), Unsupported (Section 14.44), and Supported (Section (Section 14.31), Proxy-Supported (Section 14.32), Unsupported
14.41) header fields. (Section 14.46), and Supported (Section 14.43) 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 20. IANA Section 20.
The usage of feature tags are further described in section 10 that | The usage of feature tags are further described in section 10 that
deals with capability handling. | deals with capability handling.
3.8 Entity Tags | 3.8 Entity Tags
Entity tags opaque strings that are used to compare two entities from | Entity tags are opaque strings that are used to compare two entities
the same resource, for example in caches or to optimize setup after a | from the same resource, for example in caches or to optimize setup
redirect. Further explanation is present in [H3.11]. For explanation | after a redirect. Further explanation is present in [H3.11]. For
on how to compare Entity tags see [H13.3]. Entity tags can be carried | explanation on how to compare Entity tags see [H13.3]. Entity tags
in the ETag header (see section 14.20) or in SDP (see section C.1.8). | can be carried in the ETag header (see section 14.21) or in SDP (see
section C.1.8).
Entity tags are used in RTSP to make some methods conditional. The | Entity tags are used in RTSP to make some methods conditional. The
methods are made conditional through the inclusion of headers, see | methods are made conditional through the inclusion of headers, see
14.24 and 14.26. 14.25 and 14.27.
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 [14]). 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
skipping to change at page 29, line 42 skipping to change at page 29, line 12
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 [14]) 10xxxxxx. (See RFC 2279 [14])
RTSP messages can be carried over any lower-layer transport protocol
that is 8-bit clean. RTSP messages are vulnerable to bit errors and
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.
4.1 Message Types 4.1 Message Types
See [H4.1]. See [H4.1].
4.2 Message Headers 4.2 Message Headers
See [H4.2]. See [H4.2].
4.3 Message Body 4.3 Message Body
See [H4.3] See [H4.3]
skipping to change at page 30, line 25 skipping to change at page 29, line 40
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.15) is 2. If a Content-Length header field (section 14.16) 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
length, even if it is generated dynamically, making the length, even if it is generated dynamically, making the
chunked transfer encoding unnecessary. chunked transfer encoding unnecessary.
5 General Header Fields 5 General Header Fields
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
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 |
be applied to the resource, the identifier of the resource, and the |
Header Name Comment Header Name Comment
_________________________________ _________________________________
Cache-Control See section 14.10 Cache-Control See section 14.10
Connection See section 14.11 Connection See section 14.11
CSeq See section 14.18 CSeq See section 14.19
Date See section 14.19 Date See section 14.20
Supported See section 14.41 Supported See section 14.43
Timestamp See section 14.42 Timestamp See section 14.44
Via See section 14.47 Via See section 14.49
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 | 6 Request
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 | A request messages uses the format outlined below, regardless of the
characters Carriage Return (CR) and Line Feed (LF), indicates the end | direction of a request, client to server or server to client:
of the header part. Optionally a message body (entity) follows to the |
end of the message. The length of the message body is indicated | o Request line, containing the method to be applied to the
through the Content-Length entity header. resource, the identifier of the resource, and the protocol
version in use;
o zero or more Header lines, that can be of the following types:
general (Section 5), request (Section 6.2), or entity (Section
8.1);
o One empty line (CR/LF) to indicate the end of the header
section;
o Optionally a message body (entity), consisting of one or more
lines. the length of the message body in number of bytes is
indicated by 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 key information about the request:
request: What method, on what resources and using which RTSP version. What method, on what resources and using which RTSP version. The
The methods that is defined by this specification can be seen in methods that is defined by this specification can be seen in Table
Table 6.1. The resource is identified through an absolute RTSP URL 6.1. The resource is identified through an absolute RTSP URI (see
(see section 3.2. section 3.2.
<Method> SP <Request-URL> SP <RTSP-Version> CRLF <Method> SP <Request-URI> SP <RTSP-Version> CRLF
Please note: The request line's syntax can't be freely changed in | Please note: The request line's syntax can't be freely changed in
future versions of RTSP, as this line indicates the version of the | future versions of RTSP, as this line indicates the version of the
messages 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 URI (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 URI,
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.
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 The asterisk "*" in the Request-URI means that the request does not
apply to a particular resource, but to the server or proxy itself, apply to a particular resource, but to the server or proxy itself,
and is only allowed when the method used does not necessarily apply 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 URI 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 3 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
Header Defined in Section Header Defined in Section
_____________________________________ _____________________________________
Accept Section 14.1 Accept Section 14.1
Accept-Encoding Section 14.3 Accept-Encoding Section 14.3
Accept-Language Section 14.4 Accept-Language Section 14.4
Authorization Section 14.7 Authorization Section 14.7
Bandwidth Section 14.8 Bandwidth Section 14.8
Blocksize Section 14.9 Blocksize Section 14.9
From Section 14.22 From Section 14.23
If-Match Section 14.24 If-Match Section 14.25
If-Modified-Since Section 14.25 If-Modified-Since Section 14.26
If-None-Match Section 14.26 If-None-Match Section 14.27
Proxy-Require Section 14.30 Proxy-Require Section 14.31
Range Section 14.32 Range Section 14.34
Referer Section 14.33 Referer Section 14.35
Require Section 14.35 Require Section 14.37
Scale Section 14.37 Scale Section 14.39
Session Section 14.40 Session Section 14.42
Speed Section 14.38 Speed Section 14.40
Supported Section 14.41 Supported Section 14.43
Transport Section 14.43 Transport Section 14.45
User-Agent Section 14.45 User-Agent Section 14.47
Table 3: The RTSP request headers Table 3: The RTSP request headers
7 Response
[H6] applies except that HTTP-Version is replaced by RTSP-Version. [H6] applies except that HTTP-Version is replaced by RTSP-Version.
Also, RTSP defines additional status codes and does not define some Also, RTSP defines additional status codes and does not define some
HTTP codes. The valid response codes and the methods they can be used HTTP codes. The valid response codes and the methods they can be used
with are defined in Table 4. with are defined in Table 4.
After receiving and interpreting a request message, the recipient After receiving and interpreting a request message, the recipient
responds with an RTSP response message. responds with an RTSP response message.
7.1 Status-Line 7.1 Status-Line
skipping to change at page 34, line 21 skipping to change at page 33, line 38
The first digit of the Status-Code defines the class of response. The 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 last two digits do not have any categorization role. There are 5
values for the first digit: values for the first digit:
o 1xx: Informational - Request received, continuing process o 1xx: Informational - Request received, continuing process
o 2xx: Success - The action was successfully received, o 2xx: Success - The action was successfully received,
understood, and accepted understood, and accepted
o 3rr: Redirection - Further action must be taken in order to o 3rr: Redirection - Further action needs to be taken in order
complete the request to complete the request
o 4xx: Client Error - The request contains bad syntax or cannot o 4xx: Client Error - The request contains bad syntax or cannot
be fulfilled be fulfilled
o 5xx: Server Error - The server failed to fulfill an apparently o 5xx: Server Error - The server failed to fulfill an apparently
valid request valid request
The individual values of the numeric status codes defined for The individual values of the numeric status codes defined for
RTSP/1.0, and an example set of corresponding Reason-Phrase's, are RTSP/1.0, and an example set of corresponding Reason-Phrases, are
presented in table 4. The reason phrases listed here are only presented in table 4. The reason phrases listed here are only
recommended they may be replaced by local equivalents without recommended; they may be replaced by local equivalents without
affecting the protocol. Note that RTSP adopts most HTTP/1.1 [4] affecting the protocol. Note that RTSP adopts most HTTP/1.1 [4]
status codes and adds RTSP-specific status codes starting at x50 to status codes and adds RTSP-specific status codes starting at x50 to
avoid conflicts with newly defined HTTP status codes. avoid conflicts with newly defined HTTP status codes.
RTSP status codes are extensible. RTSP applications are not required RTSP status codes are extensible. RTSP applications are not required
to understand the meaning of all registered status codes, though such to understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST understanding is obviously desirable. However, applications MUST
understand the class of any status code, as indicated by the first understand the class of any status code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the digit, and treat any unrecognized response as being equivalent to the
x00 status code of that class, with the exception that an x00 status code of that class, with the exception that an
skipping to change at page 35, line 11 skipping to change at page 34, line 29
cases, user agents SHOULD present to the user the entity returned cases, user agents SHOULD present to the user the entity returned
with the response, since that entity is likely to include human- with the response, since that entity is likely to include human-
readable information which will explain the unusual status. readable information which will explain the unusual status.
7.1.2 Response Header Fields 7.1.2 Response Header Fields
The response-header fields allow the request recipient to pass The response-header fields allow the request recipient to pass
additional information about the response which cannot be placed in additional information about the response which cannot be placed in
the Status-Line. These header fields give information about the the Status-Line. These header fields give information about the
server and about further access to the resource identified by the server and about further access to the resource identified by the
Request-URL. All headers currently being classified as response Request-URI. All headers currently being classified as response
headers are listed in table 5. 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
skipping to change at page 35, line 41 skipping to change at page 35, line 14
In this section, both sender and recipient refer to either the client In this section, both sender and recipient refer to either the client
or the server, depending on who sends and who receives the entity. or the server, depending on who sends and who receives the entity.
8.1 Entity Header Fields 8.1 Entity Header Fields
Entity-header fields define optional meta-information about the Entity-header fields define optional meta-information about the
entity-body or, if no body is present, about the resource identified 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. by the request. The entity header fields are listed in table 8.1.
Header Defined in Section
____________________________________
Allow Section 14.6
Content-Base Section 14.13
Content-Encoding Section 14.14
Content-Language Section 14.15
Content-Length Section 14.16
Content-Location Section 14.17
Content-Type Section 14.18
Expires Section 14.22
Last-Modified Section 14.28
Table 6: The RTSP entity headers
The extension-header mechanism allows additional entity-header fields The extension-header mechanism allows additional entity-header fields
to be defined without changing the protocol, but these fields cannot to be defined without changing the protocol, but these fields cannot
be assumed to be recognizable by the recipient. Unrecognized header be assumed to be recognizable by the recipient. Unrecognized header
fields SHOULD be ignored by the recipient and forwarded by proxies. fields SHOULD be ignored by the recipient and forwarded by proxies.
8.2 Entity Body 8.2 Entity Body
See [H7.2] with the addition that a RTSP message with an entity body See [H7.2] with the addition that an RTSP message with an entity body
MUST include the Content-Type and Content-Length headers. MUST include the Content-Type and Content-Length headers.
9 Connections 9 Connections
RTSP requests can be transmitted in several different ways: RTSP requests can be transmitted in several different ways:
o persistent transport connections used for several request- o persistent transport connections used for several request-
response transactions; response transactions;
o one connection per request/response transaction; o one connection per request/response transaction;
o connectionless mode. o connectionless mode.
The type of transport is defined by the RTSP URL (Section 3.2). For The type of transport is defined by the RTSP URI (Section 3.2). For
the scheme "rtsp", a connection is assumed, while the scheme "rtspu" the scheme "rtsp", a connection is assumed, while the scheme "rtsps"
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
skipping to change at page 37, line 33 skipping to change at page 36, line 33
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
411 Length Required all 411 Length Required all
412 Precondition Failed DESCRIBE, SETUP 412 Precondition Failed DESCRIBE, SETUP
413 Request Entity Too Large all 413 Request Entity Too Large all
414 Request-URL Too Long all 414 Request-URI Too Long all
415 Unsupported Media Type all 415 Unsupported Media Type all
451 Parameter Not Understood SET_PARAMETER 451 Parameter Not Understood SET_PARAMETER
452 reserved n/a 452 reserved n/a
453 Not Enough Bandwidth SETUP 453 Not Enough Bandwidth SETUP
454 Session Not Found all 454 Session Not Found all
455 Method Not Valid In This State all 455 Method Not Valid In This State all
456 Header Field Not Valid all 456 Header Field Not Valid 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
skipping to change at page 38, line 7 skipping to change at page 37, line 7
__________________________________________________________ __________________________________________________________
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
Header Defined in Section Header Defined in Section
______________________________________ __________________________________________
Accept-Ranges Section 14.5 Accept-Ranges Section 14.5
ETag Section 14.20 Connection-Credentials Section 14.12
Location Section 14.28 ETag Section 14.21
Proxy-Authenticate Section 14.29 Location Section 14.29
Public Section 14.31 Proxy-Authenticate Section 14.30
Range Section 14.32 Public Section 14.33
Retry-After Section 14.34 Range Section 14.34
RTP-Info Section 14.36 Retry-After Section 14.36
Scale Section 14.37 RTP-Info Section 14.38
Session Section 14.40 Scale Section 14.39
Server Section 14.39 Session Section 14.42
Speed Section 14.38 Server Section 14.41
Transport Section 14.43 Speed Section 14.40
Unsupported Section 14.44 Transport Section 14.45
Vary Section 14.46 Unsupported Section 14.46
WWW-Authenticate Section 14.48 Vary Section 14.48
WWW-Authenticate Section 14.50
Table 5: The RTSP response headers Table 5: The RTSP response headers
Header Defined in Section calls for RTSP requests to be sent using a secure protocol.
____________________________________ Unlike HTTP, RTSP allows the media server to send requests to the
Allow Section 14.6 media client. However, this is only supported for persistent
Content-Base Section 14.12 connections, as the media server otherwise has no reliable way of
Content-Encoding Section 14.13 reaching the client. Also, this is the only way that requests from
Content-Language Section 14.14 media server to client are likely to traverse firewalls.
Content-Length Section 14.15
Content-Location Section 14.16
Content-Type Section 14.17
Expires Section 14.21
Last-Modified Section 14.27
Table 6: The RTSP entity headers 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 sufficient for
interoperable implementations. Due to lack of interest, this
specification does not specify how RTSP over UDP is implemented.
However to maintain backwards compatibility in the message format
certain RTSP headers are maintained.
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.18), which MUST be incremented by one for each distinct request 14.19), 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 The usage of connections
This section provides some information to future specification of
RTSP over unreliable transport.
Requests shall be acknowledged by the receiver. If there is no
acknowledgement, the sender may resend the same message after a
timeout of one round-trip time (RTT). The round-trip time is
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
the initial value for future connections.
If RTSP is used over a small-RTT LAN, standard procedures for
optimizing initial TCP round trip estimates, such as those used in
T/TCP (RFC 1644) [36], can be beneficial.
The Timestamp header (Section 14.42) is used to avoid the
retransmission ambiguity problem [37] and obviates the need for
Karn's algorithm.
If a request is repeated because of lack of acknowledgement, the
request must carry the original sequence number (i.e., the sequence
number is not incremented).
A number of RTSP messages destined for the same control end point may
be packed into a single lower-layer PDU.
The default port for the RTSP server is 554 for UDP.
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.
skipping to change at page 40, line 44 skipping to change at page 39, line 31
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 A Client is strongly RECOMMENDED to use persistent connections as it
requires the client to use persistent connection. The client closing allows the server to send request to the client. In cases where no
the connection may result in that the server removes the session. To connection exist between the server and the client, this may cause
achieve interoperability with old servers any client is strongly the server to be forced to drop the RTSP session without notifying
RECOMMENDED to use persistent connections. the client why, due to the lack of signalling channel. An example of
such a case is when the server desires to send a REDIRECT request for
A Client is also strongly RECOMMENDED to use persistent connections an RTSP session to the client.
as it allows the server to send request to the client. In cases
where no connection exist between the server and the client, this may
cause the server to be forced to drop the RTSP session without
notifying the client why, due to the lack of signalling channel. An
example of such a case is when the server desires to send a REDIRECT
request for a RTSP session to the client.
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.4 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
skipping to change at page 41, line 45 skipping to change at page 40, line 27
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.42) in any RTSP request. Timestamp header (section 14.44) in any RTSP request.
9.6 Use of IPv6 9.5 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 URI pointing at a IPv6 host
use fully qualified domain name and not a IPv6 address. Further the needs to use fully qualified domain name and not an IPv6 address.
Transport header must not use the parameters source and destination. Further the Transport header can not use the parameters source and
destination.
Implementations according to this specification MUST understand IPv6 Implementations according to this specification MUST understand IPv6
addresses in URLs, and headers. By this requirement the feature-tag addresses in URIs, and headers. By this requirement the feature-tag
"play.basic" can be used to determine that a server or client is "play.basic" can be used to determine that a server or client is
capable of handling IPv6 within RTSP. capable of handling IPv6 within RTSP.
10 Capability Handling 10 Capability Handling
This chapter describes the capability handling mechanism available in This section describes the capability handling mechanism available in
RTSP which allows RTSP to be extended. Extensions to this version of RTSP which allows RTSP to be extended. Extensions to this version of
the protocol are basically done in two ways. First, new headers can the protocol are basically done in two ways. First, new headers can
be added. Secondly, new methods can be added. The capability handling be added. Secondly, new methods can be added. The capability handling
mechanism is designed to handle these two cases. mechanism is designed to handle both cases.
When a method is added the involved parties can use the OPTIONS When a method is added, the involved parties can use the OPTIONS
method to discover if it is supported. This is done by issuing a method to discover wether it is supported. This is done by issuing a
OPTIONS request to the other party. Depending on the URL it will OPTIONS request to the other party. Depending on the URI it will
either apply in regards to a certain media resource, the whole server either apply in regards to a certain media resource, the whole server
in general, or simply the next hop. The OPTIONS response will contain in general, or simply the next hop. The OPTIONS response will contain
a Public header which declares all methods supported for the a Public header which declares all methods supported for the
indicated resource. indicated resource.
It is not necessary to use OPTIONS to discover support of a method, It is not necessary to use OPTIONS to discover support of a method,
the client could simply try the method. If the receiver of the the client could simply try the method. If the receiver of the
request does not support the method it will respond with an error request does not support the method it will respond with an error
code indicating the the method is either not implemented (501) or code indicating the the method is either not implemented (501) or
does not apply for the resource (405). The choice between the two does not apply for the resource (405). The choice between the two
discovery methods depends on the requirements of the service. discovery methods depends on the requirements of the service.
To handle functionality additions that are not new methods feature- Feature-Tags are defined to handle functionality additions that are
tags are defined. Each feature-tag represents a certain block of not new methods. Each feature-tag represents a certain block of
functionality. The amount of functionality that a feature-tag functionality. The amount of functionality that a feature-tag
represents can vary significantly. A simple feature-tag can simple represents can vary significantly. A feature-tag can for example
represent the functionality a single header gives. Another feature- represent the functionality a single RTSP header provides. Another
tag is "play.basic" which represents the minimal playback feature-tag can represent much more functionality, such as the
"play.basic" feature tag which represents the minimal playback
implementation according to the updated specification. implementation according to the updated specification.
The feature-tags are then used to determine if the client, server or Feature-tags are used to determine wether the client, server or proxy
proxy supports the functionality that is necessary to achieve the supports the functionality that is necessary to achieve the desired
desired service. To determine support of a feature-tag several service. To determine support of a feature-tag, several different
different headers can be used, each explained below: headers can be used, each explained below:
Supported: The supported header is used to determine the Supported: The supported header is used to determine the
complete set of functionality that both client and server complete set of functionality that both client and server
has. The intended usage is to determine before one needs to have. The intended usage is to determine before one needs
use a functionality that it is supported. It can be used in to use a functionality that it is supported. It can be used
any method however OPTIONS is the most suitable as one at in any method, however OPTIONS is the most suitable one as
the same time determines all methods that are implemented. it at the same time determines all methods that are
When sending a request the requestor declares all its implemented. When sending a request the requestor declares
capabilities by including all supported feature-tags. This all its capabilities by including all supported feature-
results in that the receiver learns the requestors feature tags. This results in that the receiver learns the
support. The receiver then includes its set of features in requestors feature support. The receiver then includes its
the response. set of features in the response.
Proxy-Supported: The Proxy-Supported header is used similar to
the Supported header, but instead of giving the supported
functionality of the client or server it provides both the
requestor and the responder a view of what functionality
the proxy chain between the two supports. Proxies are
required to add this header whenever the Supported header
is present, but proxies may independently of the requestor
add it.
Require: The Require header can be included in any request where Require: The Require header can be included in any request where
the end point, i.e. the client or server, is required to the end-point, i.e. the client or server, is required to
understand the feature to correctly perform the request. understand the feature to correctly perform the request.
This can for example be a SETUP request where the server This can, for example, be a SETUP request where the server
must understand a certain parameter to be able to set up is required to understand a certain parameter to be able to
the media delivery correctly. Ignoring this parameter would set up the media delivery correctly. Ignoring this
not have the desired effect and is not acceptable. parameter would not have the desired effect and is not
Therefore the end-point receiving a request containing a acceptable. Therefore the end-point receiving a request
Require must negatively acknowledge any feature that it containing a Require MUST negatively acknowledge any
does not understand and not perform the request. The feature that it does not understand and not perform the
response in cases where features are not understood are 551 request. The response in cases where features are not
(Option Not Supported). Also the features that are not supported are 551 (Option Not Supported). Also the
understood are given in the Unsupported header in the features that are not supported are given in the
response. Unsupported header in the response.
Proxy-Require: This method has the same purpose and workings as Proxy-Require: This method has the same purpose and workings as
Require except that it only applies to proxies and not the Require except that it only applies to proxies and not the
end point. Features that needs to be supported by both end-point. Features that needs to be supported by both
proxies and end-point needs to be included in both the proxies and end-point needs to be included in both the
Require and Proxy-Require header. Require and Proxy-Require header.
Unsupported: This header is used in 551 error response to tell Unsupported: This header is used in a 551 error response, to
which feature(s) that was not supported. Such a response is indicate which feature(s) that was not supported. Such a
only the result of the usage of the Require and/or Proxy- response is only the result of the usage of the Require
Require header where one or more feature where not and/or Proxy-Require header where one or more feature where
supported. This information allows the requestor to make not supported. This information allows the requestor to
the best of situations as it knows which features that was make the best of situations as it knows which features are
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-URI. 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 SHALL NOT
with a $ character (decimal 24) and must be a token as defined by the start with a $ character (decimal 24) and MUST be a token as defined
ABNF. Methods are summarized in Table 11. by the ABNF [5]. Methods are summarized in Table 7.
Note on Table 7: PAUSE is recommended, but not required.
For example, a fully functional server can be built to
deliver live feeds, which do not support this method.
If an RTSP agent does not support a particular method, it MUST return
501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD
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=Respond, | (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
Notes on Table 11: PAUSE is recommended, but not required. For | NOT try this method again for the given agent / resource combination.
example, a fully functional server can be built to deliver live feeds |
that does not support this method. If a RTSP agent does not support a |
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 semantics of the RTSP OPTIONS method is equivalent to that of the | The semantics of the RTSP OPTIONS method is equivalent to that of the
HTTP OPTIONS method described in [H9.2]. In, RTSP, however, OPTIONS | HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is
is bi-directional, where a client can request it to a server and vice | bi-directional, in that a client can request it to a server and vice
versa. A client MUST implement the capability to send an OPTIONS | versa. A client MUST implement the capability to send an OPTIONS
request and a server or a proxy MUST implement the capability to | request and a server or a proxy MUST implement the capability to
respond to an OPTIONS request. The client, server or proxy MAY also | respond to an OPTIONS request. The client, server or proxy MAY also
implement the converse of their required capability. | implement the converse of their required capability.
An OPTIONS request may be issued at any time. Such a request does not | An OPTIONS request may be issued at any time. Such a request does not
modify the session state. However, it may prolong the session | modify the session state. However, it may prolong the session
lifespan (see below). The URL in an OPTIONS request determines the | lifespan (see below). The URI in an OPTIONS request determines the
scope of the request and the corresponding response. If the request | scope of the request and the corresponding response. If the Request-
URL refers to a specific media resource on a given host, the scope is | URI refers to a specific media resource on a given host, the scope is
limited to the set of methods supported for that media resource by | limited to the set of methods supported for that media resource by
the indicated RTSP agent. A request URL with only the host address | the indicated RTSP agent. A Request-URI with only the host address
limits the scope to the specified RTSP agent's general capabilities | limits the scope to the specified RTSP agent's general capabilities
without regard to any specific media. If the request URL is an | without regard to any specific media. If the Request-URI is an
asterisk ("*"), the scope is limited to the general capabilities of | asterisk ("*"), the scope is limited to the general capabilities of
the next hop (i.e. the RTSP agent in direct communication with the | the next hop (i.e. the RTSP agent in direct communication with the
request sender). | request sender).
Regardless of scope of the request, the Public header MUST always be |
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 to keep an RTSP session alive. | Regardless of scope of the request, the Public header MUST always be
However, it is not the preferred means of session keep-alive | included in the OPTIONS response listing the methods that are
signalling, see section 14.40. An OPTIONS request intended for | supported by the responding RTSP agent. In addition, if the scope of
keeping alive a RTSP session MUST include the Session header with the | the request is limited to a media resource, the Allow header MAY be
associated session ID. Such a request SHOULD also use the media or | included in the response to enumerate the set of methods that are
the aggregated control URL as the request URL. 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 to keep an RTSP session alive.
However, it is not the preferred means of session keep-alive
signalling, see section 14.42. An OPTIONS request intended for
keeping alive an RTSP session MUST include the Session header with
the associated session ID. Such a request SHOULD also use the media
or the aggregated control URI as the Request-URI.
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
skipping to change at page 45, line 43 skipping to change at page 44, line 38
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 is used to retrieve the description of a | The DESCRIBE method is used to retrieve the description of a
presentation or media object from a server. The request URL of the | presentation or media object from a server. The Request-URI of the
DESCRIBE request identifies the media resource of interest. The | DESCRIBE request identifies the media resource of interest. The
client MAY include the Accept header in the request to list the | client MAY include the Accept header in the request to list the
description formats that it understands. The server SHALL respond | description formats that it understands. The server SHALL respond
with a description of the requested resource and return the | with a description of the requested resource and return the
description in the entity of the response. The DESCRIBE reply- description in the entity of the response. The DESCRIBE reply-
response pair constitutes the media initialization phase of RTSP. 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
skipping to change at page 46, line 36 skipping to change at page 45, line 32
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. Servers SHOULD NOT | information for the resource(s) that it describes. Servers SHOULD NOT
use the DESCRIBE response as a means of media indirection. | use the DESCRIBE response as a means of media indirection.
By forcing a DESCRIBE response to contain all media |
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. |
Media initialization is a requirement for any RTSP-based system, but | By forcing a DESCRIBE response to contain all media
the RTSP specification does not dictate that this must be done via | initialization for the set of streams that it describes,
the DESCRIBE method. There are four ways that an RTSP client may | and discouraging the use of DESCRIBE for media indirection,
receive initialization information: | any looping problems can be avoided that might have
resulted from other approaches.
o via a RTSP DESCRIBE method | Media initialization is a requirement for any RTSP-based system, but
the RTSP specification does not dictate that this is required to be
done via the DESCRIBE method. There are three ways that an RTSP
client may receive initialization information:
o via some other protocol (HTTP, email attachment, etc.) | o via an RTSP DESCRIBE method
o via the command line or standard input | o via some other protocol (HTTP, email attachment, etc.)
o via some form of a user interface
If a client obtains a valid description from an alternate source, the If a client obtains a valid description from an alternate source, the
client MAY use this description for initialization purposes without client MAY use this description for initialization purposes without
issuing a DESCRIBE request for the same media. issuing a DESCRIBE request for the same media.
It is RECOMMENDED that minimal servers support the DESCRIBE method, It is RECOMMENDED that minimal servers support the DESCRIBE method,
and highly recommended that minimal clients support the ability to | and highly recommended that minimal clients support the ability to
act as "helper applications" that accept a media initialization file | act as "helper applications" that accept a media initialization file
from standard input, command line, and/or other means that are | from a user interface, and/or other means that are appropriate to the
appropriate to the operating environment of the clients. 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 an URI specifies the transport mechanism to be
used for the streamed media. The SETUP method may be used in three | used for the streamed media. The SETUP method may be used in three
different cases; Create a RTSP session, add a media to a session, and | different cases; Create an RTSP session, add a media to a session,
change the transport parameters of already set up media stream. Using | and change the transport parameters of already set up media stream.
SETUP to create or add media to a session when in PLAY state is | When in PLAY state, using SETUP to create or add media to a session
unspecified. Otherwise SETUP can be used in all three states; INIT, | when in PLAY state is unspecified. Otherwise SETUP can be used in all
and READY, for both purposes and in PLAY to change the transport | three states; INIT, and READY, for both purposes and in PLAY to
parameters. change the transport parameters.
The Transport header, see section 14.43, specifies the transport The Transport header, see section 14.45, 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 such as firewalls, or NATs.
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
skipping to change at page 48, line 29 skipping to change at page 47, line 21
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;timeout=60 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 wants to create an RTSP session
containing the media resource "rtsp://example.com/foo/bar/baz.rm". containing the media resource "rtsp://example.com/foo/bar/baz.rm".
The transport parameters acceptable to the client is either 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
received RTP and RTCP from, and the RTP SSRC that will be used by the received RTP and RTCP from, and the RTP SSRC that will be used by the
server. server.
The server MUST generate a session identifier in response to a The server MUST generate a session identifier in response to a
successful SETUP request, unless a SETUP request to a server includes successful SETUP request, unless a SETUP request to a server includes
a session identifier, in which case the server MUST bundle this setup a session identifier, in which case the server MUST bundle this setup
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 URI MUST be used to control an aggregated
session. This URL MUST be different from the stream control URLs of session. This URI MUST be different from the stream control URIs 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 URI 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 URI 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 URI 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 URI
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 URI enables the resource in question to
be easily identified. The Aggregate control URL is also be easily identified. The Aggregate control URI 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 URI 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(s) within a
timeout period. The default timeout value is 60 seconds; the server certain timeout period. The default timeout value is 60 seconds; the
MAY set this to a different value and indicate so in the timeout server MAY set this to a different value and indicate so in the
field of the Session header in the SETUP response. For further timeout field of the Session header in the SETUP response. For
discussion see chapter 14.40. Signs of liveness for a RTSP session further discussion see section 14.42. Signs of liveness for an RTSP
are: session are:
o Any RTSP request from a client which includes a Session header o Any RTSP request from a client(s) which includes a Session
with that session's ID. header 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(s)
any of the media streams in that RTSP session. for any of the media streams in that RTSP session. RTCP Sender
Reports may for example be received in sessions where the
server is invited into a conference session and is as valid
for keep-alive.
If a SETUP request on a session fails for any reason, the session If a SETUP request on a session fails for any reason, the session
state, as well as transport and other parameters for associated state, as well as transport and other parameters for associated
streams SHALL remain unchanged from their values as if the SETUP streams SHALL remain unchanged from their values as if the SETUP
request had never been received by the server. request had never been received by the server.
A client MAY issue a SETUP request for a stream that is already set A client MAY issue a SETUP request for a stream that is already set
up or playing in the session to change transport parameters, which a up or playing in the session to change transport parameters, which a
server MAY allow. If it does not allow this, it MUST respond with server MAY allow. If it does not allow this, it MUST respond with
error 455 (Method Not Valid In This State). Reasons to support error 455 (Method Not Valid In This State). Reasons to support
changing transport parameters, is to allow for application layer changing transport parameters, is to allow for application layer
mobility and flexibility to utilize the best available transport as mobility and flexibility to utilize the best available transport as
it becomes available. it becomes available.
In a SETUP response for a request to change the transport parameters In a SETUP response for a request to change the transport parameters
while in Play state, the server SHOULD include the Range to indicate while in Play state, the server SHOULD include the Range to indicate
from what point the new transport parameters are used. Further if RTP from what point the new transport parameters are used. Further, if
is used for delivery the server SHOULD also include the RTP-Info RTP is used for delivery, the server SHOULD also include the RTP-Info
header to indicate from what timestamp and RTP sequence number the header to indicate from what timestamp and RTP sequence number the
change has taken place. If both RTP-Info and Range is included in the change has taken place. If both RTP-Info and Range is included in the
response the "rtp_time" parameter and range MUST be for the response the "rtp_time" parameter and range MUST be for the
corresponding time, i.e. be used in the same way as for PLAY to corresponding time, i.e. be used in the same way as for PLAY to
ensure the correct synchronization information is present. ensure the correct synchronization information is available.
If the transport parameter change while in PLAY state results in a If the transport parameters change while in PLAY state results in a
change of synchronization related information, for example changing change of synchronization related information, for example changing
RTP SSRC, the server MUST provide in the SETUP response the necessary RTP SSRC, the server MUST provide in the SETUP response the necessary
synchronization information. However the server is RECOMMENDED to synchronization information. However the server is RECOMMENDED to
avoid changing the synchronization information if possible. avoid changing the synchronization information if possible.
11.4 PLAY 11.4 PLAY
The PLAY method tells the server to start sending data via the The PLAY method tells the server to start sending data via the
mechanism specified in SETUP. A client MUST NOT issue a PLAY request mechanism specified in SETUP. A client MUST NOT issue a PLAY request
until any outstanding SETUP requests have been acknowledged as until any outstanding SETUP requests have been acknowledged as
successful. PLAY requests are valid when the session is in READY successful. PLAY requests are valid when the session is in READY
state; the use of PLAY requests when the session is in PLAY state is state; the use of PLAY requests when the session is in PLAY state is
deprecated. A PLAY request MUST include a Session header to indicate deprecated. A PLAY request MUST include a Session header to indicate
which session the request applies to. which session the request applies to.
In an aggregated session the PLAY request MUST contain an aggregated In an aggregated session the PLAY request MUST contain an aggregated
control URL. A server SHALL responde with error 460 (Only Aggregate control URI. A server SHALL responde with error 460 (Only Aggregate
Operation Allowed) if the client PLAY request URL is for one of the Operation Allowed) if the client PLAY Request-URI is for one of the
media. The media in an aggregate SHALL be played in sync. If a client media. The media in an aggregate SHALL be played in sync. If a client
want individual control of the media it must use separate RTSP want individual control of the media it needs to use separate RTSP
sessions for each media. sessions for each media.
The PLAY request SHALL position the normal play time to the beginning The PLAY request SHALL position the normal play time to the beginning
of the range specified by the Range header and delivers stream data of the range specified by the Range header and delivers stream data
until the end of the range if given, else to the end of the media is until the end of the range if given, else to the end of the media is
reached. To allow for precise composition multiple ranges MAY be reached. To allow for precise composition multiple ranges MAY be
specified in one PLAY Request. The range values are valid if all specified in one PLAY Request. The range values are valid if all
given ranges are part of any media within the aggregate. If a given given ranges are part of any media within the aggregate. If a given
range value points outside of the media, the response SHALL be the range value points outside of the media, the response SHALL be the
457 (Invalid Range) error code. 457 (Invalid Range) error code.
skipping to change at page 51, line 34 skipping to change at page 50, line 32
Range header MUST indicate a valid time. It is RECOMMENDED that Range header MUST indicate a valid time. It is RECOMMENDED that
normal play time is used, either the "now" indicator, for example normal play time is used, either the "now" indicator, for example
"npt=now-", or the time since session start as an open interval, e.g. "npt=now-", or the time since session start as an open interval, e.g.
"npt=96.23-". An absolute time value (clock) for the corresponding "npt=96.23-". An absolute time value (clock) for the corresponding
time MAY be given, i.e. "clock=20030213T143205Z-". The UTC clock 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 an on-demand stream, the server MUST reply with the actual range
that will be played back, i.e. for which duration all media having | that will be played back, i.e. for which duration any media (having
content at this time is delivered. This may differ from the requested | content at this time) is delivered. This may differ from the
range if alignment of the requested range to valid frame boundaries | requested range if alignment of the requested range to valid frame
is required for the media source. Note that some media streams in an | boundaries is required for the media source. Note that some media
aggregate may need to be delivered from even earlier points. Also | streams in an aggregate may need to be delivered from even earlier
some media format has very long duration per individual data unit, | points. Also, some media format have a very long duration per
therefore it might be necessary for the client to parse the data | individual data unit, therefore it might be necessary for the client
unit, and select where to start. | to parse the data unit, and select where to start.
Example: Single audio stream (MIDI) | Example: Single audio stream (MIDI)
C->S: PLAY rtsp://example.com/audio RTSP/1.0 | C->S: PLAY rtsp://example.com/audio RTSP/1.0
CSeq: 836 | CSeq: 836
Session: 12345678 | Session: 12345678
Range: npt=7.05- | Range: npt=7.05-
S->C: RTSP/1.0 200 OK | S->C: RTSP/1.0 200 OK
CSeq: 836 | CSeq: 836
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: npt=3.52- | Range: npt=3.52-
RTP-Info:url=rtsp://example.com/audio; | RTP-Info:url=rtsp://example.com/audio;
seq=14783;rtptime=2345962545 | seq=14783;rtptime=2345962545
S->C: RTP Packet TS=2345962545 => NPT=3.52 | S->C: RTP Packet TS=2345962545 => NPT=3.52
Duration: 4.15 seconds | Duration: 4.15 seconds
In this example the client receives the first media packet that | In this example the client receives the first media packet that
stretches all the way up and past the requested playtime. Thus it is | 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 | the client's decision if to render to the user the time between 3.52
between 3.52 and 7.05 that the user requested. In most cases it is | and 7.05, or to skip it. In most cases it is probably most suitable
probably suitable to not render that time period. | to not render that time period.
For live media sources it might be impossible to specify from which | For live media sources it might be impossible to specify from which
point in time all media streams that has active content can actually | point in time all media streams carrying active content can actually
be delivered. Therefore a server MAY specify a start time (or now-) | 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. 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 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 still be returned in the reply. If the medias that are part of an
aggregate has different lengths, the PLAY request SHALL be performed aggregate has different lengths, the PLAY request SHALL be performed
as long as the given range is valid for any media, for example the 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 longest media. Media will be sent whenever it is available for the
given play-out point. given play-out point.
A PLAY response MAY include a header(s) carrying synchronization | A PLAY response MAY include a header(s) carrying synchronization
information. As the information necessary is dependent on the media | information. As the information necessary is dependent on the media
transport format, further rules specifying the header and its usage | transport format, further rules specifying the header and its usage
is needed. For RTP the RTP-Info header is specified, see section | is needed. For RTP the RTP-Info header is specified, see section
14.36. 14.38.
After playing the desired range, the presentation is NOT After playing the desired range, the presentation is NOT
automatically paused, media delivery simply stops. A PAUSE request automatically paused, media delivery simply stops. A PAUSE request
MUST be issued before another PLAY request can be issued. Note: This MUST be issued before another PLAY request can be issued.
is one change resulting in a non-operability with RFC 2326
implementations. A client not issuing a PAUSE request before a new Note: The above is a change resulting in a non-operability
PLAY will be stuck in PLAY state. To mitigate this backwards with RFC 2326 implementations. See Appendix F.1
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.
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
skipping to change at page 54, line 14 skipping to change at page 53, line 8
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 respond 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 deprecated. 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
The PAUSE request causes the stream delivery to be interrupted The PAUSE request causes the stream delivery to be interrupted
(halted) temporarily. A PAUSE request MUST be done with the (halted) temporarily. A PAUSE request MUST be done with the
aggregated control URL for aggregated sessions, resulting in all aggregated control URI for aggregated sessions, resulting in all
media being halted, or the media URL for non-aggregated sessions. media being halted, or the media URI for non-aggregated sessions.
Any attempt to do muting of a single media with an PAUSE request in Any attempt to do muting of a single media with an PAUSE request in
an aggregated session SHALL be responded with error 460 (Only an aggregated session SHALL be responded with error 460 (Only
Aggregate Operation Allowed). After resuming playback, Aggregate Operation Allowed). After resuming playback,
synchronization of the tracks MUST be maintained. Any server synchronization of the tracks MUST be maintained. Any server
resources are kept, though servers MAY close the session and free resources are kept, though servers MAY close the session and free
resources after being paused for the duration specified with the resources after being paused for the duration specified with the
timeout parameter of the Session header in the SETUP message. timeout parameter of the Session header in the SETUP message.
Example: Example:
skipping to change at page 55, line 4 skipping to change at page 53, line 42
Example: Example:
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
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Range: npt=45.76- Range: npt=45.76-
The PAUSE request MAY contain a Range header specifying when the The PAUSE request MAY contain a Range header specifying when the
stream or presentation is to be halted. We refer to this point as the stream or presentation is to be halted. This point is referred to as
"pause point". The time parameter in the Range MUST NOT be used. The the "pause point". The time parameter in the Range MUST NOT be used.
Range header MUST contain a single value, expressed as the beginning The Range header MUST contain a single value, expressed as the
value an open range. For example, the following clip will be played beginning value an open range. For example, the following clip will
from 10 seconds through 21 seconds of the clip's normal play time, be played from 10 seconds through 21 seconds of the clip's normal
under the assumption that the PAUSE request reaches the server within play time, under the assumption that the PAUSE request reaches the
11 seconds of the PLAY request. Note that some lines has been broken server within 11 seconds of the PLAY request. Note that some lines
in an non-correct way to fit the page: has been broken in an non-correct way to fit the page:
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/1.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
Range: npt=10-30 Range: npt=10-30
S->C: RTSP/1.0 200 OK S->C: RTSP/1.0 200 OK
CSeq: 834 CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
skipping to change at page 56, line 31 skipping to change at page 55, line 24
and servers implementing according to RFC 2326 will probably not and servers implementing according to RFC 2326 will probably not
return the range header. return the range header.
For example, if the server have a play request for ranges 10 to 15 For example, if the server have a play request for ranges 10 to 15
and 20 to 29 pending and then receives a pause request for NPT 21, it and 20 to 29 pending and then receives a pause request for NPT 21, it
would start playing the second range and stop at NPT 21. If the pause would start playing the second range and stop at NPT 21. If the pause
request is for NPT 12 and the server is playing at NPT 13 serving the request is for NPT 12 and the server is playing at NPT 13 serving the
first play request, the server stops immediately. If the pause first play request, the server stops immediately. If the pause
request is for NPT 16, the server returns a 457 error message. To request is for NPT 16, the server returns a 457 error message. To
prevent that the second range is played and the server stops after prevent that the second range is played and the server stops after
completing the first range, a PAUSE request for 20 must be issued. completing the first range, a PAUSE request for NPT 20 needs to be
issued.
As another example, if a server has received requests to play ranges As another example, if a server has received requests to play ranges
10 to 15 and then 13 to 20 (that is, overlapping ranges), the PAUSE 10 to 15 and then 13 to 20 (that is, overlapping ranges), the PAUSE
request for NPT=14 would take effect while the server plays the first request for NPT=14 would take effect while the server plays the first
range, with the second range effectively being ignored, assuming the range, with the second range effectively being ignored, assuming the
PAUSE request arrives before the server has started playing the PAUSE request arrives before the server has started playing the
second, overlapping range. Regardless of when the PAUSE request second, overlapping range. Regardless of when the PAUSE request
arrives, it sets the pause point to 14. The below example messages is arrives, it sets the pause point to 14. The below example messages is
for the above case when the PAUSE request arrives before the first for the above case when the PAUSE request arrives before the first
occurrence of NPT=14. occurrence of NPT=14.
skipping to change at page 58, line 11 skipping to change at page 57, line 8
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 URI, freeing the resources associated with it. A TEARDOWN
MAY be done using either an aggregated or a media control URL. request MAY be performed on either an aggregated or a media control
However some restrictions apply depending on the current state. The URI. However some restrictions apply depending on the current state.
TEARDOWN request SHALL contain a Session header indicating what The 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 URI or the media URI 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 URI in an aggregated session MAY only be
done in Ready state. Such a request only removes the indicated media | done in Ready state. Such a request only removes the indicated media
stream and associated resources from the session. This may result in | stream and associated resources from the session. This may result in
that a session returns to non-aggregated control, due to that it only | that a session returns to non-aggregated control, due to that it only
contains a single media after the requests completion. In the | contains a single media after the requests completion. A session that
response to TEARDOWN request resulting in that the session still | will exist after the processing of the TEARDOWN request SHALL in the
exist SHALL contain a Session header to indicate this. response to that TEARDOWN request contain a Session header. Thus the
presence of the Session indicates to the receiver of the response if
the session is still existing or has been removed.
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
skipping to change at page 59, line 4 skipping to change at page 57, line 45
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 The GET_PARAMETER request retrieves the value of a parameter or
parameters for a presentation or stream specified in the URL. If the parameters for a presentation or stream specified in the URI. If the
Session header is present in a request, the value of a parameter MUST Session header is present in a request, the value of a parameter MUST
be retrieved in the specified session context. The content of the be retrieved in the specified session context. The content of the
reply and response is left to the implementation. reply and response is left to the implementation.
The method MAY also be used without a body (entity). If the this The 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 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 keep-alive timer has been updated. Any non-required header present in
such a request, may or may not been processed. The allow a client to such a request may or may not been processed. To 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 to be retrieved are sent in the body, 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
skipping to change at page 59, line 39 skipping to change at page 58, line 35
C->S: RTSP/1.0 200 OK C->S: RTSP/1.0 200 OK
CSeq: 431 CSeq: 431
Content-Length: 46 Content-Length: 46
Content-Type: text/parameters Content-Type: text/parameters
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 body.
with the intention that the reply content and response
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 URI. The
method MAY also be used without a body (entity). If the this request method MAY also be used without a body (entity). If this request is
is successful, i.e. a 200 OK response is received, then the keep- successful, i.e. a 200 OK response is received, then the keep-alive
alive time has been updated. Any non-required header present in such timer has been updated. Any non-required header present in such a
a request, may or may not been processed. The allow a client to request may or may not been processed. To allow a client to determine
determine if any such header has been processed, it is necessary to if any such header has been processed, it is necessary to use a
use a feature tag and the Require header. Due to this reason it is 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 cannot 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
not allowed to change the error code 458 (Parameter Is Read-Only). not allowed to change, the error code is 458 (Parameter Is Read-
The response body SHOULD contain only the parameters that has errors. Only). The response body SHOULD contain only the parameters that have
Otherwise no body SHALL be returned. errors. Otherwise no body SHALL be returned.
Note: transport parameters for the media stream MUST only be set with Note: transport parameters for the media stream MUST only be set with
the SETUP command. the SETUP command.
Restricting setting transport parameters to SETUP is for Restricting setting transport parameters to SETUP is for
the benefit of firewalls. the benefit of firewalls.
The parameters are split in a fine-grained fashion so that The parameters are split in a fine-grained fashion so that
there can be more meaningful error indications. However, it there can be more meaningful error indications. However, it
may make sense to allow the setting of several parameters may make sense to allow the setting of several parameters
skipping to change at page 61, line 4 skipping to change at page 59, line 44
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
The REDIRECT method is issued by a server to inform a client that it | The REDIRECT method is issued by a server to inform a client that it
MUST connect to another server location to access the resource | required to connect to another server location to access the resource
indicated by the Request URL. The presence of the Session header in a | indicated by the Request-URI. The presence of the Session header in a
REDIRECT request indicates the scope of the request, and determines | REDIRECT request indicates the scope of the request, and determines
the specific semantics of the request. | the specific semantics of the request.
A REDIRECT request with a Session header has end-to-end (i.e. server | A REDIRECT request with a Session header has end-to-end (i.e. server
to client) scope and applies only to the given session. Any | to client) scope and applies only to the given session. Any
intervening proxies SHOULD NOT disconnect the control channel while | intervening proxies SHOULD NOT disconnect the control channel while
there are other remaining end-to-end sessions. The OPTIONAL Location | there are other remaining end-to-end sessions. The OPTIONAL Location
header, if included in such a request, SHALL contain a complete | header, if included in such a request, SHALL contain a complete
absolute URL pointing to the resource to which the client SHOULD | absolute URI pointing to the resource to which the client SHOULD
reconnect. Specifically, the Location SHALL NOT contain just the host | reconnect. Specifically, the Location SHALL NOT contain just the
and port. A client may receive a REDIRECT request with a Session | 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. | header, if and only if, an end-to-end session has been established.
A client may receive a REDIRECT request without a Session header at | A client may receive a REDIRECT request without a Session header at
any time when it has communication or a connection established with a | any time when it has communication or a connection established with a
server. The scope of such a request is limited to the next-hop (i.e. | server. The scope of such a request is limited to the next-hop (i.e.
the RTSP agent in direct communication with the server) and applies, | the RTSP agent in direct communication with the server) and applies,
as well, to the control connection between the next-hop RTSP agent | as well, to the control connection between the next-hop RTSP agent
and the server. A REDIRECT request without a Session header indicates | and the server. A REDIRECT request without a Session header
that all sessions and pending requests being managed via the control | indicates that all sessions and pending requests being managed via
connection MUST be redirected. The OPTIONAL Location header, if | the control connection MUST be redirected. The OPTIONAL Location
included in such a request, SHOULD contain an absolute URL with only | header, if included in such a request, SHOULD contain an absolute URI
the host address and the OPTIONAL port number of the server to which | with only the host address and the OPTIONAL port number of the server
the RTSP agent SHOULD reconnect. Any intervening proxies SHOULD do | to which the RTSP agent SHOULD reconnect. Any intervening proxies
all of the following in the order listed: | SHOULD do all of the following in the order listed:
1. respond to the REDIRECT request | 1. respond to the REDIRECT request
2. disconnect the control channel from the requesting server | 2. disconnect the control channel from the requesting server
3. connect to the server at the given host address | 3. connect to the server at the given host address
4. pass the REDIRECT request to each applicable client |
(typically those clients with an active session or an |
unanswered request) |
Note: The proxy is responsible for accepting REDIRECT responses from | 4. pass the REDIRECT request to each applicable client
its clients; these responses MUST NOT be passed on to either the | (typically those clients with an active session or an
original server or the redirected server. | unanswered request)
The lack of a Location header in any REDIRECT request is indicative | Note: The proxy is responsible for accepting REDIRECT responses from
of the server no longer being able to fulfill the current request and | its clients; these responses MUST NOT be passed on to either the
having no alternatives for the client to continue with its normal | original server or the redirected server.
operation. It is akin to a server initiated TEARDOWN that applies |
both to sessions as well as the general connection associated with |
that client. |
When the Range header is not included in a REDIRECT request, the | The lack of a Location header in any REDIRECT request is indicative
client SHOULD perform the redirection immediately and return a | of the server no longer being able to fulfill the current request and
response to the server. The server can consider the session as | having no alternatives for the client to continue with its normal
terminated and can free any associated state after it receives the | operation. It is akin to a server initiated TEARDOWN that applies
successful (2xx) response. The server MAY close the signalling | both to sessions as well as the general connection associated with
connection upon receiving the response and the client SHOULD close | that client.
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 | When the Range header is not included in a REDIRECT request, the
indicates when the redirection shall take effect. The range value | client SHOULD perform the redirection immediately and return a
MUST be an open ended single value, e.g. npt=59-, indicating the | response to the server. The server can consider the session as
play out time when redirection SHALL occur. Alternatively, a range | terminated and can free any associated state after it receives the
with a time= parameter indicates the wall clock time by when the | successful (2xx) response. The server MAY close the signalling
redirection MUST take place. When the time= parameter is present in | connection upon receiving the response and the client SHOULD close
the range, any range value MUST be ignored even though it MUST be | the signalling connection after sending the 2xx response. The
syntactically correct. When the indicated redirect point is reached, | exception to this is when the client has several sessions on the
a client MUST issue a TEARDOWN request and SHOULD close the | server being managed by the given signalling connection. In this
signalling connection after receiving a 2xx response. The normal | case, the client SHOULD close the connection when it has received and
connection considerations apply for the server. | responded to REDIRECT requests for all the sessions managed by the
signalling connection.
The differentiation of REDIRECT requests with and without | If the OPTIONAL Range header is included in a REDIRECT request, it
range headers is to allow for clear and explicit state | indicates when the redirection takes effect. The range value MUST be
handling. As the state in the server needs to be kept until | an open ended single value, e.g. npt=59-, indicating the play out
the point of redirection, the handling becomes more clear | time when redirection SHALL occur. Alternatively, a range with a
if the client is required to TEARDOWN the session at the | time= parameter indicates the wall clock time by when the redirection
redirect point. | MUST take place. When the time= parameter is present in the range,
After a REDIRECT request has been processed, a client that wants to | any range value MUST be ignored even though it MUST be syntactically
continue to send or receive media for the resource identified by the | correct. When the indicated redirect point is reached, a client MUST
request URL will have to establish a new session with the designated | issue a TEARDOWN request and SHOULD close the signalling connection
host. If the URL given in the Location header is a valid resource | after receiving a 2xx response. The normal connection considerations
URL, a client SHOULD issue a DESCRIBE request for the URL. | apply for the server.
Note: The media resource indicated by the Location header | The differentiation of REDIRECT requests with and without
can be either identical, slightly different or totally | range headers is to allow for clear and explicit state
different. This is the reason why a new DESCRIBE request | handling. As the state in the server needs to be kept until
SHOULD be issued. If the Location header contains only a | the point of redirection, the handling becomes more clear
host address, the client MAY assume that the media on the | if the client is required to TEARDOWN the session at the
new server is identical to the media on the old server, | redirect point.
i.e. all media configuration information from the old |
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-URI will have to establish a new session with the designated
host. If the URI given in the Location header is a valid resource
URI, a client SHOULD issue a DESCRIBE request for the URI.
Note: The media resource indicated by the Location header
can be 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. 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 63, line 42 skipping to change at page 62, line 38
MUST include a session header with the session ID of the session that MUST include a session header with the session ID of the session that
is being checked for liveness. is being checked for liveness.
Prior to using this method, an OPTIONS method is RECOMMENDED to be Prior to using this method, an OPTIONS method is RECOMMENDED to be
issued in the direction which the PING method would be used. This issued in the direction which the PING method would be used. This
method MUST NOT be used if support is not indicated by the Public method MUST NOT be used if support is not indicated by the Public
header. Note: That an 501 (Not Implemented) response means that the header. Note: That an 501 (Not Implemented) response means that the
keep-alive timer has not been updated. keep-alive timer has not been updated.
When a proxy is in use, PING with a * indicates a single-hop liveness When a proxy is in use, PING with a * indicates a single-hop liveness
check, whereas PING with a URL including an host address indicates an check, whereas PING with an URI including an host address indicates
end-to-end liveness check. an end-to-end liveness check.
Example: Example:
C->S: PING * RTSP/1.0 C->S: PING * RTSP/1.0
CSeq: 123 CSeq: 123
Session:12345678 Session:12345678
S->C: RTSP/1.0 200 OK S->C: RTSP/1.0 200 OK
CSeq: 123 CSeq: 123
Session:12345678 Session:12345678
12 Embedded (Interleaved) Binary Data 12 Embedded (Interleaved) Binary Data
Certain firewall designs and other circumstances may force a server In order to fulfill certain requirements on the network side, e.g.
to interleave RTSP messages and media stream data. This interleaving in conjunction with firewalls that block RTP traffic, it may be
should generally be avoided unless necessary since it complicates necessary to interleave RTSP messages and media stream data. This
client and server operation and imposes additional overhead. Also interleaving should generally be avoided unless necessary since it
head of line blocking may cause problems. Interleaved binary data complicates client and server operation and imposes additional
SHOULD only be used if RTSP is carried over TCP. overhead. Also head of line blocking may cause problems. Interleaved
binary data SHOULD only be used if RTSP is carried over TCP.
Stream data such as RTP packets is encapsulated by an ASCII dollar Stream data such as RTP packets is encapsulated by an ASCII dollar
sign (24 decimal), followed by a one-byte channel identifier, sign (24 decimal), followed by a one-byte channel identifier,
followed by the length of the encapsulated binary data as a binary, followed by the length of the encapsulated binary data as a binary,
two-byte integer in network byte order. The stream data follows two-byte integer in network byte order. The stream data follows
immediately afterwards, without a CRLF, but including the upper-layer immediately afterwards, without a CRLF, but including the upper-layer
protocol headers. Each $ block SHALL contain exactly one upper-layer protocol headers. Each $ block SHALL contain exactly one upper-layer
protocol data unit, e.g., one RTP packet. protocol data unit, e.g., one RTP packet.
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.43). interleaved parameter(Section 14.45).
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.43. If interleaved parameter of the Transport header, see section 14.45. 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.
skipping to change at page 66, line 39 skipping to change at page 65, line 31
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 URI pointing out the media resource the client is redirected
to, the URL SHALL NOT only contain the host name. to, the URI SHALL NOT only contain the host name.
13.3.1 300 Multiple Choices 13.3.1 300 Multiple Choices
See [H10.3.1] [TBW]
13.3.2 301 Moved Permanently 13.3.2 301 Moved Permanently
The request resource are moved permanently and resides now at the URL The request resource are moved permanently and resides now at the URI
given by the location header. The user client SHOULD redirect given by the location header. The user client SHOULD redirect
automatically to the given URL. This response MUST NOT contain a automatically to the given URI. This response MUST NOT contain a
message-body. message-body.
13.3.3 302 Found 13.3.3 302 Found
The requested resource reside temporarily at the URL given by the
The requested resource reside temporarily at the URI 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. URI. 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 14.26) 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:
o Date o Date
o ETag and/or Content-Location, if the header would have been o ETag and/or Content-Location, if the header would have been
sent in a 200 response to the same request. sent in a 200 response to the same request.
skipping to change at page 68, line 10 skipping to change at page 67, line 4
13.4.1 400 Bad Request 13.4.1 400 Bad Request
The request could not be understood by the server due to malformed The request could not be understood by the server due to malformed
syntax. The client SHOULD NOT repeat the request without syntax. The client SHOULD NOT repeat the request without
modifications [H10.4.1]. If the request does not have a CSeq header, modifications [H10.4.1]. If the request does not have a CSeq header,
the server MUST NOT include a CSeq in the response. the server MUST NOT include a CSeq in the response.
13.4.2 405 Method Not Allowed 13.4.2 405 Method Not Allowed
The method specified in the request is not allowed for the resource The method specified in the request is not allowed for the resource
identified by the request URL. The response MUST include an Allow identified by the Request-URI. The response MUST include an Allow
header containing a list of valid methods for the requested resource. header containing a list of valid methods for the requested resource.
This status code is also to be used if a request attempts to use a This status code is also to be used if a request attempts to use a
method not indicated during SETUP, e.g., if a RECORD request is method not indicated during SETUP, e.g., if a RECORD request is
issued even though the mode parameter in the Transport header only issued even though the mode parameter in the Transport header only
specified PLAY. specified PLAY.
13.4.3 451 Parameter Not Understood 13.4.3 451 Parameter Not Understood
The recipient of the request does not support one or more parameters The recipient of the request does not support one or more parameters
contained in the request.When returning this error message the sender contained in the request. When returning this error message the
SHOULD return a entity body containing the offending parameter(s). sender SHOULD return a entity body containing the offending
parameter(s).
13.4.4 452 reserved 13.4.4 452 reserved
This error code was removed from RFC 2326 [1] and is obsolete. This error code was removed from RFC 2326 [1] and is obsolete.
13.4.5 453 Not Enough Bandwidth 13.4.5 453 Not Enough Bandwidth
The request was refused because there was insufficient bandwidth. The request was refused because there was insufficient bandwidth.
This may, for example, be the result of a resource reservation This may, for example, be the result of a resource reservation
failure. failure.
skipping to change at page 69, line 18 skipping to change at page 68, line 13
presentation. presentation.
13.4.10 458 Parameter Is Read-Only 13.4.10 458 Parameter Is Read-Only
The parameter to be set by SET_PARAMETER can be read but not The parameter to be set by SET_PARAMETER can be read but not
modified. When returning this error message the sender SHOULD return modified. When returning this error message the sender SHOULD return
a entity body containing the offending parameter(s). a entity body containing the offending parameter(s).
13.4.11 459 Aggregate Operation Not Allowed 13.4.11 459 Aggregate Operation Not Allowed
The requested method may not be applied on the URL in question since The requested method may not be applied on the URI in question since
it is an aggregate (presentation) URL. The method may be applied on a it is an aggregate (presentation) URI. The method may be applied on a
media URL. media URI.
13.4.12 460 Only Aggregate Operation Allowed 13.4.12 460 Only Aggregate Operation Allowed
The requested method may not be applied on the URL in question since The requested method may not be applied on the URI in question since
it is not an aggregate control (presentation) URL. The method may be it is not an aggregate control (presentation) URI. The method may be
applied on the aggregate control URL. applied on the aggregate control URI.
13.4.13 461 Unsupported Transport 13.4.13 461 Unsupported Transport
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
skipping to change at page 70, line 7 skipping to change at page 68, line 51
13.4.16 471 Connection Credentials not accepted 13.4.16 471 Connection Credentials not accepted
When performing a secure connection over multiple connections, a When performing a secure connection over multiple connections, a
intermediary has refused to connect to the next hop and carry out the intermediary has refused to connect to the next hop and carry out the
request due to unacceptable credentials for the used policy. 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 A 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
method direction object acronym Body method direction object acronym Body
_________________________________________________ _________________________________________________
DESCRIBE C -> S P,S DES r DESCRIBE C -> S P,S DES r
GET_PARAMETER C -> S, S -> C P,S GPR R,r GET_PARAMETER C -> S, S -> C P,S GPR R,r
OPTIONS C -> S P,S OPT OPTIONS C -> S P,S OPT
skipping to change at page 71, line 4 skipping to change at page 69, line 44
Information about header fields in relation to methods and proxy Information about header fields in relation to methods and proxy
processing is summarized in Tables 9, 10, 11, and 12. 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. An empty proxy column indicates that the proxy SHALL
NOT do any changes to that header, all allowed operations are
explicitly stated:
a: A proxy can add or concatenate the header field if not a: A proxy can add or concatenate the header field if not
present. present.
m: A proxy can modify an existing header field value. m: A proxy can modify an existing header field value.
d: A proxy can delete a header field value. d: A proxy can delete a header field value.
r: A proxy must be able to read the header field, and thus this r: A proxy needs to be able to read the header field, and thus
header field cannot be encrypted. this header field cannot be encrypted.
The rest of the columns relate to the presence of a header field in a The rest of the columns relate to the presence of a header field in a
method. The method names when abbreviated, are according to table 8: method. The method names when abbreviated, are according to table 8:
c: Conditional; requirements on the header field depend on the c: Conditional; requirements on the header field depend on the
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 SHALL be present if the message body is
empty. See sections 14.15, 14.17 and 4.3 for details. not empty. See sections 14.16, 14.18 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 "Optional" means that a Client/Server MAY include the header field in
a request or response. The Client/Server behavior when receiving such a request or response. The Client/Server behavior when receiving such
headers varies, for some it may ignore the header field, in other headers varies, for some it may ignore the header field, in other
case it is request to process the header. This is regulated by the case it is request to process the header. This is regulated by the
method and header descriptions. Example of such headers that require method and header descriptions. Example of such headers that require
processing are the Require and Proxy-Require header fields discussed processing are the Require and Proxy-Require header fields discussed
in 14.35 and 14.30. A "mandatory" header field MUST be present in a in 14.37 and 14.31. A "mandatory" header field MUST be present in a
request, and MUST be understood by the Client/Server receiving the request, and MUST be understood by the Client/Server receiving the
request. A mandatory response header field MUST be present in the request. A mandatory response header field MUST be present in the
response, and the header field MUST be understood by the response, and the header field MUST be understood by the
Client/Server processing the response. "Not applicable" means that Client/Server processing the response. "Not applicable" means that
the header field MUST NOT be present in a request. If one is placed the header field MUST NOT be present in a request. If one is placed
in a request by mistake, it MUST be ignored by the Client/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 MUST place the header field in the response, and the Client/Server MUST
ignore the header field in the response. ignore the header field in the response.
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 an URI. If the
URL contains a comma, or semicolon, the URL MUST be enclosed in URI contains a comma, or semicolon, the URI MUST be enclosed in
double quotas ("). Any URL parameters are contained within these double quotas ("). Any URI parameters are contained within these
quotas. If the URL is not enclosed in double quotas, any semicolon- quotas. If the URI is not enclosed in double quotas, any semicolon-
delimited parameters are header-parameters, not URL parameters. delimited parameters are header-parameters, not URI parameters.
14.1 Accept 14.1 Accept
The Accept request-header field can be used to specify certain The Accept request-header field can be used to specify certain
presentation description content types which are acceptable for the presentation description 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: Example of use:
Accept: application/rtsl q=1.0, application/sdp Accept: application/rtsl q=1.0, application/sdp
14.2 Accept-Credentials 14.2 Accept-Credentials
The Accept-Credentials header has different usage in RTSP requests | The Accept-Credentials header is a request header used to indicate to
and responses. In a request it is used to indicate to any trusted | any trusted intermediary how to handle further secured connections to
intermediary how to handle further secured connections to proxies or | proxies or servers. See section 17 for the usage of this header. It
servers. In responses the header is used to carry the credentials of | SHALL only be included in client to server requests.
In a request the header SHALL contain the method (User, Proxy, or
Any) for approving credentials selected by the requestor. The method
SHALL NOT be changed by any proxy. If the method is "User" the header
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 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 - - -
Connection o o o o o o Connection o o o o o o
Connection-Credentials 470,407 ar o o o o o o
Content-Base r o - - - - - Content-Base r o - - - - -
Content-Base 4xx o o o o o o Content-Base 4xx o o o o o o
Content-Encoding R r - - - - - - Content-Encoding R r - - - - - -
Content-Encoding r r o - - - - - Content-Encoding r r o - - - - -
Content-Encoding 4xx r o o o o o o Content-Encoding 4xx r o o o o o o
Content-Language R r - - - - - - Content-Language R r - - - - - -
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 * * * * * *
skipping to change at page 74, line 9 skipping to change at page 73, line 9
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 Table 9: Overview of RTSP header fields (A-L) related to methods
DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.
Header Where Proxy DES OPT SETUP PLAY PAUSE TRD 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
Proxy-Supported R amr oc oc oc oc oc oc
Proxy-Supported r c c c c c c
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 - - -
RTP-Info r - - o c - - RTP-Info r - - o c - -
Scale - - - o - - Scale - - - o - -
Session R - o o m m m Session R - o o m m m
skipping to change at page 74, line 41 skipping to change at page 73, line 43
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 10: Overview of RTSP header fields (P-W) related to methods Table 10: Overview of RTSP header fields (P-W) related to methods
DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.
any next hop that need to be approved by the requestor. See section | contains zero or more of credentials that the client accept. Each
17 for the usage of this header. It SHALL only be included in client | credential SHALL consist of one URI identifying the proxy or server,
to server requests, and server to client responses. | and the SHA-1 [15] hash computed over that entity's DER encoded
certificate [16] in Base64 [36].
Example:
In a request the header SHALL contain the method (User, Proxy, or |
Any) for approving credentials selected by the requestor. The method |
SHALL NOT be changed by any proxy. If the method is "User" the header |
contains zero or more of credentials that the client accept. Each |
credential SHALL consist of one URI identifying the proxy or 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 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 -
Connection-Credentials 470,407 ar o 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 - -
Content-Encoding 4xx r o o o - Content-Encoding 4xx r o o o -
Content-Language R r o o - - Content-Language R r o o - -
Content-Language r r o o - - Content-Language r r o o - -
Content-Language 4xx r o o o - Content-Language 4xx r o o o -
Content-Length R r * * - - Content-Length R r * * - -
skipping to change at page 75, line 41 skipping to change at page 74, line 42
CSeq Rc m m m m CSeq Rc m m m m
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
Proxy-Supported R amr oc oc oc oc
Proxy-Supported r c c c c
Public 501 admr m* m* m* m* Public 501 admr m* m* m* m*
__________________________________________________ ______________________________________________________
Header Where Proxy GPR SPR RDR PNG Header Where Proxy GPR SPR RDR PNG
Table 11: Overview of RTSP header fields (A-P) related to methods Table 11: Overview of RTSP header fields (A-P) related to methods
GET_PARAMETER, SET_PARAMETER, REDIRECT, and PING. GET_PARAMETER, SET_PARAMETER, REDIRECT, and PING.
Header Where Proxy GPR SPR RDR PNG 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
skipping to change at page 76, line 34 skipping to change at page 75, line 34
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 12: Overview of RTSP header fields (R-W) related to methods Table 12: Overview of RTSP header fields (R-W) related to methods
GET_PARAMETER, SET_PARAMETER, REDIRECT, and PING. GET_PARAMETER, SET_PARAMETER, REDIRECT, and PING.
and the SHA-1 [16] hash computed over that entity's DER encoded | "rtsps://server.example.com/";lurbjj5khhB0NhIuOXtt4bBRH1M=
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 14.3 Accept-Encoding
See [H14.3] See [H14.3]
14.4 Accept-Language 14.4 Accept-Language
See [H14.4]. Note that the language specified applies to the See [H14.4]. Note that the language specified applies to the
presentation description and any reason phrases, not the media presentation description and any reason phrases, not the media
content. content.
14.5 Accept-Ranges 14.5 Accept-Ranges
The Accept-Ranges response-header field allows the server to indicate The Accept-Ranges response-header field allows the server to indicate
its acceptance of range requests and possible formats for a resource: its acceptance of range requests and possible formats for a resource:
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
This header has the same syntax as [H14.5] and the syntax is defined 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 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 the time formats indicates acceptance by the server for PLAY and
PAUSE requests with this format. The headers value is valid for the PAUSE requests with this format. The headers value is valid for the
resource specified by the URL in the request, this response resource specified by the URI in the request, this response
corresponds to. A server SHOULD use this header in SETUP responses to corresponds to. A server SHOULD use this header in SETUP responses to
indicate to the client which range time formats the media supports. indicate to the client which range time formats the media supports.
The header SHOULD also be included in "456" responses which is a The header SHOULD also be included in "456" responses which is a
result of use of unsupported range formats. result of use of unsupported range formats.
14.6 Allow 14.6 Allow
The Allow entity-header field lists the methods supported by the The Allow entity-header field lists the methods supported by the
resource identified by the request-URL. The purpose of this field is resource identified by the Request-URI. The purpose of this field is
to strictly inform the recipient of valid methods associated with the to strictly inform the recipient of valid methods associated with the
resource. An Allow header field MUST be present in a 405 (Method Not resource. An Allow header field MUST be present in a 405 (Method Not
Allowed) response. See [H14.7] for syntax definition. Allowed) response. See [H14.7] for syntax definition.
Example of use: Example of use:
Allow: SETUP, PLAY, SET_PARAMETER Allow: SETUP, PLAY, SET_PARAMETER
14.7 Authorization 14.7 Authorization
See [H14.8] See [H14.8]
14.8 Bandwidth 14.8 Bandwidth
The Bandwidth request-header field describes the estimated bandwidth The Bandwidth request-header field describes the estimated bandwidth
available to the client, expressed as a positive integer and measured available to the client, expressed as a positive integer and measured
in bits per second. The bandwidth available to the client may change in bits per second. The bandwidth available to the client may change
during an RTSP session, e.g., due to modem retraining. during an RTSP session, e.g., due to mobility.
Example: Example:
Bandwidth: 4000 Bandwidth: 4000
14.9 Blocksize 14.9 Blocksize
The Blocksize request-header field is sent from the client to the The Blocksize request-header field is sent from the client to the
media server asking the server for a particular media packet size. media server asking the server for a particular media packet size.
This packet size does not include lower-layer headers such as IP, This packet size does not include lower-layer headers such as IP,
skipping to change at page 78, line 34 skipping to change at page 77, line 23
override it with the media-specific size if necessary. The block size override it with the media-specific size if necessary. The block size
MUST be a positive decimal number, measured in octets. The server 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.10 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
skipping to change at page 80, line 13 skipping to change at page 78, line 48
min-fresh: Indicates that the client is willing to accept a min-fresh: Indicates that the client is willing to accept a
media stream whose freshness lifetime is no less than its media stream whose freshness lifetime is no less than its
current age plus the specified time in seconds. That is, current age plus the specified time in seconds. That is,
the client wants a response that will still be fresh for at the client wants a response that will still be fresh for at
least the specified number of seconds. least the specified number of seconds.
must-revalidate: When the must-revalidate directive is present must-revalidate: When the must-revalidate directive is present
in a SETUP response received by a cache, that cache MUST in a SETUP response received by a cache, that cache MUST
NOT use the entry after it becomes stale to respond to a NOT use the entry after it becomes stale to respond to a
subsequent request without first revalidating it with the subsequent request without first revalidating it with the
origin server. That is, the cache must do an end-to-end origin server. That is, the cache is required to do an
revalidation every time, if, based solely on the origin end-to-end revalidation every time, if, based solely on the
server's Expires, the cached response is stale.) origin server's Expires, the cached response is stale.)
proxy-revalidate: The proxy-revalidate directive has the same proxy-revalidate: The proxy-revalidate directive has the same
meaning as the must-revalidate directive, except that it meaning as the must-revalidate directive, except that it
does not apply to non-shared user agent caches. It can be does not apply to non-shared user agent caches. It can be
used on a response to an authenticated request to permit used on a response to an authenticated request to permit
the user's cache to store and later return the response the user's cache to store and later return the response
without needing to revalidate it (since it has already been without needing to revalidate it (since it has already been
authenticated once by that user), while still requiring authenticated once by that user), while still requiring
proxies that service many users to revalidate each time (in proxies that service many users to revalidate each time (in
order to make sure that each user has been authenticated). order to make sure that each user has been authenticated).
Note that such authenticated responses also need the public Note that such authenticated responses also need the public
skipping to change at page 81, line 10 skipping to change at page 79, line 44
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.11 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 has the choice of
continue using a connection indefinitely as long as it sends valid continuing using a connection indefinitely, as long as it sends valid
messages. messages.
14.12 Content-Base 14.12 Connection-Credentials
The Connection-Credentials response header is used to carry the
credentials of any next hop that need to be approved by the
requestor. It SHALL only be used in server to client responses.
The Connection-Credentials header in an 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 [16] certificate in base64 [36].
Example:
Accept-Credentials:"rtsps://proxy2.example.com/";MIIDNTCCAp6gA...
14.13 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. URI for resolving relative URIs 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 URI 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 URI
is an absolute URL) or the URL used to initiate the request, in that is an absolute URI) or the URI 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 URI 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.13 Content-Encoding 14.14 Content-Encoding
See [H14.11] See [H14.11]
14.14 Content-Language 14.15 Content-Language
See [H14.12] See [H14.12]
14.15 Content-Length 14.16 Content-Length
The Content-Length general-header field contains the length of the The Content-Length general-header field contains the length of the
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.16 Content-Location 14.17 Content-Location
See [H14.14] See [H14.14]
14.17 Content-Type 14.18 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.18 CSeq 14.19 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.19 Date 14.20 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.20 ETag | 14.21 ETag
The ETag response header MAY be included in DESCRIBE or SETUP | The ETag response header MAY be included in DESCRIBE or SETUP
responses. The entity tag returned in a DESCRIBE response is for the | responses. The entity tag returned in a DESCRIBE response is for the
included entity, while for SETUP it refers to the media resource just | included entity, while for SETUP it refers to the media resource just
set up. This differentiation allows for cache validation of both | set up. This differentiation allows for cache validation of both
session description and the media resource associated with the | session description and the media resource associated with the
description. If the ETag is provided both inside the entity, e.g. | description. If the ETag is provided both inside the entity, e.g.
within the "a=etag" attribute in SDP, and in the response message, | 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 | then both tags SHALL be identical. It is RECOMMENDED that the ETag is
primarily given in the RTSP response message, to ensure that caches | primarily given in the RTSP response message, to ensure that caches
can use the ETag without requiring content inspection. | can use the ETag without requiring content inspection.
SETUP and DESCRIBE requests can be made conditional upon the ETag | SETUP and DESCRIBE requests can be made conditional upon the ETag
using the headers If-Match (Section 14.24) and If-None-Match (Section | using the headers If-Match (Section 14.25) and If-None-Match (Section
14.26). | 14.27).
14.21 Expires 14.22 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 83, line 50 skipping to change at page 83, line 7
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.10). indicated otherwise by a Cache-Control header field (Section 14.10).
14.22 From 14.23 From
See [H14.22]. See [H14.22].
14.23 Host 14.24 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.24 If-Match 14.25 If-Match
See [H14.24]. The If-Match request-header field is especially useful | See [H14.24].
for ensuring the integrity of the presentation description, in both |
the case where it is fetched via means external to RTSP (such as |
HTTP), or in the case where the server implementation is guaranteeing |
the integrity of the description between the time of the DESCRIBE |
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). |
This validation check is also very useful if a session has been | The If-Match request-header field is especially useful for ensuring
redirected from one server to another. | the integrity of the presentation description, in both the case where
it is fetched via means external to RTSP (such as HTTP), or in the
case where the server implementation is guaranteeing the integrity of
the description between the time of the DESCRIBE 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).
14.25 If-Modified-Since This validation check is also very useful if a session has been
redirected from one server to another.
14.26 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.26 If-None-Match 14.27 If-None-Match
See [H14.26]. See [H14.26].
This request header can be used with entity tags to make DESCRIBE This request header can be used with entity tags to make DESCRIBE
requests conditional. A new session description is retrieved only if requests conditional. A new session description is retrieved only if
another entity than the already available would be included. If the another entity than the already available would be included. If the
entity available for delivery is matching the one the client already entity available for delivery is matching the one the client already
has, then a 304 (Not Modified) response is given. has, then a 304 (Not Modified) response is given.
14.27 Last-Modified 14.28 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.28 Location 14.29 Location
See [H14.30]. See [H14.30].
14.29 Proxy-Authenticate 14.30 Proxy-Authenticate
See [H14.33]. See [H14.33].
14.30 Proxy-Require 14.31 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 end-point (server or client).
feature is supported by both proxies and servers the tag must be To ensure that a feature is supported by both proxies and servers the
included in also a Require header. tag needs to be included in also a Require header.
See Section 14.35 for more details on the mechanics of this message See Section 14.37 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.31 Public 14.32 Proxy-Supported
The Public response header field lists the set of methods supported | The Proxy-Supported header field enumerates all the extensions
by the response sender. This header applies to the general | supported by the proxy using feature tags. The header carries the
capabilities of the sender and its only purpose is to indicate the | intersection of extensions supported by the forwarding proxies. The
Proxy-Supported header MAY be included in any request by a proxy. It
SHALL be added by any proxy if the Supported header is present in a
request. When present in a request, the receiver MUST in the response
copy the received Proxy-Supported header.
The Proxy-Supported header field contains a list of feature-tags
applicable to proxies, as described in Section 3.7. The list are the
intersection of all feature-tags understood by the proxies. To
achieve an intersection, the proxy adding the Proxy-Supported header
includes all proxy feature-tags it understands. Any proxy receiving a
request with the header, checks the list and removes any feature tag
it do not support. A Proxy-Supported header present in the response
SHALL NOT be touched by the proxies.
Example:
C->P1: OPTIONS rtsp://example.com/ RTSP/1.0
Supported: foo, bar, blech
P1->P2: OPTIONS rtsp://example.com/ RTSP/1.0
Supported: foo, bar, blech
Proxy-Supported: proxy-foo, proxy-bar, proxy-blech
Via: 1.0 prox1.example.com
P2->S: OPTIONS rtsp://example.com/ RTSP/1.0
Supported: foo, bar, blech
Proxy-Supported: proxy-foo, proxy-blech
Via: 1.0 prox1.example.com, 1.0 prox2.example.com
S->C: RTSP/1.0 200 OK
Supported: foo, bar, baz
Proxy-Supported: proxy-foo, proxy-blech
Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
Via: 1.0 prox1.example.com, 1.0 prox2.example.com
14.33 Public
The Public response header field lists the set of methods supported
by the response sender. This header applies to the general
capabilities of the sender and its only purpose is to indicate the
sender's capabilities to the recipient. The methods listed may or may sender's capabilities to the recipient. The methods listed may or may
not be applicable to the Request-URL; the Allow header field (section not be applicable to the Request-URI; the Allow header field (section
14.7) MAY be used to indicate methods allowed for a particular URL. 14.7) MAY be used to indicate methods allowed for a particular URI.
Example of use: Example of use:
Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
In the event that there are proxies between the sender and the | In the event that there are proxies between the sender and the
recipient of a response, each intervening proxy MUST modify the | recipient of a response, each intervening proxy MUST modify the
Public header field to remove any methods that are not supported via | Public header field to remove any methods that are not supported via
that proxy. The resulting Public header field will contain an | that proxy. The resulting Public header field will contain an
intersection of the sender's methods and the methods allowed through | intersection of the sender's methods and the methods allowed through
by the intervening proxies. | by the intervening proxies.
In general proxies should allow all methods to | In general proxies should allow all methods to
transparently pass through from the sending RTSP agent to | transparently pass through from the sending RTSP agent to
the receiving RTSP agent, but there may be cases where this | the receiving RTSP agent, but there may be cases where this
is not desirable for a given proxy. Modification of the | is not desirable for a given proxy. Modification of the
Public response header field by the intervening proxies | Public response header field by the intervening proxies
ensures that the request sender gets an accurate response | ensures that the request sender gets an accurate response
indicating the methods that can be used on the target agent | indicating the methods that can be used on the target agent
via the proxy chain. via the proxy chain.
14.32 Range 14.34 Range
The Range request and response header field specifies a range of The Range request and response header field specifies a range of
time. The header is used in PLAY request to indicate the range of 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 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 PLAY indicates what range of time that is actually being played. In
a SETUP response the header MAY be used, to ensure correct a SETUP response the header MAY be used, to ensure correct
synchronization information after changes of transport parameters. synchronization information after changes of transport parameters.
The range can be specified in a number of units. This specification The range can be specified in a number of units. This specification
defines the smpte (Section 3.4), npt (Section 3.5), and clock defines the smpte (Section 3.4), npt (Section 3.5), and clock
skipping to change at page 87, line 30 skipping to change at page 87, line 32
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.37) indicates a negative scale value. For example, this section 14.39) 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 88, line 13 skipping to change at page 88, line 15
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.33 Referer 14.35 Referer
See [H14.36]. The URL refers to that of the presentation description, See [H14.36]. The URI refers to that of the presentation description,
typically retrieved via HTTP. typically retrieved via HTTP.
14.34 Retry-After 14.36 Retry-After
See [H14.37]. See [H14.37].
14.35 Require 14.37 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.41) is much more effective in this purpose. The server (Section 14.43) 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.30). respect to proxies see, header Proxy-Require (Section 14.31).
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 89, line 17 skipping to change at page 89, line 19
CSeq: 302 CSeq: 302
Unsupported: funky-feature Unsupported: funky-feature
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 SHALL ignore this header. If a
are not understood in this field. If a particular extension requires particular extension requires that intermediate devices support it,
that intermediate devices support it, the extension should be tagged the extension should be tagged in the Proxy-Require field instead
in the Proxy-Require field instead (see Section 14.30). (see Section 14.31).
14.36 RTP-Info 14.38 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 first value of the ssrc | synchronization source identified by the first value of the ssrc
parameter of the Transport response header in the SETUP response. For | parameter of the Transport response header in the SETUP response. For
streams using RTP as transport protocol the RTP-Info header SHOULD be | streams using RTP as transport protocol the RTP-Info header SHOULD be
part of a 200 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 URI which for which the following RTP
parameters correspond, this URL MUST be the same used in parameters correspond, this URI 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 URI
SHALL use the request URL as base URL. SHALL use the Request-URI as base URI.
seq: Indicates the sequence number of the first packet of the | seq: Indicates the sequence number of the first packet of the
stream that is direct result of the request. This allows | stream that is direct result of the request. This allows
clients to gracefully deal with packets when seeking. The | clients to gracefully deal with packets when seeking. The
client uses this value to differentiate packets that | client uses this value to differentiate packets that
originated before the seek from packets that originated | originated before the seek from packets that originated
after the seek. Note that a client may not receive the | after the seek. Note that a client may not receive the
packet with the expressed sequence number, and instead | packet with the expressed sequence number, and instead
packets with a higher sequence number, due to packet loss | packets with a higher sequence number, due to packet loss
or reordering. 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 90, line 39 skipping to change at page 90, line 41
ensure that this information is available at the ensure that this information is available at the
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 first SSRC reported in the transport | single SSRC within a stream (the first SSRC reported in the transport
response header; see section 14.43). If there are multiple | response header; see section 14.45). 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 needs to be used to map RTP and NTP
for those sources, for both synchronization and drift-checking. Due | timestamps for those sources, for both synchronization and drift-
to backwards compatibility reasons these shortcomings can't be fixed | checking. Due to backwards compatibility reasons these shortcomings
without defining a new header, which is for future work if needed. can't be fixed 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
18.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 an URI 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.37 Scale 14.39 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
skipping to change at page 91, line 43 skipping to change at page 91, line 46
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.32. 14.34.
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.38 Speed 14.40 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.
skipping to change at page 92, line 37 skipping to change at page 92, line 40
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.39 Server 14.41 Server
See [H14.38], however the header syntax is corrected in section See [H14.38], however the header syntax is corrected in section
18.2.3. 18.2.3.
14.40 Session 14.42 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
that session. This means that the Session header MUST be included in that session. This means that the Session header MUST be included in
a request using the following methods: PLAY, PAUSE, PING, and a request using the following methods: PLAY, PAUSE, PING, and
TEARDOWN, and MAY be included in SETUP, OPTIONS, SET_PARAMETER, TEARDOWN, and MAY be included in SETUP, OPTIONS, SET_PARAMETER,
GET_PARAMETER, and REDIRECT, and SHALL NOT be included in DESCRIBE. GET_PARAMETER, and REDIRECT, and SHALL NOT be included in DESCRIBE.
In a RTSP response the session header SHALL be included in methods, In an RTSP response the session header SHALL be included in methods,
SETUP, PING, PLAY, and PAUSE, and MAY be included in methods, SETUP, PING, PLAY, and PAUSE, and MAY be included in methods,
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).
skipping to change at page 94, line 38 skipping to change at page 94, line 43
regarding checking of support in server and proxies. regarding checking of support in server and proxies.
OPTIONS: This method does also work. However it causes the OPTIONS: This method does also work. However it causes the
server to perform unnecessary processing and result in server to perform unnecessary processing and result in
bigger responses than necessary for the task. The reason bigger responses than necessary for the task. The reason
for this is that the Public is always included creating for this is that the Public is always included creating
overhead. overhead.
Note that a session identifier identifies an RTSP session across Note that a session identifier identifies an RTSP session across
transport sessions or connections. RTSP requests for a given session transport sessions or connections. RTSP requests for a given session
can use different URLs (Presentation and media URLs). Note, that can use different URIs (Presentation and media URIs). Note, that
there are restrictions depending on the session which URLs that are there are restrictions depending on the session which URIs that are
acceptable for a given method. However, multiple "user" sessions for acceptable for a given method. However, multiple "user" sessions for
the same URL from the same client will require use of different the same URI 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 URI 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.41 Supported 14.43 Supported
The Supported header field enumerates all the extensions supported by |
the client or server using feature tags. The header carries the | The Supported header field enumerates all the extensions supported by
extensions supported by the message sending entity. The Supported | the client or server using feature tags. The header carries the
header MAY be included in any request. When present in a request, | extensions supported by the message sending entity. The Supported
the receiver MUST respond with its corresponding Supported header. | header MAY be included in any request. When present in a request,
Note, also in 4xx and 5xx responses shall the supported header be | the receiver MUST respond with its corresponding Supported header.
included. Note, also in 4xx and 5xx responses is the supported header 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.42 Timestamp 14.44 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.43 Transport 14.45 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
skipping to change at page 96, line 16 skipping to change at page 96, line 19
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 type 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 A request or a response including a transport header with any
extended way requires that request or response contains a Require parameter not defined in RFC 2326 SHOULD use the Require header and
header with the "play.basic" feature tag. the "play.basic" feature tag. This is to ensure consistent behavior
with the new parameters. Any parameters part of future extensions
requires clarification if they are safe to ignore in accordance to
this specification, or is required to be understood. If a parameter
is required to be understood, then a feature tag MUST be defined and
used in the Require and/or Proxy-Require headers.
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.
skipping to change at page 96, line 46 skipping to change at page 97, line 8
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 is to 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:
skipping to change at page 97, line 38 skipping to change at page 97, line 47
stream will be sent. The client originating the RTSP stream will be sent. The client originating the RTSP
request may specify the destination address of the stream request may specify the destination address of the stream
recipient with the destination parameter. When the recipient with the destination parameter. When the
destination field is specified, the recipient may be a destination field is specified, the recipient may be a
different party than the originator of the request. To different party than the originator of the request. To
avoid becoming the unwitting perpetrator of a remote- avoid becoming the unwitting perpetrator of a remote-
controlled denial-of-service attack, a server SHOULD controlled denial-of-service attack, a server SHOULD
authenticate the client originating the request and SHOULD authenticate the client originating the request and SHOULD