draft-ietf-mmusic-rfc2326bis-09.txt   draft-ietf-mmusic-rfc2326bis-10.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-09.txt Columbia U. draft-ietf-mmusic-rfc2326bis-10.txt Columbia U.
February 21, 2005 A. Rao July 18, 2005 Anup Rao
Expires: August 21, 2005 Cisco Expires: January 18, 2006 Cisco
R. Lanphier Robert Lanphier
RealNetworks RealNetworks
M. Westerlund Magnus Westerlund
Ericsson Ericsson
A. Narasimhan Aravind Narasimhan
Overture Overture Computing
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 RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
Abstract Abstract
This memorandum is a revision of RFC 2326, which is currently a This memorandum defines RTSP version 1.1 which is a revision of the
Proposed Standard. Proposed Standard RTSP version 1.0 which is defined in RFC 2326.
The Real Time Streaming Protocol, or RTSP, is an application-level The Real Time Streaming Protocol, or RTSP, is an application-level
protocol for control over the delivery of data with real-time protocol for control over the delivery of data with real-time
properties. RTSP provides an extensible framework to enable properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and controlled, on-demand delivery of real-time data, such as audio and
video. Sources of data can include both live data feeds and stored video. Sources of data can include both live data feeds and stored
clips. This protocol is intended to control multiple data delivery clips. This protocol is intended to control multiple data delivery
sessions, provide a means for choosing delivery channels such as UDP, sessions, provide a means for choosing delivery channels such as UDP,
multicast UDP and TCP, and provide a means for choosing delivery multicast UDP and TCP, and provide a means for choosing delivery
mechanisms based upon RTP (RFC 3550). mechanisms based upon RTP (RFC 3550).
Table of Contents Table of Contents
1 Introduction ........................................ 9 1 Introduction ........................................ 9
1.1 RTSP Specification Update ........................... 9 1.1 RTSP Specification Update ........................... 9
1.2 Purpose ............................................. 10 1.2 Purpose ............................................. 9
1.3 Notational Conventions .............................. 11 1.3 Notational Conventions .............................. 11
1.4 Terminology ......................................... 12 1.4 Terminology ......................................... 12
1.5 Protocol Properties ................................. 15 1.5 Protocol Properties ................................. 15
1.6 Extending RTSP ...................................... 17 1.6 Extending RTSP ...................................... 16
1.7 Overall Operation ................................... 18 1.7 Overall Operation ................................... 17
1.8 RTSP States ......................................... 19 1.8 RTSP States ......................................... 18
1.9 Relationship with Other Protocols ................... 19 1.9 Relationship with Other Protocols ................... 19
2 RTSP Use Cases ...................................... 20 2 RTSP Use Cases ...................................... 19
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 ................ 21
2.3 On-demand Playback using Multicast .................. 22 2.3 On-demand Playback using Multicast .................. 21
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 ................................. 23
3.1 RTSP Version ........................................ 24 3.1 RTSP Version ........................................ 23
3.2 RTSP URI ............................................ 24 3.2 RTSP URI ............................................ 23
3.3 Session Identifiers ................................. 26 3.3 Session Identifiers ................................. 25
3.4 SMPTE Relative Timestamps ........................... 26 3.4 SMPTE Relative Timestamps ........................... 25
3.5 Normal Play Time .................................... 26 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 ........................................ 27
3.8 Entity Tags ......................................... 28 3.8 Entity Tags ......................................... 27
4 RTSP Message ........................................ 28 4 RTSP Message ........................................ 28
4.1 Message Types ....................................... 29 4.1 Message Types ....................................... 28
4.2 Message Headers ..................................... 29 4.2 Message Headers ..................................... 28
4.3 Message Body ........................................ 29 4.3 Message Body ........................................ 28
4.4 Message Length ...................................... 29 4.4 Message Length ...................................... 29
5 General Header Fields ............................... 30 5 General Header Fields ............................... 29
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 ............................... 31
7 Response ............................................ 33 7 Response ............................................ 32
7.1 Status-Line ......................................... 33 7.1 Status-Line ......................................... 32
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 ................................ 34
8.2 Entity Body ......................................... 35 8.2 Entity Body ......................................... 34
9 Connections ......................................... 35 9 Connections ......................................... 35
9.1 Reliability and Acknowledgements .................... 37 9.1 Reliability and Acknowledgements .................... 35
9.2 Using Connections ................................... 38 9.2 Using Connections ................................... 38
9.3 Closing Connections ................................. 39 9.3 Closing Connections ................................. 39
9.4 Timing Out Connections and RTSP Messages ............ 40 9.4 Timing Out Connections and RTSP Messages ............ 40
9.5 Use of IPv6 ......................................... 41 9.5 Use of IPv6 ......................................... 40
10 Capability Handling ................................. 41 10 Capability Handling ................................. 41
11 Method Definitions .................................. 43 11 Method Definitions .................................. 42
11.1 OPTIONS ............................................. 44 11.1 OPTIONS ............................................. 43
11.2 DESCRIBE ............................................ 45 11.2 DESCRIBE ............................................ 44
11.3 SETUP ............................................... 47 11.3 SETUP ............................................... 46
11.4 PLAY ................................................ 50 11.3.1 Changing Transport Parameters ....................... 48
11.5 PAUSE ............................................... 54 11.4 PLAY ................................................ 49
11.6 TEARDOWN ............................................ 58 11.5 PAUSE ............................................... 53
11.6 TEARDOWN ............................................ 57
11.7 GET_PARAMETER ....................................... 58 11.7 GET_PARAMETER ....................................... 58
11.8 SET_PARAMETER ....................................... 59 11.8 SET_PARAMETER ....................................... 59
11.9 REDIRECT ............................................ 61 11.9 REDIRECT ............................................ 60
11.10 PING ................................................ 63 12 Embedded (Interleaved) Binary Data .................. 62
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 ..................................... 64
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 ....................................... 65
13.3.4 303 See Other ....................................... 67 13.3.5 304 Not Modified .................................... 65
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 ........................ 66
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 .......................... 67
13.4.10 458 Parameter Is Read-Only .......................... 69 13.4.11 459 Aggregate Operation Not Allowed ................. 67
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 463 Destination Prohibited .......................... 68
13.4.15 470 Connection Authorization Required ............... 69 13.4.16 470 Connection Authorization Required ............... 68
13.4.16 471 Connection Credentials not accepted ............. 69 13.4.17 471 Connection Credentials not accepted ............. 68
13.5 Server Error 5xx .................................... 69 13.5 Server Error 5xx .................................... 68
13.5.1 551 Option not supported ............................ 69 13.5.1 551 Option not supported ............................ 68
14 Header Field Definitions ............................ 70 14 Header Field Definitions ............................ 69
14.1 Accept .............................................. 72 14.1 Accept .............................................. 71
14.2 Accept-Credentials .................................. 72 14.2 Accept-Credentials .................................. 71
14.3 Accept-Encoding ..................................... 76 14.3 Accept-Encoding ..................................... 75
14.4 Accept-Language ..................................... 76 14.4 Accept-Language ..................................... 75
14.5 Accept-Ranges ....................................... 76 14.5 Accept-Ranges ....................................... 75
14.6 Allow ............................................... 77 14.6 Allow ............................................... 76
14.7 Authorization ....................................... 77 14.7 Authorization ....................................... 76
14.8 Bandwidth ........................................... 77 14.8 Bandwidth ........................................... 76
14.9 Blocksize ........................................... 77 14.9 Blocksize ........................................... 76
14.10 Cache-Control ....................................... 78 14.10 Cache-Control ....................................... 77
14.11 Connection .......................................... 80 14.11 Connection .......................................... 79
14.12 Connection-Credentials .............................. 80 14.12 Connection-Credentials .............................. 79
14.13 Content-Base ........................................ 81 14.13 Content-Base ........................................ 80
14.14 Content-Encoding .................................... 81 14.14 Content-Encoding .................................... 80
14.15 Content-Language .................................... 81 14.15 Content-Language .................................... 80
14.16 Content-Length ...................................... 81 14.16 Content-Length ...................................... 80
14.17 Content-Location .................................... 81 14.17 Content-Location .................................... 80
14.18 Content-Type ........................................ 81 14.18 Content-Type ........................................ 80
14.19 CSeq ................................................ 82 14.19 CSeq ................................................ 81
14.20 Date ................................................ 82 14.20 Date ................................................ 81
14.21 ETag ................................................ 82 14.21 ETag ................................................ 81
14.22 Expires ............................................. 83 14.22 Expires ............................................. 82
14.23 From ................................................ 83 14.23 From ................................................ 83
14.24 Host ................................................ 84 14.24 Host ................................................ 83
14.25 If-Match ............................................ 84 14.25 If-Match ............................................ 83
14.26 If-Modified-Since ................................... 84 14.26 If-Modified-Since ................................... 83
14.27 If-None-Match ....................................... 84 14.27 If-None-Match ....................................... 83
14.28 Last-Modified ....................................... 85 14.28 Last-Modified ....................................... 84
14.29 Location ............................................ 85 14.29 Location ............................................ 84
14.30 Proxy-Authenticate .................................. 85 14.30 Proxy-Authenticate .................................. 84
14.31 Proxy-Require ....................................... 85 14.31 Proxy-Require ....................................... 84
14.32 Proxy-Supported ..................................... 85 14.32 Proxy-Supported ..................................... 84
14.33 Public .............................................. 86 14.33 Public .............................................. 85
14.34 Range ............................................... 87 14.34 Range ............................................... 86
14.35 Referer ............................................. 89 14.35 Referer ............................................. 88
14.36 Retry-After ......................................... 89 14.36 Retry-After ......................................... 88
14.37 Require ............................................. 89 14.37 Require ............................................. 88
14.38 RTP-Info ............................................ 90 14.38 RTP-Info ............................................ 89
14.39 Scale ............................................... 92 14.39 Scale ............................................... 91
14.40 Speed ............................................... 93 14.40 Speed ............................................... 91
14.41 Server .............................................. 94 14.41 Server .............................................. 92
14.42 Session ............................................. 94 14.42 Session ............................................. 92
14.43 Supported ........................................... 96 14.43 Supported ........................................... 94
14.44 Timestamp ........................................... 96 14.44 Timestamp ........................................... 94
14.45 Transport ........................................... 96 14.45 Transport ........................................... 95
14.46 Unsupported ......................................... 103 14.46 Unsupported ......................................... 99
14.47 User-Agent .......................................... 103 14.47 User-Agent .......................................... 100
14.48 Vary ................................................ 103 14.48 Vary ................................................ 100
14.49 Via ................................................. 103 14.49 Via ................................................. 100
14.50 WWW-Authenticate .................................... 103 14.50 WWW-Authenticate .................................... 100
15 Caching ............................................. 103 15 Proxies ............................................. 100
16 Examples ............................................ 104 16 Caching ............................................. 101
16.1 Media on Demand (Unicast) ........................... 105 17 Examples ............................................ 102
16.2 Streaming of a Container file ....................... 107 17.1 Media on Demand (Unicast) ........................... 102
16.3 Single Stream Container Files ....................... 110 17.2 Streaming of a Container file ....................... 105
16.4 Live Media Presentation Using Multicast ............. 112 17.3 Single Stream Container Files ....................... 108
16.5 Capability Negotiation .............................. 113 17.4 Live Media Presentation Using Multicast ............. 110
17 Security Framework .................................. 114 17.5 Capability Negotiation .............................. 111
17.1 RTSP and HTTP Authentication ........................ 115 18 Security Framework .................................. 112
17.2 RTSP over TLS ....................................... 115 18.1 RTSP and HTTP Authentication ........................ 112
17.3 Security and Proxies ................................ 116 18.2 RTSP over TLS ....................................... 112
17.3.1 Accept-Credentials .................................. 117 18.3 Security and Proxies ................................ 113
17.3.2 User approved TLS procedure ......................... 118 18.3.1 Accept-Credentials .................................. 114
18 Syntax .............................................. 119 18.3.2 User approved TLS procedure ......................... 115
18.1 Base Syntax ......................................... 119 19 Syntax .............................................. 117
18.2 RTSP Protocol Definition ............................ 121 19.1 Base Syntax ......................................... 117
18.2.1 Generic Protocol elements ........................... 121 19.2 RTSP Protocol Definition ............................ 119
18.2.2 Message Syntax ...................................... 122 19.2.1 Generic Protocol elements ........................... 119
18.2.3 Header Syntax ....................................... 126 19.2.2 Message Syntax ...................................... 120
19 Security Considerations ............................. 129 19.2.3 Header Syntax ....................................... 124
20 IANA Considerations ................................. 131 19.3 SDP extension Syntax ................................ 129
20.1 Feature-tags ........................................ 131 20 Security Considerations ............................. 130
20.1.1 Description ......................................... 131 20.1 Remote denial of Service Attack ..................... 132
20.1.2 Registering New Feature-tags with IANA .............. 132 21 IANA Considerations ................................. 132
20.1.3 Registered entries .................................. 132 21.1 Feature-tags ........................................ 133
20.2 RTSP Methods ........................................ 132 21.1.1 Description ......................................... 133
20.2.1 Description ......................................... 132 21.1.2 Registering New Feature-tags with IANA .............. 133
20.2.2 Registering New Methods with IANA ................... 132 21.1.3 Registered entries .................................. 133
20.2.3 Registered Entries .................................. 133 21.2 RTSP Methods ........................................ 134
20.3 RTSP Status Codes ................................... 133 21.2.1 Description ......................................... 134
20.3.1 Description ......................................... 133 21.2.2 Registering New Methods with IANA ................... 134
20.3.2 Registering New Status Codes with IANA .............. 133 21.2.3 Registered Entries .................................. 134
20.3.3 Registered Entries .................................. 133 21.3 RTSP Status Codes ................................... 134
20.4 RTSP Headers ........................................ 133 21.3.1 Description ......................................... 134
20.4.1 Description ......................................... 133 21.3.2 Registering New Status Codes with IANA .............. 135
20.4.2 Registering New Headers with IANA ................... 134 21.3.3 Registered Entries .................................. 135
20.4.3 Registered entries .................................. 134 21.4 RTSP Headers ........................................ 135
20.5 Transport Header registries ......................... 134 21.4.1 Description ......................................... 135
20.5.1 Transport Protocols ................................. 135 21.4.2 Registering New Headers with IANA ................... 135
20.5.2 Profile ............................................. 135 21.4.3 Registered entries .................................. 136
20.5.3 Lower Transport ..................................... 136 21.5 Transport Header registries ......................... 136
20.5.4 Transport modes ..................................... 136 21.5.1 Transport Protocols ................................. 136
20.6 Cache Directive Extensions .......................... 136 21.5.2 Profile ............................................. 137
20.7 Accept-Credentials policies ......................... 137 21.5.3 Lower Transport ..................................... 137
20.8 URI Schemes ......................................... 138 21.5.4 Transport modes ..................................... 138
20.9 SDP attributes ...................................... 138 21.5.5 Transport Parameters ................................ 138
A RTSP Protocol State Machine ......................... 139 21.6 Cache Directive Extensions .......................... 139
A.1 States .............................................. 139 21.7 Accept-Credentials policies ......................... 139
A.2 State variables ..................................... 139 21.8 URI Schemes ......................................... 140
A.3 Abbreviations ....................................... 140 21.9 SDP attributes ...................................... 140
A.4 State Tables ........................................ 140 A RTSP Protocol State Machine ......................... 141
B Media Transport Alternatives ........................ 143 A.1 States .............................................. 141
B.1 RTP ................................................. 143 A.2 State variables ..................................... 142
B.1.1 AVP ................................................. 143 A.3 Abbreviations ....................................... 142
B.1.2 AVP/UDP ............................................. 144 A.4 State Tables ........................................ 142
B.1.3 AVP/TCP ............................................. 146 B Media Transport Alternatives ........................ 145
B.1.4 Handling NPT Jumps in the RTP Media Layer ........... 146 B.1 RTP ................................................. 146
B.1.5 Handling RTP Timestamps after PAUSE ................. 149 B.1.1 AVP ................................................. 146
B.1.6 RTSP / RTP Integration .............................. 151 B.1.2 AVP/UDP ............................................. 146
B.1.7 Scaling with RTP .................................... 151 B.1.3 AVP/TCP ............................................. 147
B.1.8 Maintaining NPT synchronization with RTP B.1.4 AVPF ................................................ 148
timestamps ..................................................... 151 B.1.5 SAVP ................................................ 148
B.1.9 Continuous Audio .................................... 151 B.1.6 Handling NPT Jumps in the RTP Media Layer ........... 148
B.1.10 Multiple Sources in an RTP Session .................. 152 B.1.7 Handling RTP Timestamps after PAUSE ................. 151
B.1.11 Usage of SSRCs and the RTCP BYE Message During an B.1.8 RTSP / RTP Integration .............................. 153
RTSP Session ................................................... 152 B.1.9 Scaling with RTP .................................... 153
B.2 Future Additions .................................... 152 B.1.10 Maintaining NPT synchronization with RTP
C Use of SDP for RTSP Session Descriptions ............ 153 timestamps .......................................... 153
C.1 Definitions ......................................... 153 B.1.11 Continuous Audio .................................... 153
C.1.1 Control URI ......................................... 153 B.1.12 Multiple Sources in an RTP Session .................. 153
C.1.2 Media Streams ....................................... 154 B.1.13 Usage of SSRCs and the RTCP BYE Message During an
C.1.3 Payload Type(s) ..................................... 155 RTSP Session ........................................ 154
C.1.4 Format-Specific Parameters .......................... 155 B.2 Future Additions .................................... 154
C.1.5 Range of Presentation ............................... 155 C Use of SDP for RTSP Session Descriptions ............ 155
C.1.6 Time of Availability ................................ 156 C.1 Definitions ......................................... 155
C.1.7 Connection Information .............................. 156 C.1.1 Control URI ......................................... 155
C.1.8 Entity Tag .......................................... 157 C.1.2 Media Streams ....................................... 156
C.2 Aggregate Control Not Available ..................... 157 C.1.3 Payload Type(s) ..................................... 157
C.3 Aggregate Control Available ......................... 158 C.1.4 Format-Specific Parameters .......................... 157
C.4 RTSP external SDP delivery .......................... 159 C.1.5 Range of Presentation ............................... 157
D Minimal RTSP implementation ......................... 159 C.1.6 Time of Availability ................................ 158
D.1 Client .............................................. 159 C.1.7 Connection Information .............................. 158
D.1.1 Basic Playback ...................................... 160 C.1.8 Entity Tag .......................................... 158
D.1.2 Authentication-enabled .............................. 161 C.2 Aggregate Control Not Available ..................... 159
D.2 Server .............................................. 161 C.3 Aggregate Control Available ......................... 160
D.2.1 Basic Playback ...................................... 162 C.4 RTSP external SDP delivery .......................... 161
D.2.2 Authentication-enabled .............................. 162 D Minimal RTSP implementation ......................... 161
D.1 Minimal Core Implementation ......................... 161
D.2 The Basic Playback Feature Support .................. 162
D.2.1 Client .............................................. 162
D.2.2 Server .............................................. 163
D.2.3 Proxy ............................................... 163
D.3 Secure Transport .................................... 163
D.4 Old Implementation Text ............................. 163
D.5 Client .............................................. 164
D.5.1 Basic Playback ...................................... 164
D.5.2 Authentication-enabled .............................. 165
D.6 Server .............................................. 165
D.6.1 Basic Playback ...................................... 166
D.6.2 Authentication-enabled .............................. 166
E Requirements for Unreliable Transport of RTSP E Requirements for Unreliable Transport of RTSP
messages ....................................................... 163 messages ............................................ 167
F Backwards Compatibility Considerations .............. 164 F Backwards Compatibility Considerations .............. 168
F.1 Requirement on Pause before Play in Play mode ....... 164 F.1 Play Request in Play mode ........................... 168
F.2 Using Persistent Connections ........................ 164 F.2 Using Persistent Connections ........................ 168
G Open Issues ......................................... 164 G Open Issues ......................................... 169
H Changes ............................................. 166 H Changes ............................................. 169
H.1 Issues Addressed .................................... 166 H.1 Changes needing to be updated ....................... 175
H.2 Changes made to the protocol and specification I Author Addresses .................................... 175
.............................................................. 167 J Contributors ........................................ 176
I Author Addresses .................................... 172 K Acknowledgements .................................... 176
J Contributors ........................................ 172 L Normative References ................................ 177
K Acknowledgements .................................... 173 M Informative References .............................. 179
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 memorandum specifies RTSP 1.1 which is an update of RTSP 1.0, a
defined in RFC 2326 [23]. The goal the update is to progress RTSP to proposed standard defined in RFC 2326 [24]. The goal of this version
draft standard status. Many flaws have been identified in RTSP since is to correct the many flaws that have been identified in RTSP 1.0
its publication. While this draft tries to address these flaws, not since its publication. The corrections are such that full backwards
all known issues have been resolved. Appendix H catalogs the issues compatibility was impossible. Thus a new version was decided the most
that have already been addressed. Known open issues are listed in appropriate solution to get a more functional protocol. There are no
appendix G. plans to revise RTSP 1.0. Appendix H catalogs the changes of this
version in relation to RTSP 1.0.
The possibility of progressing RTSP to draft standard without A few open issues still remain to be resolved, and are listed in
republishing RTSP as a proposed standard depends on the changes appendix G. These are intended to be close quickly.
necessary to make the protocol work.
A list of bugs against the specification is available at A list of bugs against RFC 2326 is available at
"http://rtspspec.sourceforge.net". These bugs should be taken into "http://rtspspec.sourceforge.net". These bugs should be taken into
account when reading this specification. Input on the unresolved bugs account when reading this memorandum. Input on the unresolved bugs
and other issues can be sent via e-mail to the MMUSIC WG's mailing and other issues can be sent via e-mail to the MMUSIC WG's mailing
list mmusic@ietf.org and the authors. list mmusic@ietf.org and the authors.
Not all of the contents of RFC 2326 are part of this draft. In an RTSP 1.1 is reduced in functionality in regards to RTSP 1.0 and aims
attempt to prevent bloat, the specification has been reduced and at specifying the RTSP core, functionality and rules for extensions,
split. The content of this draft is the core specification of the and basic interaction with the media delivery protocol RTP.
protocol. It contains the general idea behind RTSP and the basic
functionality necessary to establish an on-demand play-back session. Any other functionality would be need to be published as extension
It also contains the mechanisms for extending the protocol. Any other documents. The Working group has discussed a number of different
functionality will be published as extension documents. The Working proposals to extensions and is currently working on:
group is currently working on:
o NAT and FW traversal mechanisms for RTSP are described in a o NAT and FW traversal mechanisms for RTSP are described in a
document called "How to make Real-Time Streaming Protocol document called "How to make Real-Time Streaming Protocol
(RTSP) traverse Network Address Translators (NAT) and interact (RTSP) traverse Network Address Translators (NAT) and interact
with Firewalls." [24]. with Firewalls." [25].
There have also been discussion or proposals about the following
extensions to RTSP:
o Mute and Unmute Extension [25].
o RTSP Stream Switching [26].
o Live Streaming Relays [27].
o Unreliable transport of RTSP messages (rtspu).
o The Record functionality.
o A text body type with suitable syntax for basic parameters to
be used in SET_PARAMETER, and GET_PARAMETER. Including IANA
registry within the defined name space.
o An RTSP MIB.
1.2 Purpose 1.2 Purpose
The Real-Time Streaming Protocol (RTSP) establishes and controls The Real-Time Streaming Protocol (RTSP) establishes and controls one
single or several time-synchronized streams of continuous media such or several time-synchronized streams of continuous media such as
as audio and video. Put simply, RTSP acts as a "network remote audio and video. Put simply, RTSP acts as a "network remote control"
control" for multimedia servers. for multimedia servers.
There is no notion of an RTSP connection in the protocol. Instead, an There is no notion of an RTSP connection in the protocol. Instead, an
RTSP server maintains a session labelled by an identifier to RTSP server maintains a session labeled by an identifier to associate
associate groups of media streams and their states. An RTSP session groups of media streams and their states. An RTSP session is not tied
is not tied to a transport-level connection such as a TCP connection. to a transport-level connection such as a TCP connection. During a
During a session, a client may open and close many reliable transport session, a client may open and close many reliable transport
connections to the server to issue RTSP requests for that session. connections to the server to issue RTSP requests for that session.
This memorandum describes the use of RTSP over a reliable connection This memorandum describes the use of RTSP over a reliable connection
based transport level protocol such as TCP. RTSP may be implemented based transport level protocol such as TCP. RTSP may be implemented
over an unreliable connectionless transport protocol such as UDP. over an unreliable connectionless transport protocol such as UDP.
While nothing in RTSP precludes this, additional definition of this While nothing in RTSP precludes this, additional definition of this
problem area 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
[23] and the tradeoff in size and complexity of this spec. [24] and the tradeoff in size and complexity of this
for a small gain in a targeted problem space was not deemed memorandum for a small gain in a limited problem space was
justifiable. not deemed 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
[1] 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 [2] 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 [3] 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
skipping to change at page 11, line 19 skipping to change at page 10, line 46
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
[28]. [26].
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 [3] 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
or some other method. If the presentation is being or some other method. If the presentation is being
multicast, the presentation description contains the multicast, the presentation description contains the
multicast addresses and ports to be used for the continuous multicast addresses and ports to be used for the continuous
media. If the presentation is to be sent only to the client media. If the presentation is to be sent only to the client
via unicast, the client provides the destination for via unicast, the client provides the destination of
security reasons. necessity.
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 [3]. HTTP/1.1 [3].
skipping to change at page 12, line 4 skipping to change at page 11, line 30
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 [3]. 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 [3]). 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 (ABNF) described in detail
RFC 2234 [4]. in 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 [5]. 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 in an
review in an extension specification to RTSP. extension specification to RTSP.
1.4 Terminology 1.4 Terminology
Some of the terminology has been adopted from HTTP/1.1 [3]. 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
skipping to change at page 13, line 29 skipping to change at page 13, line 6
Entity: The information transferred as the payload of a request Entity: The information transferred as the payload of a request
or response. An entity consists of meta-information in the or response. An entity consists of meta-information in the
form of entity-header fields and content in the form of an form of entity-header fields and content in the form of an
entity-body, as described in Section 8. entity-body, as described in Section 8.
Feature-tag: A tag representing a certain set of functionality, Feature-tag: A tag representing a certain set of functionality,
i.e. a feature. i.e. a feature.
Live: Normally used to describe a presentation or session with Live: Normally used to describe a presentation or session with
media coming from ongoing event. This generally results in media coming from an ongoing event. This generally results
that the session has a unbound or only loosely defined in that the session has a unbound or only loosely defined
duration, and that no seek operations are possible. duration, and that no seek operations are possible.
Media initialization: Datatype/codec specific initialization. Media initialization: Datatype/codec specific initialization.
This includes such things as clock rates, color tables, This includes such things as clock rates, color tables,
etc. Any transport-independent information which is etc. Any transport-independent information which is
required by a client for playback of a media stream occurs required by a client for playback of a media stream occurs
in the media initialization phase of stream setup. in the media initialization phase of stream setup.
Media parameter: Parameter specific to a media type that may be Media parameter: Parameter specific to a media type that may be
changed before or during stream playback. changed before or during stream playback.
skipping to change at page 14, line 10 skipping to change at page 13, line 36
different media server. different media server.
(Media) stream: A single media instance, e.g., an audio stream (Media) stream: A single media instance, e.g., an audio stream
or a video stream as well as a single whiteboard or shared or a video stream as well as a single whiteboard or shared
application group. When using RTP, a stream consists of all application group. When using RTP, a stream consists of all
RTP and RTCP packets created by a source within an RTP RTP and RTCP packets created by a source within an RTP
session. session.
Message: The basic unit of RTSP communication, consisting of a Message: The basic unit of RTSP communication, consisting of a
structured sequence of octets matching the syntax defined structured sequence of octets matching the syntax defined
in Section 18 and transmitted over a connection or a in Section 19 and transmitted over a connection or a
connectionless transport. connectionless transport.
Non-Aggregated Control: Control of a single media stream. Only Non-Aggregated Control: Control of a single media stream. Only
possible in RTSP sessions with a single media. possible in RTSP sessions with a single media.
Participant: Member of a conference. A participant may be a Participant: Member of a conference. A participant may be a
machine, e.g., a playback server. machine, e.g., a playback server.
Presentation: A set of one or more streams presented to the Presentation: A set of one or more streams presented to the
client as a complete media feed and described by a client as a complete media feed and described by a
skipping to change at page 15, line 23 skipping to change at page 14, line 48
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 3986 [18]. In RTSP URI: Universal Resource Identifier, see RFC 3986 [10]. In RTSP
the used URIs are as general rule in fact URI's as they the used URIs are as general rule in fact URL's as they
gives an location for the resource. Therefore although RTSP gives an location for the resource. As URLs are a subset of
URIs are a subset of URIs, they will be refered as URIs. URIs, they will be referred to as URIs to cover also the
cases when an RTSP URI would not be an URL.
URI: Universal Resource Locator, is an URI which identifies the URL: Universal Resource Locator, is an URI which identifies the
resource through its primary access mechanism, rather than resource through its primary access mechanism, rather than
identifying the resource by name or by some other identifying the resource by name or by some other
attribute(s) of that resource. attribute(s) of that resource.
1.5 Protocol Properties 1.5 Protocol Properties
RTSP has the following properties: RTSP has the following properties:
Extendable: New methods and parameters can be easily added to Extendable: New methods and parameters can be easily added to
RTSP. RTSP.
skipping to change at page 16, line 20 skipping to change at page 15, line 46
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 [29] or H.323 [30] may be conference. In particular, SIP [27] or H.323 [28] 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
[31]) firewalls. A firewall may need to understand the [29]) 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 [32,33]) for associating labels with content. Selection [30,31]) 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 19 skipping to change at page 16, line 45
Since not all media servers have the same functionality, media Since not all media servers have the same functionality, media
servers by necessity will support different sets of requests. For servers by necessity will support different sets of requests. For
example: example:
o A server may not be capable of seeking (absolute positioning) o A server may not be capable of seeking (absolute positioning)
if it is to support live events only. if it is to support live events only.
o Some servers may not support setting stream parameters and o Some servers may not support setting stream parameters and
thus not support GET_PARAMETER and SET_PARAMETER. thus not support GET_PARAMETER and SET_PARAMETER.
o Some server may support an RTSP extension, for example the o Some server may support an RTSP extension.
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 [3], 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:
skipping to change at page 19, line 22 skipping to change at page 18, line 45
transported on a TCP connection while the media data is conveyed via transported on a TCP connection while the media data is conveyed via
UDP. Thus, data delivery continues even if no RTSP requests are UDP. Thus, data delivery continues even if no RTSP requests are
received by the media server. Also, during its lifetime, a single received by the media server. Also, during its lifetime, a single
media stream may be controlled by RTSP requests issued sequentially media stream may be controlled by RTSP requests issued sequentially
on different TCP connections. Therefore, the server needs to maintain on different TCP connections. Therefore, the server needs to maintain
"session state" to be able to correlate RTSP requests with a stream. "session state" to be able to correlate RTSP requests with a stream.
The state transitions are described in Appendix A. The state transitions are described in Appendix A.
Many methods in RTSP do not contribute to state. However, the Many methods in RTSP do not contribute to state. However, the
following play a central role in defining the allocation and usage of following play a central role in defining the allocation and usage of
stream resources on the server: SETUP, PLAY, PAUSE, REDIRECT, PING stream resources on the server: SETUP, PLAY, PAUSE, REDIRECT, and
and TEARDOWN. TEARDOWN.
SETUP: Causes the server to allocate resources for a stream and SETUP: Causes the server to allocate resources for a stream and
create an RTSP session. create an RTSP session.
PLAY: Starts data transmission on a stream allocated via SETUP. PLAY: Starts data transmission on a stream allocated via SETUP.
PAUSE: Temporarily halts a stream without freeing server PAUSE: Temporarily halts a stream without freeing server
resources. resources.
REDIRECT: Indicates that the session should be moved to new REDIRECT: Indicates that the session should be moved to new
server / location server / location
PING: Prevents the identified session from being timed out.
TEARDOWN: Frees resources associated with the stream. The RTSP TEARDOWN: Frees resources associated with the stream. The RTSP
session ceases to exist on the server. session ceases to exist on the server.
RTSP methods that contribute to state use the Session header field RTSP methods that contribute to state use the Session header field
(Section 14.42) to identify the RTSP session whose state is being (Section 14.42) to identify the RTSP session whose state is being
manipulated. The server generates session identifiers in response to manipulated. The server generates session identifiers in response to
SETUP requests (Section 11.3). SETUP requests (Section 11.3).
1.9 Relationship with Other Protocols 1.9 Relationship with Other Protocols
skipping to change at page 20, line 30 skipping to change at page 20, line 4
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)
[1] 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 the most important and considered use cases
This section describes some of the use cases for RTSP. They are for RTSP. They are listed in descending order of importance in
listed in descending order of importance in regards to ensuring that regards to ensuring that all necessary functionality is present. This
all necessary functionality is present. This specification does only specification does only fully support usage of the two first. Also in
fully support usage of the two first. Also in these first two cases these first two cases, there are special cases or exceptions that are
are there special cases that will not be supported without not supported without extensions, e.g. the redirection of media to
extensions, e.g. the redirection of media to another address than the another address than the controlling entity.
controlling entity.
2.1 On-demand Playback of Stored Content 2.1 On-demand Playback of Stored Content
An RTSP capable server stores content suitable for being streamed to An RTSP capable server stores content suitable for being streamed to
a client. A client desiring playback of any of the stored content a client. A client desiring playback of any of the stored content
uses RTSP to set up the media transport required for the desired then uses RTSP to set up and configure the media transport required
content. Then RTSP is used to initiate, halt and manipulate the for the desired content. Then RTSP is used to initiate, halt and
transmission of the content. There are also requirement on being able manipulate the actual transmission (playout) of the content. There
to use RTSP to carry necessary description and synchronization are also requirement on being able to use RTSP to carry necessary
information for the content. The above high level description can be description and synchronization information for the content. The
broken down into a number of functionalities that RTSP needs to be above high level description can be broken down into a number of
capable of. functionalities that RTSP needs to be capable of.
Presentation Description: The possibility to carry Presentation Description: The possibility to carry
initialization information about the presentation initialization information about the presentation
(content), for example, which media codec(s) that are (content), for example, which media codec(s) that are
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 used 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 [3] or email to fetch or receive the use of HTTP [3] or email to fetch or receive
presentation descriptions like SDP [1]. .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 at arbitrary times start or stop the transmission
the content. There are also exist need to be able to start of the content. There are also exist need to be able to
the transmission at an any point in the timeline of the start the transmission at an any point in the timeline of
presentation. .XP Synchronization: For media transport the presentation. .XP Synchronization: For media transport
protocols like RTP [16] 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:
skipping to change at page 21, line 52 skipping to change at page 21, line 23
and can be accessed at any time during a time period when and can be accessed at any time during a time period when
it is intended to be available. .XP Independent sessions: A it is intended to be available. .XP Independent sessions: A
server is capable of serving a number of clients server is capable of serving a number of clients
simultaneously, including from the same piece of content at simultaneously, including from the same piece of content at
different points in that presentations time-line. .XP different points in that presentations time-line. .XP
Unicast Transport: Content for each individual client is Unicast Transport: Content for each individual client is
transmitted to them using unicast traffic. transmitted to them using unicast traffic.
It is also possible to redirect the media traffic to another It is also possible to redirect the media traffic to another
destination than where the entity controlling traffic uses. destination than where the entity controlling traffic uses.
However allowing this without appropriate mechanisms for However allowing this without appropriate mechanisms for
checking that the destination approves of this is a denial of checking that the destination approves of this is allows for
service threat. distributed denial of service attacks (DDoS).
2.2 Unicast distribution of Live Content 2.2 Unicast distribution of Live Content
This use cases is not that different from the above on-demand content This use cases is not that different from the above on-demand content
case (see section 2.1. The difference is really the restriction the case (see section 2.1. The difference is really the restriction the
content itself establish. Live content is continuously distributed as content itself establish. Live content is continuously distributed as
it becomes available from a source, i.e. the main difference to on- it becomes available from a source, i.e. the main difference to on-
demand is that one starts distributing content before the end of it demand is that one starts distributing content before the end of it
has become available to the server. In many cases the consumer of has become available to the server. In many cases the consumer of
live content is only interested in consuming what is actually happens live content is only interested in consuming what is actually happens
skipping to change at page 23, line 7 skipping to change at page 22, line 27
transmission to the group is simplest controlled by a single transmission to the group is simplest controlled by a single
participant or leader of the conference. Shared control might be participant or leader of the conference. Shared control might be
possible, but would require further investigation and possibly possible, but would require further investigation and possibly
extensions. There are some protocol mechanisms missing for this extensions. There are some protocol mechanisms missing for this
scenario. For reasonable complexity in the media transmission stage, scenario. For reasonable complexity in the media transmission stage,
this use case assumes that there exist either multicast or a this use case assumes that there exist either multicast or a
conference focus that redistribute media to all participants. In some conference focus that redistribute media to all participants. In some
more detail, this use case is intended to be able to handle the more detail, this use case is intended to be able to handle the
following scenario: A conference leader or participant (from here following scenario: A conference leader or participant (from here
called the controller) has some pre-stored content on a RTSP server called the controller) has some pre-stored content on a RTSP server
that he likes to share with the group. The controller sets up a RTSP that he likes to share with the group. The controller sets up an RTSP
session at the streaming server for the content the controller likes session at the streaming server for the content the controller likes
to share. The session description for the content is retrieved to the to share. The session description for the content is retrieved by the
controller. The media destination for the media content is set to the controller. The media destination for the media content is sent to
shared multicast group or conference focus. When desired by the the shared multicast group or conference focus. When desired by the
controller, he/she can start and stop the transmission of the media controller, he/she can start and stop the transmission of the media
to the conference group. There are several issues with this use case to the conference group. There are several issues with this use case
that is not solved by this core specification for RTSP: that is not solved by this core specification for RTSP:
o Denial of service threat, to avoid a RTSP server from being a o Denial of service threat, to avoid a RTSP server from being a
unknowing participant of a denial of service attack the server unknowing participant of a denial of service attack the server
needs to be able to verify the destinations acceptance for the needs to be able to verify the destinations acceptance for the
media. Such a mechanism does not yet exist that can be used to media. Such a mechanism does not yet exist that can be used to
verify the approval to received media, instead only policies verify the approval to received media, instead only policies
can be used, which can be made to work in controlled can be used, which can be made to work in controlled
skipping to change at page 23, line 40 skipping to change at page 23, line 12
required by an external protocol for the necessary exchange of required by an external protocol for the necessary exchange of
state information and possibly floor control of who is state information and possibly floor control of who is
controlling the RTSP session. controlling the RTSP session.
So if there interest in this use case further work on the necessary So if there interest in this use case further work on the necessary
extensions has to be performed. extensions has to be performed.
2.5 Live Content using Multicast 2.5 Live Content using Multicast
This use case does in its simplest form do not require any use of This use case does in its simplest form do not require any use of
RTSP at all. This is what multicast conferences being announce with RTSP at all. This is what multicast conferences being announced with
SAP and SDP are intended to handle. However in use cases where more SAP and SDP are intended to handle. However in use cases where more
advance features like access control to the multicast session is advance features like access control to the multicast session is
desired, RTSP could be used for session establishment. A client desired, RTSP could be used for session establishment. A client
desiring to join a live multicasted media session with cryptographic desiring to join a live multicasted media session with cryptographic
(encryption) access control could use RTSP in the following way. The (encryption) access control could use RTSP in the following way. The
source of the session, announces the session and gives all interested source of the session, announces the session and gives all interested
to join, a RTSP URI. The client connects to the server and requests to join, a RTSP URI. The client connects to the server and requests
the presentation description allowing for configuration the the presentation description allowing for configuration the
reception. In this step it is possible to use secured transport for reception. In this step it is possible to use secured transport for
the client, and also desired levels of authentication, for example the client, and also desired levels of authentication, for example
for charging purposes or simply access control. An RTSP link also for charging purposes or simply access control. An RTSP link also
allows for load balancing between multiple servers. However if this allows for load balancing between multiple servers. However if this
the only thing that occurs it can probably be solved as simple using was the only thing that occurred it could probably be solved as
HTTP. However for session where the sender likes to keep track of simply using HTTP. However for session where the sender likes to keep
each individual receiver during the session, and possibly use this track of each individual receiver during the session, and possibly
side channel for pushing out key-updates or other side information use this side channel for pushing out key-updates or other side
that is desirable to be done on a per receiver basis, and the information that is desirable to be done on a per receiver basis, and
receivers are not know prior to the session start, the state the receivers are not know prior to the session start, the state
establishment that RTSP provides can be beneficial. In this case a establishment that RTSP provides can be beneficial. In this case a
client would establish a RTSP session to the multicast group. The client would establish a RTSP session to the multicast group. The
RTSP server will not transmit any media, instead it will simply point RTSP server will not transmit any media, instead it will simply point
to the multicast group. However the client and server will be able to to the multicast group. However the client and server will be able to
keep the session alive for as long as the receiver participates in keep the session alive for as long as the receiver participates in
the session. Thus enabling for example server to client pushes of the session. Thus enabling, for example server to client pushes of
updates. This use cases will most likely not be able to actually updates. This use cases will most likely not be able to actually
implement some extensions in relation to the server to client push implement without some extensions in relation to the server to client
mechanism. Here a method like ANNOUNCE might be suitable, however it push mechanism. Here a method like ANNOUNCE (see RFC 2326 [24] might
will require a RTSP extension to revive the method. be suitable, however it will require a RTSP extension to revive the
method.
3 Protocol Parameters 3 Protocol Parameters
3.1 RTSP Version 3.1 RTSP Version
HTTP Specification Section [H3.1] applies, with HTTP replaced by HTTP Specification Section [H3.1] applies, with HTTP replaced by
RTSP. This specification defines version 1.0 of RTSP. RTSP. This specification defines version 1.1 of RTSP.
3.2 RTSP URI 3.2 RTSP URI
The "rtsp", "rtsps" schemes are used to refer to network resources The "rtsp", "rtsps" schemes are used to refer to network resources
via the RTSP protocol. This section defines the scheme-specific via the RTSP protocol. This section defines the scheme-specific
syntax and semantics for RTSP URIs. The RTSP URI is case sensitive. syntax and semantics for RTSP URIs. The RTSP URI is case sensitive.
An URI scheme "rtspu" was defined in RFC 2326 for transport of RTSP An URI scheme "rtspu" was defined in RFC 2326 for transport of RTSP
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:
skipping to change at page 24, line 43 skipping to change at page 24, line 16
syntax and semantics for RTSP URIs. The RTSP URI is case sensitive. syntax and semantics for RTSP URIs. The RTSP URI is case sensitive.
An URI scheme "rtspu" was defined in RFC 2326 for transport of RTSP An URI scheme "rtspu" was defined in RFC 2326 for transport of RTSP
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 19.2.1 for the formal definition of the RTSP URI syntax.
The fragment identifier is used as defined in section 4.1 of [18], The fragment identifier is used as defined in section 4.1 of [10],
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.
skipping to change at page 25, line 21 skipping to change at page 24, line 41
identifies a reliable transport using secure transport (TLS [6]). 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 [10]). Note: Using qualified domain names in any URI is (see RFC 1924 [11]). This specification updates the RTSP URI scheme
one requirement for making it possible for RFC 2326 implementations to allow for literal IPv6 addresses using the host specification in
of RTSP to use IPv6. This specification is updated to allow for RFC 2732 [12].
literal IPv6 addresses in RTSP URIs using the host specification in
RFC 2732 [11]. Note: Using qualified domain names in any URI is one
requirement for making it possible for RTSP 1.0 (RFC 2326)
implementations of RTSP to use IPv6.
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 3986 [18]). URIs may refer to a stream or an aggregate of URIs (RFC 3986 [10]). 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
identifies the audio stream within the presentation "twister", which may identify the audio stream within the presentation "twister",
can be controlled via RTSP requests issued over a TCP connection to which can be controlled via RTSP requests issued over a TCP
port 554 of host media.example.com connection to port 554 of host media.example.com
Also, the RTSP URI: Also, the RTSP URI:
rtsp://media.example.com:554/twister rtsp://media.example.com:554/twister
identifies the presentation "twister", which may be composed of audio identifies the presentation "twister", which may be composed of audio
and video streams. and video streams.
This does not imply a standard way to reference streams in This does not imply a standard way to reference streams in
URIs. The presentation description defines the hierarchical URIs. The presentation description defines the hierarchical
skipping to change at page 26, line 22 skipping to change at page 25, line 44
not imply any particular file system structure for the server. not imply any particular file system structure for the server.
This decoupling also allows presentation descriptions to be This decoupling also allows presentation descriptions to be
used with non-RTSP media control protocols simply by used with non-RTSP media control protocols simply by
replacing the scheme in the URI. replacing the scheme in the URI.
3.3 Session Identifiers 3.3 Session Identifiers
Session identifiers are strings of any arbitrary length. A session Session identifiers are strings of any arbitrary length. A session
identifier MUST be chosen randomly and MUST be at least eight identifier MUST be chosen randomly and MUST be at least eight
characters long to make guessing it more difficult. (See Section 19.) characters long to make guessing it more difficult. (See Section 20.)
3.4 SMPTE Relative Timestamps 3.4 SMPTE Relative Timestamps
A SMPTE relative timestamp expresses time relative to the start of A SMPTE relative timestamp expresses time relative to the start of
the clip. Relative timestamps are expressed as SMPTE time codes for the clip. Relative timestamps are expressed as SMPTE time codes for
frame-level access accuracy. The time code has the format frame-level access accuracy. The time code has the format
hours:minutes:seconds:frames.subframes, hours:minutes:seconds:frames.subframes,
with the origin at the start of the clip. The default smpte format with the origin at the start of the clip. The default smpte format is
is"SMPTE 30 drop" format, with frame rate is 29.97 frames per second. "SMPTE 30 drop" format, with frame rate is 29.97 frames per second.
Other SMPTE codes MAY be supported (such as "SMPTE 25") through the Other SMPTE codes MAY be supported (such as "SMPTE 25") through the
use of alternative use of "smpte time". For the "frames" field in the use of alternative use of "smpte time". For the "frames" field in the
time value can assume the values 0 through 29. The difference between time value can assume the values 0 through 29. The difference between
30 and 29.97 frames per second is handled by dropping the first two 30 and 29.97 frames per second is handled by dropping the first two
frame indices (values 00 and 01) of every minute, except every tenth frame indices (values 00 and 01) of every minute, except every tenth
minute. If the frame value is zero, it may be omitted. Subframes are minute. If the frame value is zero, it may be omitted. Subframes are
measured in one-hundredth of a frame. measured in one-hundredth of a frame.
Examples: Examples:
smpte=10:12:33:20- smpte=10:12:33:20-
smpte=10:07:33- smpte=10:07:33-
smpte=10:07:00-10:07:33:05.01 smpte=10:07:00-10:07:33:05.01
smpte-25=10:07:00-10:07:33:05.01 smpte-25=10:07:00-10:07:33:05.01
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) [34]. The timestamp consists of with the Network Time Protocol (NTP) [32]. 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 [35]: "Intuitively, NPT is the clock the NPT is defined as in DSM-CC [33]: "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 [36]. The npt-sec notation The syntax conforms to ISO 8601 [34]. 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 [36] timestamps, using UTC Absolute time is expressed as ISO 8601 [34] 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
RTSP. These tags are used in Require (Section 14.37), Proxy-Require RTSP. These tags are used in Require (Section 14.37), Proxy-Require
(Section 14.31), Proxy-Supported (Section 14.32), Unsupported (Section 14.31), Proxy-Supported (Section 14.32), Unsupported
(Section 14.46), and Supported (Section 14.43) header fields. (Section 14.46), and Supported (Section 14.43) header fields.
Feature tag needs to indicate if they apply to servers only, proxies Feature tag needs to indicate which combination of clients, servers,
only, or both server and proxies. or proxies they applies too.
The creator of a new RTSP feature-tag should either prefix the The creator of a new RTSP feature-tag should either prefix the
feature-tag with a reverse domain name (e.g., feature-tag with a reverse domain name (e.g.,
"com.example.mynewfeature" is an apt name for a feature whose "com.example.mynewfeature" is an apt name for a feature whose
inventor can be reached at "example.com"), or register the new inventor can be reached at "example.com"), or register the new
feature-tag with the Internet Assigned Numbers Authority (IANA), see feature-tag with the Internet Assigned Numbers Authority (IANA), see
IANA Section 20. IANA Section 21.
The usage of feature tags are further described in section 10 that The usage of feature tags are further described in section 10 that
deals with capability handling. deals with capability handling.
3.8 Entity Tags 3.8 Entity Tags
Entity tags are opaque strings that are used to compare two entities Entity tags are opaque strings that are used to compare two entities
from the same resource, for example in caches or to optimize setup from the same resource, for example in caches or to optimize setup
after a redirect. Further explanation is present in [H3.11]. For after a redirect. Further explanation is present in [H3.11]. For
explanation on how to compare Entity tags see [H13.3]. Entity tags explanation on how to compare Entity tags see [H13.3]. Entity tags
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.
skipping to change at page 28, line 41 skipping to change at page 28, line 18
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 [13]). Lines are terminated by CRLF, but UTF-8 encoding (RFC 2279 [13]). Lines SHALL be terminated by CRLF.
receivers should be prepared to also interpret CR and LF by
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
skipping to change at page 31, line 12 skipping to change at page 30, line 38
What method, on what resources and using which RTSP version. The What method, on what resources and using which RTSP version. The
methods that are defined by this specification are listed in Table 2. methods that are defined by this specification are listed in Table 2.
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
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 syntax of the RTSP request line is the following: The syntax of the RTSP request line is the following:
<Method> SP <Request-URI> SP <RTSP-Version> CRLF <Method> SP <Request-URI> SP <RTSP-Version> CRLF
skipping to change at page 31, line 45 skipping to change at page 31, line 25
HTTP/1.0 servers, a consideration that does not apply to HTTP/1.0 servers, a consideration that does not apply to
RTSP. RTSP.
An asterisk "*" can be used in the Request-URI to indicate that the 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 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 proxy itself, and is only allowed when the request method does not
necessarily apply to a resource. necessarily apply to a resource.
For example: For example:
OPTIONS * RTSP/1.0 OPTIONS * RTSP/1.1
An OPTIONS in this form will determine the capabilities of the server An OPTIONS in this form will determine the capabilities of the server
or the proxy that first receives the request. If the capability of or the proxy that first receives the request. If the capability of
the specific server needs to be determined, without regard to the the specific server needs to be determined, without regard to the
capability of an intervening proxy, the server should be addressed capability of an intervening proxy, the server should be addressed
explicitly with an absolute URI that contains the server's address. explicitly with an absolute URI that contains the server's address.
For example: For example:
OPTIONS rtsp://example.com RTSP/1.0 OPTIONS rtsp://example.com RTSP/1.1
6.2 Request Header Fields 6.2 Request Header Fields
The RTSP headers in Table 3 can be included in a request, as request The RTSP headers in Table 3 can be included in a request, as request
headers, to modify the specifics of the request. These headers may headers, to modify the specifics of the request. These headers may
also be used in the response to a request, as response headers, to also be used in the response to a request, as response headers, to
modify the specifics of a response (Section 7.1.2). modify the specifics of a response (Section 7.1.2).
Detailed headers definition are provided in Section 14.
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
If-Match Section 14.25 If-Match Section 14.25
skipping to change at page 32, line 46 skipping to change at page 32, line 30
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 7 skipping to change at page 33, line 34
o 3rr: Redirection - Further action needs to be taken in order o 3rr: Redirection - Further action needs to be taken in order
to complete the request to complete the request
o 4xx: Client Error - The request contains bad syntax or cannot o 4xx: Client Error - The request contains bad syntax or cannot
be fulfilled be fulfilled
o 5xx: Server Error - The server failed to fulfill an apparently o 5xx: Server Error - The server failed to fulfill an apparently
valid request valid request
The individual values of the numeric status codes defined for The individual values of the numeric status codes defined for
RTSP/1.0, and an example set of corresponding Reason-Phrases, are RTSP/1.1, 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 [3] 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
skipping to change at page 35, line 18 skipping to change at page 34, line 42
In this section, both sender and recipient refer to either the client In this section, both sender and recipient refer to either the client
or the server, depending on who sends and who receives the entity. or the server, depending on who sends and who receives the entity.
8.1 Entity Header Fields 8.1 Entity Header Fields
Entity-header fields define optional meta-information about the Entity-header fields define optional meta-information about the
entity-body or, if no body is present, about the resource identified entity-body or, if no body is present, about the resource identified
by the request. The entity header fields are listed in table 8.1. by the request. The entity header fields are listed in table 8.1.
Header Defined in Section
____________________________________
Allow Section 14.6
Content-Base Section 14.13
Content-Encoding Section 14.14
Content-Language Section 14.15
Content-Length Section 14.16
Content-Location Section 14.17
Content-Type Section 14.18
Expires Section 14.22
Last-Modified Section 14.28
Table 6: The RTSP entity headers
The extension-header mechanism allows additional entity-header fields The extension-header mechanism allows additional entity-header fields
to be defined without changing the protocol, but these fields cannot to be defined without changing the protocol, but these fields cannot
be assumed to be recognizable by the recipient. Unrecognized header be assumed to be recognizable by the recipient. Unrecognized header
fields SHOULD be ignored by the recipient and forwarded by proxies. fields SHOULD be ignored by the recipient and forwarded by proxies.
8.2 Entity Body 8.2 Entity Body
See [H7.2] with the addition that 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 over two different connection RTSP requests can be transmitted over two different connection
scenarios listed below: scenarios listed below:
o persistent - transport connections used for several o persistent - transport connections used for several
request/response transactions; request/response transactions;
skipping to change at page 36, line 4 skipping to change at page 35, line 14
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 over two different connection RTSP requests can be transmitted over two different connection
scenarios listed below: scenarios listed below:
o persistent - transport connections used for several o persistent - transport connections used for several
request/response transactions; request/response transactions;
o transient - transport connections used for a single
request/response transaction.
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, RTSP 1.1 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.
Certain RTSP headers, such as the CSeq header (Section 14.19), which
may appear to be relevant to only connectionless transport scenarios
are still retained and must be implemented according to the
specification. In the case of CSeq it is quite useful in proxy
situations for keeping track of the different request when
aggregating several client requests to a single TCP connection.
9.1 Reliability and Acknowledgements
Since RTSP is transmitted primarily over connection oriented,
reliable transport protocols, all RTSP requests MUST be acknowledged
by the receiver. RTSP requests that are not immediately acknowledged
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
the RTSP application retransmit requests, each packet loss
or message loss may result in two retransmissions. The
receiver typically cannot take advantage of the
application-layer retransmission since the transport stack
will not deliver the application-layer retransmission
Code Reason Method Code Reason Method
__________________________________________________________ __________________________________________________________
100 Continue all 100 Continue all
__________________________________________________________ __________________________________________________________
200 OK all 200 OK all
201 Created RECORD 201 Reserved n/a
250 Low on Storage Space RECORD 250 Reserved n/a
__________________________________________________________ __________________________________________________________
300 Multiple Choices all 300 Multiple Choices all
301 Moved Permanently all 301 Moved Permanently all
302 Found all 302 Found all
303 See Other all 303 See Other all
305 Use Proxy all 305 Use Proxy all
__________________________________________________________ __________________________________________________________
400 Bad Request all 400 Bad Request all
401 Unauthorized all 401 Unauthorized all
skipping to change at page 36, line 47 skipping to change at page 36, line 47
453 Not Enough Bandwidth SETUP 453 Not Enough Bandwidth SETUP
454 Session Not Found all 454 Session Not Found all
455 Method Not Valid In This State all 455 Method Not Valid In This State all
456 Header Field Not Valid all 456 Header Field Not Valid all
457 Invalid Range PLAY, PAUSE 457 Invalid Range PLAY, PAUSE
458 Parameter Is Read-Only SET_PARAMETER 458 Parameter Is Read-Only SET_PARAMETER
459 Aggregate Operation Not Allowed all 459 Aggregate Operation Not Allowed all
460 Only Aggregate Operation Allowed all 460 Only Aggregate Operation Allowed all
461 Unsupported Transport all 461 Unsupported Transport all
462 Destination Unreachable all 462 Destination Unreachable all
463 Destination Prohibited SETUP
470 Connection Authorization Required all 470 Connection Authorization Required all
471 Connection Credentials not accepted all 471 Connection Credentials not accepted all
__________________________________________________________ __________________________________________________________
500 Internal Server Error all 500 Internal Server Error all
501 Not Implemented all 501 Not Implemented all
502 Bad Gateway all 502 Bad Gateway all
503 Service Unavailable all 503 Service Unavailable all
504 Gateway Timeout all 504 Gateway Timeout all
505 RTSP Version Not Supported all
Table 4: Status codes and their usage with RTSP methods Table 4: Status codes and their usage with RTSP methods
Header Defined in Section Header Defined in Section
__________________________________________ __________________________________________
Accept-Ranges Section 14.5 Accept-Ranges Section 14.5
Connection-Credentials Section 14.12 Connection-Credentials 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
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
o transient - transport connections used for a single Header Defined in Section
request/response transaction.
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.
In order to maintain backwards compatibility of the message format, ____________________________________
certain RTSP headers, such as the CSeq header (Section 14.19), which Allow Section 14.6
would be more relevant to a connectionless transport scenario are Content-Base Section 14.13
still retained and must be implemented according to the Content-Encoding Section 14.14
specification. Content-Language Section 14.15
Content-Length Section 14.16
Content-Location Section 14.17
Content-Type Section 14.18
Expires Section 14.22
Last-Modified Section 14.28
9.1 Reliability and Acknowledgements Table 6: The RTSP entity headers
Since RTSP is transmitted primarily over connection oriented,
reliable transport protocols, all RTSP requests MUST be acknowledged
by the receiver. RTSP requests that are not immediately acknowledged
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
the RTSP application retransmit requests, each packet loss
or message loss may result in two retransmissions. The
receiver typically cannot take advantage of the
application-layer retransmission since the transport stack
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.
Lack of acknowledgement of an RTSP request should be handled within Lack of acknowledgement of an RTSP request should be handled within
the constraints of the connection timeout considerations described the constraints of the connection timeout considerations described
below (Section 9.4). below (Section 9.4).
9.2 Using Connections 9.2 Using Connections
skipping to change at page 39, line 30 skipping to change at page 39, line 10
connection does not exist between a server and its client, due to the connection does not exist between a server and its client, due to the
lack of a signalling channel, the server may be forced to drop an lack of a signalling channel, the server may be forced to drop an
RTSP session without notifying the client. An example of such a case RTSP session without notifying the client. An example of such a case
is when the server desires to send a REDIRECT request for an RTSP 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 session to the client but is not able to do so because it cannot
reach the client. reach the client.
Without a persistent connection between the client and the Without a persistent connection between the client and the
server, the media server has no reliable way of reaching server, the media server has no reliable way of reaching
the client. Also, this is the only way that requests from a the client. Also, this is the only way that requests from a
media server to its client are likely to traverse server to its client are likely to traverse firewalls.
firewalls.
In light of the above, it is RECOMMENDED that clients use persistent In light of the above, it is RECOMMENDED that clients use persistent
connections whenever possible. There are also backwards compatibility connections whenever possible. A client that supports persistent
considerations for clients in supporting persistent connections connections MAY "pipeline" its requests (i.e., send multiple requests
(Section F.2). A client that supports persistent connections MAY without waiting for each response). A server MUST send its responses
"pipeline" its requests (i.e., send multiple requests without waiting to those requests in the order that the requests were received.
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.
9.3 Closing Connections 9.3 Closing Connections
The client MAY close a connection at any point when no outstanding The client MAY close a connection at any point when no outstanding
request/response transactions exist for any RTSP session being request/response transactions exist for any RTSP session being
managed through the connection. The server, however, SHOULD NOT close managed through the connection. The server, however, SHOULD NOT close
a connection until all RTSP sessions being managed through the a connection until all RTSP sessions being managed through the
connection have been timed out (Section 14.42). A server SHOULD NOT connection have been timed out (Section 14.42). A server SHOULD NOT
close a connection immediately after responding to a session-level close a connection immediately after responding to a session-level
TEARDOWN request for the last RTSP session being controlled through TEARDOWN request for the last RTSP session being controlled through
the connection. Instead, it should wait for a reasonable amount of the connection. Instead, it should wait for a reasonable amount of
time for the client to: receive the TEARDOWN response, take time for the client to: receive the TEARDOWN response, take
appropriate action, and initiate the connection closing. The server appropriate action, and initiate the connection closing. The server
SHOULD wait at least 10 seconds after sending the TEARDOWN response SHOULD wait at least 10 seconds after sending the TEARDOWN response
before closing the connection. before closing the connection.
This is to ensure that the client has time to issue a SETUP This is to ensure that the client has time to issue a SETUP
for a new session on the existing connection after having for a new session on the existing connection after having
torn the last one down. 10 seconds should give the client torn the last one down. 10 seconds should give the client
an opportunity get its message to the server. ample opportunity get its message to the server.
A server SHOULD NOT close the connection directly as a result of A server SHOULD NOT close the connection directly as a result of
responding to a request with an error code. responding to a request with an error code.
Certain error responses such as "460 Only Aggregate Certain error responses such as "460 Only Aggregate
Operation Allowed" (Section 13.4.12) are used for Operation Allowed" (Section 13.4.12) are used for
negotiating capabilities of a server with respect to negotiating capabilities of a server with respect to
content or other factors. In such cases, it is inefficient content or other factors. In such cases, it is inefficient
for the server to close a connection on an error response. for the server to close a connection on an error response.
Also, such behavior would prevent implementation of Also, such behavior would prevent implementation of
advanced/special types of requests or result in extra advanced/special types of requests or result in extra
overhead for the client when testing for new features. On overhead for the client when testing for new features. On
the flip side, keeping connections open after sending an the flip side, keeping connections open after sending an
error response poses a Denial of Service security risk error response poses a Denial of Service security risk
(Section 19). (Section 20).
If a server initiates a connection close while the client is If a server initiates a connection close while the client is
attempting to send a new request, the client will have to close its attempting to send a new request, the client will have to close its
current connection, establish a new connection and send its request current connection, establish a new connection and send its request
over the new connection. over the new connection.
An RTSP message should not be terminated through a connection close. An RTSP message should not be terminated through a connection close.
Such a message will be considered to be incomplete by the receiver Such a message will be considered to be incomplete by the receiver
and discarded. An RTSP message is properly terminated as defined in and discarded. An RTSP message is properly terminated as defined in
Section 4. Section 4.
skipping to change at page 41, line 32 skipping to change at page 40, line 49
is 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 of the responder. The requestor is capable of determining the RTT of the
request/response cycle using the Timestamp header (section 14.44) in request/response cycle using the Timestamp header (section 14.44) in
any RTSP request. any RTSP request.
9.5 Use of IPv6 9.5 Use of IPv6
Since explicit IPv6 support was not present in RFC 2326, some Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP
interoperability issues do exist when working with older 1.1 has been updated for explicit IPv6 support. Implementations of
implementations. An RFC 2326 implementation can support IPv6 as long RTSP 1.1 MUST understand literal IPv6 addresses in URIs and headers.
as no literal IPv6 addresses are used within RTSP messages. Thus,
RTSP URIs pointing to IPv6 hosts need to use fully qualified domain
names instead of literal IPv6 addresses. Further, in an IPv6
environment, the Transport header cannot include the source or
destination parameters as they require literal addresses.
This specification has been updated for explicit IPv6 support.
Implementations of this specifiation MUST understand literal IPv6
addresses in URIs and headers. This requirement is subsumed in the
"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 29 skipping to change at page 41, line 35
does not apply for the resource (405). The choice between the two does not apply for the resource (405). The choice between the two
discovery methods depends on the requirements of the service. discovery methods depends on the requirements of the service.
Feature-Tags are defined to handle functionality additions that are Feature-Tags are defined to handle functionality additions that are
not new methods. Each feature-tag represents a certain block of not new methods. Each feature-tag represents a certain block of
functionality. The amount of functionality that a feature-tag functionality. The amount of functionality that a feature-tag
represents can vary significantly. A feature-tag can for example represents can vary significantly. A feature-tag can for example
represent the functionality a single RTSP header provides. Another represent the functionality a single RTSP header provides. Another
feature-tag can represent much more functionality, such as the feature-tag can represent much more functionality, such as the
"play.basic" feature tag which represents the minimal playback "play.basic" feature tag which represents the minimal playback
implementation according to the updated specification. implementation.
Feature-tags are used to determine wether the client, server or proxy Feature-tags are used to determine wether the client, server or proxy
supports the functionality that is necessary to achieve the desired supports the functionality that is necessary to achieve the desired
service. To determine support of a feature-tag, several different service. To determine support of a feature-tag, several different
headers can be used, each explained below: headers can be used, each explained below:
Supported: The supported header is used to determine the Supported: The supported header is used to determine the
complete set of functionality that both client and server complete set of functionality that both client and server
have. The intended usage is to determine before one needs have. The intended usage is to determine before one needs
to use a functionality that it is supported. It can be used to use a functionality that it is supported. It can be used
skipping to change at page 43, line 44 skipping to change at page 42, line 49
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 [4]. Methods are summarized in Table 7. by the ABNF [4] in the syntax chapter 19. The methods are summarized
in Table 7.
Note on Table 7: PAUSE is recommended, but not required.
For example, a fully functional server can be built to
deliver live feeds, which do not support this method.
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 required required
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 required
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 required 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
Note on Table 7: GET_PARAMETER is recommended, but not
required. For example, a fully functional server can be
built to deliver media without any parameters.
SET_PARAMETER is required however due to its usage for
keep-alive. PAUSE is now required due to that it is the
only way of getting out of the state machines play state
without terminating the whole session.
If an RTSP agent does not support a particular method, it MUST return If an RTSP agent does not support a particular method, it MUST return
501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD 501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD
NOT try this method again for the given agent / resource combination. NOT try this method again for the given agent / resource combination.
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
skipping to change at page 45, line 4 skipping to change at page 44, line 11
the indicated RTSP agent. A Request-URI with only the host address the indicated RTSP agent. A Request-URI with only the host address
limits the scope to the specified RTSP agent's general capabilities limits the scope to the specified RTSP agent's general capabilities
without regard to any specific media. If the Request-URI is an without regard to any specific media. If the Request-URI is an
asterisk ("*"), the scope is limited to the general capabilities of asterisk ("*"), the scope is limited to the general capabilities of
the next hop (i.e. the RTSP agent in direct communication with the the next hop (i.e. the RTSP agent in direct communication with the
request sender). request sender).
Regardless of scope of the request, the Public header MUST always be Regardless of scope of the request, the Public header MUST always be
included in the OPTIONS response listing the methods that are included in the OPTIONS response listing the methods that are
supported by the responding RTSP agent. In addition, if the scope of supported by the responding RTSP agent. In addition, if the scope of
the request is limited to a media resource, the Allow header MAY be the request is limited to a media resource, the Allow header MUST be
included in the response to enumerate the set of methods that are included in the response to enumerate the set of methods that are
allowed for that resource. If the given resource is not available, allowed for that resource unless the set of methods completely
the RTSP agent SHOULD return an appropriate response code such as 3rr matches the set in the Public header. If the given resource is not
or 4xx. The Supported header can be included in the request to query available, the RTSP agent SHOULD return an appropriate response code
the set of features that are supported by the responding RTSP agent. such as 3rr or 4xx. The Supported header MAY be included in the
request to query the set of features that are supported by the
responding RTSP agent.
The OPTIONS method can be used to keep an RTSP session alive. The OPTIONS method can be used to keep an RTSP session alive.
However, it is not the preferred means of session keep-alive However, it is not the preferred means of session keep-alive
signalling, see section 14.42. An OPTIONS request intended for signalling, see section 14.42. An OPTIONS request intended for
keeping alive an RTSP session MUST include the Session header with keeping alive an RTSP session MUST include the Session header with
the associated session ID. Such a request SHOULD also use the media the associated session ID. Such a request SHOULD also use the media
or the aggregated control URI as the Request-URI. or the aggregated control URI as the Request-URI.
Example: Example:
C->S: OPTIONS * RTSP/1.0 C->S: OPTIONS * RTSP/1.1
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Require: Require:
Proxy-Require: gzipped-messages Proxy-Require: gzipped-messages
Supported: play.basic Supported: play.basic
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
CSeq: 1 CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
Supported: play.basic, implicit-play, gzipped-messages Supported: play.basic, implicit-play, gzipped-messages
Server: PhonyServer/1.0 Server: PhonyServer/1.1
Note that some of the feature-tags in Require and Proxy-Require are Note that some of the feature-tags in Require and Proxy-Require are
necessarily fictional features (one would hope that we would not necessarily fictional features (one would hope that we would not
purposefully overlook a truly useful feature just so that we could purposefully overlook a truly useful feature just so that we could
have a strong example in this section). have a strong example in this section).
11.2 DESCRIBE 11.2 DESCRIBE
The DESCRIBE method is used to retrieve the description of a The DESCRIBE method is used to retrieve the description of a
presentation or media object from a server. The Request-URI of the presentation or media object from a server. The Request-URI of the
DESCRIBE request identifies the media resource of interest. The DESCRIBE request identifies the media resource of interest. The
client MAY include the Accept header in the request to list the client MAY include the Accept header in the request to list the
description formats that it understands. The server SHALL respond description formats that it understands. The server SHALL respond
with a description of the requested resource and return the with a description of the requested resource and return the
description in the entity of the response. The DESCRIBE reply- description in the entity of the response. The DESCRIBE reply-
response pair constitutes the media initialization phase of RTSP. response pair constitutes the media initialization phase of RTSP.
Example: Example:
skipping to change at page 46, line 7 skipping to change at page 45, line 15
presentation or media object from a server. The Request-URI of the presentation or media object from a server. The Request-URI of the
DESCRIBE request identifies the media resource of interest. The DESCRIBE request identifies the media resource of interest. The
client MAY include the Accept header in the request to list the client MAY include the Accept header in the request to list the
description formats that it understands. The server SHALL respond description formats that it understands. The server SHALL respond
with a description of the requested resource and return the with a description of the requested resource and return the
description in the entity of the response. The DESCRIBE reply- description in the entity of the response. The DESCRIBE reply-
response pair constitutes the media initialization phase of RTSP. response pair constitutes the media initialization phase of RTSP.
Example: Example:
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.1
CSeq: 312 CSeq: 312
User-Agent: PhonyClient 1.2 User-Agent: PhonyClient 1.2
Accept: application/sdp, application/rtsl, application/mheg Accept: application/sdp, application/rtsl, application/mheg
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
CSeq: 312 CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.1
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 376 Content-Length: 367
v=0 v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps u=http://www.example.com/lectures/sdp.ps
e=mjh@isi.edu (Mark Handley) e=seminar@example.com (Seminar Management)
c=IN IP4 224.2.17.12/127 c=IN IP4 224.2.17.12/127
t=2873397496 2873404696 t=2873397496 2873404696
a=recvonly a=recvonly
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31 m=video 2232 RTP/AVP 31
m=application 32416 UDP WB m=application 32416 UDP WB
a=orient:portrait a=orient:portrait
The DESCRIBE response MUST contain all media initialization The DESCRIBE response SHOULD contain all media initialization
information for the resource(s) that it describes. Servers SHOULD NOT information for the resource(s) that it describes. Servers SHOULD NOT
use the DESCRIBE response as a means of media indirection. use the DESCRIBE response as a means of media indirection by having
the description point at another server, instead usage of 3rr
responses are recommended.
By forcing a DESCRIBE response to contain all media By forcing a DESCRIBE response to contain all media
initialization for the set of streams that it describes, initialization for the set of streams that it describes,
and discouraging the use of DESCRIBE for media indirection, and discouraging the use of DESCRIBE for media indirection,
any looping problems can be avoided that might have any looping problems can be avoided that might have
resulted from other approaches. resulted from other approaches.
Media initialization is a requirement for any RTSP-based system, but Media initialization is a requirement for any RTSP-based system, but
the RTSP specification does not dictate that this is required to be the RTSP specification does not dictate that this is required to be
done via the DESCRIBE method. There are three ways that an RTSP done via the DESCRIBE method. There are three ways that an RTSP
client may receive initialization information: client may receive initialization information:
o via an RTSP DESCRIBE method o via an RTSP DESCRIBE request
o via some other protocol (HTTP, email attachment, etc.) o via some other protocol (HTTP, email attachment, etc.)
o via some form of a user interface o via some form of a user interface
If a client obtains a valid description from an alternate source, the If a client obtains a valid description from an alternate source, the
client MAY use this description for initialization purposes without client MAY use this description for initialization purposes without
issuing a DESCRIBE request for the same media. issuing a DESCRIBE request for the same media.
It is RECOMMENDED that minimal servers support the DESCRIBE method, It is RECOMMENDED that minimal servers support the DESCRIBE method,
and highly recommended that minimal clients support the ability to and highly recommended that minimal clients support the ability to
skipping to change at page 48, line 9 skipping to change at page 47, line 20
Since SETUP includes all transport initialization Since SETUP includes all transport initialization
information, firewalls and other intermediate network information, firewalls and other intermediate network
devices (which need this information) are spared the more devices (which need this information) are spared the more
arduous task of parsing the DESCRIBE response, which has arduous task of parsing the DESCRIBE response, which has
been reserved for media initialization. been reserved for media initialization.
In a SETUP response the server SHOULD include the Accept-Ranges In a SETUP response the server SHOULD include the Accept-Ranges
header (see section 14.5 to indicate which time formats that are header (see section 14.5 to indicate which time formats that are
acceptable to use for this media resource. acceptable to use for this media resource.
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.1
CSeq: 302 CSeq: 302
Transport: RTP/AVP;unicast;client_port=4588-4589, Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589",
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
CSeq: 302 CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.1
Session: 47112344;timeout=60 Session: 47112344;timeout=60
Transport: RTP/AVP;unicast;client_port=4588-4589; Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589";
server_port=6256-6257;ssrc=2A3F93ED src_addr="192.0.2.241:6256"/"192.0.2.241:6257";
ssrc=2A3F93ED
Accept-Ranges: NPT Accept-Ranges: NPT
In the above example the client wants to create an RTSP session In the above example the client wants to create an RTSP session
containing the media resource "rtsp://example.com/foo/bar/baz.rm". containing the media resource "rtsp://example.com/foo/bar/baz.rm".
The transport parameters acceptable to the client is either The transport parameters acceptable to the client is either
RTP/AVP/UDP (UDP per default) to be received on client port 4588 and RTP/AVP/UDP (UDP per default) to be received on client port 4588 and
4589 or RTP/AVP interleaved on the RTSP control channel. The server 4589 or RTP/AVP interleaved on the RTSP control channel. The server
selects the RTP/AVP/UDP transport and adds the ports it will send and selects the RTP/AVP/UDP transport and adds the ports it will send and
received RTP and RTCP from, and the RTP SSRC that will be used by the received RTP and RTCP from, and the RTP SSRC that will be used by the
server. server.
skipping to change at page 49, line 13 skipping to change at page 48, line 25
given an aggregated control URI is unspecified. given an aggregated control URI is unspecified.
While the session ID sometimes has enough information for While the session ID sometimes has enough information for
aggregate control of a session, the Aggregate control 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.
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 49, line 40 skipping to change at page 48, line 51
for any of the media streams in that RTSP session. RTCP Sender for any of the media streams in that RTSP session. RTCP Sender
Reports may for example be received in sessions where the Reports may for example be received in sessions where the
server is invited into a conference session and is as valid server is invited into a conference session and is as valid
for keep-alive. for keep-alive.
If a SETUP request on a session fails for any reason, the session If a SETUP request on a session fails for any reason, the session
state, as well as transport and other parameters for associated state, as well as transport and other parameters for associated
streams SHALL remain unchanged from their values as if the SETUP streams SHALL remain unchanged from their values as if the SETUP
request had never been received by the server. request had never been received by the server.
11.3.1 Changing Transport Parameters
A client MAY issue a SETUP request for a stream that is already set A client MAY issue a SETUP request for a stream that is already set
up or playing in the session to change transport parameters, which a up or playing in the session to change transport parameters, which a
server MAY allow. If it does not allow this, it MUST respond with server MAY allow. If it does not allow changing of parameters, it
error 455 (Method Not Valid In This State). Reasons to support MUST respond with error 455 (Method Not Valid In This State). Reasons
changing transport parameters, is to allow for application layer to support changing transport parameters, is to allow for application
mobility and flexibility to utilize the best available transport as layer mobility and flexibility to utilize the best available
it becomes available. transport as it becomes available. If a client receives a 455 when
trying to change transport parameters while the server is in play
state, it MAY try to put the server in ready state using PAUSE.
Before trying issuing the SETUP request again. If also that fails the
changing of transport parameters will require that the client
performs a TEARDOWN of the affected media and then setting it up
again. In aggregated session avoiding tearing down all the media at
the same time will avoid the creation of a new session.
All transport parameters MAY be changed. However the primary usage
expected is to either change transport protocol completely, like
switching from Interleaved TCP mode to RTP or vise versa or change
delivery address.
In a SETUP response for a request to change the transport parameters In a SETUP response for a request to change the transport parameters
while in Play state, the server SHOULD include the Range to indicate while in Play state, the server SHOULD include the Range to indicate
from what point the new transport parameters are used. Further, if from what point the new transport parameters are used. Further, if
RTP is used for delivery, the server SHOULD also include the RTP-Info RTP is used for delivery, the server SHOULD also include the RTP-Info
header to indicate from what timestamp and RTP sequence number the header to indicate from what timestamp and RTP sequence number the
change has taken place. If both RTP-Info and Range is included in the change has taken place. If both RTP-Info and Range is included in the
response the "rtp_time" parameter and range MUST be for the response the "rtp_time" parameter and range MUST be for the
corresponding time, i.e. be used in the same way as for PLAY to corresponding time, i.e. be used in the same way as for PLAY to
ensure the correct synchronization information is available. ensure the correct synchronization information is available.
skipping to change at page 50, line 20 skipping to change at page 49, line 45
change of synchronization related information, for example changing change of synchronization related information, for example changing
RTP SSRC, the server MUST provide in the SETUP response the necessary RTP SSRC, the server MUST provide in the SETUP response the necessary
synchronization information. However the server is RECOMMENDED to synchronization information. However the server is RECOMMENDED to
avoid changing the synchronization information if possible. avoid changing the synchronization information if possible.
11.4 PLAY 11.4 PLAY
The PLAY method tells the server to start sending data via the The PLAY method tells the server to start sending data via the
mechanism specified in SETUP. A client MUST NOT issue a PLAY request mechanism specified in SETUP. A client MUST NOT issue a PLAY request
until any outstanding SETUP requests have been acknowledged as until any outstanding SETUP requests have been acknowledged as
successful. PLAY requests are valid when the session is in READY successful. PLAY requests are valid when the session is in READY or
state; the use of PLAY requests when the session is in PLAY state is PLAY states. A PLAY request MUST include a Session header to indicate
deprecated. A PLAY request MUST include a Session header to indicate
which session the request applies to. which session the request applies to.
In an aggregated session the PLAY request MUST contain an aggregated In an aggregated session the PLAY request MUST contain an aggregated
control URI. A server SHALL responde with error 460 (Only Aggregate control URI. A server SHALL responde with error 460 (Only Aggregate
Operation Allowed) if the client PLAY Request-URI is for one of the Operation Allowed) if the client PLAY Request-URI is for one of the
media. The media in an aggregate SHALL be played in sync. If a client media. The media in an aggregate SHALL be played in sync. If a client
want individual control of the media it needs to use separate RTSP want individual control of the media it needs to use separate RTSP
sessions for each media. sessions for each media.
The PLAY request SHALL position the normal play time to the beginning The PLAY request SHALL position the normal play time to the beginning
skipping to change at page 50, line 45 skipping to change at page 50, line 21
reached. To allow for precise composition multiple ranges MAY be reached. To allow for precise composition multiple ranges MAY be
specified in one PLAY Request. The range values are valid if all specified in one PLAY Request. The range values are valid if all
given ranges are part of any media within the aggregate. If a given given ranges are part of any media within the aggregate. If a given
range value points outside of the media, the response SHALL be the range value points outside of the media, the response SHALL be the
457 (Invalid Range) error code. 457 (Invalid Range) error code.
The below example will first play seconds 10 through 15, then, The below example will first play seconds 10 through 15, then,
immediately following, seconds 20 to 25, and finally seconds 30 immediately following, seconds 20 to 25, and finally seconds 30
through the end. through the end.
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 C->S: PLAY rtsp://audio.example.com/audio RTSP/1.1
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Range: npt=10-15, npt=20-25, npt=30- Range: npt=10-15, npt=20-25, npt=30-
See the description of the PAUSE request for further examples. See the description of the PAUSE request for further examples.
A PLAY request without a Range header is legal. It SHALL start A PLAY request without a Range header is legal. It SHALL start
playing a stream from the beginning (npt=0-) unless the stream has playing a stream from the beginning (npt=0-) unless the stream has
been paused. If a stream has been paused via PAUSE, stream delivery been paused or is currently playing. If a stream has been paused via
resumes at the pause point. The stream SHALL play until the end of PAUSE, stream delivery resumes at the pause point. If a stream is
the media. currently playing, the new PLAY begins at the current stream
position. The stream SHALL play until the end of the media.
The Range header MUST NOT contain a time parameter. The usage of time The Range header MUST NOT contain a time parameter. The usage of time
in PLAY method has been deprecated. If a request with time parameter in PLAY method has been deprecated. If a request with time parameter
is received the server SHOULD respond with a 457 (Invalid Range) to is received the server SHOULD respond with a 457 (Invalid Range) to
indicate that the time parameter is not supported. indicate that the time parameter is not supported.
Server MUST include a "Range" header in any PLAY response. The Server MUST include a "Range" header in any PLAY response. The
response MUST use the same format as the request's range header response MUST use the same format as the request's range header
contained. If no Range header was in the request, the NPT time format contained. If no Range header was in the request, the NPT time format
SHOULD be used unless the client showed support for an other format SHOULD be used unless the client showed support for an other format
skipping to change at page 51, line 44 skipping to change at page 51, line 22
content at this time) is delivered. This may differ from the content at this time) is delivered. This may differ from the
requested range if alignment of the requested range to valid frame requested range if alignment of the requested range to valid frame
boundaries is required for the media source. Note that some media boundaries is required for the media source. Note that some media
streams in an aggregate may need to be delivered from even earlier streams in an aggregate may need to be delivered from even earlier
points. Also, some media format have a very long duration per points. Also, some media format have a very long duration per
individual data unit, therefore it might be necessary for the client individual data unit, therefore it might be necessary for the client
to parse the data unit, and select where to start. to parse the data unit, and select where to start.
Example: Single audio stream (MIDI) Example: Single audio stream (MIDI)
C->S: PLAY rtsp://example.com/audio RTSP/1.0 C->S: PLAY rtsp://example.com/audio RTSP/1.1
CSeq: 836 CSeq: 836
Session: 12345678 Session: 12345678
Range: npt=7.05- Range: npt=7.05-
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
CSeq: 836 CSeq: 836
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=3.52- Range: npt=3.52-
RTP-Info:url=rtsp://example.com/audio; RTP-Info:url="rtsp://example.com/audio"
seq=14783;rtptime=2345962545 ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTP Packet TS=2345962545 => NPT=3.52 S->C: RTP Packet TS=2345962545 => NPT=3.52
Duration: 4.15 seconds Duration: 4.15 seconds
In this example the client receives the first media packet that In this example the client receives the first media packet that
stretches all the way up and past the requested playtime. Thus, it is stretches all the way up and past the requested playtime. Thus, it is
the client's decision if to render to the user the time between 3.52 the client's decision if to render to the user the time between 3.52
and 7.05, or to skip it. In most cases it is probably most suitable and 7.05, or to skip it. In most cases it is probably most suitable
to not render that time period. to not render that time period.
skipping to change at page 52, line 37 skipping to change at page 52, line 18
as long as the given range is valid for any media, for example the as long as the given range is valid for any media, for example the
longest media. Media will be sent whenever it is available for the longest media. Media will be sent whenever it is available for the
given play-out point. given play-out point.
A PLAY response MAY include a header(s) carrying synchronization A PLAY response MAY include a header(s) carrying synchronization
information. As the information necessary is dependent on the media information. As the information necessary is dependent on the media
transport format, further rules specifying the header and its usage transport format, further rules specifying the header and its usage
is needed. For RTP the RTP-Info header is specified, see section is needed. For RTP the RTP-Info header is specified, see section
14.38. 14.38.
After playing the desired range, the presentation is NOT After playing the desired range, the presentation does NOT transition
automatically paused, media delivery simply stops. A PAUSE request to the READY state, media delivery simply stops. A PAUSE request MUST
MUST be issued before another PLAY request can be issued. be issued before the stream enters the READY state. A PLAY request
while the stream is still in the PLAYING state is legal, and can be
Note: The above is a change resulting in a non-operability issued without an intervening PAUSE request. Such a request SHALL
with RFC 2326 implementations. See Appendix F.1 replace the current PLAY action with the new one requested, i.e.
being handle the same as the request was received in ready state. In
the case the first time range in Range header has a open start time
(-endtime), the server SHALL continue to play from where it currently
was.
A client desiring to play the media from the beginning MUST send a A client desiring to play the media from the beginning MUST send a
PLAY request with a Range header pointing at the beginning, e.g. PLAY request with a Range header pointing at the beginning, e.g.
npt=0-. If a PLAY request is received without a Range header when npt=0-. If a PLAY request is received without a Range header when
media delivery has stopped at the end, the server SHOULD respond with media delivery has stopped at the end, the server SHOULD respond with
a 457 "Invalid Range" error response. In that response the current a 457 "Invalid Range" error response. In that response the current
pause point in a Range header SHALL be included. pause point in a Range header SHALL be included.
The following example plays the whole presentation starting at SMPTE The following example plays the whole presentation starting at SMPTE
time code 0:10:20 until the end of the clip. Note: The RTP-Info time code 0:10:20 until the end of the clip. Note: The RTP-Info
headers has been broken into several lines to fit the page. headers has been broken into several lines to fit the page.
C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.1
CSeq: 833 CSeq: 833
Session: 12345678 Session: 12345678
Range: smpte=0:10:20- Range: smpte=0:10:20-
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
CSeq: 833 CSeq: 833
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: smpte=0:10:22-0:15:45 Range: smpte=0:10:22-0:15:45
RTP-Info:url=rtsp://example.com/twister.en; RTP-Info:url="rtsp://example.com/twister.en"
seq=14783;rtptime=2345962545 ssrc=0D12F123:seq=14783;rtptime=2345962545
For playing back a recording of a live presentation, it may be For playing back a recording of a live presentation, it may be
desirable to use clock units: desirable to use clock units:
C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.1
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Range: clock=19961108T142300Z-19961108T143520Z Range: clock=19961108T142300Z-19961108T143520Z
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
CSeq: 835 CSeq: 835
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server:PhonyServer 1.0 Server:PhonyServer 1.0
Range: clock=19961108T142300Z-19961108T143520Z Range: clock=19961108T142300Z-19961108T143520Z
RTP-Info:url=rtsp://example.com/meeting.en; RTP-Info:url="rtsp://example.com/meeting.en"
seq=53745;rtptime=484589019 ssrc=0D12F123: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 [23] is removed The possibility to replace a current PLAY request with a new one
and multiple ranges can be used to achieve a similar functionality. replaces two RTSP 1.0 functions:
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
This State). This will signal the client that queued play are not
supported.
The use of PLAY for keep-alive signaling, i.e. PLAY request without a o The queued play functionality described in RFC 2326 [24] is
range header in PLAY state, has also been deprecated. Instead a removed and multiple ranges can be used to achieve a similar
client can use, PING, SET_PARAMETER or OPTIONS for keep alive. A functionality.
server receiving a PLAY keep alive SHALL respond with the 455 error
code. o 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 client can use, SET_PARAMETER
(recommended) or OPTIONS (allowed) for keep alive.
11.5 PAUSE 11.5 PAUSE
The PAUSE request causes the stream delivery to be interrupted The PAUSE request causes the stream delivery to be interrupted
(halted) temporarily. A PAUSE request MUST be done with the (halted) temporarily. A PAUSE request MUST be done with the
aggregated control URI for aggregated sessions, resulting in all aggregated control URI for aggregated sessions, resulting in all
media being halted, or the media URI for non-aggregated sessions. media being halted, or the media URI for non-aggregated sessions.
Any attempt to do muting of a single media with an PAUSE request in Any attempt to do muting of a single media with an PAUSE request in
an aggregated session SHALL be responded with error 460 (Only an aggregated session SHALL be responded with error 460 (Only
Aggregate Operation Allowed). After resuming playback, Aggregate Operation Allowed). After resuming playback,
synchronization of the tracks MUST be maintained. Any server synchronization of the tracks MUST be maintained. Any server
resources are kept, though servers MAY close the session and free resources are kept, though servers MAY close the session and free
resources after being paused for the duration specified with the resources after being paused for the duration specified with the
timeout parameter of the Session header in the SETUP message. timeout parameter of the Session header in the SETUP message.
Example: Example:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.1
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
CSeq: 834 CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Range: npt=45.76- Range: npt=45.76-
The PAUSE request MAY contain a Range header specifying when the The PAUSE request MAY contain a Range header specifying when the
stream or presentation is to be halted. This point is referred to as stream or presentation is to be halted. This point is referred to as
the "pause point". The time parameter in the Range MUST NOT be used. the "pause point". The time parameter in the Range MUST NOT be used.
The Range header MUST contain a single value, expressed as the The Range header MUST contain a single value, expressed as the
beginning value an open range. For example, the following clip will beginning value an open range. For example, the following clip will
be played from 10 seconds through 21 seconds of the clip's normal be played from 10 seconds through 21 seconds of the clip's normal
play time, under the assumption that the PAUSE request reaches the play time, under the assumption that the PAUSE request reaches the
server within 11 seconds of the PLAY request. Note that some lines server within 11 seconds of the PLAY request. Note that some lines
has been broken in an non-correct way to fit the page: has been broken in an non-correct way to fit the page:
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/1.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/1.1
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
Range: npt=10-30 Range: npt=10-30
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
CSeq: 834 CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=10-30 Range: npt=10-30
RTP-Info:url=rtsp://example.com/fizzle/audiotrack; RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
seq=5712;rtptime=934207921, ssrc=0D12F123:seq=5712;rtptime=934207921,
url=rtsp://example.com/fizzle/videotrack; url="rtsp://example.com/fizzle/videotrack"
seq=57654;rtptime=2792482193 ssrc=4FAD8726:seq=57654;rtptime=2792482193
Session: 12345678 Session: 12345678
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.1
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Range: npt=21- Range: npt=21-
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
CSeq: 835 CSeq: 835
Date: 23 Jan 1997 15:35:09 GMT Date: 23 Jan 1997 15:35:09 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=21- Range: npt=21-
Session: 12345678 Session: 12345678
The pause request becomes effective the first time the server is The pause request becomes effective the first time the server is
encountering the time point specified in any of the multiple ranges. encountering the time point specified in any of the multiple ranges.
If the Range header specifies a time outside any range from the PLAY If the Range header specifies a time outside any range from the PLAY
request, the error 457 (Invalid Range) SHALL be returned. If a media request, the error 457 (Invalid Range) SHALL be returned. If a media
skipping to change at page 56, line 13 skipping to change at page 55, line 37
PAUSE request's Range header, a PLAY without range SHALL resume at PAUSE request's Range header, a PLAY without range SHALL resume at
the point in time specified by the PAUSE request's Range header, as the point in time specified by the PAUSE request's Range header, as
it is assumed that the client has discarded data after that point. it is assumed that the client has discarded data after that point.
This ensures continuous pause/play cycling without gaps. This ensures continuous pause/play cycling without gaps.
The pause point after any PAUSE request SHALL be returned to the The pause point after any PAUSE request SHALL be returned to the
client by adding a Range header with what remains unplayed of the client by adding a Range header with what remains unplayed of the
PLAY request's ranges, i.e. including all the remaining ranges part PLAY request's ranges, i.e. including all the remaining ranges part
of multiple range specification. If one desires to resume playing a of multiple range specification. If one desires to resume playing a
ranged request, one simply includes the Range header from the PAUSE ranged request, one simply includes the Range header from the PAUSE
response. Note that this server behavior was not mandated previously response.
and servers implementing according to RFC 2326 will probably not
return the range header.
For example, if the server have a play request for ranges 10 to 15 For example, if the server have a play request for ranges 10 to 15
and 20 to 29 pending and then receives a pause request for NPT 21, it and 20 to 29 pending and then receives a pause request for NPT 21, it
would start playing the second range and stop at NPT 21. If the pause would start playing the second range and stop at NPT 21. If the pause
request is for NPT 12 and the server is playing at NPT 13 serving the request is for NPT 12 and the server is playing at NPT 13 serving the
first play request, the server stops immediately. If the pause first play request, the server stops immediately. If the pause
request is for NPT 16, the server returns a 457 error message. To request is for NPT 16, the server returns a 457 error message. To
prevent that the second range is played and the server stops after prevent that the second range is played and the server stops after
completing the first range, a PAUSE request for NPT 20 needs to be completing the first range, a PAUSE request for NPT 20 needs to be
issued. issued.
skipping to change at page 56, line 37 skipping to change at page 56, line 13
As another example, if a server has received requests to play ranges As another example, if a server has received requests to play ranges
10 to 15 and then 13 to 20 (that is, overlapping ranges), the PAUSE 10 to 15 and then 13 to 20 (that is, overlapping ranges), the PAUSE
request for NPT=14 would take effect while the server plays the first request for NPT=14 would take effect while the server plays the first
range, with the second range effectively being ignored, assuming the range, with the second range effectively being ignored, assuming the
PAUSE request arrives before the server has started playing the PAUSE request arrives before the server has started playing the
second, overlapping range. Regardless of when the PAUSE request second, overlapping range. Regardless of when the PAUSE request
arrives, it sets the pause point to 14. The below example messages is arrives, it sets the pause point to 14. The below example messages is
for the above case when the PAUSE request arrives before the first for the above case when the PAUSE request arrives before the first
occurrence of NPT=14. occurrence of NPT=14.
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/1.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/1.1
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
Range: npt=10-15, npt=13-20 Range: npt=10-15, npt=13-20
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
CSeq: 834 CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=10-15, npt=13-20 Range: npt=10-15, npt=13-20
RTP-Info:url=rtsp://example.com/fizzle/audiotrack; RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
seq=5712;rtptime=934207921, ssrc=0D12F123:seq=5712;rtptime=934207921,
url=rtsp://example.com/fizzle/videotrack; url="rtsp://example.com/fizzle/videotrack"
seq=57654;rtptime=2792482193 ssrc=789DAF12:seq=57654;rtptime=2792482193
Session: 12345678 Session: 12345678
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.1
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Range: npt=14- Range: npt=14-
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
CSeq: 835 CSeq: 835
Date: 23 Jan 1997 15:35:09 GMT Date: 23 Jan 1997 15:35:09 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=14-15, npt=13-20 Range: npt=14-15, npt=13-20
Session: 12345678 Session: 12345678
If a client issues a PAUSE request and the server acknowledges and If a client issues a PAUSE request and the server acknowledges and
enters the READY state, the proper server response, if the player enters the READY state, the proper server response, if the player
issues another PAUSE, is still 200 OK. The 200 OK response MUST issues another PAUSE, is still 200 OK. The 200 OK response MUST
include the Range header with the current pause point, even if the include the Range header with the current pause point, even if the
PAUSE request is asking for some other pause point. See examples PAUSE request is asking for some other pause point. See examples
below: below:
Examples: Examples:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.1
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Range: npt=45.76-98.36 Range: npt=45.76-98.36
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.1
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Range: 86- Range: 86-
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Date: 23 Jan 1997 15:35:07 GMT Date: 23 Jan 1997 15:35:07 GMT
Range: npt=45.76-98.36 Range: npt=45.76-98.36
11.6 TEARDOWN 11.6 TEARDOWN
The TEARDOWN client to server request stops the stream delivery for The TEARDOWN client to server request stops the stream delivery for
the given URI, freeing the resources associated with it. A TEARDOWN the given URI, freeing the resources associated with it. A TEARDOWN
request MAY be performed on either an aggregated or a media control request MAY be performed on either an aggregated or a media control
skipping to change at page 58, line 30 skipping to change at page 58, line 5
A TEARDOWN using a media URI in an aggregated session MAY only be A TEARDOWN using a media URI in an aggregated session MAY only be
done in Ready state. Such a request only removes the indicated media done in Ready state. Such a request only removes the indicated media
stream and associated resources from the session. This may result in stream and associated resources from the session. This may result in
that a session returns to non-aggregated control, due to that it only that a session returns to non-aggregated control, due to that it only
contains a single media after the requests completion. A session that contains a single media after the requests completion. A session that
will exist after the processing of the TEARDOWN request SHALL in the will exist after the processing of the TEARDOWN request SHALL in the
response to that TEARDOWN request contain a Session header. Thus the response to that TEARDOWN request contain a Session header. Thus the
presence of the Session indicates to the receiver of the response if presence of the Session indicates to the receiver of the response if
the session is still existing or has been removed. the session is still existing or has been removed.
Note, the indication with the session header if sessions state remain
may not be done correctly by a RFC 2326 client, but will be for any
server signalling the "play.basic" tag.
Example: Example:
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.1
CSeq: 892 CSeq: 892
Session: 12345678 Session: 12345678
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
CSeq: 892 CSeq: 892
Server: PhonyServer 1.0 Server: PhonyServer 1.0
11.7 GET_PARAMETER 11.7 GET_PARAMETER
The GET_PARAMETER request retrieves the value of a parameter or The GET_PARAMETER request retrieves the value of a parameter or
parameters for a presentation or stream specified in the URI. If the parameters for a presentation or stream specified in the URI. If the
Session header is present in a request, the value of a parameter MUST Session header is present in a request, the value of a parameter MUST
be retrieved in the specified session context. The content of the be retrieved in the specified session context. The content of the
reply and response is left to the implementation. reply and response is left to the implementation.
skipping to change at page 59, line 17 skipping to change at page 58, line 34
request is successful, i.e. a 200 OK response is received, then the request is successful, i.e. a 200 OK response is received, then the
keep-alive timer has been updated. Any non-required header present in keep-alive timer has been updated. Any non-required header present in
such a request may or may not been processed. To allow a client to such a request may or may not been processed. To allow a client to
determine if any such header has been processed, it is necessary to determine if any such header has been processed, it is necessary to
use a feature tag and the Require header. Due to this reason it is use a feature tag and the Require header. Due to this reason it is
RECOMMENDED that any parameters to be retrieved are sent in the body, RECOMMENDED that any parameters to be retrieved are sent in the body,
rather than using any header. rather than using any header.
Example: Example:
S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.1
CSeq: 431 CSeq: 431
Content-Type: text/parameters Content-Type: text/parameters
Session: 12345678 Session: 12345678
Content-Length: 15 Content-Length: 26
packets_received packets_received
jitter jitter
C->S: RTSP/1.0 200 OK C->S: RTSP/1.1 200 OK
CSeq: 431 CSeq: 431
Content-Length: 46 Content-Length: 38
Content-Type: text/parameters Content-Type: text/parameters
packets_received: 10 packets_received: 10
jitter: 0.3838 jitter: 0.3838
The "text/parameters" section is only an example type for a
The "text/parameters" section is only an example type for body carrying parameters.
parameter body.
11.8 SET_PARAMETER 11.8 SET_PARAMETER
This method requests to set the value of a parameter or a set of This method requests to set the value of a parameter or a set of
parameters for a presentation or stream specified by the URI. The parameters for a presentation or stream specified by the URI. The
method MAY also be used without a body (entity). If this request is method MAY also be used without a body (entity). It is the
successful, i.e. a 200 OK response is received, then the keep-alive RECOMMENDED method to use in request sent for the sole purpose of
timer has been updated. Any non-required header present in such a updating the keep-alive timer. If this request is successful, i.e. a
request may or may not been processed. To allow a client to determine 200 OK response is received, then the keep-alive timer has been
if any such header has been processed, it is necessary to use a updated. Any non-required header present in such a request may or may
feature tag and the Require header. Due to this reason it is not been processed. To allow a client to determine if any such header
RECOMMENDED that any parameters are sent in the body, rather than has been processed, it is necessary to use a feature tag and the
using any header. Require header. Due to this reason it is RECOMMENDED that any
parameters are sent in the body, rather than using any header.
A request is RECOMMENDED to only contain a single parameter to allow A request is RECOMMENDED to only contain a single parameter to allow
the client to determine why a particular request failed. If the the client to determine why a particular request failed. If the
request contains several parameters, the server MUST only act on the request contains several parameters, the server MUST only act on the
request if all of the parameters can be set successfully. A server request if all of the parameters can be set successfully. A server
MUST allow a parameter to be set repeatedly to the same value, but it MUST allow a parameter to be set repeatedly to the same value, but it
MAY disallow changing parameter values. If the receiver of the MAY disallow changing parameter values. If the receiver of the
request does not understand or cannot locate a parameter, error 451 request does not understand or cannot locate a parameter, error 451
(Parameter Not Understood) SHALL be used. In the case a parameter is (Parameter Not Understood) SHALL be used. In the case a parameter is
not allowed to change, the error code is 458 (Parameter Is Read- not allowed to change, the error code is 458 (Parameter Is Read-
skipping to change at page 60, line 33 skipping to change at page 59, line 48
The parameters are split in a fine-grained fashion so that The parameters are split in a fine-grained fashion so that
there can be more meaningful error indications. However, it there can be more meaningful error indications. However, it
may make sense to allow the setting of several parameters may make sense to allow the setting of several parameters
if an atomic setting is desirable. Imagine device control if an atomic setting is desirable. Imagine device control
where the client does not want the camera to pan unless it where the client does not want the camera to pan unless it
can also tilt to the right angle at the same time. can also tilt to the right angle at the same time.
Example: Example:
C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.1
CSeq: 421 CSeq: 421
Content-length: 20 Content-length: 20
Content-type: text/parameters Content-type: text/parameters
barparam: barstuff barparam: barstuff
S->C: RTSP/1.0 451 Parameter Not Understood S->C: RTSP/1.1 451 Parameter Not Understood
CSeq: 421 CSeq: 421
Content-length: 10 Content-length: 10
Content-type: text/parameters Content-type: text/parameters
barparam barparam
The "text/parameters" section is only an example type for The "text/parameters" section is only an example type for
parameter. This method is intentionally loosely defined parameter. This method is intentionally loosely defined
with the intention that the reply content and response with the intention that the reply content and response
content will be defined after further experimentation. content will be defined after further experimentation.
11.9 REDIRECT 11.9 REDIRECT
The REDIRECT method is issued by a server to inform a client that it The REDIRECT method is issued by a server to inform a client that it
required to connect to another server location to access the resource required to connect to another server location to access the resource
indicated by the Request-URI. The presence of the Session header in a indicated by the Request-URI. The presence of the Session header in a
skipping to change at page 63, line 18 skipping to change at page 62, line 31
issued. issued.
If the Location header contains only a host address, the client MAY If the Location header contains only a host address, the client MAY
assume that the media on the new server is identical to the media on assume that the media on the new server is identical to the media on
the old server, i.e. all media configuration information from the old the old server, i.e. all media configuration information from the old
session is still valid except for the host address. session is still valid except for the host address.
This example request redirects traffic for this session to the new This example request redirects traffic for this session to the new
server at the given absolute time: server at the given absolute time:
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.1
CSeq: 732 CSeq: 732
Location: rtsp://s2.example.com:8001 Location: rtsp://s2.example.com:8001
Range: npt=0- ;time=19960213T143205Z Range: npt=0- ;time=19960213T143205Z
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
11.10 PING
This method is a bi-directional mechanism for server or client
liveness checking. It has no side effects. The issuer of the request
MUST include a session header with the session ID of the session that
is being checked for liveness.
Prior to using this method, an OPTIONS method is RECOMMENDED to be
issued in the direction which the PING method would be used. This
method MUST NOT be used if support is not indicated by the Public
header. Note: That an 501 (Not Implemented) response means that the
keep-alive timer has not been updated.
When a proxy is in use, PING with a * indicates a single-hop liveness
check, whereas PING with an URI including an host address indicates
an end-to-end liveness check.
Example:
C->S: PING * RTSP/1.0
CSeq: 123
Session:12345678
S->C: RTSP/1.0 200 OK
CSeq: 123
Session:12345678
12 Embedded (Interleaved) Binary Data 12 Embedded (Interleaved) Binary Data
In order to fulfill certain requirements on the network side, e.g. In order to fulfill certain requirements on the network side, e.g.
in conjunction with firewalls that block RTP traffic, it may be in conjunction with network address translators that block RTP
necessary to interleave RTSP messages and media stream data. This traffic over UDP, it may be necessary to interleave RTSP messages and
interleaving should generally be avoided unless necessary since it media stream data. This interleaving should generally be avoided
complicates client and server operation and imposes additional unless necessary since it complicates client and server operation and
overhead. Also head of line blocking may cause problems. Interleaved imposes additional overhead. Also head of line blocking may cause
binary data SHOULD only be used if RTSP is carried over TCP. problems. Interleaved binary data SHOULD only be used if RTSP is
carried over TCP.
Stream data such as RTP packets is encapsulated by an ASCII dollar Stream data such as RTP packets is encapsulated by an ASCII dollar
sign (24 decimal), followed by a one-byte channel identifier, sign (24 decimal), followed by a one-byte channel identifier,
followed by the length of the encapsulated binary data as a binary, followed by the length of the encapsulated binary data as a binary,
two-byte integer in network byte order. The stream data follows two-byte integer in network byte order. The stream data follows
immediately afterwards, without a CRLF, but including the upper-layer immediately afterwards, without a CRLF, but including the upper-layer
protocol headers. Each $ block SHALL contain exactly one upper-layer protocol headers. Each $ block SHALL contain exactly one upper-layer
protocol data unit, e.g., one RTP packet. protocol data unit, e.g., one RTP packet.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"$" = 24 Channel ID Length in bytes | "$" = 24 | Channel ID | Length in bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Length number of bytes of binary data : : Length number of bytes of binary data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The channel identifier is defined in the Transport header with the The channel identifier is defined in the Transport header with the
interleaved parameter(Section 14.45). interleaved parameter(Section 14.45).
When the transport choice is RTP, RTCP messages are also interleaved When the transport choice is RTP, RTCP messages are also interleaved
by the server over the TCP connection. The usage of RTCP messages is by the server over the TCP connection. The usage of RTCP messages is
indicated by including a range containing a second channel in the indicated by including a range containing a second channel in the
skipping to change at page 65, line 8 skipping to change at page 63, line 37
higher than the RTP channel. The channels are bi-directional and higher than the RTP channel. The channels are bi-directional and
therefore RTCP traffic are sent on the second channel in both therefore RTCP traffic are sent on the second channel in both
directions. directions.
RTCP is needed for synchronization when two or more streams RTCP is needed for synchronization when two or more streams
are interleaved in such a fashion. Also, this provides a are interleaved in such a fashion. Also, this provides a
convenient way to tunnel RTP/RTCP packets through the TCP convenient way to tunnel RTP/RTCP packets through the TCP
control connection when required by the network control connection when required by the network
configuration and transfer them onto UDP when possible. configuration and transfer them onto UDP when possible.
C->S: SETUP rtsp://example.com/bar.file RTSP/1.0 C->S: SETUP rtsp://example.com/bar.file RTSP/1.1
CSeq: 2 CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1 Transport: RTP/AVP/TCP;unicast;interleaved=0-1
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
CSeq: 2 CSeq: 2
Date: 05 Jun 1997 18:57:18 GMT Date: 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;unicast;interleaved=5-6 Transport: RTP/AVP/TCP;unicast;interleaved=5-6
Session: 12345678 Session: 12345678
C->S: PLAY rtsp://example.com/bar.file RTSP/1.0 C->S: PLAY rtsp://example.com/bar.file RTSP/1.1
CSeq: 3 CSeq: 3
Session: 12345678 Session: 12345678
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
CSeq: 3 CSeq: 3
Session: 12345678 Session: 12345678
Date: 05 Jun 1997 18:59:15 GMT Date: 05 Jun 1997 18:59:15 GMT
RTP-Info: url=rtsp://example.com/bar.file; RTP-Info: url="rtsp://example.com/bar.file"
seq=232433;rtptime=972948234 ssrc=0D12F123:seq=232433;rtptime=972948234
S->C: $005{2 byte length}{"length" bytes data, w/RTP header} S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
S->C: $005{2 byte length}{"length" bytes data, w/RTP header} S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
S->C: $006{2 byte length}{"length" bytes RTCP packet} S->C: $006{2 byte length}{"length" bytes RTCP packet}
13 Status Code Definitions 13 Status Code Definitions
Where applicable, HTTP status [H10] codes are reused. Status codes Where applicable, HTTP status [H10] codes are reused. Status codes
that have the same meaning are not repeated here. See Table 4 for a that have the same meaning are not repeated here. See Table 4 for a
listing of which status codes may be returned by which requests. All listing of which status codes may be returned by which requests. All
skipping to change at page 66, line 43 skipping to change at page 65, line 32
13.3.1 300 Multiple Choices 13.3.1 300 Multiple Choices
See [H10.3.1] [TBW] See [H10.3.1] [TBW]
13.3.2 301 Moved Permanently 13.3.2 301 Moved Permanently
The request resource are moved permanently and resides now at the URI The request resource are moved permanently and resides now at the URI
given by the location header. The user client SHOULD redirect given by the location header. The user client SHOULD redirect
automatically to the given URI. This response MUST NOT contain a automatically to the given URI. This response MUST NOT contain a
message-body. message-body. The Location header MUST be included in the response.
13.3.3 302 Found 13.3.3 302 Found
The requested resource reside temporarily at the URI given by the The requested resource reside temporarily at the URI given by the
Location header. The Location header MUST be included in the Location header. The Location header MUST be included in the
response. Is intended to be used for many types of temporary response. Is intended to be used for many types of temporary
redirects, e.g. load balancing. It is RECOMMENDED that one set the redirects, e.g. load balancing. It is RECOMMENDED that one set the
reason phrase to something more meaningful than "Found" in these reason phrase to something more meaningful than "Found" in these
cases. The user client SHOULD redirect automatically to the given cases. The user client SHOULD redirect automatically to the given
URI. This response MUST NOT contain a message-body. URI. This response MUST NOT contain a message-body.
13.3.4 303 See Other 13.3.4 303 See Other
This status code SHALL NOT be used in RTSP. However as it was allowed This status code SHALL NOT be used in RTSP. However as it was allowed
to use in RFC 2326 it is possible that such response may be received, to use in RTSP 1.1 (RFC 2326).
in which case the behavior is undefined.
13.3.5 304 Not Modified 13.3.5 304 Not Modified
If the client has performed a conditional DESCRIBE or SETUP (see If the client has performed a conditional DESCRIBE or SETUP (see
14.26) and the requested resource has not been modified, the server 14.26) and the requested resource has not been modified, the server
SHOULD send a 304 response. This response MUST NOT contain a SHOULD send a 304 response. This response MUST NOT contain a
message-body. message-body.
The response MUST include the following header fields: The response MUST include the following header fields:
skipping to change at page 67, line 32 skipping to change at page 66, line 21
o ETag and/or Content-Location, if the header would have been o ETag and/or Content-Location, if the header would have been
sent in a 200 response to the same request. sent in a 200 response to the same request.
o Expires, Cache-Control, and/or Vary, if the field-value might o Expires, Cache-Control, and/or Vary, if the field-value might
differ from that sent in any previous response for the same differ from that sent in any previous response for the same
variant. variant.
This response is independent for the DESCRIBE and SETUP requests. This response is independent for the DESCRIBE and SETUP requests.
That is, a 304 response to DESCRIBE does NOT imply that the resource That is, a 304 response to DESCRIBE does NOT imply that the resource
content is unchanged and a 304 response to SETUP does NOT imply that content is unchanged (only the session description) and a 304
the resource description is unchanged. The ETag and If-Match headers response to SETUP does NOT imply that the resource description is
may be used to link the DESCRIBE and SETUP in this manner. unchanged. The ETag and If-Match headers may be used to link the
DESCRIBE and SETUP in this manner.
13.3.6 305 Use Proxy 13.3.6 305 Use Proxy
See [H10.3.6]. See [H10.3.6].
13.4 Client Error 4xx 13.4 Client Error 4xx
13.4.1 400 Bad Request 13.4.1 400 Bad Request
The request could not be understood by the server due to malformed The request could not be understood by the server due to malformed
skipping to change at page 68, line 20 skipping to change at page 67, line 10
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 [23] and is obsolete. This error code was removed from RFC 2326 [24] 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 68, line 22
13.4.13 461 Unsupported Transport 13.4.13 461 Unsupported Transport
The Transport field did not contain a supported transport The Transport field did not contain a supported transport
specification. specification.
13.4.14 462 Destination Unreachable 13.4.14 462 Destination Unreachable
The data transmission channel could not be established because the The data transmission channel could not be established because the
client address could not be reached. This error will most likely be client address could not be reached. This error will most likely be
the result of a client attempt to place an invalid Destination the result of a client attempt to place an invalid dest_addr
parameter in the Transport field. parameter in the Transport field.
13.4.15 470 Connection Authorization Required 13.4.15 463 Destination Prohibited
The data transmission channel was not established because the server
prohibited access to the client address. This error is most likely
the result of a client attempt to redirect media traffic to another
destination with a dest_addr parameter in the Transport header.
13.4.16 470 Connection Authorization Required
The secured connection attempt need user or client authorization The secured connection attempt need user or client authorization
before proceeding. The next hops certificate is included in this before proceeding. The next hops certificate is included in this
response in the Accept-Credentials header. response in the Accept-Credentials header.
13.4.16 471 Connection Credentials not accepted 13.4.17 471 Connection Credentials not accepted
When performing a secure connection over multiple connections, a When performing a secure connection over multiple connections, a
intermediary has refused to connect to the next hop and carry out the intermediary has refused to connect to the next hop and carry out the
request due to unacceptable credentials for the used policy. request due to unacceptable credentials for the used policy.
13.5 Server Error 5xx 13.5 Server Error 5xx
13.5.1 551 Option not supported 13.5.1 551 Option not supported
A feature-tag given in the Require or the Proxy-Require fields was A feature-tag given in the Require or the Proxy-Require fields was
skipping to change at page 70, line 15 skipping to change at page 69, line 14
14 Header Field Definitions 14 Header Field Definitions
method direction object acronym Body method direction object acronym Body
_________________________________________________ _________________________________________________
DESCRIBE C -> S P,S DES r DESCRIBE C -> S P,S DES r
GET_PARAMETER C -> S, S -> C P,S GPR R,r GET_PARAMETER C -> S, S -> C P,S GPR R,r
OPTIONS C -> S P,S OPT OPTIONS C -> S P,S OPT
S -> C S -> C
PAUSE C -> S P,S PSE PAUSE C -> S P,S PSE
PING C -> S, S -> C P,S PNG
PLAY C -> S P,S PLY PLAY C -> S P,S PLY
REDIRECT S -> C P,S RDR REDIRECT S -> C P,S RDR
SETUP C -> S S STP SETUP C -> S S STP
SET_PARAMETER C -> S, S -> C P,S SPR R,r SET_PARAMETER C -> S, S -> C P,S SPR R,r
TEARDOWN C -> S P,S TRD TEARDOWN C -> S P,S TRD
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 header fields are
section 18.2.3. Throughout this section, we use [HX.Y] to refer to present in section 19.2.3. Throughout this section, we use [HX.Y] to
Section X.Y of the current HTTP/1.1 specification RFC 2616 [3]. refer to Section X.Y of the current HTTP/1.1 specification RFC 2616
Examples of each header field are given. [3]. 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;
r: header field may only appear in responses; r: header field may only appear in responses;
skipping to change at page 72, line 13 skipping to change at page 71, line 10
the header field MUST NOT be present in a request. If one is placed the header field MUST NOT be present in a request. If one is placed
in a request by mistake, it MUST be ignored by the Client/Server in a request by mistake, it MUST be ignored by the Client/Server
receiving the request. Similarly, a header field labeled "not receiving the request. Similarly, a header field labeled "not
applicable" for a response means that the Client/Server MUST NOT applicable" for a response means that the Client/Server MUST NOT
place the header field in the response, and the Client/Server MUST place the header field in the response, and the Client/Server MUST
ignore the header field in the response. ignore the header field in the response.
A Client/Server SHOULD ignore extension header parameters that are A Client/Server SHOULD ignore extension header parameters that are
not understood. not understood.
The From, Location, and RTP-Info header fields contain an URI. If the The From and Location header fields contain an URI. If the URI
URI contains a comma, or semicolon, the URI MUST be enclosed in contains a comma, or semicolon, the URI MUST be enclosed in double
double quotas ("). Any URI parameters are contained within these quotas ("). Any URI parameters are contained within these quotas. If
quotas. If the URI is not enclosed in double quotas, any semicolon- the URI is not enclosed in double quotas, any semicolon- delimited
delimited parameters are header-parameters, not URI parameters. parameters are header-parameters, not URI parameters.
14.1 Accept 14.1 Accept
The Accept request-header field can be used to specify certain The Accept request-header field can be used to specify certain
presentation description content types which are acceptable for the presentation description content types which are acceptable for the
response. response.
The "level" parameter for presentation descriptions is The "level" parameter for presentation descriptions is
properly defined as part of the MIME type registration, not properly defined as part of the MIME type registration, not
here. here.
skipping to change at page 72, line 39 skipping to change at page 71, line 36
See [H14.1] for syntax. See [H14.1] for syntax.
Example of use: Example of use:
Accept: application/rtsl q=1.0, application/sdp Accept: application/rtsl q=1.0, application/sdp
14.2 Accept-Credentials 14.2 Accept-Credentials
The Accept-Credentials header is a request header used to indicate to The Accept-Credentials header is a request header used to indicate to
any trusted intermediary how to handle further secured connections to any trusted intermediary how to handle further secured connections to
proxies or servers. See section 17 for the usage of this header. It proxies or servers. See section 18 for the usage of this header. It
SHALL only be included in client to server requests. SHALL only be included in client to server requests.
In a request the header SHALL contain the method (User, Proxy, or In a request the header SHALL contain the method (User, Proxy, or
Any) for approving credentials selected by the requestor. The method Any) for approving credentials selected by the requestor. The method
SHALL NOT be changed by any proxy. If the method is "User" the header SHALL NOT be changed by any proxy. If the method is "User" the header
contains zero or more of credentials that the client accept. Each
credential SHALL consist of one URI identifying the proxy or server,
and the SHA-1 [14] hash computed over that entity's DER encoded
Header Where Proxy DES OPT SETUP PLAY PAUSE TRD Header Where Proxy DES OPT SETUP PLAY PAUSE TRD
_________________________________________________________________ _________________________________________________________________
Accept R o - - - - - Accept R o - - - - -
Accept-Credentials R r o o o o o o Accept-Credentials R r o o o o o o
Accept-Encoding R r o - - - - - Accept-Encoding R r o - - - - -
Accept-Language R r o - - - - - Accept-Language R r o - - - - -
Accept-Ranges r r - - o - - - Accept-Ranges r r - - o - - -
Accept-Ranges 456 r - - - o o - Accept-Ranges 456 r - - - o o -
Allow r - o - - - - Allow r am - c - - - -
Allow 405 m m m m m m Allow 405 am m m m m m m
Authorization R o o o o o o Authorization R o o o o o o
Bandwidth R o o o o - - Bandwidth R o o o o - -
Blocksize R o - o o - - Blocksize R o - o o - -
Cache-Control r - - o - - - Cache-Control r - - o - - -
Connection o o o o o o Connection o o o o o o
Connection-Credentials 470,407 ar o o o o o o Connection-Credentials 470,407 ar o o o o o o
Content-Base r o - - - - - Content-Base r o - - - - -
Content-Base 4xx o o o o o o Content-Base 4xx o o o o o o
Content-Encoding R r - - - - - - Content-Encoding R r - - - - - -
Content-Encoding r r o - - - - - Content-Encoding r r o - - - - -
Content-Encoding 4xx r o o o o o o Content-Encoding 4xx r o o o o o o
Content-Language R r - - - - - - Content-Language R r - - - - - -
Content-Language r r o - - - - - Content-Language r r o - - - - -
Content-Language 4xx r o o o o o o Content-Language 4xx r o o o o o o
Content-Length r r * - - - - - Content-Length r r * - - - - -
Content-Length 4xx r * * * * * * Content-Length 4xx r * * * * * *
Content-Location r o - - - - - Content-Location r o - - - - -
Content-Location 4xx o o o o o o Content-Location 4xx o o o o o o
Content-Type r * - - - - - Content-Type r * - - - - -
Content-Type 4xx * * * * * * Content-Type 4xx * * * * * *
CSeq Rc m m m m m m CSeq Rc rm m m m m m m
Date am o o o o o o Date am o o o o o o
ETag r r o - o - - - ETag r r o - o - - -
Expires r r o - - - - - Expires r r o - - - - -
From R r o o o o o o From R r o o o o o o
Host - - - - - - Host - - - - - -
If-Match R r - - o - - - If-Match R r - - o - - -
If-Modified-Since R r o - o - - - If-Modified-Since R r o - o - - -
If-None-Match R r o - - - - - If-None-Match R r o - - - - -
Last-Modified r r o - - - - - Last-Modified r r o - - - - -
Location 3rr o o o o o o Location 3rr o o o o o o
Table 9: Overview of RTSP header fields (A-L) related to methods Table 9: Overview of RTSP header fields (A-L) related to methods
DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.
Header Where Proxy DES OPT SETUP PLAY PAUSE TRD Header Where Proxy DES OPT SETUP PLAY PAUSE TRD
_____________________________________________________________ _____________________________________________________________
Proxy-Authenticate 407 amr m m m m m m Proxy-Authenticate 407 amr m m m m m m
Proxy-Require R ar o o o o o o Proxy-Require R ar o o o o o o
Proxy-Require r r c c c c c c
Proxy-Supported R amr oc oc oc oc oc oc Proxy-Supported R amr oc oc oc oc oc oc
Proxy-Supported r c c c c c c Proxy-Supported r c c c c c c
Public r admr - m* - - - - Public r admr - m* - - - -
Public 501 admr m* m* m* m* m* m* Public 501 admr m* m* m* m* m* m*
Range R - - - o o - Range R - - - o o -
Range r - - c m* m* - Range r - - c m* m* -
Referer R o o o o o o Referer R o o o o o o
Require R o o o o o o Require R o o o o o o
Retry-After 3rr,503 o o o - - - Retry-After 3rr,503 o o o - - -
RTP-Info r - - o c - - RTP-Info r - - o c - -
Scale - - - o - - Scale - - - o - -
Session R - o o m m m Session R r - o o m m m
Session r - c m m m o Session r r - c m m m o
Server R - o - - - - Server R r - o - - - -
Server r o o o o o o Server r r o o o o o o
Speed - - - o - - Speed - - - o - -
Supported R o o o o o o Supported R amr o o o o o o
Supported r c c c c c c Supported r amr c c c c c c
Timestamp R o o o o o o Timestamp R admr o o o o o o
Timestamp c m m m m m m Timestamp c admr m m m m m m
Transport - - m - - - Transport amr - - m - - -
Unsupported r c c c c c c Unsupported r c c c c c c
User-Agent R m* m* m* m* m* m* User-Agent R m* m* m* m* m* m*
Vary r c c c c c c Vary r c c c c c c
Via R amr o o o o o o Via R amr o o o o o o
Via c dr m m m m m m Via c dr m m m m m m
WWW-Authenticate 401 m m m m m m WWW-Authenticate 401 m m m m m m
_____________________________________________________________ _____________________________________________________________
Header Where Proxy DES OPT SETUP PLAY PAUSE TRD Header Where Proxy DES OPT SETUP PLAY PAUSE TRD
Table 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 certificate [15] in Base64 [35].
credential SHALL consist of one URI identifying the proxy or server,
and the SHA-1 [14] hash computed over that entity's DER encoded
certificate [15] in Base64 [37].
Example: Example:
Accept-Credentials:User,
"rtsps://proxy2.example.com/";exaIl9VMbQMOFGClx5rXnPJKVNI=,
Header Where Proxy GPR SPR RDR
__________________________________________________
Accept-Credentials R r o o o
Allow 405 amr m m m
Authorization R o o o
Bandwidth R - o -
Blocksize R - o -
Connection o o o
Connection-Credentials 470,407 ar o o o
Content-Base R o o -
Content-Base r o o -
Content-Base 4xx o o o
Content-Encoding R r o o -
Content-Encoding r r o o -
Content-Encoding 4xx r o o o
Content-Language R r o o -
Content-Language r r o o -
Content-Language 4xx r o o o
Content-Length R r * * -
Content-Length r r * * -
Content-Length 4xx r * * *
Content-Location R o o -
Content-Location r o o -
Content-Location 4xx o o o
Content-Type R * * -
Content-Type r * * -
Content-Type 4xx * * *
CSeq Rc mr m m m
Date am o o o
From R r o o o
Host - - -
Last-Modified R r - - -
Last-Modified r r o - -
Location 3rr o o o
Location R - - m
Proxy-Authenticate 407 amr m m m
Proxy-Require R ar o o o
Proxy-Require r r c c c
Proxy-Supported R amr oc oc oc
Proxy-Supported r c c c
Public 501 admr m* m* m*
Header Where Proxy GPR SPR RDR PNG __________________________________________________
______________________________________________________ Header Where Proxy GPR SPR RDR
Accept-Credentials R r o o o o
Allow 405 m m m m
Authorization R o o o o
Bandwidth R - o - -
Blocksize R - o - -
Connection o o o -
Connection-Credentials 470,407 ar o o o o
Content-Base R o o - -
Content-Base r o o - -
Content-Base 4xx o o o -
Content-Encoding R r o o - -
Content-Encoding r r o o - -
Content-Encoding 4xx r o o o -
Content-Language R r o o - -
Content-Language r r o o - -
Content-Language 4xx r o o o -
Content-Length R r * * - -
Content-Length r r * * - -
Content-Length 4xx r * * * -
Content-Location R o o - -
Content-Location r o o - -
Content-Location 4xx o o o -
Content-Type R * * - -
Content-Type r * * - -
Content-Type 4xx * * * -
CSeq Rc m m m m
Date am o o o o
From R r o o o o
Host - - - -
Last-Modified R r - - - -
Last-Modified r r o - - -
Location 3rr o o o o
Location R - - m -
Proxy-Authenticate 407 amr m m m m
Proxy-Require R ar o o o o
Proxy-Supported R amr oc oc oc oc
Proxy-Supported r c c c c
Public 501 admr m* m* m* m*
______________________________________________________
Header Where Proxy GPR SPR RDR PNG
Table 11: Overview of RTSP header fields (A-P) related to methods Table 11: Overview of RTSP header fields (A-P) related to methods
GET_PARAMETER, SET_PARAMETER, REDIRECT, and PING. GET_PARAMETER, SET_PARAMETER, and REDIRECT.
Header Where Proxy GPR SPR RDR PNG Header Where Proxy GPR SPR RDR
________________________________________________ ____________________________________________
Range R - - o - Range R - - o
Referer R o o o - Referer R o o o
Require R o o o o Require R r o o o
Retry-After 3rr,503 o o - - Retry-After 3rr,503 o o -
Scale - - - - Scale - - -
Session R o o o m Session R r o o o
Session r c c o m Session r r c c o
Server R o o o o Server R r o o o
Server r o o - o Server r r o o -
Supported R o o o o Supported R adrm o o o
Supported r c c c c Supported r adrm c c c
Timestamp R o o o o Timestamp R adrm o o o
Timestamp c m m m m Timestamp c adrm m m m
Unsupported r c c c c Unsupported r arm c c c
User-Agent R m* m* - m* User-Agent R r m* m* -
User-Agent r - - m* - User-Agent r r - - m*
Vary r c c - - Vary r c c -
Via R amr o o o o Via R amr o o o
Via c dr m m m m Via c dr m m m
WWW-Authenticate 401 m m m m WWW-Authenticate 401 m m m
________________________________________________ ____________________________________________
Header Where Proxy GPR SPR RDR PNG Header Where Proxy GPR SPR RDR
Table 12: Overview of RTSP header fields (R-W) related to methods Table 12: Overview of RTSP header fields (R-W) related to methods
GET_PARAMETER, SET_PARAMETER, REDIRECT, and PING. GET_PARAMETER, SET_PARAMETER, and REDIRECT.
"rtsps://server.example.com/";lurbjj5khhB0NhIuOXtt4bBRH1M=
14.3 Accept-Encoding 14.3 Accept-Encoding
See [H14.3] See [H14.3]
14.4 Accept-Language 14.4 Accept-Language
See [H14.4]. Note that the language specified applies to the See [H14.4]. Note that the language specified applies to the
presentation description and any reason phrases, not the media presentation description and any reason phrases, not the media
content. content.
skipping to change at page 77, line 6 skipping to change at page 76, line 4
See [H14.4]. Note that the language specified applies to the See [H14.4]. Note that the language specified applies to the
presentation description and any reason phrases, not the media presentation description and any reason phrases, not the media
content. content.
14.5 Accept-Ranges 14.5 Accept-Ranges
The Accept-Ranges response-header field allows the server to indicate The Accept-Ranges response-header field allows the server to indicate
its acceptance of range requests and possible formats for a resource: its acceptance of range requests and possible formats for a resource:
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
This header has the same syntax as [H14.5] and the syntax is defined This header has the same syntax as [H14.5] and the syntax is defined
in 18.2.3. However, new range-units are defined. Inclusion of any of in 19.2.3. However, new range-units are defined. Inclusion of any of
the time formats indicates acceptance by the server for PLAY and the time formats indicates acceptance by the server for PLAY and
PAUSE requests with this format. The headers value is valid for the PAUSE requests with this format. The headers value is valid for the
resource specified by the URI in the request, this response resource specified by the URI in the request, this response
corresponds to. A server SHOULD use this header in SETUP responses to corresponds to. A server SHOULD use this header in SETUP responses to
indicate to the client which range time formats the media supports. indicate to the client which range time formats the media supports.
The header SHOULD also be included in "456" responses which is a The header SHOULD also be included in "456" responses which is a
result of use of unsupported range formats. result of use of unsupported range formats.
14.6 Allow 14.6 Allow
The Allow entity-header field lists the methods supported by the The Allow entity-header field lists the methods supported by the
resource identified by the Request-URI. The purpose of this field is resource identified by the Request-URI. The purpose of this field is
to strictly inform the recipient of valid methods associated with the to strictly inform the recipient of valid methods associated with the
resource. An Allow header field MUST be present in a 405 (Method Not resource. An Allow header field MUST be present in a 405 (Method Not
Allowed) response. See [H14.7] for syntax definition. Allowed) response. See [H14.7] for syntax definition. The Allow
header MUST also be present in all OPTIONS responses where the
content of the header will not include exactly the same methods as
listed in the Public header.
Example of use: Example of use:
Allow: SETUP, PLAY, SET_PARAMETER Allow: SETUP, PLAY, SET_PARAMETER
14.7 Authorization 14.7 Authorization
See [H14.8] See [H14.8]
14.8 Bandwidth 14.8 Bandwidth
skipping to change at page 78, line 29 skipping to change at page 77, line 29
Cache directives MUST be passed through by a proxy or gateway Cache directives MUST be passed through by a proxy or gateway
application, regardless of their significance to that application, application, regardless of their significance to that application,
since the directives may be applicable to all recipients along the since the directives may be applicable to all recipients along the
request/response chain. It is not possible to specify a cache- request/response chain. It is not possible to specify a cache-
directive for a specific cache. directive for a specific cache.
Cache-Control should only be specified in a SETUP request and its Cache-Control should only be specified in a SETUP request and its
response. Note: Cache-Control does not govern the caching of response. Note: Cache-Control does not govern the caching of
responses as for HTTP, instead it applies to the media stream responses as for HTTP, instead it applies to the media stream
identified by the SETUP request. The caching of RTSP requests are identified by the SETUP request. The caching of RTSP requests are
generally not cacheable, for further information see 15. Below is the generally not cacheable, for further information see section 16.
description of the cache directives that can be included in the Below is the description of the cache directives that can be included
Cache-Control header. in the Cache-Control header.
no-cache: Indicates that the media stream MUST NOT be cached no-cache: Indicates that the media stream MUST NOT be cached
anywhere. This allows an origin server to prevent caching anywhere. This allows an origin server to prevent caching
even by caches that have been configured to return stale even by caches that have been configured to return stale
responses to client requests. responses to client requests.
public: Indicates that the media stream is cacheable by any public: Indicates that the media stream is cacheable by any
cache. cache.
private: Indicates that the media stream is intended for a private: Indicates that the media stream is intended for a
skipping to change at page 81, line 7 skipping to change at page 80, line 6
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 [15] certificate in base64 [37]. X.509v3 [15] certificate in base64 [35].
Example: Example:
Accept-Credentials:"rtsps://proxy2.example.com/";MIIDNTCCAp6gA...
Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC...
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
If no Content-Base field is present, the base URI of an entity is If no Content-Base field is present, the base URI of an entity is
defined either by its Content-Location (if that Content-Location URI defined either by its Content-Location (if that Content-Location URI
skipping to change at page 81, line 36 skipping to change at page 80, line 36
See [H14.11] See [H14.11]
14.15 Content-Language 14.15 Content-Language
See [H14.12] See [H14.12]
14.16 Content-Length 14.16 Content-Length
The Content-Length general-header field contains the length of the The Content-Length general-header field contains the length of the
content of the method (i.e. after the double CRLF following the last body (entity) of the message (i.e. after the double CRLF following
header). Unlike HTTP, it MUST be included in all messages that carry the last header). Unlike HTTP, it MUST be included in all messages
content beyond the header portion of the message. If it is missing, a that carry body beyond the header portion of the message. If it is
default value of zero is assumed. It is interpreted according to missing, a default value of zero is assumed. It is interpreted
[H14.13]. according to [H14.13].
14.17 Content-Location 14.17 Content-Location
See [H14.14] See [H14.14]
14.18 Content-Type 14.18 Content-Type
See [H14.17]. Note that the content types suitable for RTSP are See [H14.17]. Note that the content types suitable for RTSP are
likely to be restricted in practice to presentation descriptions and likely to be restricted in practice to presentation descriptions and
parameter-value types. parameter-value types.
skipping to change at page 83, line 12 skipping to change at page 82, line 12
using the headers If-Match (Section 14.25) and If-None-Match (Section using the headers If-Match (Section 14.25) and If-None-Match (Section
14.27). 14.27).
14.22 Expires 14.22 Expires
The Expires entity-header field gives a date and time after which the The Expires entity-header field gives a date and time after which the
description or media-stream should be considered stale. The description or media-stream should be considered stale. The
interpretation depends on the method: interpretation depends on the method:
DESCRIBE response: The Expires header indicates a date and time DESCRIBE response: The Expires header indicates a date and time
after which the description SHOULD be considered stale. after which the presentation description (body) SHOULD be
considered stale.
SETUP response: The Expires header indicate a date and time SETUP response: The Expires header indicate a date and time
after which the media stream SHOULD be considered stale. after which the media stream SHOULD be considered stale.
A stale cache entry may not normally be returned by a cache (either a A stale cache entry may not normally be returned by a cache (either a
proxy cache or an user agent cache) unless it is first validated with proxy cache or an user agent cache) unless it is first validated with
the origin server (or with an intermediate cache that has a fresh the origin server (or with an intermediate cache that has a fresh
copy of the entity). See section 15 for further discussion of the copy of the entity). See section 16 for further discussion of the
expiration model. expiration model.
The presence of an Expires field does not imply that the original The presence of an Expires field does not imply that the original
resource will change or cease to exist at, before, or after that resource will change or cease to exist at, before, or after that
time. time.
The format is an absolute date and time as defined by HTTP-date in The format is an absolute date and time as defined by HTTP-date in
[H3.3]; it MUST be in RFC1123-date format: [H3.3]; it MUST be in RFC1123-date format:
An example of its use is An example of its use is
Expires: Thu, 01 Dec 1994 16:00:00 GMT Expires: Thu, 01 Dec 1994 16:00:00 GMT
RTSP/1.0 clients and caches MUST treat other invalid date formats, RTSP/1.1 clients and caches MUST treat other invalid date formats,
especially including the value "0", as having occurred in the past especially including the value "0", as having occurred in the past
(i.e., already expired). (i.e., already expired).
To mark a response as "already expired," an origin server should use To mark a response as "already expired," an origin server should use
an Expires date that is equal to the Date header value. To mark a an Expires date that is equal to the Date header value. To mark a
response as "never expires," an origin server SHOULD use an Expires response as "never expires," an origin server SHOULD use an Expires
date approximately one year from the time the response is sent. date approximately one year from the time the response is sent.
RTSP/1.0 servers SHOULD NOT send Expires dates more than one year in RTSP/1.1 servers SHOULD NOT send Expires dates more than one year in
the future. the future.
The presence of an Expires header field with a date value of some The presence of an Expires header field with a date value of some
time in the future on a media stream that otherwise would by default time in the future on a media stream that otherwise would by default
be non-cacheable indicates that the media stream is cacheable, unless be non-cacheable indicates that the media stream is cacheable, unless
indicated otherwise by a Cache-Control header field (Section 14.10). indicated otherwise by a Cache-Control header field (Section 14.10).
14.23 From 14.23 From
See [H14.22]. See [H14.22].
14.24 Host 14.24 Host
The Host HTTP request header field [H14.23] is not needed for RTSP, The Host HTTP request header field [H14.23] is not needed for RTSP,
and SHALL NOT be sent. It SHALL be silently ignored if received. and SHALL NOT be sent. It SHALL be silently ignored if received.
14.25 If-Match 14.25 If-Match
See [H14.24]. See [H14.24].
skipping to change at page 86, line 16 skipping to change at page 85, line 18
applicable to proxies, as described in Section 3.7. The list are the applicable to proxies, as described in Section 3.7. The list are the
intersection of all feature-tags understood by the proxies. To intersection of all feature-tags understood by the proxies. To
achieve an intersection, the proxy adding the Proxy-Supported header achieve an intersection, the proxy adding the Proxy-Supported header
includes all proxy feature-tags it understands. Any proxy receiving a includes all proxy feature-tags it understands. Any proxy receiving a
request with the header, checks the list and removes any feature tag request with the header, checks the list and removes any feature tag
it do not support. A Proxy-Supported header present in the response it do not support. A Proxy-Supported header present in the response
SHALL NOT be touched by the proxies. SHALL NOT be touched by the proxies.
Example: Example:
C->P1: OPTIONS rtsp://example.com/ RTSP/1.0 C->P1: OPTIONS rtsp://example.com/ RTSP/1.1
Supported: foo, bar, blech Supported: foo, bar, blech
P1->P2: OPTIONS rtsp://example.com/ RTSP/1.0 P1->P2: OPTIONS rtsp://example.com/ RTSP/1.1
Supported: foo, bar, blech Supported: foo, bar, blech
Proxy-Supported: proxy-foo, proxy-bar, proxy-blech Proxy-Supported: proxy-foo, proxy-bar, proxy-blech
Via: 1.0 prox1.example.com Via: 1.1 prox1.example.com
P2->S: OPTIONS rtsp://example.com/ RTSP/1.0 P2->S: OPTIONS rtsp://example.com/ RTSP/1.1
Supported: foo, bar, blech Supported: foo, bar, blech
Proxy-Supported: proxy-foo, proxy-blech Proxy-Supported: proxy-foo, proxy-blech
Via: 1.0 prox1.example.com, 1.0 prox2.example.com Via: 1.1 prox1.example.com, 1.1 prox2.example.com
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
Supported: foo, bar, baz Supported: foo, bar, baz
Proxy-Supported: proxy-foo, proxy-blech Proxy-Supported: proxy-foo, proxy-blech
Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
Via: 1.0 prox1.example.com, 1.0 prox2.example.com Via: 1.1 prox1.example.com, 1.1 prox2.example.com
14.33 Public 14.33 Public
The Public response header field lists the set of methods supported The Public response header field lists the set of methods supported
by the response sender. This header applies to the general by the response sender. This header applies to the general
capabilities of the sender and its only purpose is to indicate the capabilities of the sender and its only purpose is to indicate the
sender's capabilities to the recipient. The methods listed may or may sender's capabilities to the recipient. The methods listed may or may
not be applicable to the Request-URI; the Allow header field (section not be applicable to the Request-URI; the Allow header field (section
14.7) MAY be used to indicate methods allowed for a particular URI. 14.7) MAY be used to indicate methods allowed for a particular URI.
skipping to change at page 88, line 11 skipping to change at page 87, line 11
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 [3] 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.
in the future, although a server may refuse to keep server
resources for extended idle periods.
By default, range intervals increase, where the second point is By default, range intervals increase, where the second point is
larger than the first point. larger than the first point.
Example: Example:
Range: npt=10-15 Range: npt=10-15
However, range intervals can also decrease if the Scale header (see However, range intervals can also decrease if the Scale header (see
section 14.39) indicates a negative scale value. For example, this section 14.39) indicates a negative scale value. For example, this
skipping to change at page 89, line 42 skipping to change at page 88, line 39
by both sides, and only slow down if features are not by both sides, and only slow down if features are not
understood (as in the example below). For a well-matched understood (as in the example below). For a well-matched
client-server pair, the interaction proceeds quickly, client-server pair, the interaction proceeds quickly,
saving a round-trip often required by negotiation saving a round-trip often required by negotiation
mechanisms. In addition, it also removes state ambiguity mechanisms. In addition, it also removes state ambiguity
when the client requires features that the server does not when the client requires features that the server does not
understand. understand.
Example: Example:
C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.1
CSeq: 302 CSeq: 302
Require: funky-feature Require: funky-feature
Funky-Parameter: funkystuff Funky-Parameter: funkystuff
S->C: RTSP/1.0 551 Option not supported S->C: RTSP/1.1 551 Option not supported
CSeq: 302 CSeq: 302
Unsupported: funky-feature Unsupported: funky-feature
In this example, "funky-feature" is the feature-tag which indicates In this example, "funky-feature" is the feature-tag which indicates
to the client that the fictional Funky-Parameter field is required. to the client that the fictional Funky-Parameter field is required.
The relationship between "funky-feature" and Funky-Parameter is not The relationship between "funky-feature" and Funky-Parameter is not
communicated via the RTSP exchange, since that relationship is an communicated via the RTSP exchange, since that relationship is an
immutable property of "funky-feature" and thus should not be immutable property of "funky-feature" and thus should not be
transmitted with every exchange. transmitted with every exchange.
Proxies and other intermediary devices SHALL ignore this header. If a Proxies and other intermediary devices SHALL ignore this header. If a
particular extension requires that intermediate devices support it, particular extension requires that intermediate devices support it,
the extension should be tagged in the Proxy-Require field instead the extension should be tagged in the Proxy-Require field instead
skipping to change at page 90, line 19 skipping to change at page 89, line 18
transmitted with every exchange. transmitted with every exchange.
Proxies and other intermediary devices SHALL ignore this header. If a Proxies and other intermediary devices SHALL ignore this header. If a
particular extension requires that intermediate devices support it, particular extension requires that intermediate devices support it,
the extension should be tagged in the Proxy-Require field instead the extension should be tagged in the Proxy-Require field instead
(see Section 14.31). (see Section 14.31).
14.38 RTP-Info 14.38 RTP-Info
The RTP-Info response-header field is used to set RTP-specific The RTP-Info response-header field is used to set RTP-specific
parameters in the PLAY response. These parameters correspond to the parameters in the PLAY response. For streams using RTP as transport
synchronization source identified by the first value of the ssrc protocol the RTP-Info header SHOULD be part of a 200 response to
parameter of the Transport response header in the SETUP response. For PLAY.
streams using RTP as transport protocol the RTP-Info header SHOULD be
part of a 200 response to PLAY.
The exclusion of the RTP-Info in a PLAY response for RTP The exclusion of the RTP-Info in a PLAY response for RTP
transported media will result in that a client needs to transported media will result in that a client needs to
synchronize the media streams using RTCP. This may have synchronize the media streams using RTCP. This may have
negative impact as the RTCP can be lost, and does not need negative impact as the RTCP can be lost, and does not need
to be particulary timely in their arrival. Also to be particulary timely in their arrival. Also
functionality as informing the client from which packet a functionality as informing the client from which packet a
seek has occurred is affected. seek has occurred is affected.
The RTP-Info MAY also be included in SETUP responses to provide The RTP-Info MAY also be included in SETUP responses to provide
skipping to change at page 90, line 45 skipping to change at page 89, line 42
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. This parameter SHALL SHALL use the Request-URI as base URI. This parameter SHALL
be present. be present.
ssrc: The Synchronization source (SSRC) that the RTP timestamp
and sequence number provide applies to. 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. This parameter is RECOMMENDED to be present. or reordering. This parameter is RECOMMENDED to be present.
skipping to change at page 91, line 36 skipping to change at page 90, line 36
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 NTP, using presentations, RTSP clients should additionally map NPT to NTP, using
initial RTCP sender reports to do the mapping, and later reports to initial RTCP sender reports to do the mapping, and later reports to
check drift against the mapping. check drift against the mapping.
Example: Example:
Range:npt=3.25-15 Range:npt=3.25-15
RTP-Info:url=rtsp://example.com/foo/audio;seq=45102;rtptime=12345678, RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102;
url=rtsp://example.com/foo/video;seq=30211;rtptime=29567112 rtptime=12345678,url="rtsp://example.com/foo/video"
ssrc=9A9DE123:seq=30211;rtptime=29567112
Lets assume that audio uses a 16kHz RTP timestamp clock and Video Lets assume that audio uses a 16kHz RTP timestamp clock and Video
a 90kHz RTP timestamp clock. Then the media synchronization is a 90kHz RTP timestamp clock. Then the media synchronization is
depicted in the following way. depicted in the following way.
NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6 NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6
Audio PA A Audio PA A
Video V PV Video V PV
X: NPT time value = 3.25, from Range header. X: NPT time value = 3.25, from Range header.
skipping to change at page 91, line 50 skipping to change at page 91, line 4
a 90kHz RTP timestamp clock. Then the media synchronization is a 90kHz RTP timestamp clock. Then the media synchronization is
depicted in the following way. depicted in the following way.
NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6 NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6
Audio PA A Audio PA A
Video V PV Video V PV
X: NPT time value = 3.25, from Range header. X: NPT time value = 3.25, from Range header.
A: RTP timestamp value for Audio from RTP-Info header (12345678). A: RTP timestamp value for Audio from RTP-Info header (12345678).
V: RTP timestamp value for Video from RTP-Info header (29567112). V: RTP timestamp value for Video from RTP-Info header (29567112).
PA: RTP audio packet carrying an RTP timestamp of 12344878. Which PA: RTP audio packet carrying an RTP timestamp of 12344878. Which
corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2 corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2
PV: RTP video packet carrying an RTP timestamp of 29573412. Which PV: RTP video packet carrying an RTP timestamp of 29573412. Which
corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32 corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32
Additionally, the RTP-Info header parameter fields only apply to a
single SSRC within a stream (the first SSRC reported in the transport
response header; see section 14.45). If there are multiple
synchronization sources (SSRCs) present within a RTP session
transmitting media, RTCP needs to be used to map RTP and NTP
timestamps for those sources, for both synchronization and drift-
checking. Due to backwards compatibility reasons these shortcomings
can't be fixed without defining a new header, which is for future
work if needed.
Additional constraint: The syntax element "safe-url" (see section
18.2.3) MUST NOT contain the semicolon (";") or comma (",")
characters. The quoted-url form SHOULD only be used when an URI does
not meet the safe-url constraint, in order to ensure compatibility
with implementations conformant to RFC 2326 [23].
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
delivered. A negative value indicates reverse direction. For certain delivered. A negative value indicates reverse direction. For certain
skipping to change at page 93, line 44 skipping to change at page 92, line 30
Speed: 2.5 Speed: 2.5
Use of this field changes the bandwidth used for data delivery. It is Use of this field changes the bandwidth used for data delivery. It is
meant for use in specific circumstances where preview of the meant for use in specific circumstances where preview of the
presentation at a higher or lower rate is necessary. Implementors presentation at a higher or lower rate is necessary. Implementors
should keep in mind that bandwidth for the session may be negotiated should keep in mind that bandwidth for the session may be negotiated
beforehand (by means other than RTSP), and therefore re-negotiation beforehand (by means other than RTSP), and therefore re-negotiation
may be necessary. When data is delivered over UDP, it is highly may be necessary. When data is delivered over UDP, it is highly
recommended that means such as RTCP be used to track packet loss recommended that means such as RTCP be used to track packet loss
rates. If the data transport is performed over public best-effort rates. If the data transport is performed over public best-effort
networks the sender SHOULD perform congestion control of the networks the sender MUST perform congestion control of the stream(s).
stream(s). This can result in that the communicated speed is This can result in that the communicated speed is impossible to
impossible to maintain. maintain.
14.41 Server 14.41 Server
See [H14.38], however the header syntax is corrected in section See [H14.38], however the header syntax is corrected in section
18.2.3. 19.2.3.
14.42 Session 14.42 Session
The Session request-header and response-header field identifies an The Session request-header and response-header field identifies an
RTSP session. An RTSP session is created by the server as a result of RTSP session. An RTSP session is created by the server as a result of
a successful SETUP request and in the response the session identifier a successful SETUP request and in the response the session identifier
is given to the client. The RTSP session exist until destroyed by a is given to the client. The RTSP session exist until destroyed by a
TEARDOWN or timed out by the server. TEARDOWN or timed out by the server.
The session identifier is chosen by the server (see Section 3.3) and The session identifier is chosen by the server (see Section 3.3) and
MUST be returned in the SETUP response. Once a client receives a MUST be returned in the SETUP response. Once a client receives a
session identifier, it SHALL be included in any request related to session identifier, it SHALL be included in any request related to
that session. This means that the Session header MUST be included in that session. This means that the Session header MUST be included in
a request using the following methods: PLAY, PAUSE, PING, and a request using the following methods: PLAY, PAUSE, and TEARDOWN, and
TEARDOWN, and MAY be included in SETUP, OPTIONS, SET_PARAMETER, MAY be included in SETUP, OPTIONS, SET_PARAMETER, GET_PARAMETER, and
GET_PARAMETER, and REDIRECT, and SHALL NOT be included in DESCRIBE. REDIRECT, and SHALL NOT be included in DESCRIBE. In an RTSP response
In an RTSP response the session header SHALL be included in methods, the session header SHALL be included in methods, SETUP, PLAY, and
SETUP, PING, PLAY, and PAUSE, and MAY be included in methods, PAUSE, and MAY be included in methods, TEARDOWN, and REDIRECT, and if
TEARDOWN, and REDIRECT, and if included in the request of the included in the request of the following methods it SHALL also be
following methods it SHALL also be included in the response, OPTIONS, included in the response, OPTIONS, GET_PARAMETER, and SET_PARAMETER,
GET_PARAMETER, and SET_PARAMETER, and SHALL NOT be included in and SHALL NOT be included in DESCRIBE.
DESCRIBE.
Note that RFC 2326 servers and client may in some cases not include
or return a Session header when expected according to the above text.
Any client or server is RECOMMENDED to be forgiving of this error if
possible (which it is in many cases).
The timeout parameter MAY be included in a SETUP response, and SHALL The timeout parameter MAY be included in a SETUP response, and SHALL
NOT be included in requests. The server uses it to indicate to the NOT be included in requests. The server uses it to indicate to the
client how long the server is prepared to wait between RTSP commands client how long the server is prepared to wait between RTSP commands
or other signs of life before closing the session due to lack of or other signs of life before closing the session due to lack of
activity (see below and Section A). The timeout is measured in activity (see below and Section A). The timeout is measured in
seconds, with a default of 60 seconds (1 minute). The length of the seconds, with a default of 60 seconds (1 minute). The length of the
session timeout SHALL NOT be changed in a established session. session timeout SHALL NOT be changed in a established session.
The mechanisms for showing liveness of the client is, any RTSP The mechanisms for showing liveness of the client is, any RTSP
skipping to change at page 95, line 24 skipping to change at page 93, line 50
that it can be ignored in most cases. For example, a that it can be ignored in most cases. For example, a
session with 60 seconds timeout and enough bitrate assigned session with 60 seconds timeout and enough bitrate assigned
to RTCP messages to send a message from client to server on to RTCP messages to send a message from client to server on
average every 5 seconds. That client have for a network average every 5 seconds. That client have for a network
with 5 % packet loss, the probability to fail showing with 5 % packet loss, the probability to fail showing
liveness sign in that session within the timeout interval liveness sign in that session within the timeout interval
of 2.4*E-16. In sessions with shorter timeout times, or of 2.4*E-16. In sessions with shorter timeout times, or
much higher packet loss, or small RTCP bandwidths SHOULD much higher packet loss, or small RTCP bandwidths SHOULD
also use any of the mechanisms below. also use any of the mechanisms below.
PING: The use of the PING method is the best of the RTSP based
methods. It has no other effects than updating the timeout
timer. In that way it will be a minimal message, that also
does not cause any extra processing for the server. The
downside is that it may not be implemented. A client SHOULD
use a OPTIONS request to verify support of the PING at the
server. It is also possible to detect support by sending a
PING to the server. If a 200 (OK) message is received the
server supports it. In case a 501 (Not Implemented) is
received it does not support PING and there is no meaning
in continue trying. Also the reception of a error message
will also mean that the liveness timer has not been
updated.
SET_PARAMETER: When using SET_PARAMETER for keep alive, no body SET_PARAMETER: When using SET_PARAMETER for keep alive, no body
SHOULD be included. This method is basically as good as SHOULD be included. This method is the RECOMMENDED RTSP
PING, however the implementation support of the method is method to use in request only intended to perform keep-
today limited. The same considerations as for PING apply alive.
regarding checking of support in server and proxies.
OPTIONS: This method does also work. However it causes the OPTIONS: This method does also work. However it causes the
server to perform unnecessary processing and result in server to perform unnecessary processing and result in
bigger responses than necessary for the task. The reason bigger responses than necessary for the task. The reason
for this is that the Public is always included creating for this is that the server needs to determine what
overhead. capabilities that are associated with the media resource to
correctly populate the Public and Allow headers.
Note that a session identifier identifies an RTSP session across Note that a session identifier identifies an RTSP session across
transport sessions or connections. RTSP requests for a given session transport sessions or connections. RTSP requests for a given session
can use different URIs (Presentation and media URIs). Note, that can use different URIs (Presentation and media URIs). Note, that
there are restrictions depending on the session which URIs that are there are restrictions depending on the session which URIs that are
acceptable for a given method. However, multiple "user" sessions for acceptable for a given method. However, multiple "user" sessions for
the same URI from the same client will require use of different the same URI from the same client will require use of different
session identifiers. session identifiers.
The session identifier is needed to distinguish several The session identifier is needed to distinguish several
skipping to change at page 96, line 31 skipping to change at page 94, line 43
extensions supported by the message sending entity. The Supported extensions supported by the message sending entity. The Supported
header MAY be included in any request. When present in a request, header MAY be included in any request. When present in a request,
the receiver MUST respond with its corresponding Supported header. the receiver MUST respond with its corresponding Supported header.
Note, also in 4xx and 5xx responses is the supported header included. Note, also in 4xx and 5xx responses is the supported header included.
The Supported header field contains a list of feature-tags, described The Supported header field contains a list of feature-tags, described
in Section 3.7, that are understood by the client or server. in Section 3.7, that are understood by the client or server.
Example: Example:
C->S: OPTIONS rtsp://example.com/ RTSP/1.0 C->S: OPTIONS rtsp://example.com/ RTSP/1.1
Supported: foo, bar, blech Supported: foo, bar, blech
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
Supported: bar, blech, baz Supported: bar, blech, baz
14.44 Timestamp 14.44 Timestamp
The Timestamp general-header field describes when the agent sent the
The Timestamp general-header field describes when the client sent the request. The value of the timestamp is of significance only to the
request to the server. The value of the timestamp is of significance agent and may use any timescale. The responding agent MUST echo the
only to the client and may use any timescale. The server MUST echo exact same value and MAY, if it has accurate information about this,
the exact same value and MAY, if it has accurate information about add a floating point number indicating the number of seconds that has
this, add a floating point number indicating the number of seconds elapsed since it has received the request. The timestamp is used by
that has elapsed since it has received the request. The timestamp is the agent to compute the round-trip time to the responding agent so
used by the client to compute the round-trip time to the server so
that it can adjust the timeout value for retransmissions. It also that it can adjust the timeout value for retransmissions. It also
resolves retransmission ambiguities for unreliable transport of RTSP. resolves retransmission ambiguities for unreliable transport of RTSP.
14.45 Transport 14.45 Transport
The Transport request and response header field indicates which The Transport request and response header field indicates which
transport protocol is to be used and configures its parameters such transport protocol is to be used and configures its parameters such
as destination address, compression, multicast time-to-live and as destination address, compression, multicast time-to-live and
destination port for a single stream. It sets those values not destination port for a single stream. It sets those values not
already determined by a presentation description. already determined by a presentation description.
Transports are comma separated, listed in order of preference. Transports are comma separated, listed in order of preference.
Parameters may be added to each transport, separated by a semicolon. Parameters may be added to each transport, separated by a semicolon.
The server SHOULD return a Transport response-header field in the The server SHOULD return a Transport response-header field in the
response to indicate the values actually chosen. The Transport header response to indicate the values actually chosen. The Transport header
skipping to change at page 97, line 20 skipping to change at page 95, line 32
Transports are comma separated, listed in order of preference. Transports are comma separated, listed in order of preference.
Parameters may be added to each transport, separated by a semicolon. Parameters may be added to each transport, separated by a semicolon.
The server SHOULD return a Transport response-header field in the The server SHOULD return a Transport response-header field in the
response to indicate the values actually chosen. The Transport header response to indicate the values actually chosen. The Transport header
field MAY also be used to change certain transport parameters. A field MAY also be used to change certain transport parameters. A
server MAY refuse to change parameters of an existing stream. server MAY refuse to change parameters of an existing stream.
A Transport request header field MAY contain a list of transport A Transport request header field MAY contain a list of transport
options acceptable to the client, in the form of multiple options acceptable to the client, in the form of multiple
transportspec entries. In that case, the server MUST return the transportspec entries. In that case, the server MUST return the
single option (transport-spec) which was actually chosen. The number single (transport-spec) which was actually chosen. The number of
of transportspec entries is expected to be limited as the client will transportspec entries is expected to be limited as the client will
get guidance on what configurations that are possible from the get guidance on what configurations that are possible from the
presentation description. presentation description.
A transport-spec transport option may only contain one of any given A transport-spec transport option may only contain one of any given
parameter within it. Parameters may be given in any order. parameter within it. Parameters MAY be given in any order.
Additionally, it may only contain the unicast or multicast transport Additionally, it may only contain the unicast or the multicast
type parameter. Unknown transport parameters SHALL be ignored. The transport type parameter. Unknown parameters SHALL be ignored. The
requester need to ensure that the responder understands the requester need to ensure that the responder understands the
parameters through the use of feature tags and the Require header. parameters through the use of feature tags and the Require header.
A request or a response including a transport header with any Any parameters part of future extensions requires clarification if
parameter not defined in RFC 2326 SHOULD use the Require header and they are safe to ignore in accordance to this specification, or is
the "play.basic" feature tag. This is to ensure consistent behavior required to be understood. If a parameter is required to be
with the new parameters. Any parameters part of future extensions understood, then a feature tag MUST be defined for the functionality
requires clarification if they are safe to ignore in accordance to and used in the Require and/or Proxy-Require headers.
this specification, or is required to be understood. If a parameter
is required to be understood, then a feature tag MUST be defined and
used in the Require and/or Proxy-Require headers.
The Transport header field is restricted to describing a The Transport header field is restricted to describing a
single media stream. (RTSP can also control multiple single media stream. (RTSP can also control multiple
streams as a single entity.) Making it part of RTSP rather streams as a single entity.) Making it part of RTSP rather
than relying on a multitude of session description formats than relying on a multitude of session description formats
greatly simplifies designs of firewalls. greatly simplifies designs of firewalls.
The syntax for the transport specifier is The syntax for the transport specifier is
transport/profile/lower-transport. transport/profile/lower-transport.
The default value for the "lower-transport" parameters is specific to The default value for the "lower-transport" parameters is specific to
the profile. For RTP/AVP, the default is UDP. the profile. For RTP/AVP, the default is UDP.
There is three different methods for how to specify where the media There are two different methods for how to specify where the media
should be delivered: should be delivered:
o The presence of this parameter and its values indicates o The presence of this parameter and its values indicates the
address and port pairs for one or more IP flow necessary for destination address or addresses (host address and port pairs
the media transport. This is an improved version of the for IP flows) necessary for the media transport.
Destination parameter.
o The presence of this parameter and its value indicates what IP
address the media SHALL be delivered to. This method is kept
for backwards compatibility reasons, dest_addr is a better
choice.
o The lack of of both of the above parameters indicates that the o The lack of the dest_addr parameter indicates that the server
server SHALL send media to same address for which the RTSP SHALL send media to same address for which the RTSP messages
messages originates. originates. Does not work for transports requiring explicitly
given destination ports.
The choice of method for indicating where the media is to be The choice of method for indicating where the media is to be
delivered depends on the use case. In many case the only allowed delivered depends on the use case. In many case the only allowed
method will be to use no explicit indication and have the server method will be to use no explicit address indication and have the
deliver media to the source of the RTSP messages. server deliver media to the source of the RTSP messages.
An RTSP proxy will also need to take care. If the media is not An RTSP proxy will need to take care. If the media is not desired to
desired to be routed through the proxy, the proxy will need to be routed through the proxy, the proxy will need to introduce the
introduce the destination indication. destination indication.
Below are the configuration parameters associated with transport: Below are the configuration parameters associated with transport:
General parameters: General parameters:
unicast / multicast: This parameter is a mutually exclusive unicast / multicast: This parameter is a mutually exclusive
indication of whether unicast or multicast delivery will be indication of whether unicast or multicast delivery will be
attempted. One of the two values MUST be specified. Clients attempted. One of the two values MUST be specified. Clients
that are capable of handling both unicast and multicast that are capable of handling both unicast and multicast
transmission MUST indicate such capability by including two transmission needs to indicate such capability by including
full transport-specs with separate parameters for each. two full transport-specs with separate parameters for each.
destination: The address of the stream recipient to which a
stream will be sent. The client originating the RTSP
request may specify the destination address of the stream
recipient with the destination parameter. When the
destination field is specified, the recipient may be a
different party than the originator of the request. To
avoid becoming the unwitting perpetrator of a remote-
controlled denial-of-service attack, a server SHOULD
authenticate the client originating the request and SHOULD
log such attempts before allowing the client to direct a
media stream to a recipient address not chosen by the
server. Implementations cannot rely on TCP as reliable
means of client identification.
The server SHOULD NOT allow the destination field to be set
unless a mechanism exists in the system to authorize the
request originator to direct streams to the recipient. It
is preferred that this authorization be performed by the
recipient itself and the credentials passed along to the
server. However, in certain cases, such as when recipient
address is a multicast group, or when the recipient is
unable to communicate with the server in an out-of-band
manner, this may not be possible. In these cases server may
chose another method such as a server-resident
authorization list to ensure that the request originator
has the proper credentials to request stream delivery to
the recipient.
This parameter SHALL NOT be used when src_addr and
dest_addr is used in a transport declaration. For IPv6
addresses it is RECOMMENDED that they be given as fully
qualified domain to make it backwards compatible with RFC
2326 implementations.
source: If the source address for the stream is different than
can be derived from the RTSP end-point address (the server
in playback), the source address SHOULD be specified. To
maintain backwards compatibility with RFC 2326, any IPv6
host's address needs to be given as a fully qualified
domain name. This parameter SHALL NOT be used when src_addr
and dest_addr is used in a transport declaration.
This information may also be available through SDP.
However, since this is more a feature of transport
than media initialization, the authoritative source
for this information should be in the SETUP response.
layers: The number of multicast layers to be used for this media layers: The number of multicast layers to be used for this media
stream. The layers are sent to consecutive addresses stream. The layers are sent to consecutive addresses
starting at the destination address. starting at the dest_addr address.
dest_addr: A general destination address parameter that can dest_addr: A general destination address parameter that can
contain one or more address and port pair. For each contain one or more address specifications. Each
combination of Protocol/Profile/Lower Transport the combination of Protocol/Profile/Lower Transport needs to
interpretation of the address or addresses needs to be have the format and interpretation of its address
defined. The host address part of the tuple MAY be empty, specification defined. For RTP/AVP/UDP and RTP/AVP/TCP,
for example ":8000", in cases when only destination port is the address specification is a tuple containing a host
desired to be specified. address and port.
The client or server SHALL NOT use this parameter unless The client originating the RTSP request MAY specify the
both client and server has shown support. This parameter destination address of the stream recipient with the host
MUST be supported by client and servers that implements address part of the tuple. When the destination address is
this specification. Support is indicated by the use of the specified, the recipient may be a different party than the
feature-tag "play.basic". This parameter SHALL NOT be used originator of the request. To avoid becoming the unwitting
in the same transport specification as any of the perpetrator of a remote-controlled denial-of-service
parameters "destination", "source", "port", "client_port", attack, a server MUST perform security checks (see Section
and "server_port". 20.1) and SHOULD log such attempts before allowing the
client to direct a media stream to a recipient address not
chosen by the server. Implementations cannot rely on TCP as
reliable means of client identification. If the server does
not allow the host address part of the tuple to be set, it
SHALL return 463 (Destination Prohibited).
The same security consideration that are given for the The host address part of the tuple MAY be empty, for
"Destination" parameter does also applies to this example ":58044", in cases when only destination port is
parameter. This parameter can be used for redirecting desired to be specified.
traffic to recipient not desiring the media traffic.
src_addr: A general source address parameter that can contain src_addr: A general source address parameter that can contain
one or more address and port pairs. For each combination of one or more address specifications. Each combination of
Protocol/Profile/Lower Transport the interpretation of the Protocol/Profile/Lower Transport needs to have the format
address or addresses needs to be defined. The client or and interpretation of its address specification defined.
server SHALL NOT use this parameter unless both client and For RTP/AVP/UDP and RTP/AVP/TCP, the address specification
server have shown support. This parameter MUST be supported is a tuple containing a host address and port.
by client and servers that implement this specification.
Support is indicated by the use the feature-tag
"play.basic". This parameter SHALL NOT be used in the same
transport specification as any of the parameters
"destination", "source", "port", "client_port", and
"server_port".
This parameter MUST be specified by the server if it This parameter MUST be specified by the server if it
transmits media packets from another address than the one transmits media packets from another address than the one
RTSP messages are sent to. This will allow the client to RTSP messages are sent to. This will allow the client to
verify source address and give it a destination address for verify source address and give it a destination address for
its RTCP feedback packets if RTP is used. The address or its RTCP feedback packets if RTP is used. The address or
addresses indicated in the src_addr parameter SHOULD be addresses indicated in the src_addr parameter SHOULD be
used both for sending and receiving of the media streams used both for sending and receiving of the media streams
data packets. The main reasons are threefold: First, data packets. The main reasons are threefold: First,
indicating the port and source address(s) lets the receiver indicating the port and source address(s) lets the receiver
know where from the packets is expected to originate. know where from the packets is expected to originate.
Secondly, traversal of NATs are greatly simplified when Secondly, traversal of NATs are greatly simplified when
traffic is flowing symmetrically over a NAT binding. traffic is flowing symmetrically over a NAT binding.
Thirdly, certain NAT traversal mechanisms, needs to know to Thirdly, certain NAT traversal mechanisms, needs to know to
which address and port to send so called "binding packets" which address and port to send so called "binding packets"
from the receiver to the sender, thus creating a address from the receiver to the sender, thus creating a address
binding in the NAT that the sender to receiver packet flow binding in the NAT that the sender to receiver packet flow
can use. can use.
This information may also be available through SDP.
However, since this is more a feature of transport
than media initialization, the authoritative source
for this information should be in the SETUP response.
mode: The mode parameter indicates the methods to be supported mode: The mode parameter indicates the methods to be supported
for this session. Valid values are PLAY and RECORD. If not for this session. Valid values are PLAY and RECORD. If not
provided, the default is PLAY. The RECORD value was provided, the default is PLAY. The RECORD value was
defined in RFC 2326 and is deprecated in this defined in RFC 2326 and is deprecated in this
specification. specification.
append: The append parameter was used together with RECORD and append: The append parameter was used together with RECORD and
is now deprecated. is now deprecated.
interleaved: The interleaved parameter implies mixing the media interleaved: The interleaved parameter implies mixing the media
skipping to change at page 101, line 44 skipping to change at page 99, line 5
Multicast-specific: Multicast-specific:
ttl: multicast time-to-live. ttl: multicast time-to-live.
RTP-specific: RTP-specific:
These parameters are MAY only be used if the media transport protocol These parameters are MAY only be used if the media transport protocol
is RTP. is RTP.
port: This parameter provides the RTP/RTCP port pair for a
multicast session. It is should be specified as a range,
e.g., port=3456-3457
client_port: This parameter provides the unicast RTP/RTCP port
pair on the client where media data and control information
is to be sent. It is specified as a range, e.g.,
port=3456-3457. This parameter SHALL NOT be used when
src_addr and dest_addr is used in a transport declaration.
server_port: This parameter provides the unicast RTP/RTCP port
pair on the server where media data and control information
is to be sent. It is specified as a range, e.g.,
port=3456-3457. This parameter SHALL NOT be used when
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 [16] 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. If the expressed as an eight digit hexadecimal value.
client has indicated support for a minimal implementation
of this specification (Section 10), a list of SSRC values
MAY be specified by the server. The first value listed
should correspond to the source whose synchronization
information is provided in the RTP-Info header. Regardless,
there may be other sources not listed whose ssrc's must be
deduced from the actual RTP/RTCP stream.
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,
reflector, etc.), the value will be the "packet sender's
SSRC" that would have been used in the RTCP Receiver
Reports generated by the server, regardless of whether the
server actually generates RTCP RRs.
The functionality of specifying the ssrc parameter in a The ssrc parameter SHALL NOT be specified in requests. The
SETUP request is deprecated as it is incompatible with the functionality of specifying the ssrc parameter in a SETUP
request is deprecated as it is incompatible with the
specification of RTP in RFC 3550 [16]. 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.
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.1
CSeq: 302 CSeq: 302
Transport: RTP/AVP;multicast;mode="PLAY", Transport: RTP/AVP;multicast;mode="PLAY",
RTP/AVP;unicast;client_port=3456-3457;mode="PLAY" RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
"192.0.2.5:3457";mode="PLAY"
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
CSeq: 302 CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344 Session: 47112344
Transport: RTP/AVP;unicast;client_port=3456-3457; Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
server_port=6256-6257;mode="PLAY" "192.0.2.5:3457";src_addr="192.0.2.224:6256"
/"192.0.2.224:6257";mode="PLAY"
14.46 Unsupported 14.46 Unsupported
The Unsupported response-header field lists the features not The Unsupported response-header field lists the features not
supported by the server. In the case where the feature was specified supported by the server. In the case where the feature was specified
via the Proxy-Require field (Section 14.31), if there is a proxy on via the Proxy-Require field (Section 14.31), if there is a proxy on
the path between the client and the server, the proxy MUST send a the path between the client and the server, the proxy MUST send a
response message with a status code of 551 (Option Not Supported). response message with a status code of 551 (Option Not Supported).
The request SHALL NOT be forwarded. The request SHALL NOT be forwarded.
skipping to change at page 103, line 46 skipping to change at page 100, line 25
See [H14.44] See [H14.44]
14.49 Via 14.49 Via
See [H14.45]. See [H14.45].
14.50 WWW-Authenticate 14.50 WWW-Authenticate
See [H14.47]. See [H14.47].
15 Caching 15 Proxies
RTSP Proxies are RTSP agents that sit in between a client and a
server. A proxy can take on both the role as a client and as server
depending on what it tries to accomplish. Proxies are also introduced
for several different reasons.
o This type of proxy is used to reduce the workload on servers
and connections. By caching a presentation, both description
and media streams the proxy can serve a client content without
requesting it from the server once it has been cached and
hasn't become stale. See the caching section 16.
o This type of proxy is used to ensure that a RTSP client get
access to servers on an external network. Thus this proxy is
placed on the border between two domains, e.g. a private
address space and the public internet. The proxy performs the
necessary translation, usually addresses, and often also media
stream translation or redirection.
o This type of proxy is used to help facilitate security
functions around RTSP. For example when having a firewalled
network, the security proxy request that the necessary
pinholes in the firewall is opened when a client in the
protected network want to access media streams on the external
side. It can also provide network owners with a logging and
audit point for RTSP sessions, e.g. for corporations that
tracks or limits their employees access to certain type of
content.
All type of proxies can be used also when using secured communication
with TLS as RTSP 1.1 allows the client to approve certificates for
connection establishment from a proxy, see section 18.3.2.
Access proxies SHOULD NOT be used in equipment like NATs and
firewalls that aren't expected to be regularly maintained, like home
or small office equipment. In these cases it is better to use the NAT
traversal procedures defined for RTSP 1.1 [25]. The reason for these
recommendations is that any extensions of RTSP resulting in new media
transport protocols or profiles, new parameters etc may fail in a
proxy that isn't maintained. Thus resulting in blocking further
development of RTSP and its usage.
The existence of proxies must always be considered when developing
new RTSP extensions. There must be definition of how proxies may
handle the extension, if it is required to understand it, thus
requiring a feature tag to be used in the Proxy-Require header.
16 Caching
In HTTP, response-request pairs are cached. RTSP differs In HTTP, response-request pairs are cached. RTSP differs
significantly in that respect. Responses are not cacheable, with the significantly in that respect. Responses are not cacheable, with the
exception of the presentation description returned by DESCRIBE. exception of the presentation description returned by DESCRIBE.
(Since the responses for anything but DESCRIBE and GET_PARAMETER do (Since the responses for anything but DESCRIBE and GET_PARAMETER do
not return any data, caching is not really an issue for these not return any data, caching is not really an issue for these
requests.) However, it is desirable for the continuous media data, requests.) However, it is desirable for the continuous media data,
typically delivered out-of-band with respect to RTSP, to be cached, typically delivered out-of-band with respect to RTSP, to be cached,
as well as the session description. as well as the session description.
On receiving a SETUP or PLAY request, a proxy ascertains whether it On receiving a SETUP or PLAY request, a proxy ascertains whether it
has an up-to-date copy of the continuous media content and its has an up-to-date copy of the continuous media content and its
description. It can determine whether the copy is up-to-date by description. It can determine whether the copy is up-to-date by
issuing a SETUP or DESCRIBE request, respectively, and comparing the issuing a SETUP or DESCRIBE request, respectively, and comparing the
skipping to change at page 104, line 45 skipping to change at page 102, line 21
cache has to store the content type, content language, and so on for cache has to store the content type, content language, and so on for
the objects it caches, a media cache has to store the presentation the objects it caches, a media cache has to store the presentation
description. Typically, a cache eliminates all transport-references description. Typically, a cache eliminates all transport-references
(that is, multicast information) from the presentation description, (that is, multicast information) from the presentation description,
since these are independent of the data delivery from the cache to since these are independent of the data delivery from the cache to
the client. Information on the encodings remains the same. If the the client. Information on the encodings remains the same. If the
cache is able to translate the cached media data, it would create a cache is able to translate the cached media data, it would create a
new presentation description with all the encoding possibilities it new presentation description with all the encoding possibilities it
can offer. can offer.
16 Examples 17 Examples
This section contains several different examples trying to illustrate This section contains several different examples trying to illustrate
possible ways of using RTSP. The examples can also help with the possible ways of using RTSP. The examples can also help with the
understanding of how functions of RTSP work. However remember that understanding of how functions of RTSP work. However remember that
this is examples and the normative and syntax description in the this is examples and the normative and syntax description in the
other sections takes precedence. Please also note that many of the other sections takes precedence. Please also note that many of the
example MAY contain syntax illegal line breaks to accommodate the example MAY contain syntax illegal line breaks to accommodate the
formatting restriction that the RFC series impose. formatting restriction that the RFC series impose.
16.1 Media on Demand (Unicast) 17.1 Media on Demand (Unicast)
Client C requests a movie distributed from two different media Client C requests a movie distributed from two different media
servers A (audio.example.com ) and V (video.example.com ). The media servers A (audio.example.com ) and V (video.example.com ). The media
description is stored on a web server W. The media description description is stored on a web server W. The media description
contains descriptions of the presentation and all its streams, contains descriptions of the presentation and all its streams,
including the codecs that are available, dynamic RTP payload types, including the codecs that are available, dynamic RTP payload types,
the protocol stack, and content information such as language or the protocol stack, and content information such as language or
copyright restrictions. It may also give an indication about the copyright restrictions. It may also give an indication about the
timeline of the movie. timeline of the movie.
In this example, the client is only interested in the last part of In this example, the client is only interested in the last part of
the movie. the movie.
C->W: GET /twister.sdp HTTP/1.1 C->W: GET /twister.sdp HTTP/1.1
Host: www.example.com Host: www.example.com
Accept: application/sdp Accept: application/sdp
W->C: HTTP/1.0 200 OK W->C: HTTP/1.0 200 OK
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 255 Content-Length: 264
Expires: 23 Jan 1998 15:35:06 GMT Expires: 23 Jan 1998 15:35:06 GMT
v=0 v=0
o=- 2890844526 2890842807 IN IP4 192.16.24.202 o=- 2890844526 2890842807 IN IP4 192.16.24.202
s=RTSP Session s=RTSP Session
e=adm@example.com e=adm@example.com
a=range:npt=0-1:49:34 a=range:npt=0-1:49:34
t=0 0 t=0 0
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=control:rtsp://audio.example.com/twister/audio.en a=control:rtsp://audio.example.com/twister/audio.en
m=video 0 RTP/AVP 31 m=video 0 RTP/AVP 31
a=control:rtsp://video.example.com/twister/video a=control:rtsp://video.example.com/twister/video
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.1
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;client_port=3056-3057, Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057",
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
A->C: RTSP/1.0 200 OK A->C: RTSP/1.1 200 OK
CSeq: 1 CSeq: 1
Session: 12345678 Session: 12345678
Transport: RTP/AVP/UDP;unicast;client_port=3056-3057; Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057";
server_port=5000-5001 src_addr="192.0.2.5:5000"/"192.0.2.5:5001"
Date: 23 Jan 1997 15:35:12 GMT Date: 23 Jan 1997 15:35:12 GMT
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Expires: 24 Jan 1997 15:35:12 GMT Expires: 24 Jan 1997 15:35:12 GMT
Cache-Control: public Cache-Control: public
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0 C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.1
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;client_port=3058-3059, Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059",
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
V->C: RTSP/1.0 200 OK V->C: RTSP/1.1 200 OK
CSeq: 1 CSeq: 1
Session: 23456789 Session: 23456789
Transport: RTP/AVP/UDP;unicast;client_port=3058-3059; Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059";
server_port=5002-5003 src_addr="192.0.2.5:5002"/"192.0.2.5:5003"
Date: 23 Jan 1997 15:35:12 GMT Date: 23 Jan 1997 15:35:12 GMT
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Cache-Control: public Cache-Control: public
Expires: 24 Jan 1997 15:35:12 GMT Expires: 24 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.1
C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 2 CSeq: 2
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 23456789 Session: 23456789
Range: smpte=0:10:00- Range: smpte=0:10:00-
V->C: RTSP/1.0 200 OK V->C: RTSP/1.1 200 OK
CSeq: 2 CSeq: 2
Session: 23456789 Session: 23456789
Range: smpte=0:10:00-1:49:23 Range: smpte=0:10:00-1:49:23
RTP-Info: url=rtsp://video.example.com/twister/video; RTP-Info: url="rtsp://video.example.com/twister/video"
seq=12312232;rtptime=78712811 ssrc=A17E189D:seq=12312232;rtptime=78712811
Server: PhonyServer/2.0 Server: PhonyServer/2.0
Date: 23 Jan 1997 15:35:13 GMT Date: 23 Jan 1997 15:35:13 GMT
C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.1
CSeq: 2 CSeq: 2
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 12345678 Session: 12345678
Range: smpte=0:10:00- Range: smpte=0:10:00-
A->C: RTSP/1.0 200 OK A->C: RTSP/1.1 200 OK
CSeq: 2 CSeq: 2
Session: 12345678 Session: 12345678
Range: smpte=0:10:00-1:49:23 Range: smpte=0:10:00-1:49:23
RTP-Info: url=rtsp://audio.example.com/twister/audio.en; RTP-Info: url="rtsp://audio.example.com/twister/audio.en"
seq=876655;rtptime=1032181 ssrc=3D124F01:seq=876655;rtptime=1032181
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:13 GMT Date: 23 Jan 1997 15:35:13 GMT
C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.1
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 12345678 Session: 12345678
A->C: RTSP/1.0 200 OK A->C: RTSP/1.1 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:36:52 GMT Date: 23 Jan 1997 15:36:52 GMT
C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.1
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 23456789 Session: 23456789
V->C: RTSP/1.0 200 OK V->C: RTSP/1.1 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/2.0 Server: PhonyServer/2.0
Date: 23 Jan 1997 15:36:52 GMT Date: 23 Jan 1997 15:36:52 GMT
Even though the audio and video track are on two different servers, Even though the audio and video track are on two different servers,
may start at slightly different times, and may drift with respect to may start at slightly different times, and may drift with respect to
each other, the client can synchronize the two using standard RTP each other, the client can synchronize the two using standard RTP
methods, in particular the time scale contained in the RTCP sender methods, in particular the time scale contained in the RTCP sender
reports. Initial synchronization is achieved through the RTP-Info and reports. Initial synchronization is achieved through the RTP-Info and
Range headers information in the PLAY response. Range headers information in the PLAY response.
16.2 Streaming of a Container file 17.2 Streaming of a Container file
For purposes of this example, a container file is a storage entity in For purposes of this example, a container file is a storage entity in
which multiple continuous media types pertaining to the same end-user which multiple continuous media types pertaining to the same end-user
presentation are present. In effect, the container file represents an presentation are present. In effect, the container file represents an
RTSP presentation, with each of its components being RTSP streams. RTSP presentation, with each of its components being RTSP streams.
Container files are a widely used means to store such presentations. Container files are a widely used means to store such presentations.
While the components are transported as independent streams, it is While the components are transported as independent streams, it is
desirable to maintain a common context for those streams at the desirable to maintain a common context for those streams at the
server end. server end.
skipping to change at page 108, line 28 skipping to change at page 106, line 5
multiple streams. It also illustrates the use of aggregate URIs. In a multiple streams. It also illustrates the use of aggregate URIs. In a
container file it is also desirable to not write any URI parts which container file it is also desirable to not write any URI parts which
is not kept, when the container is distributed, like the host and is not kept, when the container is distributed, like the host and
most of the path element. Therefore this example also uses the "*" most of the path element. Therefore this example also uses the "*"
and relative URI in the delivered SDP. and relative URI in the delivered SDP.
Client C requests a presentation from media server M. The movie is Client C requests a presentation from media server M. The movie is
stored in a container file. The client has obtained an RTSP URI to stored in a container file. The client has obtained an RTSP URI to
the container file. the container file.
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/1.0 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/1.1
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
M->C: RTSP/1.0 200 OK M->C: RTSP/1.1 200 OK
CSeq: 1 CSeq: 1
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 257 Content-Length: 257
Content-Base: rtsp://example.com/twister.3gp/ Content-Base: rtsp://example.com/twister.3gp/
Expires: 24 Jan 1997 15:35:06 GMT Expires: 24 Jan 1997 15:35:06 GMT
v=0 v=0
o=- 2890844256 2890842807 IN IP4 172.16.2.93 o=- 2890844256 2890842807 IN IP4 172.16.2.93
skipping to change at page 109, line 6 skipping to change at page 106, line 31
i=An Example of RTSP Session Usage i=An Example of RTSP Session Usage
e=adm@example.com e=adm@example.com
a=control: * a=control: *
a=range: npt=0-0:10:34.10 a=range: npt=0-0:10:34.10
t=0 0 t=0 0
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=control: trackID=1 a=control: trackID=1
m=video 0 RTP/AVP 26 m=video 0 RTP/AVP 26
a=control: trackID=4 a=control: trackID=4
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/1.0 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/1.1
CSeq: 2 CSeq: 2
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Require: play.basic Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001"
M->C: RTSP/1.0 200 OK M->C: RTSP/1.1 200 OK
CSeq: 2 CSeq: 2
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001; Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001;
src_addr="172.16.2.93:9000"/"172.16.2.93:9001" src_addr="192.0.2.5:9000"/"192.0.2.5:9001"
ssrc=93CB001E ssrc=93CB001E
Session: 12345678 Session: 12345678
Expires: 24 Jan 1997 15:35:12 GMT Expires: 24 Jan 1997 15:35:12 GMT
Date: 23 Jan 1997 15:35:12 GMT Date: 23 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT Accept-Ranges: NPT
C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/1.0 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/1.1
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Require: play.basic Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
Session: 12345678 Session: 12345678
M->C: RTSP/1.0 200 OK M->C: RTSP/1.1 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003; Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003;
src_addr="172.16.2.93:9002"/"172.16.2.93:9003"; src_addr="192.0.2.5:9002"/"192.0.2.5:9003";
ssrc=A813FC13 ssrc=A813FC13
Session: 12345678 Session: 12345678
Expires: 24 Jan 1997 15:35:13 GMT Expires: 24 Jan 1997 15:35:13 GMT
Date: 23 Jan 1997 15:35:13 GMT Date: 23 Jan 1997 15:35:13 GMT
Accept-Range: NPT Accept-Range: NPT
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/1.0 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/1.1
CSeq: 4 CSeq: 4
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Range: npt=0-10, npt=30- Range: npt=0-10, npt=30-
Session: 12345678 Session: 12345678
M->C: RTSP/1.0 200 OK M->C: RTSP/1.1 200 OK
CSeq: 4 CSeq: 4
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:14 GMT Date: 23 Jan 1997 15:35:14 GMT
Session: 12345678 Session: 12345678
Range: npt=0-10, npt=30-623.10 Range: npt=0-10, npt=30-623.10
RTP-Info: url=rtsp://example.com/twister.3gp/trackID=4; RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
seq=12345;rtptime=3450012, ssrc=0D12F123:seq=12345;rtptime=3450012,
url=rtsp://example.com/twister.3gp/trackID=1; url="rtsp://example.com/twister.3gp/trackID=1";
seq=54321;rtptime=2876889 ssrc=4F312DD8:seq=54321;rtptime=2876889
C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/1.0 C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/1.1
CSeq: 5 CSeq: 5
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 12345678 Session: 12345678
M->C: RTSP/1.0 200 OK M->C: RTSP/1.1 200 OK
CSeq: 5 CSeq: 5
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:36:01 GMT Date: 23 Jan 1997 15:36:01 GMT
Session: 12345678 Session: 12345678
Range: npt=34.57-623.10 Range: npt=34.57-623.10
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/1.0 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/1.1
CSeq: 6 CSeq: 6
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Range: npt=34.57-623.10 Range: npt=34.57-623.10
Session: 12345678 Session: 12345678
M->C: RTSP/1.1 200 OK
M->C: RTSP/1.0 200 OK
CSeq: 6 CSeq: 6
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:36:01 GMT Date: 23 Jan 1997 15:36:01 GMT
Session: 12345678 Session: 12345678
Range: npt=34.57-623.10 Range: npt=34.57-623.10
RTP-Info: url=rtsp://example.com/twister.3gp/trackID=4; RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
seq=12555;rtptime=6330012, ssrc=0D12F123:seq=12555;rtptime=6330012,
url=rtsp://example.com/twister.3gp/trackID=1; url="rtsp://example.com/twister.3gp/trackID=1"
seq=55021;rtptime=3132889 ssrc=4F312DD8:seq=55021;rtptime=3132889
16.3 Single Stream Container Files 17.3 Single Stream Container Files
Some RTSP servers may treat all files as though they are "container Some RTSP servers may treat all files as though they are "container
files", yet other servers may not support such a concept. Because of files", yet other servers may not support such a concept. Because of
this, clients SHOULD use the rules set forth in the session this, clients SHOULD use the rules set forth in the session
description for Request-URIs, rather than assuming that a consistent description for Request-URIs, rather than assuming that a consistent
URI may always be used throughout. Below are an example of how a URI may always be used throughout. Below are an example of how a
multi-stream server might expect a single-stream file to be served: multi-stream server might expect a single-stream file to be served:
C->S: DESCRIBE rtsp://foo.com/test.wav RTSP/1.0 C->S: DESCRIBE rtsp://foo.com/test.wav RTSP/1.1
Accept: application/x-rtsp-mh, application/sdp Accept: application/x-rtsp-mh, application/sdp
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
CSeq: 1 CSeq: 1
Content-base: rtsp://foo.com/test.wav/ Content-base: rtsp://foo.com/test.wav/
Content-type: application/sdp Content-type: application/sdp
Content-length: 48 Content-length: 148
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Expires: 23 Jan 1997 17:00:00 GMT Expires: 23 Jan 1997 17:00:00 GMT
v=0 v=0
o=- 872653257 872653257 IN IP4 172.16.2.187 o=- 872653257 872653257 IN IP4 172.16.2.187
s=mu-law wave file s=mu-law wave file
i=audio test i=audio test
t=0 0 t=0 0
a=control: * a=control: *
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=control:streamid=0 a=control:streamid=0
C->S: SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0 C->S: SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.1
Transport: RTP/AVP/UDP;unicast; Transport: RTP/AVP/UDP;unicast;
client_port=6970-6971;mode="PLAY" dest_addr=":6970"/":6971";mode="PLAY"
CSeq: 2 CSeq: 2
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
Transport: RTP/AVP/UDP;unicast;client_port=6970-6971; Transport: RTP/AVP/UDP;unicast;dest_addr=":6970"/":6971";
server_port=6970-6971;mode="PLAY";ssrc=EAB98712 src_addr="192.0.2.5:6970"/"192.0.2.5:6971";
mode="PLAY";ssrc=EAB98712
CSeq: 2 CSeq: 2
Session: 2034820394 Session: 2034820394
Expires: 23 Jan 1997 16:00:00 GMT Expires: 23 Jan 1997 16:00:00 GMT
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:07 GMT Date: 23 Jan 1997 15:35:07 GMT
C->S: PLAY rtsp://foo.com/test.wav/ RTSP/1.0 C->S: PLAY rtsp://foo.com/test.wav/ RTSP/1.1
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 2034820394 Session: 2034820394
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:08 GMT Date: 23 Jan 1997 15:35:08 GMT
Session: 2034820394 Session: 2034820394
Range: npt=0-600 Range: npt=0-600
RTP-Info: url=rtsp://foo.com/test.wav/streamid=0; RTP-Info: url="rtsp://foo.com/test.wav/streamid=0"
seq=981888;rtptime=3781123 ssrc=0D12F123:seq=981888;rtptime=3781123
Note the different URI in the SETUP command, and then the switch back Note the different URI in the SETUP command, and then the switch back
to the aggregate URI in the PLAY command. This makes complete sense to the aggregate URI in the PLAY command. This makes complete sense
when there are multiple streams with aggregate control, but is less when there are multiple streams with aggregate control, but is less
than intuitive in the special case where the number of streams is than intuitive in the special case where the number of streams is
one. However the server has declared that the aggregated control URI one. However the server has declared that the aggregated control URI
in the SDP and therefore this is legal. in the SDP and therefore this is legal.
In this case, it is also required that servers accept implementations In this case, it is also required that servers accept implementations
that use the non-aggregated interpretation and use the individual that use the non-aggregated interpretation and use the individual
media URI, like this: media URI, like this:
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.1
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
16.4 Live Media Presentation Using Multicast 17.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.
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">
... ...
</html> </html>
C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.0 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.1
CSeq: 1 CSeq: 1
Supported: play.basic, play.scale Supported: play.basic, play.scale
M->C: RTSP/1.0 200 OK
M->C: RTSP/1.1 200 OK
CSeq: 1 CSeq: 1
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 181 Content-Length: 182
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Supported: play.basic Supported: play.basic
v=0 v=0
o=- 2890844526 2890842807 IN IP4 192.16.24.202 o=- 2890844526 2890842807 IN IP4 192.16.24.202
s=RTSP Session s=RTSP Session
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
c=IN IP4 224.2.0.1/16 c=IN IP4 224.2.0.1/16
a=control: rtsp://live.example.com/concert/audio a=control: rtsp://live.example.com/concert/audio
a=range:npt=0- a=range:npt=0-
C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.1
CSeq: 2 CSeq: 2
Transport: RTP/AVP;multicast Transport: RTP/AVP;multicast
M->C: RTSP/1.0 200 OK M->C: RTSP/1.1 200 OK
CSeq: 2 CSeq: 2
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Transport: RTP/AVP;multicast;destination=224.2.0.1; Transport: RTP/AVP;multicast;dest_addr="224.2.0.1:3456"/"
port=3456-3457;ttl=16 224.2.0.1:3457";ttl=16
Session: 0456804596 Session: 0456804596
Accept-Ranges: NPT, UTC Accept-Ranges: NPT, UTC
C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.1
CSeq: 3 CSeq: 3
Session: 0456804596 Session: 0456804596
M->C: RTSP/1.0 200 OK M->C: RTSP/1.1 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:07 GMT Date: 23 Jan 1997 15:35:07 GMT
Session: 0456804596 Session: 0456804596
Range:npt=1256- Range:npt=1256-
RTP-Info: url=rtsp://live.example.com/concert/audio; RTP-Info: url="rtsp://live.example.com/concert/audio"
seq=1473; rtptime=80000 ssrc=0D12F123:seq=1473; rtptime=80000
16.5 Capability Negotiation 17.5 Capability Negotiation
This examples illustrate how the client and server determines their This examples illustrate how the client and server determines their
capability to support a special feature, in this case "play.scale". capability to support a special feature, in this case "play.scale".
The server, through the clients request and the included Supported The server, through the clients request and the included Supported
header, learns that the client is supporting this updated header, learns that the client is supporting this updated
specification, and also supports the playback time scaling feature of specification, and also supports the playback time scaling feature of
RTSP. The server's response contains the following feature related RTSP. The server's response contains the following feature related
information to the client; it supports the updated specification information to the client; it supports the updated specification
(play.basic), the extended functionality of time scaling of content (play.basic), the extended functionality of time scaling of content
(play.scale), and one "example.com" proprietary feature (play.scale), and one "example.com" proprietary feature
(example.com.flight). The client also learns the methods supported (example.com.flight). The client also learns the methods supported
(Public header) by the server for the indicated resource. (Public header) by the server for the indicated resource.
skipping to change at page 114, line 15 skipping to change at page 111, line 36
The server, through the clients request and the included Supported The server, through the clients request and the included Supported
header, learns that the client is supporting this updated header, learns that the client is supporting this updated
specification, and also supports the playback time scaling feature of specification, and also supports the playback time scaling feature of
RTSP. The server's response contains the following feature related RTSP. The server's response contains the following feature related
information to the client; it supports the updated specification information to the client; it supports the updated specification
(play.basic), the extended functionality of time scaling of content (play.basic), the extended functionality of time scaling of content
(play.scale), and one "example.com" proprietary feature (play.scale), and one "example.com" proprietary feature
(example.com.flight). The client also learns the methods supported (example.com.flight). The client also learns the methods supported
(Public header) by the server for the indicated resource. (Public header) by the server for the indicated resource.
C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/1.0 C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/1.1
CSeq: 1 CSeq: 1
Supported: play.basic, play.scale Supported: play.basic, play.scale
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
CSeq: 1 CSeq: 1
Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
Server: PhonyServer/2.0 Server: PhonyServer/2.0
Supported: play.basic, play.scale, example.com.flight Supported: play.basic, play.scale, example.com.flight
When the client sends its SETUP request it tells the server that it When the client sends its SETUP request it tells the server that it
is requires support of the play.scale feature for this session by is requires support of the play.scale feature for this session by
including the Require header. including the Require header.
C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/1.0 C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/1.1
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;client_port=3056-3057, Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057",
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
Require: play.scale Require: play.scale
S->C: RTSP/1.0 200 OK S->C: RTSP/1.1 200 OK
CSeq: 3 CSeq: 3
Session: 12345678