draft-ietf-mmusic-rfc2326bis-08.txt   draft-ietf-mmusic-rfc2326bis-09.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-08.txt Columbia U. draft-ietf-mmusic-rfc2326bis-09.txt Columbia U.
October 25, 2004 A. Rao February 21, 2005 A. Rao
Expires: April, 2005 Cisco Expires: August 21, 2005 Cisco
R. Lanphier R. Lanphier
RealNetworks RealNetworks
M. Westerlund M. Westerlund
Ericsson Ericsson
A. Narasimhan A. Narasimhan
Princeton Overture
Real Time Streaming Protocol (RTSP) Real Time Streaming Protocol (RTSP)
STATUS OF THIS MEMO STATUS OF THIS MEMO
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes? have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with( Section 6 of) RFC 3668. aware will be disclosed, in accordance with 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 28 skipping to change at page 3, line 28
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 ............ 22 2.4 Inviting a RTSP server into a conference ............ 22
2.5 Live Content using Multicast ........................ 23 2.5 Live Content using Multicast ........................ 23
3 Protocol Parameters ................................. 24 3 Protocol Parameters ................................. 24
3.1 RTSP Version ........................................ 24 3.1 RTSP Version ........................................ 24
3.2 RTSP URI ............................................ 24 3.2 RTSP URI ............................................ 24
3.3 Session Identifiers ................................. 26 3.3 Session Identifiers ................................. 26
3.4 SMPTE Relative Timestamps ........................... 26 3.4 SMPTE Relative Timestamps ........................... 26
3.5 Normal Play Time .................................... 27 3.5 Normal Play Time .................................... 26
3.6 Absolute Time ....................................... 27 3.6 Absolute Time ....................................... 27
3.7 Feature-tags ........................................ 28 3.7 Feature-tags ........................................ 28
3.8 Entity Tags ......................................... 28 3.8 Entity Tags ......................................... 28
4 RTSP Message ........................................ 28 4 RTSP Message ........................................ 28
4.1 Message Types ....................................... 29 4.1 Message Types ....................................... 29
4.2 Message Headers ..................................... 29 4.2 Message Headers ..................................... 29
4.3 Message Body ........................................ 29 4.3 Message Body ........................................ 29
4.4 Message Length ...................................... 29 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 ........................................ 30 6.1 Request Line ........................................ 30
6.2 Request Header Fields ............................... 32 6.2 Request Header Fields ............................... 32
7 Response ............................................ 32 7 Response ............................................ 33
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 .............................. 34 7.1.2 Response Header Fields .............................. 34
8 Entity .............................................. 34 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 ......................................... 35 9 Connections ......................................... 35
9.1 Pipelining .......................................... 37 9.1 Reliability and Acknowledgements .................... 37
9.2 Reliability and Acknowledgements .................... 37 9.2 Using Connections ................................... 38
9.3 The usage of connections ............................ 38 9.3 Closing Connections ................................. 39
9.4 Timing Out RTSP messages ............................ 39 9.4 Timing Out Connections and RTSP Messages ............ 40
9.5 Use of IPv6 ......................................... 40 9.5 Use of IPv6 ......................................... 41
10 Capability Handling ................................. 40 10 Capability Handling ................................. 41
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 ......................................... 65
13.1.1 100 Continue ........................................ 64 13.1.1 100 Continue ........................................ 65
13.2 Success 2xx ......................................... 64 13.2 Success 2xx ......................................... 65
13.3 Redirection 3xx ..................................... 65 13.3 Redirection 3xx ..................................... 66
13.3.1 300 Multiple Choices ................................ 65 13.3.1 300 Multiple Choices ................................ 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 .............................. 67
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 ................................... 68
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 ............................ 69
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 ..................................... 76
14.4 Accept-Language ..................................... 75 14.4 Accept-Language ..................................... 76
14.5 Accept-Ranges ....................................... 75 14.5 Accept-Ranges ....................................... 76
14.6 Allow ............................................... 76 14.6 Allow ............................................... 77
14.7 Authorization ....................................... 76 14.7 Authorization ....................................... 77
14.8 Bandwidth ........................................... 76 14.8 Bandwidth ........................................... 77
14.9 Blocksize ........................................... 77 14.9 Blocksize ........................................... 77
14.10 Cache-Control ....................................... 77 14.10 Cache-Control ....................................... 78
14.11 Connection .......................................... 79 14.11 Connection .......................................... 80
14.12 Connection-Credentials .............................. 79 14.12 Connection-Credentials .............................. 80
14.13 Content-Base ........................................ 80 14.13 Content-Base ........................................ 81
14.14 Content-Encoding .................................... 80 14.14 Content-Encoding .................................... 81
14.15 Content-Language .................................... 80 14.15 Content-Language .................................... 81
14.16 Content-Length ...................................... 80 14.16 Content-Length ...................................... 81
14.17 Content-Location .................................... 80 14.17 Content-Location .................................... 81
14.18 Content-Type ........................................ 81 14.18 Content-Type ........................................ 81
14.19 CSeq ................................................ 81 14.19 CSeq ................................................ 82
14.20 Date ................................................ 81 14.20 Date ................................................ 82
14.21 ETag ................................................ 81 14.21 ETag ................................................ 82
14.22 Expires ............................................. 82 14.22 Expires ............................................. 83
14.23 From ................................................ 83 14.23 From ................................................ 83
14.24 Host ................................................ 83 14.24 Host ................................................ 84
14.25 If-Match ............................................ 83 14.25 If-Match ............................................ 84
14.26 If-Modified-Since ................................... 83 14.26 If-Modified-Since ................................... 84
14.27 If-None-Match ....................................... 83 14.27 If-None-Match ....................................... 84
14.28 Last-Modified ....................................... 84 14.28 Last-Modified ....................................... 85
14.29 Location ............................................ 84 14.29 Location ............................................ 85
14.30 Proxy-Authenticate .................................. 84 14.30 Proxy-Authenticate .................................. 85
14.31 Proxy-Require ....................................... 84 14.31 Proxy-Require ....................................... 85
14.32 Proxy-Supported ..................................... 84 14.32 Proxy-Supported ..................................... 85
14.33 Public .............................................. 85 14.33 Public .............................................. 86
14.34 Range ............................................... 86 14.34 Range ............................................... 87
14.35 Referer ............................................. 88 14.35 Referer ............................................. 89
14.36 Retry-After ......................................... 88 14.36 Retry-After ......................................... 89
14.37 Require ............................................. 88 14.37 Require ............................................. 89
14.38 RTP-Info ............................................ 89 14.38 RTP-Info ............................................ 90
14.39 Scale ............................................... 91 14.39 Scale ............................................... 92
14.40 Speed ............................................... 92 14.40 Speed ............................................... 93
14.41 Server .............................................. 92 14.41 Server .............................................. 94
14.42 Session ............................................. 92 14.42 Session ............................................. 94
14.43 Supported ........................................... 95 14.43 Supported ........................................... 96
14.44 Timestamp ........................................... 95 14.44 Timestamp ........................................... 96
14.45 Transport ........................................... 95 14.45 Transport ........................................... 96
14.46 Unsupported ......................................... 102 14.46 Unsupported ......................................... 103
14.47 User-Agent .......................................... 102 14.47 User-Agent .......................................... 103
14.48 Vary ................................................ 102 14.48 Vary ................................................ 103
14.49 Via ................................................. 102 14.49 Via ................................................. 103
14.50 WWW-Authenticate .................................... 102 14.50 WWW-Authenticate .................................... 103
15 Caching ............................................. 102 15 Caching ............................................. 103
16 Examples ............................................ 103 16 Examples ............................................ 104
16.1 Media on Demand (Unicast) ........................... 103 16.1 Media on Demand (Unicast) ........................... 105
16.2 Streaming of a Container file ....................... 106 16.2 Streaming of a Container file ....................... 107
16.3 Single Stream Container Files ....................... 109 16.3 Single Stream Container Files ....................... 110
16.4 Live Media Presentation Using Multicast ............. 111 16.4 Live Media Presentation Using Multicast ............. 112
16.5 Capability Negotiation .............................. 112 16.5 Capability Negotiation .............................. 113
17 Security Framework .................................. 113 17 Security Framework .................................. 114
17.1 RTSP and HTTP Authentication ........................ 114 17.1 RTSP and HTTP Authentication ........................ 115
17.2 RTSP over TLS ....................................... 114 17.2 RTSP over TLS ....................................... 115
17.3 Security and Proxies ................................ 115 17.3 Security and Proxies ................................ 116
17.3.1 Accept-Credentials .................................. 116 17.3.1 Accept-Credentials .................................. 117
17.3.2 User approved TLS procedure ......................... 117 17.3.2 User approved TLS procedure ......................... 118
18 Syntax .............................................. 118 18 Syntax .............................................. 119
18.1 Base Syntax ......................................... 118 18.1 Base Syntax ......................................... 119
18.2 RTSP Protocol Definition ............................ 119 18.2 RTSP Protocol Definition ............................ 121
18.2.1 Generic Protocol elements ........................... 119 18.2.1 Generic Protocol elements ........................... 121
18.2.2 Message Syntax ...................................... 120 18.2.2 Message Syntax ...................................... 122
18.2.3 Header Syntax ....................................... 124 18.2.3 Header Syntax ....................................... 126
19 Security Considerations ............................. 127 19 Security Considerations ............................. 129
20 IANA Considerations ................................. 129 20 IANA Considerations ................................. 131
20.1 Feature-tags ........................................ 130 20.1 Feature-tags ........................................ 131
20.1.1 Description ......................................... 130 20.1.1 Description ......................................... 131
20.1.2 Registering New Feature-tags with IANA .............. 130 20.1.2 Registering New Feature-tags with IANA .............. 132
20.1.3 Registered entries .................................. 130 20.1.3 Registered entries .................................. 132
20.2 RTSP Methods ........................................ 130 20.2 RTSP Methods ........................................ 132
20.2.1 Description ......................................... 130 20.2.1 Description ......................................... 132
20.2.2 Registering New Methods with IANA ................... 131 20.2.2 Registering New Methods with IANA ................... 132
20.2.3 Registered Entries .................................. 131 20.2.3 Registered Entries .................................. 133
20.3 RTSP Status Codes ................................... 131 20.3 RTSP Status Codes ................................... 133
20.3.1 Description ......................................... 131 20.3.1 Description ......................................... 133
20.3.2 Registering New Status Codes with IANA .............. 131 20.3.2 Registering New Status Codes with IANA .............. 133
20.3.3 Registered Entries .................................. 132 20.3.3 Registered Entries .................................. 133
20.4 RTSP Headers ........................................ 132 20.4 RTSP Headers ........................................ 133
20.4.1 Description ......................................... 132 20.4.1 Description ......................................... 133
20.4.2 Registering New Headers with IANA ................... 132 20.4.2 Registering New Headers with IANA ................... 134
20.4.3 Registered entries .................................. 132 20.4.3 Registered entries .................................. 134
20.5 Transport Header registries ......................... 133 20.5 Transport Header registries ......................... 134
20.5.1 Transport Protocols ................................. 133 20.5.1 Transport Protocols ................................. 135
20.5.2 Profile ............................................. 133 20.5.2 Profile ............................................. 135
20.5.3 Lower Transport ..................................... 134 20.5.3 Lower Transport ..................................... 136
20.5.4 Transport modes ..................................... 134 20.5.4 Transport modes ..................................... 136
20.6 Cache Directive Extensions .......................... 135 20.6 Cache Directive Extensions .......................... 136
20.7 Accept-Credentials policies ......................... 135 20.7 Accept-Credentials policies ......................... 137
20.8 URI Schemes ......................................... 136 20.8 URI Schemes ......................................... 138
20.9 SDP attributes ...................................... 136 20.9 SDP attributes ...................................... 138
A RTSP Protocol State Machine ......................... 137 A RTSP Protocol State Machine ......................... 139
A.1 States .............................................. 137 A.1 States .............................................. 139
A.2 State variables ..................................... 138 A.2 State variables ..................................... 139
A.3 Abbreviations ....................................... 138 A.3 Abbreviations ....................................... 140
A.4 State Tables ........................................ 138 A.4 State Tables ........................................ 140
B Media Transport Alternatives ........................ 141 B Media Transport Alternatives ........................ 143
B.1 RTP ................................................. 142 B.1 RTP ................................................. 143
B.1.1 AVP ................................................. 142 B.1.1 AVP ................................................. 143
B.1.2 AVP/UDP ............................................. 142 B.1.2 AVP/UDP ............................................. 144
B.1.3 AVP/TCP ............................................. 144 B.1.3 AVP/TCP ............................................. 146
B.1.4 Handling NPT Jumps in the RTP Media Layer ........... 144 B.1.4 Handling NPT Jumps in the RTP Media Layer ........... 146
B.1.5 Handling RTP Timestamps after PAUSE ................. 147 B.1.5 Handling RTP Timestamps after PAUSE ................. 149
B.1.6 RTSP / RTP Integration .............................. 149 B.1.6 RTSP / RTP Integration .............................. 151
B.1.7 Scaling with RTP .................................... 149 B.1.7 Scaling with RTP .................................... 151
B.1.8 Maintaining NPT synchronization with RTP B.1.8 Maintaining NPT synchronization with RTP
timestamps ..................................................... 150 timestamps ..................................................... 151
B.1.9 Continuous Audio .................................... 150 B.1.9 Continuous Audio .................................... 151
B.1.10 Multiple Sources in an RTP Session .................. 150 B.1.10 Multiple Sources in an RTP Session .................. 152
B.1.11 Usage of SSRCs and the RTCP BYE Message During an B.1.11 Usage of SSRCs and the RTCP BYE Message During an
RTSP Session ................................................... 150 RTSP Session ................................................... 152
B.2 Future Additions .................................... 151 B.2 Future Additions .................................... 152
C Use of SDP for RTSP Session Descriptions ............ 151 C Use of SDP for RTSP Session Descriptions ............ 153
C.1 Definitions ......................................... 151 C.1 Definitions ......................................... 153
C.1.1 Control URI ......................................... 152 C.1.1 Control URI ......................................... 153
C.1.2 Media Streams ....................................... 153 C.1.2 Media Streams ....................................... 154
C.1.3 Payload Type(s) ..................................... 153 C.1.3 Payload Type(s) ..................................... 155
C.1.4 Format-Specific Parameters .......................... 154 C.1.4 Format-Specific Parameters .......................... 155
C.1.5 Range of Presentation ............................... 154 C.1.5 Range of Presentation ............................... 155
C.1.6 Time of Availability ................................ 154 C.1.6 Time of Availability ................................ 156
C.1.7 Connection Information .............................. 155 C.1.7 Connection Information .............................. 156
C.1.8 Entity Tag .......................................... 155 C.1.8 Entity Tag .......................................... 157
C.2 Aggregate Control Not Available ..................... 156 C.2 Aggregate Control Not Available ..................... 157
C.3 Aggregate Control Available ......................... 156 C.3 Aggregate Control Available ......................... 158
C.4 RTSP external SDP delivery .......................... 157 C.4 RTSP external SDP delivery .......................... 159
D Minimal RTSP implementation ......................... 158 D Minimal RTSP implementation ......................... 159
D.1 Client .............................................. 158 D.1 Client .............................................. 159
D.1.1 Basic Playback ...................................... 159 D.1.1 Basic Playback ...................................... 160
D.1.2 Authentication-enabled .............................. 159 D.1.2 Authentication-enabled .............................. 161
D.2 Server .............................................. 159 D.2 Server .............................................. 161
D.2.1 Basic Playback ...................................... 160 D.2.1 Basic Playback ...................................... 162
D.2.2 Authentication-enabled .............................. 161 D.2.2 Authentication-enabled .............................. 162
E Requirements for Unreliable Transport of RTSP E Requirements for Unreliable Transport of RTSP
messages ....................................................... 161 messages ....................................................... 163
F Backwards Compatibility Considerations .............. 162 F Backwards Compatibility Considerations .............. 164
F.1 Requirement on Pause before Play in Play mode ....... 162 F.1 Requirement on Pause before Play in Play mode ....... 164
F.2 Usage of persistent connections ..................... 163 F.2 Using Persistent Connections ........................ 164
G Open Issues ......................................... 163 G Open Issues ......................................... 164
H Changes ............................................. 164 H Changes ............................................. 166
H.1 Issues Addressed .................................... 164 H.1 Issues Addressed .................................... 166
H.2 Changes made to the protocol and specification ...... 165 H.2 Changes made to the protocol and specification
I Author Addresses .................................... 170 .............................................................. 167
J Contributors ........................................ 171 I Author Addresses .................................... 172
K Acknowledgements .................................... 171 J Contributors ........................................ 172
L Normative References ................................ 172 K Acknowledgements .................................... 173
M Informative References .............................. 173 L Normative References ................................ 173
M Informative References .............................. 175
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 [23]. 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 H 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 G. 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.
skipping to change at page 9, line 39 skipping to change at page 9, line 39
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." [23]. with Firewalls." [24].
There have also been discussion or proposals about the following There have also been discussion or proposals about the following
extensions to RTSP: extensions to RTSP:
o Mute and Unmute Extension [24]. o Mute and Unmute Extension [25].
o RTSP Stream Switching [25]. o RTSP Stream Switching [26].
o Live Streaming Relays [26]. o Live Streaming Relays [27].
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 An RTSP MIB. o An RTSP MIB.
skipping to change at page 10, line 34 skipping to change at page 10, line 34
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 needs to 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. [23] 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 an RTSP session is defined by The set of streams to be controlled in an RTSP session is defined by
a 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 [1] 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 [2] 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 [3]
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 An RTSP server needs to maintain state by default in almost o An RTSP server needs to maintain state by default in almost
skipping to change at page 11, line 19 skipping to change at page 11, line 19
o Both an 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
[27]. [28].
o The Request-URI always contains the absolute URI. 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 [3]
carries only the absolute path in the request and puts the carries only the absolute path in the request and puts the
host name in a separate header field. host name in a separate header field.
This makes "virtual hosting" easier, where a single This makes "virtual hosting" easier, where a single
host with one IP address hosts several document trees. host with one IP address hosts several document trees.
The protocol supports the following operations: The protocol supports the following operations:
Retrieval of media from media server: The client can either Retrieval of media from media server: The client can either
request a presentation description via RTSP DESCRIBE, HTTP request a presentation description via RTSP DESCRIBE, HTTP
skipping to change at page 11, line 48 skipping to change at page 11, line 48
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
example distributed teaching applications. Several parties example distributed teaching applications. Several parties
in the conference may take turns "pushing the remote in the conference may take turns "pushing the remote
control 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 [3].
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 [3]).
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 [4].
Indented and smaller-type paragraphs are used to provide informative Indented and smaller-type paragraphs are used to provide informative
background and motivation. This is intended to give readers who were background and motivation. This is intended to give readers who were
not involved with the formulation of the specification an not involved with the formulation of the specification an
understanding 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 [5].
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 [3]. 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 URI: The URI used in an 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
skipping to change at page 14, line 32 skipping to change at page 14, line 29
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. Presentations presentation description as defined below. Presentations
with more than one media stream is often handled in RTSP with more than one media stream is often handled in RTSP
under aggregate control. 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 [1]) 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: An RTSP response. If an HTTP response is meant, that Response: An RTSP response. If an HTTP response is meant, that
is indicated explicitly. is indicated explicitly.
Request: An 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.
skipping to change at page 15, line 26 skipping to change at page 15, line 23
existence of a session implies the existence of state about existence of a session implies the existence of state about
the session's media streams and their respective transport the session's media streams and their respective transport
mechanisms. A given session can have zero or more media mechanisms. A given session can have zero or more media
streams associated with it. An RTSP server uses the session streams associated with it. An RTSP server uses the session
to aggregate control 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 3986 [18]. In RTSP
the used URIs are as general rule in fact URI'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
URIs are a subset of URIs, they will be refered as URIs. URIs are a subset of URIs, they will be refered as URIs.
URI: 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.
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 [6]) 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 [3]) and digest authentication (RFC 2617 [7]) 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]) as it unreliable datagram protocol (UDP) (RFC 768 [8]) as it
would be possible to implement application-level would be possible to implement application-level
reliability. The use of a connectionless datagram protocol reliability. The use of a connectionless datagram protocol
such as UDP requires additional definition that may be such as UDP requires additional definition that may be
provided as extensions to the core RTSP specification. The provided as extensions to the core RTSP specification. The
usage of the reliable stream protocol TCP (RFC 793 [10]) usage of the reliable stream protocol TCP (RFC 793 [9]) and
and secured reliable stream protocol TLS over TCP [7] is secured reliable stream protocol TLS over TCP [6] is what
what is currently defined as transport protocol of RTSP is currently defined as 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 [28] or H.323 [29] may be conference. In particular, SIP [29] or H.323 [30] 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 is required to contain at least presentation description is required to contain at least
one RTSP URI. 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
[30]) firewalls. A firewall may need to understand the [31]) firewalls. A firewall may need to understand the
SETUP method to open a "hole" for the media stream. SETUP method to open a "hole" for the media stream.
HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so
that the existing infrastructure can be reused. This that the existing infrastructure can be reused. This
infrastructure includes PICS (Platform for Internet Content infrastructure includes PICS (Platform for Internet Content
Selection [31,32]) for associating labels with content. Selection [32,33]) 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
needs to 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
skipping to change at page 17, line 28 skipping to change at page 17, line 25
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 o Some server may support an RTSP extension, for example the
currently proposed "end of stream" indication. 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 [3],
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
skipping to change at page 20, line 27 skipping to change at page 20, line 24
been acknowledged. been acknowledged.
Re-using HTTP functionality has advantages in at least two Re-using HTTP functionality has advantages in at least two
areas, namely security and proxies. The requirements are areas, namely security and proxies. The requirements are
very similar, so having the ability to adopt HTTP work on very similar, so having the ability to adopt HTTP work on
caches, proxies and authentication is valuable. caches, proxies and authentication is valuable.
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 [1] 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
skipping to change at page 21, line 20 skipping to change at page 21, line 18
needed for the content. Other information that are needed for the content. Other information that are
important; how many media stream that the presentation important; how many media stream that the presentation
contains; what transport protocols to use for the media contains; what transport protocols to use for the media
streams; and identifiers for these media streams. This streams; and identifiers for these media streams. This
information is required before setup of the content is information is required before setup of the content is
possible. The information is also needed by the client to possible. The information is also needed by the client to
determine if it is capable at all to support the content. determine if it is capable at all to support the content.
This information is not required to be sent using RTSP, This information is not required to be sent using RTSP,
instead other external protocols can be utilized to instead other external protocols can be utilized to
transport presentation descriptions. Two good examples are transport presentation descriptions. Two good examples are
the use of HTTP [4] or email to fetch or receive the use of HTTP [3] or email to fetch or receive
presentation descriptions like SDP [2]. .XP Setup: presentation descriptions like SDP [1]. .XP Setup:
Performing setup of some or all of the media streams in a Performing setup of some or all of the media streams in a
presentation. The setup itself consist of determining which presentation. The setup itself consist of determining which
protocols for media transport to use; the necessary protocols for media transport to use; the necessary
parameters for the protocol, like addresses and ports. .XP parameters for the protocol, like addresses and ports. .XP
Control of Transmission: After the necessary media streams Control of Transmission: After the necessary media streams
has been established the client can request the server to has been established the client can request the server to
start transmitting the content. There is need to allow the start transmitting the content. There is need to allow the
client to arbitrary times start or stop the transmission of client to arbitrary times start or stop the transmission of
the content. There are also exist need to be able to start the content. There are also exist need to be able to start
the transmission at an any point in the timeline of the the transmission at an any point in the timeline of the
presentation. .XP Synchronization: For media transport presentation. .XP Synchronization: For media transport
protocols like RTP [17] it might be beneficial to carry protocols like RTP [16] it might be beneficial to carry
synchronization information within RTSP. Either due to the synchronization information within RTSP. Either due to the
lack of inter media synchronization within the protocol lack of inter media synchronization within the protocol
itself, or the potential delay before the synchronization itself, or the potential delay before the synchronization
is established (which is the case for RTP when using RTCP). is established (which is the case for RTP when using RTCP).
.XP Termination There is also need to be able to terminate .XP Termination There is also need to be able to terminate
the established contexts. the established contexts.
For this use cases there is a number of assumption about how it For this use cases there is a number of assumption about how it
works. These are listed below: works. These are listed below:
On-Demand content: The content available is stored at the server On-Demand content: The content available is stored at the server
skipping to change at page 24, line 48 skipping to change at page 24, line 45
messages over unreliable transport (UDP) and is currently deprecated messages over unreliable transport (UDP) and is currently deprecated
and reserved, and MUST NOT be used . See Appendix E for further and reserved, and MUST NOT be used . See Appendix E for further
information. information.
Informative RTSP URI 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 URI syntax. See section 18.2.1 for the formal definition of the RTSP URI syntax.
The fragment identifier is used as defined in section 4.1 of [13], The fragment identifier is used as defined in section 4.1 of [18],
i.e. the fragment is to be stripped from the URI by the requestor and i.e. the fragment is to be stripped from the URI by the requestor and
not included in the request. The user agent also needs to interpret not included in the request. The user agent also needs to interpret
the value of the fragment based on the media type the request relates 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 to, i.e. the media type indicated in Content-Type header in the
response to DESCRIBE. response to DESCRIBE.
The syntax of any URI query string is unspecified and responder The syntax of any URI query string is unspecified and responder
(usually the server) specific. As it is from the requestor an opaque (usually the server) specific. As it is from the requestor an opaque
string, it needs to be handled as such. string, it needs to be handled as such.
The URI scheme rtsp requires that commands are issued via a reliable The URI scheme rtsp requires that commands are issued via a reliable
protocol (within the Internet, TCP), while the scheme rtsps protocol (within the Internet, TCP), while the scheme rtsps
identifies a reliable transport using secure transport (TLS [7]). identifies a reliable transport using secure transport (TLS [6]).
If the no port number is provided in the URI, port number 554 SHALL If the no port number is provided in the URI, port number 554 SHALL
be used. The semantics are that the identified resource can be be used. The semantics are that the identified resource can be
controlled by RTSP at the server listening for TCP (scheme "rtsp") controlled by RTSP at the server listening for TCP (scheme "rtsp")
connections on that port of host, and the Request-URI for the 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 resource is rtsp_URI. For the scheme rtsps the TCP and UDP port 322
is registered and SHALL be assumed. is registered and SHALL be assumed.
The use of IP addresses in URIs SHOULD be avoided whenever possible 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 (see RFC 1924 [10]). 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 URIs using the host specification in literal IPv6 addresses in RTSP URIs using the host specification in
RFC 2732 [12]. RFC 2732 [11].
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
URIs (RFC 2396 [13]). URIs may refer to a stream or an aggregate of URIs (RFC 3986 [18]). 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 URI: For example, the RTSP URI:
rtsp://media.example.com:554/twister/audiotrack rtsp://media.example.com:554/twister/audiotrack
skipping to change at page 27, line 9 skipping to change at page 27, line 5
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) [33]. The timestamp consists of with the Network Time Protocol (NTP) [34]. The timestamp consists of
a 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 [34]: "Intuitively, NPT is the clock the NPT is defined as in DSM-CC [35]: "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." 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 [35]. The npt-sec notation The syntax conforms to ISO 8601 [36]. The npt-sec notation
is optimized for automatic generation, the ntp-hhmmss is optimized for automatic generation, the ntp-hhmmss
notation for consumption by human readers. The "now" notation for consumption by human readers. The "now"
constant allows clients to request to receive the live feed constant allows clients to request to receive the live feed
rather than the stored or time-delayed version. This is rather than the stored or time-delayed version. This is
needed since neither absolute time nor zero time are needed since neither absolute time nor zero time are
appropriate for this case. appropriate for this case.
3.6 Absolute Time 3.6 Absolute Time
Absolute time is expressed as ISO 8601 [35] timestamps, using UTC Absolute time is expressed as ISO 8601 [36] timestamps, using UTC
(GMT). 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
skipping to change at page 28, line 41 skipping to change at page 28, line 41
can be carried in the ETag header (see section 14.21) or in SDP (see can be carried in the ETag header (see section 14.21) or in SDP (see
section C.1.8). 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.25 and 14.27. 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 [13]). Lines are terminated by CRLF, but
receivers should be prepared to also interpret CR and LF by receivers should be prepared to also interpret CR and LF by
themselves as line terminators. themselves as line terminators.
Text-based protocols make it easier to add optional Text-based protocols make it easier to add optional
parameters in a self-describing manner. Since the number of parameters in a self-describing manner. Since the number of
parameters and the frequency of commands is low, processing parameters and the frequency of commands is low, processing
efficiency is not a concern. Text-based protocols, if done efficiency is not a concern. Text-based protocols, if done
carefully, also allow easy implementation of research carefully, also allow easy implementation of research
prototypes in scripting languages such as Tcl, Visual Basic prototypes in scripting languages such as Tcl, Visual Basic
and Perl. and Perl.
The 10646 character set avoids tricky character set switching, but is The 10646 character set avoids tricky character set switching, but is
invisible to the application as long as US-ASCII is being used. This invisible to the application as long as US-ASCII is being used. This
is also the encoding used for RTCP. ISO 8859-1 translates directly is also the encoding used for RTCP. ISO 8859-1 translates directly
into Unicode with a high-order octet of zero. ISO 8859-1 characters into Unicode with a high-order octet of zero. ISO 8859-1 characters
with the most-significant bit set are represented as 1100001x with the most-significant bit set are represented as 1100001x
10xxxxxx. (See RFC 2279 [14]) 10xxxxxx. (See RFC 2279 [13])
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].
skipping to change at page 29, line 45 skipping to change at page 29, line 45
(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.16) 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" Unlike an HTTP message, an RTSP message MUST contain a Content-Length
transfer coding(see [H3.6.1]) and requires the presence of the header field whenever it contains a message body. Note that RTSP does
Content-Length header field. not (at present) support the HTTP/1.1 "chunked" transfer coding(see
[H3.6.1]).
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,
skipping to change at page 30, line 48 skipping to change at page 30, line 49
section; section;
o Optionally a message body (entity), consisting of one or more o Optionally a message body (entity), consisting of one or more
lines. the length of the message body in number of bytes is lines. the length of the message body in number of bytes is
indicated by the Content-Length entity header. indicated by the Content-Length entity header.
6.1 Request Line 6.1 Request Line
The request line provides the key information about the request: The request line provides the key information about the request:
What method, on what resources and using which RTSP version. The What method, on what resources and using which RTSP version. The
methods that is defined by this specification can be seen in Table methods that are defined by this specification are listed in Table 2.
6.1. The resource is identified through an absolute RTSP URI (see
section 3.2.
<Method> SP <Request-URI> SP <RTSP-Version> CRLF
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
messages and need to be parsable also by older versions.
Note that in contrast to HTTP/1.1 [4], RTSP requests always contain
the absolute URI (that is, including the scheme, host and port)
rather than just the absolute path.
HTTP/1.1 requires servers to understand the absolute URI,
but clients are supposed to use the Host request header.
This is purely needed for backward-compatibility with
HTTP/1.0 servers, a consideration that does not apply to
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-URI means that the request does not The syntax of the RTSP request line is the following:
apply to a particular resource, but to the server or proxy itself,
and is only allowed when the method used does not necessarily apply
to a resource.
One example would be as follows: <Method> SP <Request-URI> SP <RTSP-Version> CRLF
Note: This syntax cannot be freely changed in future versions of
RTSP. This line needs to remain parsable by older RTSP
implementations since it indicates the RTSP version of the message.
In contrast to HTTP/1.1 [3], RTSP requests identify the resource
through an absolute RTSP URI (scheme, host, and port)(see section
3.2) rather than just the absolute path.
HTTP/1.1 requires servers to understand the absolute URI,
but clients are supposed to use the Host request header.
This is purely needed for backward-compatibility with
HTTP/1.0 servers, a consideration that does not apply to
RTSP.
An asterisk "*" can be used in the Request-URI to indicate that the
request does not apply to a particular resource, but to the server or
proxy itself, and is only allowed when the request method does not
necessarily apply to a resource.
For example:
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 the capability of
the server explicitly, then one should use an absolute URI with the the specific server needs to be determined, without regard to the
server's address. capability of an intervening proxy, the server should be addressed
explicitly with an absolute URI that contains the server's address.
For example:
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, as request
purpose to give further define how the request should be fulfilled. A headers, to modify the specifics of the request. These headers may
request header MAY also be response header, see section 7.1.2. also be used in the response to a request, as response headers, to
modify the specifics of a response (Section 7.1.2).
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.23 From Section 14.23
skipping to change at page 32, line 42 skipping to change at page 32, line 46
Require Section 14.37 Require Section 14.37
Scale Section 14.39 Scale Section 14.39
Session Section 14.42 Session Section 14.42
Speed Section 14.40 Speed Section 14.40
Supported Section 14.43 Supported Section 14.43
Transport Section 14.45 Transport Section 14.45
User-Agent Section 14.47 User-Agent Section 14.47
Table 3: The RTSP request headers Table 3: The RTSP request headers
Detailed headers definition are provided in Section 14.
7 Response 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.
skipping to change at page 34, line 5 skipping to change at page 34, line 10
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-Phrases, 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 [3]
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
unrecognized response MUST NOT be cached. For example, if an unrecognized response MUST NOT be cached. For example, if an
skipping to change at page 35, line 40 skipping to change at page 35, line 44
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 an 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 over two different connection
scenarios listed below:
o persistent transport connections used for several request-
response transactions;
o one connection per request/response transaction;
o connectionless mode.
The type of transport is defined by the RTSP URI (Section 3.2). For o persistent - transport connections used for several
the scheme "rtsp", a connection is assumed, while the scheme "rtsps" request/response transactions;
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 28 skipping to change at page 37, line 28
Session Section 14.42 Session Section 14.42
Server Section 14.41 Server Section 14.41
Speed Section 14.40 Speed Section 14.40
Transport Section 14.45 Transport Section 14.45
Unsupported Section 14.46 Unsupported Section 14.46
Vary Section 14.48 Vary Section 14.48
WWW-Authenticate Section 14.50 WWW-Authenticate Section 14.50
Table 5: The RTSP response headers Table 5: The RTSP response headers
calls for RTSP requests to be sent using a secure protocol. o transient - transport connections used for a single
request/response transaction.
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 RFC 2326 attempted to specify an optional mechanism for transmitting
RTSP messages in connectionless mode over a transport protocol such
as UDP. However, it was not specified in sufficient enough detail to
allow for interoperable implementations. In an attempt to reduce
complexity and scope, and due to lack of interest, this specification
does not attempt to define a mechanism for supporting RTSP over UDP
or other connectionless transport protocols. A side-effect is that
RTSP requests SHALL NOT be sent to multicast groups since no
connection can be established with a specific receiver in multicast
environments.
The transmission of RTSP over UDP was optionally to implement and In order to maintain backwards compatibility of the message format,
specified in RFC 2326. However that definition was not sufficient for certain RTSP headers, such as the CSeq header (Section 14.19), which
interoperable implementations. Due to lack of interest, this would be more relevant to a connectionless transport scenario are
specification does not specify how RTSP over UDP is implemented. still retained and must be implemented according to the
However to maintain backwards compatibility in the message format specification.
certain RTSP headers are maintained.
Any RTSP request according to this specification SHALL NOT be sent to 9.1 Reliability and Acknowledgements
a multicast address. Any RTSP request SHALL be acknowledged. If a Since RTSP is transmitted primarily over connection oriented,
reliable transport protocol is used to carry RTSP, requests MUST NOT reliable transport protocols, all RTSP requests MUST be acknowledged
be retransmitted; the RTSP application MUST instead rely on the by the receiver. RTSP requests that are not immediately acknowledged
underlying transport to provide reliability. MUST NOT be retransmitted at the application level. Instead, the
application must rely on the underlying transport to provide
reliability.
If both the underlying reliable transport such as TCP and If both the underlying reliable transport such as TCP and
the RTSP application retransmit requests, it is possible the RTSP application retransmit requests, each packet loss
that each packet loss results in two retransmissions. The or message loss may result in two retransmissions. The
receiver cannot typically take advantage of the receiver typically cannot 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 Lack of acknowledgement of an RTSP request should be handled within
14.19), which MUST be incremented by one for each distinct request the constraints of the connection timeout considerations described
transmitted to the destination end-point. The initial sequence below (Section 9.4).
number MAY be chosen arbitrary, but is RECOMMENDED to begin with 0.
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).
9.3 The usage of connections
Systems implementing RTSP MUST support carrying RTSP over TCP. The 9.2 Using Connections
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
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
Content-Length header field whenever that message contains a payload
(entity). Otherwise, an RTSP packet is terminated with an empty line
immediately following the last message header.
TCP can be used for both persistent connections and for one message A TCP transport can be used for both persistent connections (for
exchange per connection, as presented above. This section gives several message exchanges) and transient connections (for a single
further rules and recommendations on how to handle these connections message exchange). Implementations of this specification MUST support
so maximum interoperability and flexibility can be achieved. RTSP over TCP. The scheme of the RTSP URI (Section 3.2) indicates the
default port that the server will listen on.
A server SHALL handle both persistent connections and one A server MUST handle both persistent and transient connections.
request/response transaction per connection. A persistent connection
MAY be used for all transactions between the server and client,
including messages to multiple RTSP sessions. However the persistent
connection MAY also be closed after a few message exchanges, e.g. the
initial setup and play command in a session. Later when the client
wishes to send a new request, e.g. pause, to the session a new
connection is opened. This connection may either be for a single
message exchange or can be kept open for several messages, i.e.
persistent.
A major motivation for allowing non-persistent connections are that Transient connections facilitate mechanisms for fault
they ensure fault tolerance. A second one is to allow for application tolerance. They also allow for application layer mobility.
layer mobility. A server and client supporting non-persistent A server and client pair that support transient connections
connection can survive a loss of a TCP connection, e.g. due to a NAT can survive the loss of a TCP connection, e.g. due to a NAT
timeout. When the client has discovered that the TCP connection has timeout. When the client has discovered that the TCP
been lost, it can set up a new one when there is need to communicate. connection has been lost, it can set up a new one when
there is need to communicate again.
The client MAY close the connection at any time when no outstanding A persistent connection MAY be used for all transactions between the
request/response transactions exist. The server SHOULD NOT close the server and client, including messages to multiple RTSP sessions.
connection unless at least one RTSP session timeout period has passed However a persistent connection MAY also be closed after a few
without data traffic. A server SHOULD NOT initiate a close of a message exchanges. For example, a client may use a persistent
connection directly after responding to a TEARDOWN request for the connection for the initial SETUP and PLAY message exchanges in a
whole session. A server SHOULD NOT close the connection as a result session and then close the connection. Later, when the client wishes
of responding to a request with an error code. Doing this would to send a new request, such as a PAUSE for the session, a new
prevent or result in extra overhead for the client when testing connection would be opened. This connection may either be transient
advanced or special types of requests. or persistent.
The client SHOULD NOT have more than one connection to the server at A 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 SHOULD use only one connection for managing
connection. those sessions.
A Client is strongly RECOMMENDED to use persistent connections as it This saves connection resources on the server. It also
allows the server to send request to the client. In cases where no reduces complexity by and enabling the server to maintain
connection exist between the server and the client, this may cause less state about its sessions and connections.
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
an RTSP session to the client.
A server implemented according to this specification MUST respond Unlike HTTP, RTSP allows a server to send requests to a client.
that it supports the "play.basic" feature-tag above. A client MAY However, this can be supported only if a client establishes a
send a request including the Supported header in a request to persistent connection with the server. In cases where a persistent
determine support of non-persistent connections. A server supporting connection does not exist between a server and its client, due to the
non-persistent connections will return the "play.basic" feature-tag lack of a signalling channel, the server may be forced to drop an
in its response. If the client receives the feature-tag in the RTSP session without notifying the client. An example of such a case
response, it can be certain that the server handles non-persistent is when the server desires to send a REDIRECT request for an RTSP
session to the client but is not able to do so because it cannot
reach the client.
Without a persistent connection between the client and the
server, the media server has no reliable way of reaching
the client. Also, this is the only way that requests from a
media server to its client are likely to traverse
firewalls.
In light of the above, it is RECOMMENDED that clients use persistent
connections whenever possible. There are also backwards compatibility
considerations for clients in supporting persistent connections
(Section F.2). A client that supports persistent connections 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 order that the requests were received.
Server-side support for transient and persistent connections is
subsumed in the "play.basic" feature-tag. A client may use capability
negotiation (Section 10, Section 16.5) to discover if a server
supports "play.basic" and, consequently, transient and persistent
connections. connections.
9.4 Timing Out RTSP messages 9.3 Closing Connections
The client MAY close a connection at any point when no outstanding
request/response transactions exist for any RTSP session being
managed through the connection. The server, however, SHOULD NOT close
a connection until all RTSP sessions being managed through the
connection have been timed out (Section 14.42). A server SHOULD NOT
close a connection immediately after responding to a session-level
TEARDOWN request for the last RTSP session being controlled through
the connection. Instead, it should wait for a reasonable amount of
time for the client to: receive the TEARDOWN response, take
appropriate action, and initiate the connection closing. The server
SHOULD wait at least 10 seconds after sending the TEARDOWN response
before closing the connection.
This is to ensure that the client has time to issue a SETUP
for a new session on the existing connection after having
torn the last one down. 10 seconds should give the client
an opportunity get its message to the server.
A server SHOULD NOT close the connection directly as a result of
responding to a request with an error code.
Certain error responses such as "460 Only Aggregate
Operation Allowed" (Section 13.4.12) are used for
negotiating capabilities of a server with respect to
content or other factors. In such cases, it is inefficient
for the server to close a connection on an error response.
Also, such behavior would prevent implementation of
advanced/special types of requests or result in extra
overhead for the client when testing for new features. On
the flip side, keeping connections open after sending an
error response poses a Denial of Service security risk
(Section 19).
If a server initiates a connection close while the client is
attempting to send a new request, the client will have to close its
current connection, establish a new connection and send its request
over the new connection.
An RTSP message should not be terminated through a connection close.
Such a message will be considered to be incomplete by the receiver
and discarded. An RTSP message is properly terminated as defined in
Section 4.
9.4 Timing Out Connections and RTSP Messages
Receivers of a request (responder) SHOULD respond to requests in a Receivers of a request (responder) SHOULD respond to requests in a
timely manner even when a reliable transport such as TCP is used. timely manner even when a reliable transport such as TCP is used.
Similarly, the sender of a request (requestor) SHOULD wait for a Similarly, the sender of a request (requestor) SHOULD wait for a
sufficient time for a response before concluding that the responder sufficient time for a response before concluding that the responder
will not be acting upon its request. will not be acting upon its request.
A responder SHOULD respond to all requests within 5 seconds. If the A responder SHOULD respond to all requests within 5 seconds. If the
responder recognizes that processing of a request will take longer responder recognizes that processing of a request will take longer
than 5 seconds, it SHOULD send a 100 response as soon as possible. It than 5 seconds, it SHOULD send a 100 response as soon as possible. It
SHOULD continue sending a 100 response every 5 seconds thereafter SHOULD continue sending a 100 response every 5 seconds thereafter
until it is ready to send the final response to the requestor. After until it is ready to send the final response to the requestor. After
sending a 100 response, the receiver MUST send a final response sending a 100 response, the receiver MUST send a final response
indicating the success or failure of the request. indicating the success or failure of the request.
A requestor SHOULD wait at least 10 seconds for a response before A requestor SHOULD wait at least 10 seconds for a response before
concluding that the responder will not be responding to its request. concluding that the responder will not be responding to its request.
After receiving a 100 response, the requestor SHOULD continue waiting After receiving a 100 response, the requestor SHOULD continue waiting
for further responses. If more than 10 seconds elapses without for further responses. If more than 10 seconds elapses without
receiving any response, the requestor MAY assume the responder is receiving any response, the requestor MAY assume that the responder
unresponsive and abort the connection. is 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 of the
Timestamp header (section 14.44) in any RTSP request. request/response cycle using the Timestamp header (section 14.44) in
any RTSP request.
9.5 Use of IPv6 9.5 Use of IPv6
This specification has been updated so that it supports IPv6. Since explicit IPv6 support was not present in RFC 2326, some
However this support was not present in RFC 2326 therefore some interoperability issues do exist when working with older
interoperability issues exist. A RFC 2326 implementation can support implementations. An RFC 2326 implementation can support IPv6 as long
IPv6 as long as no explicit IPv6 addresses are used within RTSP as no literal IPv6 addresses are used within RTSP messages. Thus,
messages. This require that any RTSP URI pointing at a IPv6 host RTSP URIs pointing to IPv6 hosts need to use fully qualified domain
needs to use fully qualified domain name and not an IPv6 address. names instead of literal IPv6 addresses. Further, in an IPv6
Further the Transport header can not use the parameters source and environment, the Transport header cannot include the source or
destination. destination parameters as they require literal addresses.
Implementations according to this specification MUST understand IPv6 This specification has been updated for explicit IPv6 support.
addresses in URIs, and headers. By this requirement the feature-tag Implementations of this specifiation MUST understand literal IPv6
"play.basic" can be used to determine that a server or client is addresses in URIs and headers. This requirement is subsumed in the
capable of handling IPv6 within RTSP. "play.basic" feature-tag. Capability negotiation (Section 10, Section
16.5) for the "play.basic" feature-tag can be used to determine if a
client or server supports literal IPv6 addresses.
10 Capability Handling 10 Capability Handling
This section 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 both cases. mechanism is designed to handle both cases.
When a method is added, the involved parties can use the OPTIONS When a method is added, the involved parties can use the OPTIONS
skipping to change at page 42, line 42 skipping to change at page 43, line 44
not supported. This information allows the requestor to not supported. This information allows the requestor to
make the best of situations as it knows which features are 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-URI. The method name is case-sensitive. identified by the Request-URI. The method name is case-sensitive.
New methods may be defined in the future. Method names SHALL NOT New methods may be defined in the future. Method names SHALL NOT
start with a $ character (decimal 24) and MUST be a token as defined start with a $ character (decimal 24) and MUST be a token as defined
by the ABNF [5]. Methods are summarized in Table 7. by the ABNF [4]. Methods are summarized in Table 7.
Note on Table 7: PAUSE is recommended, but not required. Note on Table 7: PAUSE is recommended, but not required.
For example, a fully functional server can be built to For example, a fully functional server can be built to
deliver live feeds, which do not support this method. 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
If an 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. 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 is HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is
bi-directional, in that a client can request it to a server and vice bi-directional, in that a client can 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
skipping to change at page 48, line 12 skipping to change at page 49, line 14
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 URI 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 URI enables the resource in question to where the control URI enables the resource in question to
be easily identified. The Aggregate control URI 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 URI allows on. Finally, presence of the Aggregate control URI allows
for backwards compatibility with RFC 2326 [1]. for backwards compatibility with RFC 2326 [23].
A session will exist until it is either removed by a TEARDOWN request A session will exist until it is either removed by a TEARDOWN request
or is timed-out by the server. The server MAY remove a session that or is timed-out by the server. The server MAY remove a session that
has not demonstrated liveness signs from the client(s) within a has not demonstrated liveness signs from the client(s) within a
certain timeout period. The default timeout value is 60 seconds; the certain timeout period. The default timeout value is 60 seconds; the
server MAY set this to a different value and indicate so in the server MAY set this to a different value and indicate so in the
timeout field of the Session header in the SETUP response. For timeout field of the Session header in the SETUP response. For
further discussion see section 14.42. Signs of liveness for an RTSP further discussion see section 14.42. Signs of liveness for an RTSP
session are: session are:
skipping to change at page 53, line 5 skipping to change at page 54, line 5
RTP-Info:url=rtsp://example.com/meeting.en; RTP-Info:url=rtsp://example.com/meeting.en;
seq=53745;rtptime=484589019 seq=53745;rtptime=484589019
All range specifiers in this specification allow for ranges with All range specifiers in this specification allow for ranges with
unspecified begin times (e.g. "npt=-30"). When used in a PLAY unspecified begin times (e.g. "npt=-30"). When used in a PLAY
request, the server treats this as a request to start/resume playback request, the server treats this as a request to start/resume playback
from the current pause point, ending at the end time specified in the from the current pause point, ending at the end time specified in the
Range header. If the pause point is located later than the given end Range header. If the pause point is located later than the given end
value, a 457 (Invalid Range) response SHALL be given. value, a 457 (Invalid Range) response SHALL be given.
The queued play functionality described in RFC 2326 [1] is removed The queued play functionality described in RFC 2326 [23] 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 respond 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 deprecated. 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
skipping to change at page 67, line 20 skipping to change at page 68, line 20
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 contained in the request. When returning this error message the
sender SHOULD return a entity body containing the offending sender SHOULD return a entity body containing the offending
parameter(s). 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 [23] 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.
13.4.6 454 Session Not Found 13.4.6 454 Session Not Found
The RTSP session identifier in the Session header is missing, The RTSP session identifier in the Session header is missing,
skipping to change at page 69, line 32 skipping to change at page 70, line 32
Table 8: Overview of RTSP methods, their direction, and what objects Table 8: Overview of RTSP methods, their direction, and what objects
(P: presentation, S: stream) they operate on. Body notes if a method (P: presentation, S: stream) they operate on. Body notes if a method
is allowed to carry body and in which direction, R = Request, is allowed to carry body and in which direction, R = Request,
r=response. Note: It is allowed for all error messages 4xx and 5xx to r=response. Note: It is allowed for all error messages 4xx and 5xx to
have a body have a body
The general syntax for header fields is covered in Section 4.2 This The general syntax for header fields is covered in Section 4.2 This
section lists the full set of header fields along with notes on section lists the full set of header fields along with notes on
meaning, and usage. The syntax definition for headers are present in meaning, and usage. The syntax definition for headers are present in
section 18.2.3. Throughout this section, we use [HX.Y] to refer to section 18.2.3. Throughout this section, we use [HX.Y] to refer to
Section X.Y of the current HTTP/1.1 specification RFC 2616 [4]. Section X.Y of the current HTTP/1.1 specification RFC 2616 [3].
Examples of each header field are given. Examples of each header field are given.
Information about header fields in relation to methods and proxy Information about header fields in relation to methods and proxy
processing is summarized in 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;
skipping to change at page 73, line 45 skipping to change at page 74, line 45
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.
contains zero or more of credentials that the client accept. Each contains zero or more of credentials that the client accept. Each
credential SHALL consist of one URI identifying the proxy or server, credential SHALL consist of one URI identifying the proxy or server,
and the SHA-1 [15] hash computed over that entity's DER encoded and the SHA-1 [14] hash computed over that entity's DER encoded
certificate [16] in Base64 [36]. certificate [15] in Base64 [37].
Example: Example:
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
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 - -
skipping to change at page 80, line 11 skipping to change at page 81, line 7
14.12 Connection-Credentials 14.12 Connection-Credentials
The Connection-Credentials response header is used to carry the The Connection-Credentials response header is used to carry the
credentials of any next hop that need to be approved by the credentials of any next hop that need to be approved by the
requestor. It SHALL only be used in server to client responses. requestor. It SHALL only be used in server to client responses.
The Connection-Credentials header in an RTSP response SHALL, if The Connection-Credentials header in an RTSP response SHALL, if
included, contain the credentials information of the next hop that an included, contain the credentials information of the next hop that an
intermediary needs to securely connect to. The credential MUST intermediary needs to securely connect to. The credential MUST
include the URI of the next proxy or server and the DER encoded include the URI of the next proxy or server and the DER encoded
X.509v3 [16] certificate in base64 [36]. X.509v3 [15] certificate in base64 [37].
Example: Example:
Accept-Credentials:"rtsps://proxy2.example.com/";MIIDNTCCAp6gA... Accept-Credentials:"rtsps://proxy2.example.com/";MIIDNTCCAp6gA...
14.13 Content-Base 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
URI for resolving relative URIs 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
skipping to change at page 81, line 22 skipping to change at page 82, line 18
14.19 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 0.
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
and the server has another when sending request to the client. Each server and the server has another when sending request to the client.
requester and responder is identified with its network address. Each requester and responder is identified with its network address.
Example: Example:
CSeq: 239 CSeq: 239
14.20 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.
skipping to change at page 86, line 27 skipping to change at page 87, line 22
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.34 Range 14.34 Range
The Range request and response header field specifies a range of The Range header specifies a time range in PLAY (Section 11.4), PAUSE
time. The header is used in PLAY request to indicate the range of (Section 11.5), SETUP (Section 11.3), and REDIRECT (Section 11.9)
time the client desires the server to play back. The Range header in requests and/or responses.
a PLAY indicates what range of time that is actually being played. In
a SETUP response the header MAY be used, to ensure correct
synchronization information after changes of transport parameters.
The range can be specified in a number of units. This specification The range can be specified in a number of units. This specification
defines the smpte (Section 3.4), npt (Section 3.5), and clock defines smpte (Section 3.4), npt (Section 3.5), and clock (Section
(Section 3.6) range units. Within RTSP, byte ranges [H14.35.1] are 3.6) range units. While byte ranges [H14.35.1] and other extended
normally not meaningful, and the behavior is unspecified, but they units MAY be used, their behavior is unspecified since they are not
and other extended units MAY be used. Servers supporting the Range normally meaningful in RTSP. Servers supporting the Range header MUST
header MUST understand the NPT range format and SHOULD understand the understand the NPT range format and SHOULD understand the SMPTE range
SMPTE range format. If the Range header is given in a time format format. If the Range header is sent in a time format that is not
that is not understood, the recipient should return 456 (Header Field understood, the recipient SHOULD return 456 (Header Field Not Valid
Not Valid for Resource) and include a Accept-Ranges header indicating for Resource) and include an Accept-Ranges header indicating the
which time format that is supported for this resource. supported time formats for the given resource.
The header MAY contain a time parameter in UTC, specifying the time The Range header MAY contain a time parameter in UTC, specifying the
at which the operation is to be made effective. This functionality time at which the operation is to be made effective. This
SHALL only be used with the REDIRECT method. functionality SHALL be used only with the REDIRECT method.
Ranges are half-open intervals, including the first point, but Ranges are half-open intervals, including the first point, but
excluding the second point. In other words, a range of A-B starts excluding the second point. In other words, a range of A-B starts
exactly at time A, but stops just before B. Only the start time of a exactly at time A, but stops just before B. Only the start time of a
media unit such as a video or audio frame is relevant. As an example, media unit such as a video or audio frame is relevant. For example,
assume that video frames are generated every 40 ms. A range of assume that video frames are generated every 40 ms. A range of
10.0-10.1 would include a video frame starting at 10.0 or later time 10.0-10.1 would include a video frame starting at 10.0 or later time
and would include a video frame starting at 10.08, even though it and would include a video frame starting at 10.08, even though it
lasted beyond the interval. A range of 10.0-10.08, on the other hand, lasted beyond the interval. A range of 10.0-10.08, on the other hand,
would exclude the frame at 10.08. would exclude the frame at 10.08.
Example: Example:
Range: clock=19960213T143205Z-;time=19970123T143720Z Range: clock=19960213T143205Z-;time=19970123T143720Z
The notation is similar to that used for the HTTP/1.1 [4] The notation is similar to that used for the HTTP/1.1 [3]
byte-range header. It allows clients to select an excerpt byte-range header. It allows clients to select an excerpt
from the media object, and to play from a given point to from the media object, and to play from a given point to
the end as well as from the current location to a given the end as well as from the current location to a given
point. The start of playback can be scheduled for any time point. The start of playback can be scheduled for any time
in the future, although a server may refuse to keep server in the future, although a server may refuse to keep server
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.
skipping to change at page 87, line 41 skipping to change at page 88, line 32
However, range intervals can also decrease if the Scale header (see However, range intervals can also decrease if the Scale header (see
section 14.39) 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
when B=0 in a decreasing range. In this case, the range is closed on when B=0 in a decreasing range. In this case, the range is closed on
both ends, as otherwise there would be no way to reach 0 on a reverse both ends, as otherwise there would be no way to reach 0 on a reverse
playback. playback.
Example: Example:
Scale: -1 Scale: -1
Range: npt=15-0 Range: npt=15-0
skipping to change at page 90, line 6 skipping to change at page 90, line 42
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 URI which for which the following RTP url: Indicates the stream URI which for which the following RTP
parameters correspond, this URI MUST be the same used in parameters correspond, this URI MUST be the same used in
the SETUP request for this media stream. Any relative URI the SETUP request for this media stream. Any relative URI
SHALL use the Request-URI as base URI. SHALL use the Request-URI as base URI. This parameter SHALL
be present.
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. This parameter is RECOMMENDED to be present.
rtptime: Indicates the RTP timestamp corresponding to the time rtptime: SHALL indicate the RTP timestamp value corresponding to
value in the Range response header. (Note: For aggregate the start time value in the Range response header, or if
control, a particular stream may not actually generate a not explicitly given the implied start point. The client
packet for the Range time value returned or implied. Thus, uses this value to calculate the mapping of RTP time to NPT
there is no guarantee that the packet with the sequence or other media timescale. This parameter SHOULD be present
number indicated by seq actually has the timestamp to ensure inter-media synchronization is achieved. There
indicated by rtptime.) The client uses this value to exist no requirement that any received RTP packet will have
calculate the mapping of RTP time to NPT. the same RTP timestamp value as the one in the parameter
used to establish synchronization.
A mapping from RTP timestamps to NTP timestamps (wall A mapping from RTP timestamps to NTP timestamps (wall
clock) is available via RTCP. However, this clock) is available via RTCP. However, this information is
information is not sufficient to generate a mapping not sufficient to generate a mapping from RTP timestamps to
from RTP timestamps to NPT. Furthermore, in order to media clock time (NPT, etc.). Furthermore, in order to
ensure that this information is available at the ensure that this information is available at the necessary
necessary time (immediately at startup or after a time (immediately at startup or after a seek), and that it
seek), and that it is delivered reliably, this mapping is delivered reliably, this mapping is placed in the RTSP
is placed in the RTSP control channel. 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
NTP, using initial RTCP sender reports to do the mapping, initial RTCP sender reports to do the mapping, and later reports to
and later reports to check drift against the mapping. check drift against the mapping.
Example:
Range:npt=3.25-15
RTP-Info:url=rtsp://example.com/foo/audio;seq=45102;rtptime=12345678,
url=rtsp://example.com/foo/video;seq=30211;rtptime=29567112
Lets assume that audio uses a 16kHz RTP timestamp clock and Video
a 90kHz RTP timestamp clock. Then the media synchronization is
depicted in the following way.
NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6
Audio PA A
Video V PV
X: NPT time value = 3.25, from Range header.
A: RTP timestamp value for Audio from RTP-Info header (12345678).
V: RTP timestamp value for Video from RTP-Info header (29567112).
PA: RTP audio packet carrying an RTP timestamp of 12344878. Which
corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2
PV: RTP video packet carrying an RTP timestamp of 29573412. Which
corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32
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.45). 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 needs to be used to map RTP and NTP transmitting media, RTCP needs to be used to map RTP and NTP
timestamps for those sources, for both synchronization and drift- timestamps for those sources, for both synchronization and drift-
checking. Due to backwards compatibility reasons these shortcomings checking. Due to backwards compatibility reasons these shortcomings
can't be fixed without defining a new header, which is for future can't be fixed without defining a new header, which is for future
work if needed. 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 an URI 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 [23].
Example:
RTP-Info: url=rtsp://example.com/bar.avi/streamid=0;seq=45102,
url=rtsp://example.com/bar.avi/streamid=1;seq=30211
14.39 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
skipping to change at page 101, line 7 skipping to change at page 102, line 13
port=3456-3457. This parameter SHALL NOT be used when port=3456-3457. This parameter SHALL NOT be used when
src_addr and dest_addr is used in a transport declaration. src_addr and dest_addr is used in a transport declaration.
server_port: This parameter provides the unicast RTP/RTCP port server_port: This parameter provides the unicast RTP/RTCP port
pair on the server where media data and control information pair on the server where media data and control information
is to be sent. It is specified as a range, e.g., is to be sent. It is specified as a range, e.g.,
port=3456-3457. This parameter SHALL NOT be used when port=3456-3457. This parameter SHALL NOT be used when
src_addr and dest_addr is used in a transport declaration. src_addr and dest_addr is used in a transport declaration.
ssrc: The ssrc parameter, if included in a SETUP response, ssrc: The ssrc parameter, if included in a SETUP response,
indicates the RTP SSRC [17] value(s) that will be used by indicates the RTP SSRC [16] value(s) that will be used by
the media server for RTP packets within the stream. It is the media server for RTP packets within the stream. It is
expressed as an eight digit hexadecimal value. Multiple expressed as an eight digit hexadecimal value. If the
values MAY only be specified if the client has indicated client has indicated support for a minimal implementation
support for this specification, i.e. if including multiple of this specification (Section 10), a list of SSRC values
SSRC values, the request is required to include the MAY be specified by the server. The first value listed
"Require: play.basic" or "Supported: play.basic" headers. should correspond to the source whose synchronization
If no such support is present only a single value SHALL be information is provided in the RTP-Info header. Regardless,
included. there may be other sources not listed whose ssrc's must be
deduced from the actual RTP/RTCP stream.
If the server does not act as a synchronization source for If a client does not support a minimal implementation of
this specification, a server SHALL include only a single
value for the ssrc parameter. Under this circumstance, if
the server does not act as a synchronization source for
stream data (for instance, server is a translator, stream data (for instance, server is a translator,
reflector, etc.), and only a single value can be specified, reflector, etc.), the value will be the "packet sender's
the value will be the "packet sender's SSRC" that would SSRC" that would have been used in the RTCP Receiver
have been used in the RTCP Receiver Reports generated by Reports generated by the server, regardless of whether the
the server, regardless of whether the server actually server actually generates RTCP RRs.
generates RTCP RRs.
The first SSRC value is the one that RTP-Info
synchronization information relates to, see section 14.38.
The functionality of specifying the ssrc parameter in a The functionality of specifying the ssrc parameter in a
SETUP request is deprecated as it is incompatible with the SETUP request is deprecated as it is incompatible with the
specification of RTP in RFC 3550 [17]. If the parameter is specification of RTP in RFC 3550 [16]. If the parameter is
included in the transport header of a SETUP request, the included in the Transport header of a SETUP request, the
server MAY ignore it, and choose an appropriate SSRC for server MAY ignore it, and choose an appropriate SSRC for
the stream. The server MAY set the ssrc parameter in the the stream. The server MAY set the ssrc parameter in the
transport header of the response. Transport header of the response.
The combination of transport protocol, profile and lower transport The combination of transport protocol, profile and lower transport
needs to be defined. A number of combinations are defined in the needs to be defined. A number of combinations are defined in the
appendix B. appendix B.
Below is a usage example, showing a client advertising the capability Below is a usage example, showing a client advertising the capability
to handle multicast or unicast, preferring multicast. Since this is to handle multicast or unicast, preferring multicast. Since this is
a unicast-only stream, the server responds with the proper transport a unicast-only stream, the server responds with the proper transport
parameters for unicast. parameters for unicast.
skipping to change at page 111, line 25 skipping to change at page 112, line 29
C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/1.0 C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/1.0
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
16.4 Live Media Presentation Using Multicast 16.4 Live Media Presentation Using Multicast
The media server M chooses the multicast address and port. Here, it The media server M chooses the multicast address and port. Here, it
is assumed that the web server only contains a pointer to the full is assumed that the web server only contains a pointer to the full
description, while the media server M maintains the full description. description, while the media server M maintains the full description.
Editors note: Is this example really valid? In what situations does
it make sense to do a setup to a multicast distribution channel, and
also issue PLAY requests?
C->W: GET /sessions.html HTTP/1.1 C->W: GET /sessions.html HTTP/1.1
Host: www.example.com Host: www.example.com
W->C: HTTP/1.1 200 OK W->C: HTTP/1.1 200 OK
Content-Type: text/html Content-Type: text/html
<html> <html>
... ...
<href "Stremed Live Music performance" <href "Stremed Live Music performance"
src="rtsp://live.example.com/concert/audio"> src="rtsp://live.example.com/concert/audio">
skipping to change at page 113, line 43 skipping to change at page 115, line 4
S->C: RTSP/1.0 200 OK S->C: RTSP/1.0 200 OK
CSeq: 3 CSeq: 3
Session: 12345678 Session: 12345678
Transport: RTP/AVP/UDP;unicast;client_port=3056-3057; Transport: RTP/AVP/UDP;unicast;client_port=3056-3057;
server_port=5000-5001 server_port=5000-5001
Server: PhonyServer/2.0 Server: PhonyServer/2.0
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
17 Security Framework 17 Security Framework
The RTSP security framework consists of two high level components: The RTSP security framework consists of two high level components:
the pure authentication mechanisms based on HTTP authentication, and the pure authentication mechanisms based on HTTP authentication, and
the transport protection based on TLS, which is independent of RTSP. the transport protection based on TLS, which is independent of RTSP.
Because of the similarity in syntax and usage between RTSP servers Because of the similarity in syntax and usage between RTSP servers
and HTTP servers, the security for HTTP is re-used to a large extent. and HTTP servers, the security for HTTP is re-used to a large extent.
17.1 RTSP and HTTP Authentication 17.1 RTSP and HTTP Authentication
RTSP and HTTP share common authentication schemes, and thus follow RTSP and HTTP share common authentication schemes, and thus follow
the same usage guidelines as specified in [8] and also in [H15]. the same usage guidelines as specified in [7] and also in [H15].
Servers SHOULD implement both basic and digest [8] authentication. Servers SHOULD implement both basic and digest [7] authentication.
It should be stressed that using the HTTP authentication alone does It should be stressed that using the HTTP authentication alone does
not provide full control message security. Therefore, in environments not provide full control message security. Therefore, in environments
requiring tighter security for the control messages, TLS SHOULD be requiring tighter security for the control messages, TLS SHOULD be
used, see Section 17.2. used, see Section 17.2.
17.2 RTSP over TLS 17.2 RTSP over TLS
RTSP SHALL follow the same guidelines with regards to TLS [7] usage RTSP SHALL follow the same guidelines with regards to TLS [6] usage
as specified for HTTP, see [18]. RTSP over TLS is separated from as specified for HTTP, see [17]. RTSP over TLS is separated from
unsecured RTSP both on URI level and port level. Instead of using the unsecured RTSP both on URI level and port level. Instead of using the
"rtsp" scheme identifier in the URI, the "rtsps" scheme identifier "rtsp" scheme identifier in the URI, the "rtsps" scheme identifier
MUST be used to signal RTSP over TLS. If no port is given in a URI MUST be used to signal RTSP over TLS. If no port is given in a URI
with the "rtsps" scheme, port 322 SHALL be used for TLS over TCP/IP. with the "rtsps" scheme, port 322 SHALL be used for TLS over TCP/IP.
When a client tries to setup an insecure channel to the server (using When a client tries to setup an insecure channel to the server (using
the "rtsp" URI), and the policy for the resource requires a secure the "rtsp" URI), and the policy for the resource requires a secure
channel, the server SHALL redirect the client to the secure service channel, the server SHALL redirect the client to the secure service
by sending a 301 redirect response code together with the correct by sending a 301 redirect response code together with the correct
Location URI (using the "rtsps" scheme). Location URI (using the "rtsps" scheme).
skipping to change at page 118, line 29 skipping to change at page 119, line 29
process for approval for each hop. However after the first message process for approval for each hop. However after the first message
exchange the remaining message should not be delayed, if each message exchange the remaining message should not be delayed, if each message
contains the chain of proxies that the requestor accepts. The contains the chain of proxies that the requestor accepts. The
procedure of including the credentials in each request rather than procedure of including the credentials in each request rather than
building state in each proxy, avoids the need for revocation building state in each proxy, avoids the need for revocation
procedures. procedures.
18 Syntax 18 Syntax
The RTSP syntax is described in an augmented Backus-Naur Form (BNF) The RTSP syntax is described in an augmented Backus-Naur Form (BNF)
as defined in RFC 2234 [5]. as defined in RFC 2234 [4].
18.1 Base Syntax 18.1 Base Syntax
RTSP header field values can be folded onto multiple lines if the
continuation line begins with a space or horizontal tab. All linear
white space, including folding, has the same semantics as SP. A
recipient MAY replace any linear white space with a single SP before
interpreting the field value or forwarding the message downstream.
This is intended to behave exactly as HTTP/1.1 as described in RFC
2616 [8]. The SWS construct is used when linear white space is
optional, generally between tokens and separators.
To separate the header name from the rest of value, a colon is used,
which, by the above rule, allows whitespace before, but no line
break, and whitespace after, including a linebreak. The HCOLON
defines this construct.
OCTET = %x00-FF ; any 8-bit sequence of data OCTET = %x00-FF ; any 8-bit sequence of data
CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127) CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127)
UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z" UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z"
LOALPHA = %x61-7A ;any US-ASCII lowercase letter "a".."z" LOALPHA = %x61-7A ;any US-ASCII lowercase letter "a".."z"
ALPHA = UPALPHA / LOALPHA ALPHA = UPALPHA / LOALPHA
DIGIT = %x30-39 ; any US-ASCII digit "0".."9" DIGIT = %x30-39 ; any US-ASCII digit "0".."9"
CTL = %x00-1F / %x7F ; any US-ASCII control character CTL = %x00-1F / %x7F ; any US-ASCII control character
(octets 0 - 31) and DEL (127)> ; (octets 0 - 31) and DEL (127)
CR = %x0D ; US-ASCII CR, carriage return (13)> CR = %x0D ; US-ASCII CR, carriage return (13
LF = %x0A ; US-ASCII LF, linefeed (10)> LF = %x0A ; US-ASCII LF, linefeed (10)
SP = %x20 ; US-ASCII SP, space (32)> SP = %x20 ; US-ASCII SP, space (32)
HT = %x09 ; US-ASCII HT, horizontal-tab (9)> HT = %x09 ; US-ASCII HT, horizontal-tab (9)
DQUOTE = %x22 ; US-ASCII double-quote mark (34)> DQUOTE = %x22 ; US-ASCII double-quote mark (34)
BACKSLASH = %x5C ; US-ASCII backslash (92)> BACKSLASH = %x5C ; US-ASCII backslash (92)
CRLF = CR LF CRLF = CR LF
LWS = [CRLF] 1*( SP / HT ) LWS = [CRLF] 1*( SP / HT )
SWS = [LWS] ; sep whitespace
HCOLON = *( SP / HTAB ) ":" SWS
TEXT = %x20-7D / %x80-FF ; any OCTET except CTLs> TEXT = %x20-7D / %x80-FF ; any OCTET except CTLs>
tspecials = "(" / ")" / "<" / ">" / "@" tspecials = "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / BACKSLASH / DQUOTE / "," / ";" / ":" / BACKSLASH / DQUOTE
/ "/" / "[" / "]" / "?" / "=" / "/" / "[" / "]" / "?" / "="
/ "{" / "}" / SP / HT / "{" / "}" / SP / HT
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7A / %x7C / %x7E) / %x41-5A / %x5E-7A / %x7C / %x7E)
; 1*<any CHAR except CTLs or tspecials> ; 1*<any CHAR except CTLs or tspecials>
quoted-string = ( DQUOTE *(qdtext) DQUOTE ) quoted-string = ( DQUOTE *(qdtext) DQUOTE )
qdtext = %x20-21 / %x23-7D / %x80-FF ; any TEXT except <"> qdtext = %x20-21 / %x23-7D / %x80-FF ; any TEXT except <">
quoted-pair = BACKSLASH CHAR quoted-pair = BACKSLASH CHAR
ctext = %x20-27 / %x2A-7D / %x80-FF ; any OCTET except CTLs, "(" and ")"
safe = "$" / "-" / "_" / "." / "+" safe = "$" / "-" / "_" / "." / "+"
extra = "!" / "*" / "'" / "(" / ")" / "," extra = "!" / "*" / "'" / "(" / ")" / ","
rtsp-extra = "!" / "*" / "'" / "(" / ")" /
hex = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" / hex = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" /
"a" / "b" / "c" / "d" / "e" / "f" "a" / "b" / "c" / "d" / "e" / "f"
escape = "%" hex hex escape = "%" hex hex
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" reserved = ";" / "/" / "?" / ":" / "@" / "&" / "="
unreserved = alpha / digit / safe / extra unreserved = alpha / digit / safe / extra
xchar = unreserved / reserved / escape rtsp-unreserved = alpha /digit /safe / rtsp-extra
base64 = 0*base64-unit [base64-pad] base64 = 0*base64-unit [base64-pad]
base64-unit = 4base64-char base64-unit = 4base64-char
base64-pad = (2base64-char "==") / (3base64-char "=") base64-pad = (2base64-char "==") / (3base64-char "=")
base64-char = ALPHA / DIGIT / "+" / "/" base64-char = ALPHA / DIGIT / "+" / "/"
STAR = SWS "*" SWS ; asterisk
SLASH = SWS "/" SWS ; slash
EQUAL = SWS "=" SWS ; equal
LPAREN = SWS "(" SWS ; left parenthesis
RPAREN = SWS ")" SWS ; right parenthesis
COMMA = SWS "," SWS ; comma
SEMI = SWS ";" SWS ; semicolon
COLON = SWS ":" SWS ; colon
LDQUOT = SWS DQUOTE; open double quotation mark
RDQUOT = DQUOTE SWS ; close double quotation mark
18.2 RTSP Protocol Definition 18.2 RTSP Protocol Definition
18.2.1 Generic Protocol elements 18.2.1 Generic Protocol elements
absoluteURL = < as defined in RFC 2396 [13] and RFC2732 [12] > URI-reference = RTSP-URI / relative-ref
relativeURL = < as defined in RFC 2396 [13] and RFC2732 [12] > relative-ref = < As defined in RFC 3986 [18]>
rtsp-URI = rtsp-scheme "//" host [":" port] RTSP-URI = rtsp-uri-def / rtsps-uri-def / rtspu-uri-def
[abs-path ["?" query]] ["#" fragment] rtsp-uri-def = "rtsp:" rtsp-uri-rest
rtsp-scheme = ( "rtsp:" / "rtspu:" / "rtsps:" ) rtsps-uri-def = "rtsps:" rtsp-uri-rest
host = As defined by RFC 2732 [12] rtspu-uri-def = "rtspu:" rtsp-uri-rest
abs-path = As defined by RFC 2396 [13] rtsp-uri-rest = "//" host [":" port] [abs-path ["?" query]] ["#" fragment]
host = <As defined by RFC 3986 [18]>
abs-path = <As defined by RFC 3986 [18]>
port = *DIGIT ; Is expected to be 1*5DIGIT port = *DIGIT ; Is expected to be 1*5DIGIT
query = As defined by RFC 2396 [13] query = <As defined by RFC 3986 [18]>
fragment = As defined by RFC 2396 [13] fragment = <As defined by RFC 3986 [18]>
smpte-range = smpte-type "=" smpte-range-spec smpte-range = smpte-type "=" smpte-range-spec
;Section 3.4 ;Section 3.4
smpte-range-spec = ( smpte-time "-" [ smpte-time ] ) smpte-range-spec = ( smpte-time "-" [ smpte-time ] )
/ ( "-" smpte-time ) / ( "-" smpte-time )
smpte-type = "smpte" / "smpte-30-drop" smpte-type = "smpte" / "smpte-30-drop"
/ "smpte-25" / smpte-type-extension / "smpte-25" / smpte-type-extension
; other timecodes may be added ; other timecodes may be added
smpte-type-extension = token smpte-type-extension = token
smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT
[ ":" 1*2DIGIT [ "." 1*2DIGIT ] ] [ ":" 1*2DIGIT [ "." 1*2DIGIT ] ]
npt-range = ["npt" "="] npt-range-spec ; Section 3.5 npt-range = ["npt" "="] npt-range-spec ; Section 3.5
; implementations SHOULD use npt= prefix, ; implementations SHALL use the "npt=" prefix,
;but SHOULD be prepared to interoperate with ;but SHOULD be prepared to interoperate with
; RFC 2326 implementations which don't use it. ; RFC 2326 implementations which don't use it.
npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time ) npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time )
npt-time = "now" / npt-sec / npt-hhmmss npt-time = "now" / npt-sec / npt-hhmmss
npt-sec = 1*DIGIT [ "." *DIGIT ] npt-sec = 1*DIGIT [ "." *DIGIT ]
npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ]
npt-hh = 1*DIGIT ; any positive number npt-hh = 1*DIGIT ; any positive number
npt-mm = 1*2DIGIT ; 0-59 npt-mm = 1*2DIGIT ; 0-59
npt-ss = 1*2DIGIT ; 0-59 npt-ss = 1*2DIGIT ; 0-59
utc-range = "clock" "=" utc-range-spec ; Section 3.6 utc-range = "clock" "=" utc-range-spec ; Section 3.6
utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time ) utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time )
utc-time = utc-date "T" utc-clock "Z" utc-time = utc-date "T" utc-clock "Z"
utc-date = 8DIGIT ; < YYYYMMDD > utc-date = 8DIGIT ; < YYYYMMDD >
utc-clock = 6DIGIT [ "." fraction ]; < HHMMSS.fraction > utc-clock = 6DIGIT [ "." fraction ]; < HHMMSS.fraction >
fraction = 1*DIGIT fraction = 1*DIGIT
feature-tag = token feature-tag = token
session-id = 8*( ALPHA / DIGIT / safe ) session-id = 8*( ALPHA / DIGIT / safe )
message-header = field-name ":" [ field-value ] CRLF message-header = field-name HCOLON [ field-value ] CRLF
field-name = token field-name = token
field-value = *( field-content / LWS ) field-value = *( field-content / LWS )
field-content = <the OCTETs making up the field-value and field-content = <the OCTETs making up the field-value and
consisting of either *TEXT or combinations consisting of either *TEXT or combinations
of token, tspecials, and quoted-string> of token, tspecials, and quoted-string>
18.2.2 Message Syntax 18.2.2 Message Syntax
RTSP-message = Request / Response ; RTSP/1.0 messages RTSP-message = Request / Response ; RTSP/1.0 messages
Request = Request-Line ; Section 6.1 Request = Request-Line ; Section 6.1
*( general-header ; Section 5 *( general-header ; Section 5
/ request-header ; Section 6.2 / request-header ; Section 6.2
/ entity-header ) ; Section 8.1 / entity-header ) ; Section 8.1
CRLF CRLF
[ message-body ] ; Section 4.3 [ message-body ] ; Section 4.3
Response = Status-Line ; Section 7.1 Response = Status-Line ; Section 7.1
*( general-header ; Section 5 *( general-header ; Section 5
/ response-header ; Section 7.1.2 / response-header ; Section 7.1.2
skipping to change at page 121, line 34 skipping to change at page 123, line 20
/ "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
/ extension-method / extension-method
extension-method = token extension-method = token
Request-URI = "*" / absolute-URL Request-URI = "*" / RTSP-URI
RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT
Status-Code = "100" ; Continue Status-Code = "100" ; Continue
/ "200" ; OK / "200" ; OK
/ "201" ; Created / "201" ; Created
/ "250" ; Low on Storage Space / "250" ; Low on Storage Space
/ "300" ; Multiple Choices / "300" ; Multiple Choices
/ "301" ; Moved Permanently / "301" ; Moved Permanently
/ "302" ; Moved Temporarily / "302" ; Moved Temporarily
/ "303" ; See Other / "303" ; See Other
skipping to change at page 122, line 47 skipping to change at page 124, line 31
/ "500" ; Internal Server Error / "500" ; Internal Server Error
/ "501" ; Not Implemented / "501" ; Not Implemented
/ "502" ; Bad Gateway / "502" ; Bad Gateway
/ "503" ; Service Unavailable / "503" ; Service Unavailable
/ "504" ; Gateway Time-out / "504" ; Gateway Time-out
/ "505" ; RTSP Version not supported / "505" ; RTSP Version not supported
/ "551" ; Option not supported / "551" ; Option not supported
/ extension-code / extension-code
extension-code = 3DIGIT extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF> Reason-Phrase = *TEXT
general-header = Cache-Control ; Section 14.10 general-header = Cache-Control ; Section 14.10
/ Connection ; Section 14.11 / Connection ; Section 14.11
/ CSeq ; Section 14.19 / CSeq ; Section 14.19
/ Date ; Section 14.20 / Date ; Section 14.20
/ Proxy-Supported ; Section 14.32 / Proxy-Supported ; Section 14.32
/ Supported ; Section 14.43 / Supported ; Section 14.43
/ Timestamp ; Section 14.44 / Timestamp ; Section 14.44
/ Via ; Section 14.49 / Via ; Section 14.49
/ extension-header / extension-header
skipping to change at page 123, line 39 skipping to change at page 125, line 26
/ Scale ; Section 14.39 / Scale ; Section 14.39
/ Session ; Section 14.42 / Session ; Section 14.42
/ Speed ; Section 14.40 / Speed ; Section 14.40
/ Supported ; Section 14.43 / Supported ; Section 14.43
/ Transport ; Section 14.45 / Transport ; Section 14.45
/ User-Agent ; Section 14.47 / User-Agent ; Section 14.47
/ extension-header / extension-header
response-header = Accept-Credentials ; Section 14.2 response-header = Accept-Credentials ; Section 14.2
/ Accept-Ranges ; Section 14.5 / Accept-Ranges ; Section 14.5
/ Connection-Creds ; Section 14.12 / Connection-creds ; Section 14.12
/ ETag ; Section 14.21 / ETag ; Section 14.21
/ Location ; Section 14.29 / Location ; Section 14.29
/ Proxy-Authenticate ; Section 14.30 / Proxy-Authenticate ; Section 14.30
/ Public ; Section 14.33 / Public ; Section 14.33
/ Range ; Section 14.34 / Range ; Section 14.34
/ Retry-After ; Section 14.36 / Retry-After ; Section 14.36
/ RTP-Info ; Section 14.38 / RTP-Info ; Section 14.38
/ Scale ; Section 14.39 / Scale ; Section 14.39
/ Session ; Section 14.42 / Session ; Section 14.42
/ Server ; Section 14.41 / Server ; Section 14.41
skipping to change at page 124, line 27 skipping to change at page 126, line 15
/ Content-Location ; Section 14.17 / Content-Location ; Section 14.17
/ Content-Type ; Section 14.18 / Content-Type ; Section 14.18
/ Expires ; Section 14.22 and [H14.21] / Expires ; Section 14.22 and [H14.21]
/ Last-Modified ; Section 14.28 / Last-Modified ; Section 14.28
/ extension-header / extension-header
extension-header = message-header extension-header = message-header
18.2.3 Header Syntax 18.2.3 Header Syntax
All header syntaxes not defined in this section are defined in All header syntaxes not defined in this section are defined in
section 14 of the HTTP 1.1 specification [4]. section 14 of the HTTP 1.1 specification [3].
accept-credentials = "Accept-Credentials" ":" credential-decision accept-credentials = "Accept-Credentials" HCOLON credential-decision CRLF
credential-decision = ("User" "," [credential-info]) credential-decision = ("User" COMMA [credential-info])
/ "Proxy" / "Proxy"
/ "Any" / "Any"
/ token ; For future extensions / token ; For future extensions
credential-info = cred-info-data 0*("," cred-info-data) credential-info = cred-info-data 0*(COMMA cred-info-data)
cred-info-data = DQUOTE rtsp-URI DQUOTE ";" base64 cred-info-data = DQUOTE rtsp-URI DQUOTE SEMI base64
Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges CRLF
acceptable-ranges = (range-unit *("," LWS range-unit)) acceptable-ranges = (range-unit *(COMMA range-unit))
/ "none" / "none"
range-unit = NPT / SMPTE / UTC / extension-format range-unit = NPT / SMPTE / UTC / extension-format
extension-format = token extension-format = token
Bandwidth = "Bandwidth" ":" 1*DIGIT Bandwidth = "Bandwidth" HCOLON 1*DIGIT CRLF
Blocksize = "Blocksize" ":" 1*DIGIT Blocksize = "Blocksize" HCOLON 1*DIGIT CRLF
Cache-Control = "Cache-Control" ":" cache-directive Cache-Control = "Cache-Control" HCOLON cache-directive CRLF
*("," LWS cache-directive) *(COMMA cache-directive)
cache-directive = cache-request-directive cache-directive = cache-request-directive
/ cache-response-directive / cache-response-directive
cache-request-directive = "no-cache" cache-request-directive = "no-cache"
/ "max-stale" ["=" delta-seconds] / "max-stale" [EQUAL delta-seconds]
/ "min-fresh" "=" delta-seconds / "min-fresh" EQUAL delta-seconds
/ "only-if-cached" / "only-if-cached"
/ cache-extension / cache-extension
cache-response-directive = "public" cache-response-directive = "public"
/ "private" / "private"
/ "no-cache" / "no-cache"
/ "no-transform" / "no-transform"
/ "must-revalidate" / "must-revalidate"
/ "proxy-revalidate" / "proxy-revalidate"
/ "max-age" "=" delta-seconds / "max-age" EQUAL delta-seconds
/ cache-extension / cache-extension
cache-extension = token ["=" (token / quoted-string)] cache-extension = token [EQUAL (token / quoted-string)]
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
connection-creds = "Connection-Credentials" ":" credential-info connection-creds = "Connection-Credentials" HCOLON credential-info CRLF
connection = "Connection" ":" (connection-token) connection = "Connection" HCOLON (connection-token)
*("," connection-token) *(COMMA connection-token) CRLF
connection-token = token connection-token = token
Content-Base = "Content-Base" ":" absoluteURL Content-Base = "Content-Base" HCOLON URI-Reference CRLF
CSeq = "Cseq" ":" 1*DIGIT CSeq = "Cseq" HCOLON 1*DIGIT CRLF
Proxy-Require = "Proxy-Require" ":" feature-tag Proxy-Require = "Proxy-Require" HCOLON feature-tag CRLF
*("," LWS feature-tag) *(COMMA feature-tag)
Proxy-Supported = "Proxy-Supported" ":" feature-tag Proxy-Supported = "Proxy-Supported" HCOLON feature-tag
*("," LWS feature-tag) *(COMMA feature-tag) CRLF
Public = "Public" ":" method *("," LWS method) Public = "Public" HCOLON method *(COMMA method) CRLF
Range = "Range" ":" ranges-spec *("," LWS ranges-spec) Range = "Range" HCOLON ranges-spec *(COMMA ranges-spec)
[ ";" "time" "=" utc-time ] [ SEMI "time" EQUAL utc-time ] CRLF
ranges-spec = npt-range / utc-range / smpte-range ranges-spec = npt-range / utc-range / smpte-range
Require = "Require" ":" feature-tag *("," LWS feature-tag) Require = "Require" HCOLON feature-tag *(COMMA feature-tag) CRLF
RTP-Info = "RTP-Info" ":" rtsp-info-spec RTP-Info = "RTP-Info" HCOLON rtsp-info-spec
*("," LWS rtsp-info-spec) *(COMMA rtsp-info-spec) CRLF
rtsp-info-spec = stream-url 1*ri-parameter rtsp-info-spec = stream-url 1*ri-parameter
stream-url = quoted-url / unquoted-url stream-url = quoted-url / unquoted-url
unquoted-url = "url" "=" safe-url unquoted-url = "url" EQUAL safe-url
quoted-url = "url" "=" DQUOTE needquote-url DQUOTE quoted-url = "url" EQUAL DQUOTE needquote-url DQUOTE
safe-url = url safe-url = URI-reference ; That doesn't contain ";" or ","
needquote-url = url //That contains ; or , needquote-url = URI-reference ; That contains ";" or ","
url = ( absoluteURL / relativeURL ) ri-parameter = SEMI "seq" EQUAL 1*DIGIT
ri-parameter = ";" "seq" "=" 1*DIGIT / SEMI "rtptime" EQUAL 1*DIGIT
/ ";" "rtptime" "=" 1*DIGIT
Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ]
Speed = "Speed" ":" 1*DIGIT [ "." *DIGIT ]
Server = "Server" ":" ( product / comment )
*(SP (product / comment))
Session = "Session" ":" session-id
[ ";" "timeout" "=" delta-seconds ]
Supported = "Supported" ":" [feature-tag *("," LWS feature-tag)]
Timestamp = "Timestamp" ":" *(DIGIT) ["." *(DIGIT)] [delay] Scale = "Scale" HCOLON [ "-" ] 1*DIGIT [ "." *DIGIT ] CRLF
Speed = "Speed" HCOLON 1*DIGIT [ "." *DIGIT ] CRLF
Server = "Server" HCOLON ( product / comment )
*(LWS (product / comment)) CRLF
product = token ["/" product-version]
product-version = token
comment "(" *( ctext / quoted-pair / comment ) ")"
Session = "Session" HCOLON session-id
[ SEMI "timeout" EQUAL delta-seconds ] CRLF
Supported = "Supported" HCOLON [feature-tag *(COMMA feature-tag)] CRLF
Timestamp = "Timestamp" HCOLON *(DIGIT) ["." *(DIGIT)] LWS [delay]
delay = *(DIGIT) [ "." *(DIGIT) ] delay = *(DIGIT) [ "." *(DIGIT) ]
Transport = "Transport" ":" transport-spec Transport = "Transport" HCOLON transport-spec
*("," LWS transport-spec) *(COMMA transport-spec) CRLF
transport-spec = transport-id *tr-parameter transport-spec = transport-id *tr-parameter
transport-id = transport-prot "/" profile ["/" lower-transport] transport-id = trans-id-rtp / other-trans
trans-id-rtp = "RTP" "/" profile ["/" lower-transport]
; no LWS is allowed inside transport-id ; no LWS is allowed inside transport-id
other-trans = token *("/" token)
; Not guaranteed RFC 2326 compatible
transport-prot = "RTP" / token profile = "AVP" / "SAVP" / "AVPF" / token
profile = "AVP" / token
lower-transport = "TCP" / "UDP" / token lower-transport = "TCP" / "UDP" / token
tr-parameter = ";" ( "unicast" / "multicast" ) tr-parameter = SEMI ( "unicast" / "multicast" )
/ ";" "source" "=" host / SEMI "source" EQUAL host
/ ";" "destination" [ "=" host ] / SEMI "destination" [ EQUAL host ]
/ ";" "interleaved" "=" channel [ "-" channel ] / SEMI "interleaved" EQUAL channel [ "-" channel ]
/ ";" "append" / SEMI "append"
/ ";" "ttl" "=" ttl / SEMI "ttl" EQUAL ttl
/ ";" "layers" "=" 1*DIGIT / SEMI "layers" EQUAL 1*DIGIT
/ ";" "port" "=" port-spec / SEMI "port" EQUAL port-spec
/ ";" "client_port" "=" port-spec / SEMI "client_port" EQUAL port-spec
/ ";" "server_port" "=" port-spec / SEMI "server_port" EQUAL port-spec
/ ";" "ssrc" "=" ssrc *("/" ssrc) / SEMI "ssrc" EQUAL ssrc *("/" ssrc)
/ ";" "client_ssrc" "=" ssrc / SEMI "client_ssrc" EQUAL ssrc
/ ";" "mode" "=" mode-spec / SEMI "mode" EQUAL mode-spec
/ ";" "dest_addr" "=" addr-list / SEMI "dest_addr" EQUAL addr-list
/ ";" "src_addr" "=" addr-list / SEMI "src_addr" EQUAL addr-list
/ ";" trn-param-ext / SEMI trn-param-ext
port-spec = port [ "-" port ] port-spec = port [ "-" port ]
trn-param-ext = par-name "=" trn-par-value trn-param-ext = par-name EQUAL trn-par-value
par-name = token par-name = token
trn-par-value = *(unreserved / DQUOTE *TEXT DQUOTE) trn-par-value = *(rtsp-unreserved / DQUOTE *TEXT DQUOTE)
ttl = 1*3(DIGIT) ttl = 1*3(DIGIT)
ssrc = 8*8(HEX) ssrc = 8*8(HEX)
channel = 1*3(DIGIT) channel = 1*3(DIGIT)
mode-spec = ( DQUOTE mode *("," *SP mode) DQUOTE ) / mode mode-spec = mode / ( DQUOTE mode *(COMMA mode) DQUOTE )
mode = "PLAY" / "RECORD" / token mode = "PLAY" / "RECORD" / token
addr-list = quoted-host-port *("/" quoted-host-port) addr-list = quoted-host-port *("/" quoted-host-port)
quoted-host-port = DQUOTE host [":" port] DQUOTE quoted-host-port = DQUOTE host [":" port] DQUOTE
Unsupported = "Unsupported" ":" feature-tag *("," feature-tag) Unsupported = "Unsupported" HCOLON feature-tag *(COMMA feature-tag) CRLF
User-Agent = "User-Agent" ":" ( product / comment ) User-Agent = "User-Agent" HCOLON ( product / comment )
0*(SP (product / comment) 0*(LWS (product / comment)) CRLF
19 Security Considerations 19 Security Considerations
Because of the similarity in syntax and usage between RTSP servers Because of the similarity in syntax and usage between RTSP servers
and HTTP servers, the security considerations outlined in [H15] and HTTP servers, the security considerations outlined in [H15]
apply. Specifically, please note the following: apply. Specifically, please note the following:
Abuse of Server Log Information: RTSP and HTTP servers will Abuse of Server Log Information: RTSP and HTTP servers will
presumably have similar logging mechanisms, and thus should presumably have similar logging mechanisms, and thus should
be equally guarded in protecting the contents of those be equally guarded in protecting the contents of those
skipping to change at page 128, line 23 skipping to change at page 130, line 12
Location Headers and Spoofing: If a single server supports Location Headers and Spoofing: If a single server supports
multiple organizations that do not trust each another, then multiple organizations that do not trust each another, then
it needs to check the values of Location and Content- it needs to check the values of Location and Content-
Location header fields in responses that are generated Location header fields in responses that are generated
under control of said organizations to make sure that they under control of said organizations to make sure that they
do not attempt to invalidate resources over which they have do not attempt to invalidate resources over which they have
no authority. ([H15.4]) no authority. ([H15.4])
In addition to the recommendations in the current HTTP specification In addition to the recommendations in the current HTTP specification
(RFC 2616 [4], as of this writing) and also of the previous RFC2068 (RFC 2616 [3], as of this writing) and also of the previous RFC2068
[19], future HTTP specifications may provide additional guidance on [19], future HTTP specifications may provide additional guidance on
security issues. security issues.
The following are added considerations for RTSP implementations. The following are added considerations for RTSP implementations.
Concentrated denial-of-service attack: The protocol offers the Concentrated denial-of-service attack: The protocol offers the
opportunity for a remote-controlled denial-of-service opportunity for a remote-controlled denial-of-service
attack. attack.
The attacker may initiate traffic flows to one or more IP The attacker may initiate traffic flows to one or more IP
skipping to change at page 129, line 6 skipping to change at page 130, line 42
Session hijacking: Since there is no or little relation between Session hijacking: Since there is no or little relation between
a transport layer connection and an RTSP session, it is a transport layer connection and an RTSP session, it is
possible for a malicious client to issue requests with possible for a malicious client to issue requests with
random session identifiers which would affect unsuspecting random session identifiers which would affect unsuspecting
clients. The server SHOULD use a large, random and non- clients. The server SHOULD use a large, random and non-
sequential session identifier to minimize the possibility sequential session identifier to minimize the possibility
of this kind of attack. of this kind of attack.
Authentication: Servers SHOULD implement both basic and digest Authentication: Servers SHOULD implement both basic and digest
[8] authentication. In environments requiring tighter [7] authentication. In environments requiring tighter
security for the control messages, the transport layer security for the control messages, the transport layer
mechanism TLS (RFC 2246 [7]) SHOULD be used. mechanism TLS (RFC 2246 [6]) SHOULD be used.
Stream issues: RTSP only provides for stream control. Stream Stream issues: RTSP only provides for stream control. Stream
delivery issues are not covered in this section, nor in the delivery issues are not covered in this section, nor in the
rest of this draft. RTSP implementations will most likely rest of this draft. RTSP implementations will most likely
rely on other protocols such as RTP, IP multicast, RSVP and rely on other protocols such as RTP, IP multicast, RSVP and
IGMP, and should address security considerations brought up IGMP, and should address security considerations brought up
in those and other applicable specifications. in those and other applicable specifications.
Persistently suspicious behavior: RTSP servers SHOULD return Persistently suspicious behavior: RTSP servers SHOULD return
error code 403 (Forbidden) upon receiving a single instance error code 403 (Forbidden) upon receiving a single instance
skipping to change at page 132, line 48 skipping to change at page 134, line 35
o A description of the purpose of the header. o A description of the purpose of the header.
20.4.3 Registered entries 20.4.3 Registered entries
All headers specified in section 14 in RFCXXXX are to be registered. All headers specified in section 14 in RFCXXXX are to be registered.
Furthermore the following RTSP headers defined in other Furthermore the following RTSP headers defined in other
specifications are registered: specifications are registered:
o x-wap-profile defined in [37]. o x-wap-profile defined in [38].
o x-wap-profile-diff defined in [37]. o x-wap-profile-diff defined in [38].
o x-wap-profile-warning defined in [37]. o x-wap-profile-warning defined in [38].
o x-predecbufsize defined in [37]. o x-predecbufsize defined in [38].
o x-initpredecbufperiod defined in [37]. o x-initpredecbufperiod defined in [38].
o x-initpostdecbufperiod defined in [37]. o x-initpostdecbufperiod defined in [38].
The use of "X-" is NOT RECOMMENDED but the above headers in the The use of "X-" is NOT RECOMMENDED but the above headers in the
register list was defined prior to the clarification. register list was defined prior to the clarification.
20.5 Transport Header registries 20.5 Transport Header registries
The transport header contains a number of parameters which have The transport header contains a number of parameters which have
possibilities for future extensions. Therefore registries for these possibilities for future extensions. Therefore registries for these
needs to be defined. needs to be defined.
20.5.1 Transport Protocols 20.5.1 Transport Protocols
A registry for the parameter transport-protocol SHALL be defined with A registry for the parameter transport-protocol SHALL be defined with
the following rules: the following rules:
o Registering require an public available standards o Registering require an public available standards
skipping to change at page 133, line 38 skipping to change at page 135, line 26
o A contact person or organization with address and email. o A contact person or organization with address and email.
o A value definition that are following the BNF token o A value definition that are following the BNF token
definition. definition.
o A describing text that explains how the registered value are o A describing text that explains how the registered value are
used in RTSP. used in RTSP.
This specification registers 1 value: This specification registers 1 value:
o Use of the RTP [17] protocol for media transport. The usage o Use of the RTP [16] protocol for media transport. The usage
is explained in RFC XXXX, appendix B.1. is explained in RFC XXXX, appendix B.1.
20.5.2 Profile 20.5.2 Profile
A registry for the parameter profile SHALL be defined with the A registry for the parameter profile SHALL be defined with the
following rules: following rules:
o Registering requires public available standards specification. o Registering requires public available standards specification.
o A contact person or organization with address and email. o A contact person or organization with address and email.
skipping to change at page 134, line 14 skipping to change at page 135, line 50
o A definition of which Transport protocol(s) that this profile o A definition of which Transport protocol(s) that this profile
is valid for. is valid for.
o A describing text that explains how the registered value are o A describing text that explains how the registered value are
used in RTSP. used in RTSP.
This specification registers 1 value: This specification registers 1 value:
o The "RTP profile for audio and video conferences with minimal o The "RTP profile for audio and video conferences with minimal
control" [3] MUST only be used when the transport control" [2] MUST only be used when the transport
specification's transport-protocol is "RTP". specification's transport-protocol is "RTP".
20.5.3 Lower Transport 20.5.3 Lower Transport
A registry for the parameter lower-transport SHALL be defined with A registry for the parameter lower-transport SHALL be defined with
the following rules: the following rules:
o Registering requires public available standards specification. o Registering requires public available standards specification.
o A contact person or organization with address and email. o A contact person or organization with address and email.
o A value definition that are following the BNF token o A value definition that are following the BNF token
definition. definition.
o A text describing how the registered value are used in RTSP. o A text describing how the registered value are used in RTSP.
This specification registers 2 values: This specification registers 2 values:
UDP: Indicates the use of the "User datagram protocol" [9] for UDP: Indicates the use of the "User datagram protocol" [8] for
media transport. media transport.
TCP: Indicates the use Transmission control protocol [10] for TCP: Indicates the use Transmission control protocol [9] for
media transport. media transport.
20.5.4 Transport modes 20.5.4 Transport modes
A registry for the transport parameter mode SHALL be defined with the A registry for the transport parameter mode SHALL be defined with the
following rules: following rules:
o Registering requires an IETF standard tracks document. o Registering requires an IETF standard tracks document.
o A contact person or organization with address and email. o A contact person or organization with address and email.
skipping to change at page 136, line 34 skipping to change at page 138, line 22
20.8 URI Schemes 20.8 URI Schemes
This specification defines two URI schemes ("rtsp" and "rtsps") and This specification defines two URI schemes ("rtsp" and "rtsps") and
reserves a third one ("rtspu"). reserves a third one ("rtspu").
This will need to be done in accordance with RFC 2717. This will need to be done in accordance with RFC 2717.
20.9 SDP attributes 20.9 SDP attributes
This specification defines two SDP [2] attributes that it is This specification defines two SDP [1] attributes that it is
requested that IANA register. requested that IANA register.
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: range Attribute name: range
Long form: Media Range Attribute Long form: Media Range Attribute
Type of name: att-field Type of name: att-field
Type of attribute: Media and session level Type of attribute: Media and session level
Subject to charset: No Subject to charset: No
Purpose: RFC XXXX Purpose: RFC XXXX
skipping to change at page 139, line 42 skipping to change at page 141, line 30
SET_PARAMETER Valid parameter 200, change value of parameter SET_PARAMETER Valid parameter 200, change value of parameter
GET_PARAMETER Valid parameter 200, return value of parameter GET_PARAMETER Valid parameter 200, return value of parameter
Table 13: None state-machine changing events Table 13: None state-machine changing events
The methods in Table 13 do not have any effect on the state machine The methods in Table 13 do not have any effect on the state machine
or the state variables. However some methods do change other session or the state variables. However some methods do change other session
related parameters, for example SET_PARAMETER which will set the related parameters, for example SET_PARAMETER which will set the
parameter(s) specified in its body. parameter(s) specified in its body.
The initial state of the state machine, see Table 14 can only be left
by processing a correct SETUP request. As seen in the table the two
state variables are also set by a correct request. This table also
shows that a correct SETUP can in some cases be redirected to another
Action Requisite New State Response Action Requisite New State Response
_____________________________________________________________ _____________________________________________________________
SETUP Ready NRM=1, RP=0.0 SETUP Ready NRM=1, RP=0.0
SETUP Needs Redirect Init 3rr Redirect SETUP Needs Redirect Init 3rr Redirect
S -> C:REDIRECT No Session hdr Init Terminate all SES S -> C:REDIRECT No Session hdr Init Terminate all SES
Table 14: State: Init Table 14: State: Init
The initial state of the state machine, see Table 14 can only be left
by processing a correct SETUP request. As seen in the table the two
state variables are also set by a correct request. This table also
shows that a correct SETUP can in some cases be redirected to another
URI and/or server by a 3rr response. URI and/or server by a 3rr response.
Action Requisite New State Response Action Requisite New State Response
_____________________________________________________________________ _____________________________________________________________________
SETUP New URI Ready NRM+=1 SETUP New URI Ready NRM+=1
SETUP Setten up URI Ready Change transport param SETUP Setten up URI Ready Change transport param
TEARDOWN Prs URI,NRM>1 Init No session hdr TEARDOWN Prs URI,NRM>1 Init No session hdr
TEARDOWN md URI,NRM=1 Init No Session hdr, NRM=0 TEARDOWN md URI,NRM=1 Init No Session hdr, NRM=0
TEARDOWN md URI,NRM>1 Ready Session hdr, NRM-=1 TEARDOWN md URI,NRM>1 Ready Session hdr, NRM-=1
PLAY Prs URI, No range Play Play from RP PLAY Prs URI, No range Play Play from RP
PLAY Prs URI, Range Play according to range PLAY Prs URI, Range Play according to range
PAUSE Prs URI Ready Return PP PAUSE Prs URI Ready Return PP
S -> C:REDIRECT Range hdr Ready Set RedP S -> C:REDIRECT Range hdr Ready Set RedP
skipping to change at page 141, line 4 skipping to change at page 142, line 38
number of media stream within the session. If the Request-URI is the number of media stream within the session. If the Request-URI is the
presentations URI the whole session is torn down. If a media URI is presentations URI the whole session is torn down. If a media URI is
used in the TEARDOWN request and more than one media exist in the used in the TEARDOWN request and more than one media exist in the
session, the session will remain and a session header MUST be session, the session will remain and a session header MUST be
returned in the response. If only a single media stream remains in returned in the response. If only a single media stream remains in
the session when performing a TEARDOWN with a media URI the session the session when performing a TEARDOWN with a media URI the session
is removed. The number of media streams remaining after tearing down is removed. The number of media streams remaining after tearing down
a media stream determines the new state. a media stream determines the new state.
The Play state table, see Table 16, is the largest. The table The Play state table, see Table 16, is the largest. The table
contains an number of requests that has presentation URI as a
prerequisite on the Request-URI, this is due to the exclusion of
non-aggregated stream control in sessions with more than one media
stream.
To avoid inconsistencies between the client and server, automatic
state transitions are avoided. This can be seen at for example "End
of media" event when all media has finished playing, the session
still remain in Play state. An explicit PAUSE request MUST be sent to
change the state to Ready. It may appear that there exist two
automatic transitions in "RedP reached" and "PP reached", however
they are requested and acknowledge before they take place. The time
at which the transition will happen is known by looking at the range
Action Requisite New State Response Action Requisite New State Response
_____________________________________________________________________ ______________________________________________________________________
PAUSE PrsURI,No range Ready Set RP to present point PAUSE PrsURI,No range Ready Set RP to present point
PAUSE PrsURI,Range>now Play Set RP & PP to given p. PAUSE PrsURI,Range>now Play Set RP & PP to given p.
PAUSE PrsURI,Range<now Ready Set RP to Range Hdr. PAUSE PrsURI,Range<now Ready Set RP to Range Hdr.
PP reached Ready RP = PP PP reached Ready RP = PP
End of media All media Play No action, RP = Invalid End of media All media Play No action, RP = Invalid
End of media >1 Media plays Play No action End of media >1 Media plays Play No action
End of range Play Set RP = End of range End of range Play Set RP = End of range
SETUP New URI Play 455 SETUP New URI Play 455
SETUP Setuped URI Play 455 SETUP Setuped URI Play 455
SETUP Setuped URI, IFI Play Change transport param. SETUP Setuped URI, IFI Play Change transport param.
TEARDOWN Prs URI,NRM>1 Init No session hdr TEARDOWN Prs URI,NRM>1 Init No session hdr
TEARDOWN md URI,NRM=1 Init No Session hdr, NRM=0 TEARDOWN md URI,NRM=1 Init No Session hdr, NRM=0
TEARDOWN md URI Play 455 TEARDOWN md URI Play 455
S -> C:REDIRECT Range hdr Play Set RedP S -> C:REDIRECT Range hdr Play Set RedP
S -> C:REDIRECT no range hdr Init Session is removed S -> C:REDIRECT no range hdr Init Session is removed
RedP reached Play TEARDOWN of session RedP reached Play TEARDOWN of session
Timeout Init Stop Media playout Timeout Init Stop Media playout
Table 16: State: Play Table 16: State: Play
contains an number of requests that has presentation URI as a
prerequisite on the Request-URI, this is due to the exclusion of
non-aggregated stream control in sessions with more than one media
stream.
To avoid inconsistencies between the client and server, automatic
state transitions are avoided. This can be seen at for example "End
of media" event when all media has finished playing, the session
still remain in Play state. An explicit PAUSE request MUST be sent to
change the state to Ready. It may appear that there exist two
automatic transitions in "RedP reached" and "PP reached", however
they are requested and acknowledge before they take place. The time
at which the transition will happen is known by looking at the range
header. If the client sends request close in time to these header. If the client sends request close in time to these
transitions it needs to be prepared for getting error message as the transitions it needs to be prepared for getting error message as the
state may or may not have changed. state may or may not have changed.
B Media Transport Alternatives B Media Transport Alternatives
This section defines how certain combinations of protocols, profiles This section defines how certain combinations of protocols, profiles
and lower transports are used. This includes the usage of the and lower transports are used. This includes the usage of the
Transport header's general source and destination parameters Transport header's general source and destination parameters
"src_addr" and "dest_addr". "src_addr" and "dest_addr".
B.1 RTP B.1 RTP
This section defines the interaction of RTSP with respect to the RTP This section defines the interaction of RTSP with respect to the RTP
protocol [17]. It also defines any necessary media transport protocol [16]. It also defines any necessary media transport
signalling with regards to RTP. signalling with regards to RTP.
The available RTP profiles and lower layer transports are described The available RTP profiles and lower layer transports are described
below along with rules on signalling the available combinations. below along with rules on signalling the available combinations.
B.1.1 AVP B.1.1 AVP
The usage of the "RTP Profile for Audio and Video Conferences with The usage of the "RTP Profile for Audio and Video Conferences with
Minimal Control" [3] when using RTP for media transport over Minimal Control" [2] when using RTP for media transport over
different lower layer transport protocols is defined below in regards different lower layer transport protocols is defined below in regards
to RTSP. to RTSP.
One such case is defined within this document, the use of embedded One such case is defined within this document, the use of embedded
(interleaved) binary data as defined in section 12. The usage of (interleaved) binary data as defined in section 12. The usage of
this method is indicated by include the "interleaved" parameter. this method is indicated by include the "interleaved" parameter.
When using embedded binary data the "src_addr" and "dest_addr" SHALL When using embedded binary data the "src_addr" and "dest_addr" SHALL
NOT be used. This addressing and multiplexing is used as defined with NOT be used. This addressing and multiplexing is used as defined with
use of channel numbers and the interleaved parameter. use of channel numbers and the interleaved parameter.
B.1.2 AVP/UDP B.1.2 AVP/UDP
This part describes sending of RTP [17] over lower transport layer This part describes sending of RTP [16] over lower transport layer
UDP [9] according to the profile "RTP Profile for Audio and Video UDP [8] according to the profile "RTP Profile for Audio and Video
Conferences with Minimal Control" defined in RFC 3551 [3]. This Conferences with Minimal Control" defined in RFC 3551 [2]. This
profiles requires one or two uni- or bi-directional UDP flows per profiles requires one or two uni- or bi-directional UDP flows per
media stream. The first UDP flow is for RTP and the second is for media stream. The first UDP flow is for RTP and the second is for
RTCP. Embedding of RTP data with the RTSP messages, in accordance RTCP. Embedding of RTP data with the RTSP messages, in accordance
with section 12, SHOULD NOT be performed when RTSP messages are with section 12, SHOULD NOT be performed when RTSP messages are
transported over unreliable transport protocols, like UDP [9]. transported over unreliable transport protocols, like UDP [8].
The RTP/UDP and RTCP/UDP flows can be established in two ways using The RTP/UDP and RTCP/UDP flows can be established in two ways using
the Transport header's parameters. The way provided in RFC 2326 was the Transport header's parameters. The way provided in RFC 2326 was
to use the necessary parameters from the set of "source", to use the necessary parameters from the set of "source",
"destination", "client_port", and "server_port". This has the "destination", "client_port", and "server_port". This has the
advantage of being compatible with all RTP capable RTSP servers and advantage of being compatible with all RTP capable RTSP servers and
clients. However this method does not provide the means to specify clients. However this method does not provide the means to specify
non-continues port ranges for RTP and RTCP. The other way is to use non-continues port ranges for RTP and RTCP. The other way is to use
the parameters "src_addr", and "dest_addr". This method provides the parameters "src_addr", and "dest_addr". This method provides
total flexibility in specifying address and port number for each total flexibility in specifying address and port number for each
skipping to change at page 144, line 33 skipping to change at page 146, line 19
B.1.3 AVP/TCP B.1.3 AVP/TCP
Note that this combination is not yet defined using sperate TCP Note that this combination is not yet defined using sperate TCP
connections. However the use of embedded (interleaved) binary data connections. However the use of embedded (interleaved) binary data
transported on the RTSP connection is possible as specified in transported on the RTSP connection is possible as specified in
section 12. When using this declared combination of interleaved section 12. When using this declared combination of interleaved
binary data the RTSP messages MUST be transported over TCP. binary data the RTSP messages MUST be transported over TCP.
A possible future for this profile would be to define the A possible future for this profile would be to define the
use of a combination of the two drafts "Connection-Oriented use of a combination of the two drafts "Connection-Oriented
Media Transport in SDP" [38] and "Framing RTP and RTCP Media Transport in SDP" [39] and "Framing RTP and RTCP
Packets over Connection-Oriented Transport" [39]. However Packets over Connection-Oriented Transport" [40]. However
as this work is not finished, this functionality is as this work is not finished, this functionality is
unspecified. unspecified.
B.1.4 Handling NPT Jumps in the RTP Media Layer B.1.4 Handling NPT Jumps in the RTP Media Layer
RTSP allows media clients to control selected, non-contiguous RTSP allows media clients to control selected, non-contiguous
sections of media presentations, rendering those streams with an RTP sections of media presentations, rendering those streams with an RTP
media layer[17]. Such control allows jumps to be created in NPT media layer[16]. Such control allows jumps to be created in NPT
timeline of the RTSP session. For example, jumps in NPT can be caused timeline of the RTSP session. For example, jumps in NPT can be caused
by multiple ranges in the range specifier of a PLAY request or by multiple ranges in the range specifier of a PLAY request or
through a "seek" opertaion on an RTSP session which involves a PLAY, through a "seek" opertaion on an RTSP session which involves a PLAY,
PAUSE, PLAY scenario where a new NPT is set for the session. The PAUSE, PLAY scenario where a new NPT is set for the session. The
media layer rendering the RTP stream should not be affected by jumps media layer rendering the RTP stream should not be affected by jumps
in NPT. Thus, both RTP sequence numbers and RTP timestamps MUST be in NPT. Thus, both RTP sequence numbers and RTP timestamps MUST be
continuous and monotonic across jumps of NPT. continuous and monotonic across jumps of NPT.
We cannot assume that the RTSP client can communicate with We cannot assume that the RTSP client can communicate with
the RTP media agent, as the two may be independent the RTP media agent, as the two may be independent
skipping to change at page 147, line 30 skipping to change at page 149, line 18
During a PAUSE / PLAY interaction in an RTSP session, the duration of During a PAUSE / PLAY interaction in an RTSP session, the duration of
time for which the RTP transmission was halted MUST be reflected in time for which the RTP transmission was halted MUST be reflected in
the RTP timestamp of each RTP stream. The duration can be calculated the RTP timestamp of each RTP stream. The duration can be calculated
for each RTP stream as the time elapsed from when the last RTP packet for each RTP stream as the time elapsed from when the last RTP packet
was sent before the PAUSE request was received and when the first RTP was sent before the PAUSE request was received and when the first RTP
packet was sent after the subsequent PLAY request was received. The packet was sent after the subsequent PLAY request was received. The
duration includes all latency incurred and processing time required duration includes all latency incurred and processing time required
to complete the request. to complete the request.
The RTP RFC [17] states that: The RTP timestamp for each The RTP RFC [16] states that: The RTP timestamp for each
unit[packet] would be related to the wallclock time at unit[packet] would be related to the wallclock time at
which the unit becomes current on the virtual presentation which the unit becomes current on the virtual presentation
timeline. timeline.
In order to satisfy the requirements of [17], the RTP timestamp space In order to satisfy the requirements of [16], the RTP timestamp space
needs to increase continuously with real time. While this is not needs to increase continuously with real time. While this is not
optimal for stored media, it is required for RTP and RTCP to function optimal for stored media, it is required for RTP and RTCP to function
as intended. Using a continuous RTP timestamp space allows the same as intended. Using a continuous RTP timestamp space allows the same
timestamp model for both stored and live media and allows better timestamp model for both stored and live media and allows better
opportunity to integrate both types of media under a single control. opportunity to integrate both types of media under a single control.
As an example, assume a clock frequency of 8000 Hz, a packetization As an example, assume a clock frequency of 8000 Hz, a packetization
interval of 100 ms and an initial sequence number and timestamp of interval of 100 ms and an initial sequence number and timestamp of
zero. zero.
skipping to change at page 149, line 18 skipping to change at page 151, line 4
Session: abcdefg Session: abcdefg
Range: npt=10.4-15 Range: npt=10.4-15
RTP-Info: url= rtsp://xyz/fizzle/audiotrack;seq=4; RTP-Info: url= rtsp://xyz/fizzle/audiotrack;seq=4;
rtptime=164400 rtptime=164400
The ensuing RTP data stream is depicted below: The ensuing RTP data stream is depicted below:
S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s
S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s
S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s
First, NPT 10 through 10.3 is played, then a PAUSE is received by the First, NPT 10 through 10.3 is played, then a PAUSE is received by the
server. After 20 seconds a PLAY is received by the server which take server. After 20 seconds a PLAY is received by the server which take
15ms to process. The duration of time for which the session was 15ms to process. The duration of time for which the session was
paused is reflected in the RTP timestamp of the RTP packets sent paused is reflected in the RTP timestamp of the RTP packets sent
after this PLAY request. after this PLAY request.
A client can use the RTSP range header and RTP-Info header to map NPT A client can use the RTSP range header and RTP-Info header to map NPT
time of a presentation with the RTP timestamp. time of a presentation with the RTP timestamp.
Note: In RFC 2326 [1], this matter was not clearly defined and was Note: In RFC 2326 [23], this matter was not clearly defined and was
misunderstood commonly. Therefore, clients SHOULD expect servers to misunderstood commonly. Therefore, clients SHOULD expect servers to
break the continuity of the RTP timestamp space in various arbitrary break the continuity of the RTP timestamp space in various arbitrary
manners after a PAUSE request. In these cases, it is RECOMMENDED that manners after a PAUSE request. In these cases, it is RECOMMENDED that
clients accept the RTP stream after the pause with appropriate clients accept the RTP stream after the pause with appropriate
mappings provided by the RTP-Info and Range headers. mappings provided by the RTP-Info and Range headers.
B.1.6 RTSP / RTP Integration B.1.6 RTSP / RTP Integration
For certain datatypes, tight integration between the RTSP layer and For certain datatypes, tight integration between the RTSP layer and
the RTP layer will be necessary. This by no means precludes the above the RTP layer will be necessary. This by no means precludes the above
skipping to change at page 150, line 49 skipping to change at page 152, line 31
using a SSRC until the RTP session is terminated. Prologing the use using a SSRC until the RTP session is terminated. Prologing the use
of a SSRC allows the established synchronization context associated of a SSRC allows the established synchronization context associated
with that SSRC to be used to sychronize subsequent PLAY requests even with that SSRC to be used to sychronize subsequent PLAY requests even
if the PLAY response is late. Additionally, changing the server side if the PLAY response is late. Additionally, changing the server side
SSRC will prevent the server from synchronizing the new SSRC within SSRC will prevent the server from synchronizing the new SSRC within
RTSP as it is connected to the one declared in the ssrc parameter in RTSP as it is connected to the one declared in the ssrc parameter in
the Transport header. the Transport header.
An SSRC collision with the SSRC that transmits media does also have An SSRC collision with the SSRC that transmits media does also have
consequences, as it will force the media sender to change its SSRC in consequences, as it will force the media sender to change its SSRC in
accordance with the RTP specification [17]. This will result in a accordance with the RTP specification [16]. This will result in a
loss of synchronization context, and require any receiver to wait for loss of synchronization context, and require any receiver to wait for
RTCP sender reports for all media requiring synchronization before RTCP sender reports for all media requiring synchronization before
being able to play out synchronized. Due to these reasons a client being able to play out synchronized. Due to these reasons a client
joining a session should take care to not select the same SSRC as the joining a session should take care to not select the same SSRC as the
server. Any SSRC signalled in the Transport header SHOULD be avoided. server. Any SSRC signalled in the Transport header SHOULD be avoided.
Also a client detecting a collision prior to sending any RTP or RTCP Also a client detecting a collision prior to sending any RTP or RTCP
messages can also select a new SSRC. messages can also select a new SSRC.
B.2 Future Additions B.2 Future Additions
skipping to change at page 151, line 37 skipping to change at page 153, line 19
o For new media protocols the interaction with RTSP needs to be o For new media protocols the interaction with RTSP needs to be
addressed. One important factor will be the media addressed. One important factor will be the media
synchronization. synchronization.
See the IANA section (20) for information how to register new See the IANA section (20) for information how to register new
attributes. attributes.
C Use of SDP for RTSP Session Descriptions C Use of SDP for RTSP Session Descriptions
The Session Description Protocol (SDP, RFC 2327 [2]) may be used to The Session Description Protocol (SDP, RFC 2327 [1]) may be used to
describe streams or presentations in RTSP. This description is describe streams or presentations in RTSP. This description is
typically returned in reply to a DESCRIBE request on an URI from a typically returned in reply to a DESCRIBE request on an URI from a
server to a client, or received via HTTP from a server to a client. server to a client, or received via HTTP from a server to a client.
This appendix describes how an SDP file determines the operation of This appendix describes how an SDP file determines the operation of
an RTSP session. SDP as is provides no mechanism by which a client an RTSP session. SDP as is provides no mechanism by which a client
can distinguish, without human guidance, between several media can distinguish, without human guidance, between several media
streams to be rendered simultaneously and a set of alternatives streams to be rendered simultaneously and a set of alternatives
(e.g., two audio streams spoken in different languages). However the (e.g., two audio streams spoken in different languages). However the
SDP extension "Grouping of Media Lines in the Session Description SDP extension "Grouping of Media Lines in the Session Description
Protocol (SDP)" [40] may provide such functionality depending on Protocol (SDP)" [41] may provide such functionality depending on
need. Also future grouping semantics may in the future be developed. need. Also future grouping semantics may in the future be developed.
C.1 Definitions C.1 Definitions
The terms "session-level", "media-level" and other key/attribute The terms "session-level", "media-level" and other key/attribute
names and values used in this appendix are to be used as defined in names and values used in this appendix are to be used as defined in
SDP (RFC 2327 [2]): SDP (RFC 2327 [1]):
C.1.1 Control URI C.1.1 Control URI
The "a=control:" attribute is used to convey the control URI. This The "a=control:" attribute is used to convey the control URI. This
attribute is used both for the session and media descriptions. If attribute is used both for the session and media descriptions. If
used for individual media, it indicates the URI to be used for used for individual media, it indicates the URI to be used for
controlling that particular media stream. If found at the session controlling that particular media stream. If found at the session
level, the attribute indicates the URI for aggregate control level, the attribute indicates the URI for aggregate control
(presentation URI). The session level URI SHALL be different from any (presentation URI). The session level URI SHALL be different from any
media level URI. The presence of a session level control attribute media level URI. The presence of a session level control attribute
skipping to change at page 152, line 29 skipping to change at page 154, line 12
only contains a single media stream, in which case the attribute MAY only contains a single media stream, in which case the attribute MAY
only be present on the session level. only be present on the session level.
control-attribute = "a=" "control" ":" url control-attribute = "a=" "control" ":" url
Example: Example:
a=control:rtsp://example.com/foo a=control:rtsp://example.com/foo
This attribute MAY contain either relative and absolute URIs, This attribute MAY contain either relative and absolute URIs,
following the rules and conventions set out in RFC 2396 [13]. following the rules and conventions set out in RFC 3986 [18].
Implementations SHALL look for a base URI in the following order: Implementations SHALL look for a base URI in the following order:
1. the RTSP Content-Base field; .IP 2. the RTSP Content- 1. the RTSP Content-Base field; .IP 2. the RTSP Content-
Location field; .IP 3. the RTSP Request-URI. Location field; .IP 3. the RTSP Request-URI.
If this attribute contains only an asterisk (*), then the URI SHALL If this attribute contains only an asterisk (*), then the URI SHALL
be treated as if it were an empty embedded URI, and thus inherit the be treated as if it were an empty embedded URI, and thus inherit the
entire base URI. entire base URI.
The URI handling for SDPs from container files need special The URI handling for SDPs from container files need special
consideration. For example in a container file with the URI: consideration. For example in a container file with the URI:
"rtsp://example.com/container.mp4". Lets assume this URI as base URI, "rtsp://example.com/container.mp4". Lets assume this URI as base URI,
and a media level URI: "rtsp://example.com/container.mp4/trackID=2". and a media level URI: "rtsp://example.com/container.mp4/trackID=2".
A relative media level URI that resolves in accordance with RFC 2396 A relative media level URI that resolves in accordance with RFC 3986
[13] to the above given media URI are: "container.mp4/trackID=2". It [18] to the above given media URI are: "container.mp4/trackID=2". It
is usually not desirable to need to include in or modify the SDP is usually not desirable to need to include in or modify the SDP
stored within the container file with the server local name of the stored within the container file with the server local name of the
container file. To avoid this, one can modify the base URI used to container file. To avoid this, one can modify the base URI used to
include a trailing slash, e.g. "rtsp://example.com/container.mp4/". include a trailing slash, e.g. "rtsp://example.com/container.mp4/".
In this case the relative URI for the media will only need to be: In this case the relative URI for the media will only need to be:
"trackID=2". However this will also mean that using "*" in the SDP "trackID=2". However this will also mean that using "*" in the SDP
will result in control URI including the trailing slash, i.e. will result in control URI including the trailing slash, i.e.
"rtsp://example.com/container.mp4/". "rtsp://example.com/container.mp4/".
C.1.2 Media Streams C.1.2 Media Streams
skipping to change at page 153, line 32 skipping to change at page 155, line 13
preference, it SHOULD set the port number value to zero. preference, it SHOULD set the port number value to zero.
The "m=" lines contain information about what transport protocol, The "m=" lines contain information about what transport protocol,
profile, and possibly lower-layer is to be used for the media stream. profile, and possibly lower-layer is to be used for the media stream.
The combination of transport, profile and lower layer, like The combination of transport, profile and lower layer, like
RTP/AVP/UDP needs to be defined for how to be used with RTSP. The RTP/AVP/UDP needs to be defined for how to be used with RTSP. The
currently defined combinations are defined in section B, further currently defined combinations are defined in section B, further
combinations MAY be specified. combinations MAY be specified.
TODO: Write something about the usage of Grouping of media line, RFC TODO: Write something about the usage of Grouping of media line, RFC
3388 [40]. 3388 [41].
Example: Example:
m=audio 0 RTP/AVP 31 m=audio 0 RTP/AVP 31
C.1.3 Payload Type(s) C.1.3 Payload Type(s)
The payload type(s) are specified in the "m=" field. In case the The payload type(s) are specified in the "m=" field. In case the
payload type is a static payload type from RFC 3551 [3], no other payload type is a static payload type from RFC 3551 [2], no other
information may be required. In case it is a dynamic payload type, information may be required. In case it is a dynamic payload type,
the media attribute "rtpmap" is used to specify what the media is. the media attribute "rtpmap" is used to specify what the media is.
The "encoding name" within the "rtpmap" attribute may be one of those The "encoding name" within the "rtpmap" attribute may be one of those
specified in RFC 3551 (Sections 5 and 6), or an MIME type registered specified in RFC 3551 (Sections 5 and 6), or an MIME type registered
with IANA, or an experimental encoding as specified in SDP (RFC 2327 with IANA, or an experimental encoding as specified in SDP (RFC 2327
[2]). Codec-specific parameters are not specified in this field, but [1]). Codec-specific parameters are not specified in this field, but
rather in the "fmtp" attribute described below. rather in the "fmtp" attribute described below.
C.1.4 Format-Specific Parameters C.1.4 Format-Specific Parameters
Format-specific parameters are conveyed using the "fmtp" media Format-specific parameters are conveyed using the "fmtp" media
attribute. The syntax of the "fmtp" attribute is specific to the attribute. The syntax of the "fmtp" attribute is specific to the
encoding(s) that the attribute refers to. Note that some of the encoding(s) that the attribute refers to. Note that some of the
format specific parameters may be specified outside of the fmtp format specific parameters may be specified outside of the fmtp
parameters, like for example the "ptime" attribute for most audio parameters, like for example the "ptime" attribute for most audio
encodings. encodings.
skipping to change at page 154, line 36 skipping to change at page 156, line 15
is present at both media level and session level the media level is present at both media level and session level the media level
values SHALL be used. values SHALL be used.
The unit is specified first, followed by the value range. The units The unit is specified first, followed by the value range. The units
and their values are as defined in Section 3.4, 3.5 and 3.6 and MAY and their values are as defined in Section 3.4, 3.5 and 3.6 and MAY
be extended with further formats. Any open ended range (start-), i.e. be extended with further formats. Any open ended range (start-), i.e.
without stop range, is of unspecified duration and SHALL be without stop range, is of unspecified duration and SHALL be
considered as non-seekable content unless this property is considered as non-seekable content unless this property is
overridden. overridden.
This attribute is defined in ABNF [5] as: This attribute is defined in ABNF [4] as:
a-range-def = "a" "=" "range" ":" ranges-specifier CRLF a-range-def = "a" "=" "range" ":" ranges-specifier CRLF
Examples: Examples:
a=range:npt=0-34.4368 a=range:npt=0-34.4368
a=range:clock=19971113T2115-19971113T2203 a=range:clock=19971113T2115-19971113T2203
Non seekable stream of unknown duration: Non seekable stream of unknown duration:
a=range:npt=0- a=range:npt=0-
skipping to change at page 158, line 14 skipping to change at page 159, line 40
before being loaded into an RTSP capable client, thus if possible to before being loaded into an RTSP capable client, thus if possible to
transport the base URI it still would need to be merged into the transport the base URI it still would need to be merged into the
file. file.
The writing of the SDP session availability information, i.e. "t=" The writing of the SDP session availability information, i.e. "t="
and "r=", needs to be carefully considered. When the SDP is fetched and "r=", needs to be carefully considered. When the SDP is fetched
by the DESCRIBE method it is with very high probability that the it by the DESCRIBE method it is with very high probability that the it
is valid. However the same are much less certain for SDPs distributed is valid. However the same are much less certain for SDPs distributed
using other methods. Therefore the publisher of the SDP should take using other methods. Therefore the publisher of the SDP should take
care to follow the recommendations about availability in the SDP care to follow the recommendations about availability in the SDP
specification [2]. specification [1].
D Minimal RTSP implementation D Minimal RTSP implementation
D.1 Client D.1 Client
A client implementation MUST be able to do the following : A client implementation MUST be able to do the following :
o Generate the following requests: SETUP, TEARDOWN, PLAY. o Generate the following requests: SETUP, TEARDOWN, PLAY.
o Include the following headers in requests: CSeq, Connection, o Include the following headers in requests: CSeq, Connection,
skipping to change at page 161, line 28 skipping to change at page 163, line 9
authentication is required for the resource. authentication is required for the resource.
o Parse and include the WWW-Authenticate header o Parse and include the WWW-Authenticate header
o Implement Basic Authentication and Digest Authentication o Implement Basic Authentication and Digest Authentication
E Requirements for Unreliable Transport of RTSP messages E Requirements for Unreliable Transport of RTSP messages
This section provides any one intending to define how to transport of This section provides any one intending to define how to transport of
RTSP messages over a unreliable transport protocol with some RTSP messages over a unreliable transport protocol with some
information learned by the attempt in RFC 2326 [1]. RFC 2326 define information learned by the attempt in RFC 2326 [23]. RFC 2326 define
both an URI scheme and some basic functionality for transport of RTSP both an URI scheme and some basic functionality for transport of RTSP
messages over UDP, however it was not sufficient for reliable usage messages over UDP, however it was not sufficient for reliable usage
and successful interoperability. and successful interoperability.
The RTSP scheme defined for unreliable transport of RTSP messages was The RTSP scheme defined for unreliable transport of RTSP messages was
"rtspu". It has been reserved by this specification as at least one "rtspu". It has been reserved by this specification as at least one
commercial implementation exist, thus avoiding any collisions in the commercial implementation exist, thus avoiding any collisions in the
name space. name space.
The following considerations should exist for operation of RTSP over The following considerations should exist for operation of RTSP over
an unreliable transport protocol: an unreliable transport protocol:
o Request shall be acknowledged by the receiver. If there is no o Request shall be acknowledged by the receiver. If there is no
acknowledgement, the sender may resend the same message after acknowledgement, the sender may resend the same message after
a timeout of one round-trip time (RTT). Any retransmissions a timeout of one round-trip time (RTT). Any retransmissions
due to lack of acknowledgement must carry the same sequence due to lack of acknowledgement must carry the same sequence
number as the original request. number as the original request.
o The round-trip time can be estimated as in TCP (RFC 1123) o The round-trip time can be estimated as in TCP (RFC 1123)
[41], with an initial round-trip value of 500 ms. An [42], with an initial round-trip value of 500 ms. An
implementation may cache the last RTT measurement as the implementation may cache the last RTT measurement as the
initial value for future connections. initial value for future connections.
o If RTSP is used over a small-RTT LAN, standard procedures for o If RTSP is used over a small-RTT LAN, standard procedures for
optimizing initial TCP round trip estimates, such as those optimizing initial TCP round trip estimates, such as those
used in T/TCP (RFC 1644) [42], can be beneficial. used in T/TCP (RFC 1644) [43], can be beneficial.
o The Timestamp header (Section 14.44) is used to avoid the o The Timestamp header (Section 14.44) is used to avoid the
retransmission ambiguity problem [43] and obviates the need retransmission ambiguity problem [44] and obviates the need
for Karn's algorithm. for Karn's algorithm.
o The registered default port for UDP for the RTSP server is o The registered default port for UDP for the RTSP server is
554. 554.
o RTSP messages can be carried over any lower-layer transport o RTSP messages can be carried over any lower-layer transport
protocol that is 8-bit clean. protocol that is 8-bit clean.
o RTSP messages are vulnerable to bit errors and SHOULD NOT be o RTSP messages are vulnerable to bit errors and SHOULD NOT be
subjected to them. subjected to them.
o Source authentication, or at least validation that RTSP o Source authentication, or at least validation that RTSP
messages comes from the same entity becomes extremely messages comes from the same entity becomes extremely
important, as session hijacking may be substantially easier important, as session hijacking may be substantially easier
for RTSP message transport using an unreliable protocol like for RTSP message transport using an unreliable protocol like
UDP than for TCP. UDP than for TCP.
There exist two RTSP header thats primarily are intended for being There exist two RTSP headers thats primarily are intended for being
used by the unreliable handling of RTSP messages and which will be used by the unreliable handling of RTSP messages and which will be
maintained: maintained:
CSeq See section 14.19 CSeq See section 14.19
Timestamp See section 14.44 Timestamp See section 14.44
F Backwards Compatibility Considerations F Backwards Compatibility Considerations
This section contains notes on issues about backwards compatibility This section contains notes on issues about backwards compatibility
with clients or servers being implemented according to RFC 2326 [1]. with clients or servers being implemented according to RFC 2326 [23].
Any mechanism described in this section is intended for a migration Any mechanism described in this section is intended for a migration
period and are expected to be possible to phase out. period and is expected to be phased out in the future.
F.1 Requirement on Pause before Play in Play mode F.1 Requirement on Pause before Play in Play mode
The behavior in Play mode after having run to the end of a media The behavior in Play mode after having run to the end of a media
stream has been changed, see section 11.4. For state handling stream has been changed (Section 11.4). For state handling
consistency, a client is now required to issue an PAUSE prior to a consistency, a client is now required to issue a PAUSE request prior
PLAY request. However as this could make a RFC 2326 client become to a PLAY request. However as this could make an RFC 2326 client
stuck after having played a media stream to its end, the following become stuck after having played a media stream to its end. The
mitigation is suggested: following mitigation is suggested:
If a server receives a PLAY request when in play state and all media 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 has finished the requested play out, the server MAY interpret this as
a PLAY request received in ready state. a PLAY request received in ready state.
However the server SHALL NOT do the above if the client has shown any However the server SHALL NOT do the above if the client has shown any
support for this or newer specifications, for example by sending a support for this or newer specifications, for example, by sending a
Supported header with the play.basic feature tag. Supported header with the "play.basic" feature tag.
F.2 Usage of persistent connections F.2 Using Persistent Connections
Some implementations according to RFC 2326, requires the client to Some server implementations of RFC 2326 maintain a one-to-one
use persistent connection. The client closing the connection may relationship between a connection and an RTSP session. Such
result in that the server removes the session. To achieve implementations require clients to use a persistent connection to
interoperability with old servers any client is strongly RECOMMENDED communicate with the server and when a client closes its connection,
to use persistent connections. the server may remove the RTSP session. To achieve interoperability
with such older implementations, client implementations of this
specification SHOULD use persistent connections.
G Open Issues G Open Issues
This section contains a list of open issues that still needs to be This section contains a list of open issues that still needs to be
resolved. However also any open issues in the bug tracker at resolved. However also any open issues in the bug tracker at
http://rtspspec.sourceforge.net should also be considered. http://rtspspec.sourceforge.net should also be considered.
1. Is the example in Section 16.4 valid? 1. Is the example in Section 16.4 valid?
2. Should the SDP appendix contain any text in regards to the 2. Should the SDP appendix contain any text in regards to the
skipping to change at page 168, line 31 skipping to change at page 170, line 12
- Required Timestamp, Via, and Unsupported headers for a minimal - Required Timestamp, Via, and Unsupported headers for a minimal
server implementation. server implementation.
- Recommended that Cache-Control, Expires and Date headers be - Recommended that Cache-Control, Expires and Date headers be
supported by server implementations. supported by server implementations.
o The Protocol Syntax has been changed in the following way: o The Protocol Syntax has been changed in the following way:
- All BNF definitions are updated according to the rules defined in - All BNF definitions are updated according to the rules defined in
RFC 2234 [5] and has been gathered in a separate section 18. RFC 2234 [4] and has been gathered in a separate section 18.
- The BNF for the User-Agent and Server headers has been corrected so - The BNF for the User-Agent and Server headers has been corrected so
now only the description is in the HTTP specification. now only the description is in the HTTP specification.
- The definition in the introduction of the RTSP session has been - The definition in the introduction of the RTSP session has been
changed. changed.
- The protocol has been made fully IPv6 capable. Certain of the - The protocol has been made fully IPv6 capable. Certain of the
functionality, like using explicit IPv6 addresses in fields functionality, like using explicit IPv6 addresses in fields
requires that the protocol support this updated specification. requires that the protocol support this updated specification.
skipping to change at page 171, line 10 skipping to change at page 172, line 40
electronic mail: robla@real.com electronic mail: robla@real.com
Magnus Westerlund Magnus Westerlund
Ericsson AB, EAB/TVA/A Ericsson AB, EAB/TVA/A
Torshamsgatan 23 Torshamsgatan 23
SE-164 80 STOCKHOLM SE-164 80 STOCKHOLM
SWEDEN SWEDEN
electronic mail: magnus.westerlund@ericsson.com electronic mail: magnus.westerlund@ericsson.com
Aravind Narasimhan Aravind Narasimhan
Princeton, NJ Overture Computing Corp.,
East Windsor, NJ 08520
USA USA
electronic mail: aravind.narasimhan@gmail.com electronic mail: aravind.narasimhan@gmail.com
J Contributors J Contributors
The following people has made written contribution included in the The following people have made written contributions that were
specification: included in the specification:
o Tom Marshall has contributed with text about the usage of 3rr o Tom Marshall contributed text on the usage of 3rr status
status codes. codes.
o Thomas Zheng has contributed with text regarding the usage of o Thomas Zheng contributed text on the usage of the Range in
the Range in PLAY responses. PLAY responses.
o Sean Sheedy has contributed the text regarding the timing out o Sean Sheedy contributed text on the timeout behavior of RTSP
of RTSP messages. messages and connections.
o Fredrik Lindholm has contributed with text for the RTSP o Fredrik Lindholm contributed text about the RTSP security
security framework. framework.
The following persons has provided detailed comments on the updated The following people have provided detailed comments on updated
version of the specification: versions of this specification:
o Stephan Wenger o Stephan Wenger
K Acknowledgements K Acknowledgements
This draft is based on the functionality of the original RTSP draft This draft is based on the functionality of the original RTSP draft
submitted in October 1996. It also borrows format and descriptions submitted in October 1996. It also borrows format and descriptions
from HTTP/1.1. from HTTP/1.1.
This document has benefited greatly from the comments of all those This document has benefited greatly from the comments of all those
skipping to change at page 172, line 14 skipping to change at page 173, line 45
Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Thomas Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Thomas
Marshall, Rob McCool, David Oran, Joerg Ott, Maria Papadopouli, Sujal Marshall, Rob McCool, David Oran, Joerg Ott, Maria Papadopouli, Sujal
Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Igor Plotnikov, Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Igor Plotnikov,
Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff Smith, Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff Smith,
Alexander Sokolsky, Dale Stammen, John Francis Stracke, Maureen Alexander Sokolsky, Dale Stammen, John Francis Stracke, Maureen
Chesire, David Walker, Geetha Srikantan, Stephan Wenger, Pekka Pessi, Chesire, David Walker, Geetha Srikantan, Stephan Wenger, Pekka Pessi,
and Mela Martti. and Mela Martti.
L Normative References L Normative References
[1] H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming [1] M. Handley and V. Jacobson, "SDP: session description protocol,"
protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr.
1998.
[2] M. Handley and V. Jacobson, "SDP: session description protocol,"
RFC 2327, Internet Engineering Task Force, Apr. 1998. RFC 2327, Internet Engineering Task Force, Apr. 1998.
[3] H. Schulzrinne and S. Casner, "RTP profile for audio and video [2] H. Schulzrinne and S. Casner, "RTP profile for audio and video
conferences with minimal control," RFC 3551, Internet Engineering conferences with minimal control," RFC 3551, Internet Engineering
Task Force, July 2003. Task Force, July 2003.
[4] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P. [3] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P.
J. Leach, and T. Berners-Lee, "Hypertext transfer protocol -- J. Leach, and T. Berners-Lee, "Hypertext transfer protocol --
HTTP/1.1," RFC 2616, Internet Engineering Task Force, June 1999. HTTP/1.1," RFC 2616, Internet Engineering Task Force, June 1999.
[5] "Augmented BNF for syntax specifications: ABNF," RFC 2234, [4] "Augmented BNF for syntax specifications: ABNF," RFC 2234,
Internet Engineering Task Force, Nov. 1997. Internet Engineering Task Force, Nov. 1997.
[6] S. Bradner, "Key words for use in RFCs to indicate requirement [5] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[7] T. Dierks and C. Allen, "The TLS protocol version 1.0," RFC 2246, [6] T. Dierks and C. Allen, "The TLS protocol version 1.0," RFC 2246,
Internet Engineering Task Force, Jan. 1999. Internet Engineering Task Force, Jan. 1999.
[8] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. J. [7] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. J.
Leach, A. Luotonen, and L. Stewart, "HTTP authentication: Basic and Leach, A. Luotonen, and L. Stewart, "HTTP authentication: Basic and
digest access authentication," RFC 2617, Internet Engineering Task digest access authentication," RFC 2617, Internet Engineering Task
Force, June 1999. Force, June 1999.
[9] J. B. Postel, "User datagram protocol," RFC 768, Internet [8] J. B. Postel, "User datagram protocol," RFC 768, Internet
Engineering Task Force, Aug. 1980. Engineering Task Force, Aug. 1980.
[10] J. B. Postel, "Transmission control protocol," RFC 793, Internet [9] J. B. Postel, "Transmission control protocol," RFC 793, Internet
Engineering Task Force, Sept. 1981. Engineering Task Force, Sept. 1981.
[11] R. Elz, "A compact representation of IPv6 addresses," RFC 1924, [10] R. Elz, "A compact representation of IPv6 addresses," RFC 1924,
Internet Engineering Task Force, Apr. 1996. Internet Engineering Task Force, Apr. 1996.
[12] R. Hinden, B. E. Carpenter, and L. Masinter, "Format for literal [11] R. Hinden, B. E. Carpenter, and L. Masinter, "Format for literal
IPv6 addresses in URL's," RFC 2732, Internet Engineering Task Force, IPv6 addresses in URL's," RFC 2732, Internet Engineering Task Force,
Dec. 1999. Dec. 1999.
[13] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform resource [12] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform resource
identifiers (URI): generic syntax," RFC 2396, Internet Engineering identifiers (URI): generic syntax," RFC 2396, Internet Engineering
Task Force, Aug. 1998. Task Force, Aug. 1998.
[14] F. Yergeau, "UTF-8, a transformation format of ISO 10646," RFC [13] F. Yergeau, "UTF-8, a transformation format of ISO 10646," RFC
2279, Internet Engineering Task Force, Jan. 1998. 2279, Internet Engineering Task Force, Jan. 1998.
[15] NIST, "Fips pub 180-1:secure hash standard," tech. rep., [14] NIST, "Fips pub 180-1:secure hash standard," tech. rep.,
National Institute of Standards and Technology, Apr. 1995. National Institute of Standards and Technology, Apr. 1995.
[16] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet X.509 [15] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet X.509
public key infrastructure certificate and certificate revocation list public key infrastructure certificate and certificate revocation list
(CRL) profile," RFC 3280, Internet Engineering Task Force, Apr. 2002. (CRL) profile," RFC 3280, Internet Engineering Task Force, Apr. 2002.
[17] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: [16] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP:
a transport protocol for real-time applications," RFC 3550, Internet a transport protocol for real-time applications," RFC 3550, Internet
Engineering Task Force, July 2003. Engineering Task Force, July 2003.
[18] E. Rescorla, "HTTP over TLS," RFC 2818, Internet Engineering [17] E. Rescorla, "HTTP over TLS," RFC 2818, Internet Engineering
Task Force, May 2000. Task Force, May 2000.
[18] R. F. T. Berners-Lee and L. Masinter, "Uniform resource
identifier (uri): Generic syntax," RFC 3986, Internet Engineering
Task Force, Jan. 2005.
[19] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T. [19] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T.
Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068,
Internet Engineering Task Force, Jan. 1997. Internet Engineering Task Force, Jan. 1997.
[20] T. Narten and H. Alvestrand, "Guidelines for writing an IANA [20] T. Narten and H. Alvestrand, "Guidelines for writing an IANA
considerations section in RFCs," RFC 2434, Internet Engineering Task considerations section in RFCs," RFC 2434, Internet Engineering Task
Force, Oct. 1998. Force, Oct. 1998.
[21] S. Olson, G. Camarillo, and A. B. Roach, "Support for IPv6 in [21] S. Olson, G. Camarillo, and A. B. Roach, "Support for IPv6 in
session description protocol (SDP)," RFC 3266, Internet Engineering session description protocol (SDP)," RFC 3266, Internet Engineering
Task Force, June 2002. Task Force, June 2002.
[22] R. Hinden and S. E. Deering, "Internet protocol version 6 (ipv6) [22] R. Hinden and S. E. Deering, "Internet protocol version 6 (ipv6)
addressing architecture," RFC 3513, Internet Engineering Task Force, addressing architecture," RFC 3513, Internet Engineering Task Force,
Apr. 2003. Apr. 2003.
M Informative References M Informative References
[23] T. Z. M. Westerlund, "How to make real-time streaming protocol [23] H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming
protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr.
1998.
[24] T. Z. M. Westerlund, "How to make real-time streaming protocol
(rtsp) traverse network address translators (nat) and interact with (rtsp) traverse network address translators (nat) and interact with
firewalls.," internet draft, Internet Engineering Task Force, Feb. firewalls.," internet draft, Internet Engineering Task Force, Feb.
2004. Work in progress. 2004. Work in progress.
[24] A. Narasimhan, "Mute and unmute extension to rtsp," internet [25] A. Narasimhan, "Mute and unmute extension to rtsp," internet
draft, Internet Engineering Task Force, Feb. 2002. Work in progress. draft, Internet Engineering Task Force, Feb. 2002. Work in progress.
[25] P. Gentric, "Rtsp stream switching," internet draft, Internet [26] P. Gentric, "Rtsp stream switching," internet draft, Internet
Engineering Task Force, Jan. 2004. Work in progress. Engineering Task Force, Jan. 2004. Work in progress.
[26] A. L. G. Srikantan, J. Murata, "Streaming relays," internet [27] A. L. G. Srikantan, J. Murata, "Streaming relays," internet
draft, Internet Engineering Task Force, Dec. 2003. Work in progress. draft, Internet Engineering Task Force, Dec. 2003. Work in progress.
[27] F. Yergeau, G. Nicol, G. C. Adams, and M. Duerst, [28] F. Yergeau, G. Nicol, G. C. Adams, and M. Duerst,
"Internationalization of the hypertext markup language," RFC 2070, "Internationalization of the hypertext markup language," RFC 2070,
Internet Engineering Task Force, Jan. 1997. Internet Engineering Task Force, Jan. 1997.
[28] H. Schulzrinne, "A comprehensive multimedia control architecture [29] H. Schulzrinne, "A comprehensive multimedia control architecture
for the Internet," in Proc. International Workshop on Network and for the Internet," in Proc. International Workshop on Network and
Operating System Support for Digital Audio and Video (NOSSDAV), (St. Operating System Support for Digital Audio and Video (NOSSDAV), (St.
Louis, Missouri), May 1997. Louis, Missouri), May 1997.
[29] International Telecommunication Union, "Visual telephone systems [30] International Telecommunication Union, "Visual telephone systems
and equipment for local area networks which provide a non-guaranteed and equipment for local area networks which provide a non-guaranteed
quality of service," Recommendation H.323, Telecommunication quality of service," Recommendation H.323, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, May 1996. Standardization Sector of ITU, Geneva, Switzerland, May 1996.
[30] P. McMahon, "GSS-API authentication method for SOCKS version 5," [31] P. McMahon, "GSS-API authentication method for SOCKS version 5,"
RFC 1961, Internet Engineering Task Force, June 1996. RFC 1961, Internet Engineering Task Force, June 1996.
[31] J. Miller, P. Resnick, and D. Singer, "Rating services and [32] J. Miller, P. Resnick, and D. Singer, "Rating services and
rating systems (and their machine readable descriptions)," rating systems (and their machine readable descriptions),"
Recommendation REC-PICS-services-961031, W3C (World Wide Web Recommendation REC-PICS-services-961031, W3C (World Wide Web
Consortium), Boston, Massachusetts, Oct. 1996. Consortium), Boston, Massachusetts, Oct. 1996.
[32] J. Miller, T. Krauskopf, P. Resnick, and W. Treese, "PICS label [33] J. Miller, T. Krauskopf, P. Resnick, and W. Treese, "PICS label
distribution label syntax and communication protocols," distribution label syntax and communication protocols,"
Recommendation REC-PICS-labels-961031, W3C (World Wide Web Recommendation REC-PICS-labels-961031, W3C (World Wide Web
Consortium), Boston, Massachusetts, Oct. 1996. Consortium), Boston, Massachusetts, Oct. 1996.
[33] D. L. Mills, "Network time protocol (version 3) specification, [34] D. L. Mills, "Network time protocol (version 3) specification,
implementation," RFC 1305, Internet Engineering Task Force, Mar. implementation," RFC 1305, Internet Engineering Task Force, Mar.
1992. 1992.
[34] ISO/IEC, "Information technology -- generic coding of moving [35] ISO/IEC, "Information technology -- generic coding of moving
pictures and associated audio informaiton -- part 6: extension for pictures and associated audio informaiton -- part 6: extension for
digital storage media and control," Draft International Standard ISO digital storage media and control," Draft International Standard ISO
13818-6, International Organization for Standardization ISO/IEC 13818-6, International Organization for Standardization ISO/IEC
JTC1/SC29/WG11, Geneva, Switzerland, Nov. 1995. JTC1/SC29/WG11, Geneva, Switzerland, Nov. 1995.
[35] ISO/IEC, "Data elements and interchange formats -- information [36] ISO/IEC, "Data elements and interchange formats -- information
interchange -- representation of dates and times," Published standard interchange -- representation of dates and times," Published standard
ISO 8601, International Organization for Standardization ISO/IEC, ISO 8601, International Organization for Standardization ISO/IEC,
Geneva, Switzerland, Dec. 2000. Geneva, Switzerland, Dec. 2000.
[36] S. Josefsson and I. W. Ed., "The base16, base32, and base64 data [37] S. Josefsson and I. W. Ed., "The base16, base32, and base64 data
encodings," RFC 3548, Internet Engineering Task Force, July 2003. encodings," RFC 3548, Internet Engineering Task Force, July 2003.
[37] Third Generation Partnership Project (3GPP), "Transparent end- [38] Third Generation Partnership Project (3GPP), "Transparent end-
to-end packet-switched streaming service (pss); protocols and to-end packet-switched streaming service (pss); protocols and
codecs," Technical Specification 26.234, Third Generation Partnership codecs," Technical Specification 26.234, Third Generation Partnership
Project (3GPP), Dec. 2002. Project (3GPP), Dec. 2002.
[38] D. Yon, "Connection-oriented media transport in sdp," internet [39] D. Yon, "Connection-oriented media transport in sdp," internet
draft, Internet Engineering Task Force, Mar. 2003. Work in progress. draft, Internet Engineering Task Force, Mar. 2003. Work in progress.
[39] J. Lazzaro, "Framing rtp and rtcp packets over connection- [40] J. Lazzaro, "Framing rtp and rtcp packets over connection-
oriented transport," internet draft, Internet Engineering Task Force, oriented transport," internet draft, Internet Engineering Task Force,
Oct. 2003. Work in progress. Oct. 2003. Work in progress.
[40] G. Camarillo, G. Eriksson, J. Holler, and H. Schulzrinne, [41] G. Camarillo, G. Eriksson, J. Holler, and H. Schulzrinne,
"Grouping of media lines in the session description protocol (SDP)," "Grouping of media lines in the session description protocol (SDP),"
RFC 3388, Internet Engineering Task Force, Dec. 2002. RFC 3388, Internet Engineering Task Force, Dec. 2002.
[41] "Requirements for Internet hosts - application and support," RFC [42] "Requirements for Internet hosts - application and support," RFC
1123, Internet Engineering Task Force, Oct. 1989. 1123, Internet Engineering Task Force, Oct. 1989.
[42] R. Braden, "T/TCP -- TCP extensions for transactions functional [43] R. Braden, "T/TCP -- TCP extensions for transactions functional
specification," RFC 1644, Internet Engineering Task Force, July 1994. specification," RFC 1644, Internet Engineering Task Force, July 1994.
[43] W. R. Stevens, TCP/IP illustrated: the implementation, vol. 2. [44] W. R. Stevens, TCP/IP illustrated: the implementation, vol. 2.
Reading, Massachusetts: Addison-Wesley, 1994. Reading, Massachusetts: Addison-Wesley, 1994.
IPR Notice IPR Notice
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
skipping to change at page 176, line 14 skipping to change at page 177, line 48
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/