draft-ietf-mmusic-rfc2326bis-30.txt   draft-ietf-mmusic-rfc2326bis-31.txt 
MMUSIC Working Group H. Schulzrinne MMUSIC Working Group H. Schulzrinne
Internet-Draft Columbia University Internet-Draft Columbia University
Obsoletes: 2326 (if approved) A. Rao Obsoletes: 2326 (if approved) A. Rao
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: January 17, 2013 R. Lanphier Expires: August 29, 2013 R. Lanphier
M. Westerlund M. Westerlund
Ericsson AB Ericsson AB
M. Stiemerling (Ed.) M. Stiemerling (Ed.)
NEC NEC
July 16, 2012 February 25, 2013
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-30 draft-ietf-mmusic-rfc2326bis-31
Abstract Abstract
This memorandum defines RTSP version 2.0 which obsoletes RTSP version This memorandum defines RTSP version 2.0 which obsoletes RTSP version
1.0 defined in RFC 2326. 1.0 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 setup and control of the delivery of data with real-time protocol for setup and control of 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
skipping to change at page 1, line 48 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 17, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 7, line 15 skipping to change at page 7, line 15
18.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 160 18.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 160
18.46. Server . . . . . . . . . . . . . . . . . . . . . . . . . 162 18.46. Server . . . . . . . . . . . . . . . . . . . . . . . . . 162
18.47. Session . . . . . . . . . . . . . . . . . . . . . . . . 162 18.47. Session . . . . . . . . . . . . . . . . . . . . . . . . 162
18.48. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 163 18.48. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 163
18.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 164 18.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 164
18.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 165 18.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 165
18.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 165 18.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 165
18.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 166 18.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 166
18.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 173 18.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 173
18.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 173 18.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 173
18.55. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 173 18.55. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 174
18.56. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 174 18.56. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 174
19. Security Framework . . . . . . . . . . . . . . . . . . . . . 175 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 175
19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 175 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 175
19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 175 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 175
19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 176 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 176
19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 177 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 177
19.3.2. User approved TLS procedure . . . . . . . . . . . . 178 19.3.2. User approved TLS procedure . . . . . . . . . . . . 178
20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 181 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 181
20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 183 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 183
20.2.1. Generic Protocol elements . . . . . . . . . . . . . 183 20.2.1. Generic Protocol elements . . . . . . . . . . . . . 183
20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 186 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 186
20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 190 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 190
20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 199 20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 199
21. Security Considerations . . . . . . . . . . . . . . . . . . . 200 21. Security Considerations . . . . . . . . . . . . . . . . . . . 200
21.1. Signaling Protocol Threats . . . . . . . . . . . . . . . 200 21.1. Signaling Protocol Threats . . . . . . . . . . . . . . . 200
21.2. Media Stream Delivery Threats . . . . . . . . . . . . . 203 21.2. Media Stream Delivery Threats . . . . . . . . . . . . . 203
21.2.1. Remote denial of Service Attack . . . . . . . . . . 204 21.2.1. Remote Denial of Service Attack . . . . . . . . . . 204
21.2.2. RTP Security analysis . . . . . . . . . . . . . . . 205 21.2.2. RTP Security analysis . . . . . . . . . . . . . . . 205
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 207 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 207
22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 207 22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 207
22.1.1. Description . . . . . . . . . . . . . . . . . . . . 208 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 208
22.1.2. Registering New Feature-tags with IANA . . . . . . . 208 22.1.2. Registering New Feature-tags with IANA . . . . . . . 208
22.1.3. Registered entries . . . . . . . . . . . . . . . . . 208 22.1.3. Registered entries . . . . . . . . . . . . . . . . . 208
22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 209 22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 209
22.2.1. Description . . . . . . . . . . . . . . . . . . . . 209 22.2.1. Description . . . . . . . . . . . . . . . . . . . . 209
22.2.2. Registering New Methods with IANA . . . . . . . . . 209 22.2.2. Registering New Methods with IANA . . . . . . . . . 209
22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 209 22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 209
skipping to change at page 8, line 24 skipping to change at page 8, line 24
22.8.1. Description . . . . . . . . . . . . . . . . . . . . 215 22.8.1. Description . . . . . . . . . . . . . . . . . . . . 215
22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 215 22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 215
22.8.3. Registered Values . . . . . . . . . . . . . . . . . 216 22.8.3. Registered Values . . . . . . . . . . . . . . . . . 216
22.9. Range header formats . . . . . . . . . . . . . . . . . . 216 22.9. Range header formats . . . . . . . . . . . . . . . . . . 216
22.9.1. Description . . . . . . . . . . . . . . . . . . . . 216 22.9.1. Description . . . . . . . . . . . . . . . . . . . . 216
22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 216 22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 216
22.9.3. Registered Values . . . . . . . . . . . . . . . . . 216 22.9.3. Registered Values . . . . . . . . . . . . . . . . . 216
22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 217 22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 217
22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 217 22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 217
22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 217 22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 217
22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 217 22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 218
22.11.1. Description . . . . . . . . . . . . . . . . . . . . 217 22.11.1. Description . . . . . . . . . . . . . . . . . . . . 218
22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 218 22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 218
22.11.3. Registered Values . . . . . . . . . . . . . . . . . 218 22.11.3. Registered Values . . . . . . . . . . . . . . . . . 218
22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 218 22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 218
22.12.1. Description . . . . . . . . . . . . . . . . . . . . 218 22.12.1. Description . . . . . . . . . . . . . . . . . . . . 218
22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 218 22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 219
22.12.3. Registered Values . . . . . . . . . . . . . . . . . 219 22.12.3. Registered Values . . . . . . . . . . . . . . . . . 219
22.13. Transport Header Registries . . . . . . . . . . . . . . 219 22.13. Transport Header Registries . . . . . . . . . . . . . . 219
22.13.1. Transport Protocol Specification . . . . . . . . . . 219 22.13.1. Transport Protocol Specification . . . . . . . . . . 219
22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 221 22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 221
22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 221 22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 221
22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 222 22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 222
22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 222 22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 222
22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 223 22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 223
22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 224 22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 224
22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 225 22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 225
skipping to change at page 12, line 7 skipping to change at page 12, line 6
became necessary to enable clarification and consistent behavior. became necessary to enable clarification and consistent behavior.
This document is structured as follows. It begins with an overview This document is structured as follows. It begins with an overview
of the protocol operations and its functions in an informal way. of the protocol operations and its functions in an informal way.
Then a set of definitions of used terms and document conventions is Then a set of definitions of used terms and document conventions is
introduced. It is followed by the actual RTSP 2.0 core protocol introduced. It is followed by the actual RTSP 2.0 core protocol
specification. The appendixes describe and define some specification. The appendixes describe and define some
functionalities that are not part of the core RTSP specification, but functionalities that are not part of the core RTSP specification, but
which are still important to enable some usages. Among them, the RTP which are still important to enable some usages. Among them, the RTP
usage is defined in Appendix C and the SDP usage with RTSP is defined usage is defined in Appendix C and the SDP usage with RTSP is defined
in Appendix D, which are two mandatory appendixes. While others in Appendix D, which are two mandatory appendixes. Others include a
include a number of informational parts discussing the changes, use number of informational parts discussing the changes, use cases,
cases, different considerations or motivations. different considerations or motivations.
2. Protocol Overview 2. Protocol Overview
This section provides an informative overview of the different This section provides an informative overview of the different
mechanisms in the RTSP 2.0 protocol, to give the reader a high level mechanisms in the RTSP 2.0 protocol, to give the reader a high level
understanding before getting into all the different details. In case understanding before getting into all the different details. In case
of conflict with this description and the later sections, the later of conflict with this description and the later sections, the later
sections take precedence. For more information about considered use sections take precedence. For more information about considered use
cases for RTSP see Appendix E. cases for RTSP see Appendix E.
skipping to change at page 15, line 30 skipping to change at page 15, line 30
selected identifier in the Pipelined-Requests header to instruct the selected identifier in the Pipelined-Requests header to instruct the
server to bind multiple requests together as if they included the server to bind multiple requests together as if they included the
session identifier. session identifier.
The SETUP response also provides additional information about the The SETUP response also provides additional information about the
established sessions in a couple of different headers. The Media- established sessions in a couple of different headers. The Media-
Properties header includes a number of properties that apply for the Properties header includes a number of properties that apply for the
aggregate that is valuable when doing media delivery control and aggregate that is valuable when doing media delivery control and
configuring user interface. The Accept-Ranges header informs the configuring user interface. The Accept-Ranges header informs the
client about which range formats that the server supports with these client about which range formats that the server supports with these
media resources. The Media-Range header inform the client about the media resources. The Media-Range header informs the client about the
time range of the media currently available. time range of the media currently available.
2.3. Media Delivery Control 2.3. Media Delivery Control
After having established an RTSP session, the client can start After having established an RTSP session, the client can start
controlling the media delivery. The basic operations are Start by controlling the media delivery. The basic operations are Start by
using the PLAY method (Section 13.4) and Halt by using the PAUSE using the PLAY method (Section 13.4) and Halt by using the PAUSE
method (Section 13.6). PLAY also allows for choosing the starting method (Section 13.6). PLAY also allows for choosing the starting
media position from which the server should deliver the media. The media position from which the server should deliver the media. The
positioning is done by using the Range header (Section 18.38) that positioning is done by using the Range header (Section 18.38) that
skipping to change at page 16, line 10 skipping to change at page 16, line 10
content's media properties. Content exists in a number of different content's media properties. Content exists in a number of different
types, such as: on-demand, live, and live with simultaneous types, such as: on-demand, live, and live with simultaneous
recording. Even within these categories there are differences in how recording. Even within these categories there are differences in how
the content is generated and distributed, which affect how it can be the content is generated and distributed, which affect how it can be
accessed for playback. The properties applicable for the RTSP accessed for playback. The properties applicable for the RTSP
session are provided by the server in the SETUP response using the session are provided by the server in the SETUP response using the
Media-Properties header (Section 18.28). These are expressed using Media-Properties header (Section 18.28). These are expressed using
one or several independent attributes. A first attribute is Random one or several independent attributes. A first attribute is Random
Access, which expresses if positioning can be done, and with what Access, which expresses if positioning can be done, and with what
granularity. Another aspect is whether the content will change granularity. Another aspect is whether the content will change
during the lifetime of the session. While on-demand content will during the lifetime of the session. While on-demand content will be
provided in full from the beginning, a live stream being recorded provided in full from the beginning, a live stream being recorded
results in the length of the accessible content growing as the results in the length of the accessible content growing as the
session goes on. There also exist content that is dynamically built session goes on. There also exists content that is dynamically built
by another protocol than RTSP and thus also changes in steps during by another protocol than RTSP and thus also changes in steps during
the session, but maybe not continuously. Furthermore, when content the session, but maybe not continuously. Furthermore, when content
is recorded, there are cases where not the complete content is is recorded, there are cases where not the complete content is
maintained, but, for example, only the last hour. All these maintained, but, for example, only the last hour. All these
properties result in the need for mechanisms that will be discussed properties result in the need for mechanisms that will be discussed
below. below.
When the client accesses on-demand content that allows random access, When the client accesses on-demand content that allows random access,
the client can issue the PLAY request for any point in the content the client can issue the PLAY request for any point in the content
between the start and the end. The server will deliver media from between the start and the end. The server will deliver media from
skipping to change at page 17, line 23 skipping to change at page 17, line 23
delivery continues the client can access any media within a moving delivery continues the client can access any media within a moving
window that covers, for example, "now" to "now" minus 1 hour. A window that covers, for example, "now" to "now" minus 1 hour. A
client that pauses on a specific point within the content may not be client that pauses on a specific point within the content may not be
able to retrieve the content anymore. If the client waits too long able to retrieve the content anymore. If the client waits too long
before resuming the pause point, the content may no longer be before resuming the pause point, the content may no longer be
available. In this case the pause point will be adjusted to the end available. In this case the pause point will be adjusted to the end
of the available media. of the available media.
2.4. Session Parameter Manipulations 2.4. Session Parameter Manipulations
A session may have additional state or functionality that effects how A session may have additional state or functionality that affects how
the server or client treats the session, content, how it functions, the server or client treats the session, content, how it functions,
or feedback on how well the session works. Such extensions are not or feedback on how well the session works. Such extensions are not
defined in this specification, but may be done in various extensions. defined in this specification, but may be done in various extensions.
RTSP has two methods for retrieving and setting parameter values on RTSP has two methods for retrieving and setting parameter values on
either the client or the server: GET_PARAMETER (Section 13.8) and either the client or the server: GET_PARAMETER (Section 13.8) and
SET_PARAMETER (Section 13.9). These methods carry the parameters in SET_PARAMETER (Section 13.9). These methods carry the parameters in
a message body of the appropriate format. One can also use headers a message body of the appropriate format. One can also use headers
to query state with the GET_PARAMETER method. As an example, clients to query state with the GET_PARAMETER method. As an example, clients
needing to know the current media-range for a time-progressing needing to know the current media-range for a time-progressing
session can use the GET_PARAMETER method and include the media-range. session can use the GET_PARAMETER method and include the media-range.
skipping to change at page 25, line 11 skipping to change at page 25, line 11
video stream as well as a single whiteboard or shared application video stream as well as a single whiteboard or shared application
group. When using RTP, a stream consists of all RTP and RTCP group. When using RTP, a stream consists of all RTP and RTCP
packets created by a source within an RTP session. packets created by a source within an RTP session.
Message: The basic unit of RTSP communication, consisting of a Message: The basic unit of RTSP communication, consisting of a
structured sequence of octets matching the syntax defined in structured sequence of octets matching the syntax defined in
Section 20 and transmitted over a connection or a connectionless Section 20 and transmitted over a connection or a connectionless
transport. A message is either a Request or a Response. transport. A message is either a Request or a Response.
Message Body: The information transferred as the payload of a Message Body: The information transferred as the payload of a
message (Request and response). A message body consists of meta- message (Request or response). A message body consists of meta-
information in the form of message-body headers and content in the information in the form of message-body headers and content in the
form of a message-body, as described in Section 9. form of a message-body, as described in Section 9.
Non-Aggregated Control: Control of a single media stream. Non-Aggregated Control: Control of a single media stream.
Presentation: A set of one or more streams presented to the client Presentation: A set of one or more streams presented to the client
as a complete media feed and described by a presentation as a complete media feed and described by a presentation
description as defined below. Presentations with more than one description as defined below. Presentations with more than one
media stream are often handled in RTSP under aggregate control. media stream are often handled in RTSP under aggregate control.
skipping to change at page 27, line 38 skipping to change at page 27, line 38
lower version than RTSP/2.13, which in turn is lower than RTSP/12.3. lower version than RTSP/2.13, which in turn is lower than RTSP/12.3.
Leading zeros MUST be ignored by recipients and MUST NOT be sent. Leading zeros MUST be ignored by recipients and MUST NOT be sent.
4.2. RTSP IRI and URI 4.2. RTSP IRI and URI
RTSP 2.0 defines and registers three URI schemes "rtsp", "rtsps" and RTSP 2.0 defines and registers three URI schemes "rtsp", "rtsps" and
"rtspu". The usage of the last, "rtspu", is unspecified in RTSP 2.0, "rtspu". The usage of the last, "rtspu", is unspecified in RTSP 2.0,
and is defined here to register and reserve the URI scheme that is and is defined here to register and reserve the URI scheme that is
defined in RTSP 1.0. The "rtspu" scheme indicates unspecified defined in RTSP 1.0. The "rtspu" scheme indicates unspecified
transport of the RTSP messages over unreliable transport (UDP in RTSP transport of the RTSP messages over unreliable transport (UDP in RTSP
1.0). An RTSP server MUST response with an error code indicating the 1.0). An RTSP server MUST respond with an error code indicating the
"rtspu" scheme is not implemented (501) to a request that carries a "rtspu" scheme is not implemented (501) to a request that carries a
"rtspu" URI scheme. The details of the syntax of "rtsp" and "rtsps" "rtspu" URI scheme. The details of the syntax of "rtsp" and "rtsps"
URIs has been changed from RTSP 1.0. URIs has been changed from RTSP 1.0.
This specification also defines the format of the RTSP IRI [RFC3987] This specification also defines the format of the RTSP IRI [RFC3987]
that can be used as RTSP resource identifiers and locators, in web that can be used as RTSP resource identifiers and locators, in web
pages, user interfaces, on paper, etc. However, the RTSP request pages, user interfaces, on paper, etc. However, the RTSP request
message format only allows usage of the absolute URI format. The message format only allows usage of the absolute URI format. The
RTSP IRI format MUST use the rules and transformation for IRIs to RTSP IRI format MUST use the rules and transformation for IRIs to
URIs, as defined in [RFC3987]. This way RTSP 2.0 URIs for request URIs, as defined in [RFC3987]. This way RTSP 2.0 URIs for request
can be produced from an RTSP IRI. can be produced from an RTSP IRI.
The RTSP IRI and URI are both syntax restricted compared to the The RTSP IRI and URI are both syntax restricted compared to the
generic syntax defined in [RFC3986] and [RFC3987]: generic syntax defined in [RFC3986] and [RFC3987]:
o An absolute URI requires the authority part; i.e., a host identity o An absolute URI requires the authority part; i.e., a host identity
must be provided. MUST be provided.
o Parameters in the path element are prefixed with the reserved o Parameters in the path element are prefixed with the reserved
separator ";". separator ";".
The RTSP URI and IRI are case sensitive, with the exception of those The RTSP URI and IRI are case sensitive, with the exception of those
parts that [RFC3986] and [RFC3987] defines as case-insensitive; for parts that [RFC3986] and [RFC3987] define as case-insensitive; for
example, the scheme and host part. example, the scheme and host part.
The fragment identifier is used as defined in sections 3.5 and 4.3 of The fragment identifier is used as defined in sections 3.5 and 4.3 of
[RFC3986], i.e. the fragment is to be stripped from the IRI by the [RFC3986], i.e., the fragment is to be stripped from the IRI by the
requester and not included in the request URI. The user agent needs requester and not included in the request URI. The user agent needs
to interpret the value of the fragment based on the media type the to interpret the value of the fragment based on the media type the
request relates to; i.e., the media type indicated in Content-Type request relates to; i.e., the media type indicated in Content-Type
header in the response to DESCRIBE. header in the response to 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. The query is, from the requester's (usually the server) specific. The query is, from the requester's
perspective, an opaque string and needs to be handled as such. perspective, an opaque string and needs to be handled as such.
Please note that relative URI with queries are difficult to handle Please note that relative URI with queries are difficult to handle
due to the RFC 3986 relative URI handling rules. Any change of the due to the RFC 3986 relative URI handling rules. Any change of the
skipping to change at page 33, line 4 skipping to change at page 33, line 4
Live with Recording: A Live stream that is combined with a server- Live with Recording: A Live stream that is combined with a server-
side capability to store and retain the content of the live side capability to store and retain the content of the live
session, and allow for random access delivery within the part of session, and allow for random access delivery within the part of
the already recorded content. The actual behavior of the media the already recorded content. The actual behavior of the media
stream is very much dependent on the retention policy for the stream is very much dependent on the retention policy for the
media stream; either the server will be able to capture the media stream; either the server will be able to capture the
complete media stream, or it will have a limitation in how much complete media stream, or it will have a limitation in how much
will be retained. The media range will dynamically change as the will be retained. The media range will dynamically change as the
session progress. For servers with a limited amount of storage session progress. For servers with a limited amount of storage
available for recording, there will typically be a sliding window available for recording, there will typically be a sliding window
that moves forwards while new data is made available and older that moves forward while new data is made available and older data
data is discarded. is discarded.
To cover the above usages, the following media properties with To cover the above usages, the following media properties with
appropriate values are specified: appropriate values are specified:
4.9.1. Random Access and Seeking 4.9.1. Random Access and Seeking
Random Access is the ability to specify and get media delivered from Random Access is the ability to specify and get media delivered from
any point inside the content, an operation called seeking. This any point inside the content, an operation called seeking. This
possibility is signaled using the Seek-Style header (see possibility is signaled using the Seek-Style header (see
Section 18.45) which can take the following different values: Section 18.45) which can take the following different values:
skipping to change at page 34, line 17 skipping to change at page 34, line 17
There is also the question of how the content may change during time There is also the question of how the content may change during time
for a given media resource: for a given media resource:
Immutable: The content of the media will not change, even if the Immutable: The content of the media will not change, even if the
representation, i.e., encoding, quality, etc., may change. representation, i.e., encoding, quality, etc., may change.
Dynamic: Between explicit updates the media content will not change, Dynamic: Between explicit updates the media content will not change,
but the content may change due to external methods or triggers, but the content may change due to external methods or triggers,
such as playlists. such as playlists.
Time Progressing: As times progresses new content will become Time Progressing: As time progresses new content will become
available. If the content also is retained it will become longer available. If the content also is retained it will become longer
as everything between the start point and the point currently as everything between the start point and the point currently
being made available can be accessed. If the media server uses a being made available can be accessed. If the media server uses a
sliding window policy for retention, the start point will also sliding window policy for retention, the start point will also
change as time progresses. change as time progresses.
4.9.4. Supported Scale Factors 4.9.4. Supported Scale Factors
Content often supports only a limited set or range of scales when Content often supports only a limited set or range of scales when
delivering the media.. To enable the client to know what values or delivering the media.. To enable the client to know what values or
skipping to change at page 35, line 35 skipping to change at page 35, line 35
5.1. Message Types 5.1. Message Types
RTSP messages consist of requests from client to server, or server to RTSP messages consist of requests from client to server, or server to
client, and responses in the reverse direction. Request (Section 7) client, and responses in the reverse direction. Request (Section 7)
and Response (Section 8) messages use a format based on the generic and Response (Section 8) messages use a format based on the generic
message format of RFC 2822 [RFC2822] for transferring bodies (the message format of RFC 2822 [RFC2822] for transferring bodies (the
payload of the message). Both types of messages consist of a start- payload of the message). Both types of messages consist of a start-
line, zero or more header fields (also known as "headers"), an empty line, zero or more header fields (also known as "headers"), an empty
line (i.e., a line with nothing preceding the CRLF) indicating the line (i.e., a line with nothing preceding the CRLF) indicating the
end of the header, and possibly the data of the message body. end of the headers, and possibly the data of the message body.
generic-message = start-line generic-message = start-line
*(message-header CRLF) *(message-header CRLF)
CRLF CRLF
[ message-body-data ] [ message-body-data ]
start-line = Request-Line | Status-Line start-line = Request-Line | Status-Line
In the interest of robustness, agents MUST ignore any empty line(s) In the interest of robustness, agents MUST ignore any empty line(s)
received where a Request-Line or Response-Line is expected. In other received where a Request-Line or Response-Line is expected. In other
words, if the agent is reading the protocol stream at the beginning words, if the agent is reading the protocol stream at the beginning
of a message and receives a CRLF first, it MUST ignore the CRLF. of a message and receives a CRLF first, it MUST ignore the CRLF.
skipping to change at page 42, line 31 skipping to change at page 42, line 31
| | | | | |
| Terminate-Reason | Section 18.50 | | Terminate-Reason | Section 18.50 |
| | | | | |
| Transport | Section 18.52 | | Transport | Section 18.52 |
| | | | | |
| User-Agent | Section 18.54 | | User-Agent | Section 18.54 |
+--------------------+--------------------+ +--------------------+--------------------+
Table 3: The RTSP request headers Table 3: The RTSP request headers
Detailed header definition are provided in Section 18 Detailed header definitions are provided in Section 18.
New request headers may be defined. If the receiver of the request New request headers may be defined. If the receiver of the request
is required to understand the request header, the request MUST is required to understand the request header, the request MUST
include a corresponding feature tag in a Require or Proxy-Require include a corresponding feature tag in a Require or Proxy-Require
header to ensure the processing of the header. header to ensure the processing of the header.
8. Response 8. Response
After receiving and interpreting a request message, the recipient After receiving and interpreting a request message, the recipient
responds with an RTSP response message. Normally, there is only one, responds with an RTSP response message. Normally, there is only one,
skipping to change at page 46, line 48 skipping to change at page 46, line 48
| | | | | | | |
| 505 | RTSP Version Not Supported | all | | 505 | RTSP Version Not Supported | all |
| | | | | | | |
| 551 | Option Not Support | all | | 551 | Option Not Support | all |
+------+---------------------------------+--------------------------+ +------+---------------------------------+--------------------------+
Table 4: Status codes and their usage with RTSP methods Table 4: Status codes and their usage with RTSP methods
8.2. Response Headers 8.2. Response Headers
The response-header allows the request recipient to pass additional The response-headers allow the request recipient to pass additional
information about the response which cannot be placed in the Status- information about the response which cannot be placed in the Status-
Line. This header gives information about the server and about Line. This header gives information about the server and about
further access to the resource identified by the Request-URI. All further access to the resource identified by the Request-URI. All
headers currently classified as response headers are listed in headers currently classified as response headers are listed in
Table 5. Table 5.
+------------------------+--------------------+ +------------------------+--------------------+
| Header | Defined in Section | | Header | Defined in Section |
+------------------------+--------------------+ +------------------------+--------------------+
| Connection-Credentials | Section 18.12 | | Connection-Credentials | Section 18.12 |
skipping to change at page 48, line 10 skipping to change at page 48, line 10
header MAY be given the semantics of response-header if all parties header MAY be given the semantics of response-header if all parties
in the communication recognize them to be response-header. in the communication recognize them to be response-header.
Unrecognized headers in responses are treated as message-headers and Unrecognized headers in responses are treated as message-headers and
hence MUST be ignored. hence MUST be ignored.
9. Message Body 9. Message Body
Request and Response messages MAY transfer a message body, if not Request and Response messages MAY transfer a message body, if not
otherwise restricted by the request method or response status code. otherwise restricted by the request method or response status code.
The message body consists of the content data itself (see also The message body consists of the content data itself (see also
Section 5.2. Section 5.2).
The SET_PARAMETER and GET_PARAMETER request and response, and The SET_PARAMETER and GET_PARAMETER request and response, and
DESCRIBE response MAY have a message body. All 4xx and 5xx responses DESCRIBE response MAY have a message body. All 4xx and 5xx responses
MAY also have a message body. MAY also have a message body.
In this section, both sender and recipient refer to either the client In this section, both sender and recipient refer to either the client
or the server, depending on who sends and who receives the message or the server, depending on who sends and who receives the message
body. body.
9.1. Message-Body Header Fields 9.1. Message-Body Header Fields
skipping to change at page 55, line 6 skipping to change at page 55, line 6
responder. The requester is capable of determining the RTT of the responder. The requester is capable of determining the RTT of the
request/response cycle using the Timestamp header (Section 18.51) in request/response cycle using the Timestamp header (Section 18.51) in
any RTSP request. any RTSP request.
10 seconds was chosen for the following reasons. It gives TCP 10 seconds was chosen for the following reasons. It gives TCP
time to perform a couple of retransmissions, even if operating on time to perform a couple of retransmissions, even if operating on
default values. It is short enough that users may not abandon the default values. It is short enough that users may not abandon the
process themselves. However, it should be noted that 10 seconds process themselves. However, it should be noted that 10 seconds
can be aggressive on certain type of networks. The 5 seconds can be aggressive on certain type of networks. The 5 seconds
value for 1xx messages is half the timeout giving a reasonable value for 1xx messages is half the timeout giving a reasonable
change of successful delivery before timeout happens on the chance of successful delivery before timeout happens on the
requester side. requester side.
10.5. Showing Liveness 10.5. Showing Liveness
The mechanisms for showing liveness of the client is, any RTSP The mechanisms for showing liveness of the client is, any RTSP
request with a Session header, if RTP & RTCP is used an RTCP message, request with a Session header, if RTP & RTCP is used an RTCP message,
or through any other used media protocol capable of indicating or through any other used media protocol capable of indicating
liveness of the RTSP client. It is RECOMMENDED that a client does liveness of the RTSP client. It is RECOMMENDED that a client does
not wait to the last second of the timeout before trying to send a not wait to the last second of the timeout before trying to send a
liveness message. The RTSP message may be lost or when using liveness message. The RTSP message may be lost or when using
skipping to change at page 55, line 38 skipping to change at page 55, line 38
However, the probability of a false client timeout is so low However, the probability of a false client timeout is so low
that it can be ignored in most cases. For example, assume a that it can be ignored in most cases. For example, assume a
session with 60 seconds timeout and enough bitrate assigned to session with 60 seconds timeout and enough bitrate assigned to
RTCP messages to send a message from client to server on RTCP messages to send a message from client to server on
average every 5 seconds. That client has, for a network with 5 average every 5 seconds. That client has, for a network with 5
% packet loss, the probability to fail showing liveness sign in % packet loss, the probability to fail showing liveness sign in
that session within the timeout interval of 2.4*E-16. Sessions that session within the timeout interval of 2.4*E-16. Sessions
with shorter timeouts, or much higher packet loss, or small with shorter timeouts, or much higher packet loss, or small
RTCP bandwidths SHOULD also use any of the mechanisms below. RTCP bandwidths SHOULD also use any of the mechanisms below.
SET_PARAMETER: When using SET_PARAMETER for keep alive, no body SET_PARAMETER: When using SET_PARAMETER for keep alive, a body
SHOULD be included. This method is the RECOMMENDED RTSP method SHOULD NOT be included. This method is the RECOMMENDED RTSP
to use for a request intended only to perform keep-alive. method to use for a request intended only to perform keep-
alive.
GET_PARAMETER: When using GET_PARAMETER for keep alive, no body GET_PARAMETER: When using GET_PARAMETER for keep alive, no body
SHOULD be included. SHOULD be included.
OPTIONS: This method is also usable, but it causes the server to OPTIONS: This method is also usable, but it causes the server to
perform more unnecessary processing and results in bigger perform more unnecessary processing and results in bigger
responses than necessary for the task. The reason is that the responses than necessary for the task. The reason is that the
server needs to determine the capabilities associated with the server needs to determine the capabilities associated with the
media resource to correctly populate the Public and Allow media resource to correctly populate the Public and Allow
headers. headers.
skipping to change at page 57, line 7 skipping to change at page 57, line 7
workload should result in an increased length of the indicated workload should result in an increased length of the indicated
unavailability. It is RECOMMENDED to not send the same value in the unavailability. It is RECOMMENDED to not send the same value in the
Retry-After header to all requesting proxies and clients, but to add Retry-After header to all requesting proxies and clients, but to add
a variation to the mean value of the Retry-After header. a variation to the mean value of the Retry-After header.
Another issue are load balancing RTSP proxies, i.e., where an RTSP Another issue are load balancing RTSP proxies, i.e., where an RTSP
proxy is used to select amongst a set of RTSP servers to handle the proxy is used to select amongst a set of RTSP servers to handle the
requests, or when multiple server addresses are available for a given requests, or when multiple server addresses are available for a given
server name. The proxy or client may receive a 503 (Service server name. The proxy or client may receive a 503 (Service
Unavailable) from one of its RTSP servers or a TCP timeout (if the Unavailable) from one of its RTSP servers or a TCP timeout (if the
server is even unable to handled the request message). The proxy or server is even unable to handle the request message). The proxy or
client simply retries the other addresses, but may also receive a 503 client simply retries the other addresses, but may also receive a 503
(Service Unavailable) response or TCP timeouts from those addresses. (Service Unavailable) response or TCP timeouts from those addresses.
In such a situation, where none of the RTSP servers/addresses can In such a situation, where none of the RTSP servers/addresses can
handle the request, the RTSP agent has to wait before it can send any handle the request, the RTSP agent has to wait before it can send any
new requests to the RTSP server. Any additional request to a new requests to the RTSP server. Any additional request to a
specific address MUST be delayed according to the Retry-After headers specific address MUST be delayed according to the Retry-After headers
received. For addresses where no response was received or TCP received. For addresses where no response was received or TCP
timeout occurred, an initial wait timer SHOULD be set to 5 seconds. timeout occurred, an initial wait timer SHOULD be set to 5 seconds.
That timer MUST be doubled for each additional failure to connect or That timer MUST be doubled for each additional failure to connect or
receive response. It is RECOMMENDED to not set the same value in the receive response. It is RECOMMENDED to not set the same value in the
skipping to change at page 58, line 50 skipping to change at page 58, line 50
different headers can be used, each explained below: different headers can be used, each explained below:
Supported: This header is used to determine the complete set of Supported: This header is used to determine the complete set of
functionality that both client and server have. The intended functionality that both client and server have. The intended
usage is to determine before one needs to use a functionality usage is to determine before one needs to use a functionality
that it is supported. It can be used in any method, but that it is supported. It can be used in any method, but
OPTIONS is the most suitable one as it at the same time OPTIONS is the most suitable one as it at the same time
determines all methods that are implemented. When sending a determines all methods that are implemented. When sending a
request the requester declares all its capabilities by request the requester declares all its capabilities by
including all supported feature-tags. This results in the including all supported feature-tags. This results in the
receiver learns the requester's feature support. The receiver receiver is learning the requester's feature support. The
then includes its set of features in the response. receiver then includes its set of features in the response.
Proxy-Supported: This header is used similarly to the Supported Proxy-Supported: This header is used similarly to the Supported
header, but instead of giving the supported functionality of header, but instead of giving the supported functionality of
the client or server it provides both the requester and the the client or server it provides both the requester and the
responder a view of what functionality the proxy chain between responder a view of what functionality the proxy chain between
the two supports. Proxies are required to add this header the two supports. Proxies are required to add this header
whenever the Supported header is present, but proxies may also whenever the Supported header is present, but proxies may also
add it independently of the requester. add it independently of the requester.
Require: This header can be included in any request where the end- Require: This header can be included in any request where the end-
skipping to change at page 59, line 36 skipping to change at page 59, line 36
Proxy-Require: This header has the same purpose and workings as Proxy-Require: This header has the same purpose and workings as
Require except that it only applies to proxies and not the end- Require except that it only applies to proxies and not the end-
point. Features that need to be supported by both proxies and point. Features that need to be supported by both proxies and
end-points need to be included in both the Require and Proxy- end-points need to be included in both the Require and Proxy-
Require header. Require header.
Unsupported: This header is used in a 551 error response, to Unsupported: This header is used in a 551 error response, to
indicate which features were not supported. Such a response is indicate which features were not supported. Such a response is
only the result of the usage of the Require and/or Proxy- only the result of the usage of the Require and/or Proxy-
Require header where one or more feature where not supported. Require header where one or more features where not supported.
This information allows the requester to make the best of This information allows the requester to make the best of
situations as it knows which features are not supported. situations as it knows which features are not supported.
12. Pipelining Support 12. Pipelining Support
Pipelining is a general method to improve performance of request Pipelining is a general method to improve performance of request
response protocols by allowing the requesting agent to have more than response protocols by allowing the requesting agent to have more than
one request outstanding and send them over the same persistent one request outstanding and send them over the same persistent
connection. For RTSP, where the relative order of requests will connection. For RTSP, where the relative order of requests will
matter, it is important to maintain the order of the requests. matter, it is important to maintain the order of the requests.
Because of this, the responding agent MUST process the incoming Because of this, the responding agent MUST process the incoming
requests in their sending order. The sending order can be determined requests in their sending order. The sending order can be determined
by the CSeq header and its sequence number. For TCP the delivery by the CSeq header and its sequence number. For TCP the delivery
order will be the same as the sending order. The processing of the order will be the same between two agents, as the sending order. The
request MUST also have been finished before processing the next processing of the request MUST also have been finished before
request from the same agent. The responses MUST be sent in the order processing the next request from the same agent. The responses MUST
the requests were processed. be sent in the order the requests were processed.
RTSP 2.0 has extended support for pipelining compared to RTSP 1.0. RTSP 2.0 has extended support for pipelining compared to RTSP 1.0.
The major improvement is to allow all requests to setup and initiate The major improvement is to allow all requests to setup and initiate
media delivery to be pipelined after each other. This is media delivery to be pipelined after each other. This is
accomplished by the utilization of the Pipelined-Requests header (see accomplished by the utilization of the Pipelined-Requests header (see
Section 18.32). This header allows a client to request that two or Section 18.32). This header allows a client to request that two or
more requests are processed in the same RTSP session context which more requests are processed in the same RTSP session context which
the first request creates. In other words, a client can request that the first request creates. In other words, a client can request that
two or more media streams are set-up and then played without needing two or more media streams are set-up and then played without needing
to wait for a single response. This speeds up the initial startup to wait for a single response. This speeds up the initial startup
skipping to change at page 65, line 22 skipping to change at page 65, line 22
operating environment of the clients. operating environment of the clients.
13.3. SETUP 13.3. SETUP
Note: The states described in this section and the following are Note: The states described in this section and the following are
described in detail in Appendix B. described in detail in Appendix B.
The SETUP request for an URI specifies the transport mechanism to be The SETUP request for an URI specifies the transport mechanism to be
used for the streamed media. The SETUP method may be used in two used for the streamed media. The SETUP method may be used in two
different cases; Create an RTSP session and change the transport different cases; Create an RTSP session and change the transport
parameters of already set up media stream. SETUP can be used in all parameters of already set up media stream(s). SETUP can be used in
three states; Init, and Ready, for both purposes and in PLAY to all three states; Init, and Ready, for both purposes and in PLAY to
change the transport parameters. There is also a third possible change the transport parameters. There is also a third possible
usage for the SETUP method which is not specified in this memo: usage for the SETUP method which is not specified in this memo:
adding a media to a session. Using SETUP to add media to an existing adding a media to a session. Using SETUP to add media to an existing
session, when the session is in Play state, is unspecified. session, when the session is in Play state, is unspecified.
The Transport header, see Section 18.52, specifies the media The Transport header, see Section 18.52, specifies the media
transport parameters acceptable to the client for data transmission; transport parameters acceptable to the client for data transmission;
the response will contain the transport parameters selected by the the response will contain the transport parameters selected by the
server. This allows the client to enumerate in descending order of server. This allows the client to enumerate in descending order of
preference the transport mechanisms and parameters acceptable to it, preference the transport mechanisms and parameters acceptable to it,
skipping to change at page 66, line 10 skipping to change at page 66, line 10
firewalls and other intermediate network devices (which need this firewalls and other intermediate network devices (which need this
information) are spared the more arduous task of parsing the information) are spared the more arduous task of parsing the
DESCRIBE response, which has been reserved for media DESCRIBE response, which has been reserved for media
initialization. initialization.
The client MUST include the Accept-Ranges header in the request The client MUST include the Accept-Ranges header in the request
indicating all supported unit formats in the Range header. This indicating all supported unit formats in the Range header. This
allows the server to know which formats it may use in future session allows the server to know which formats it may use in future session
related responses, such as a PLAY response without any range in the related responses, such as a PLAY response without any range in the
request. If the client does not support a time format necessary for request. If the client does not support a time format necessary for
the presentation the server MUST respond using 456 (Header Field Not the presentation, the server MUST respond using 456 (Header Field Not
Valid for Resource) and include the Accept-Ranges header with the Valid for Resource) and include the Accept-Ranges header with the
range unit formats supported for the resource. range unit formats supported for the resource.
In a SETUP response the server MUST include the Accept-Ranges header In a SETUP response the server MUST include the Accept-Ranges header
(see Section 18.5) to indicate which time formats are acceptable to (see Section 18.5) to indicate which time formats are acceptable to
use for this media resource. use for this media resource.
The SETUP response 200 OK MUST include the Media-Properties header The SETUP response 200 OK MUST include the Media-Properties header
(see Section 18.28 ). The combination of the parameters of the (see Section 18.28 ). The combination of the parameters of the
Media-Properties header indicates the nature of the content present Media-Properties header indicates the nature of the content present
skipping to change at page 67, line 39 skipping to change at page 67, line 39
the address the RTSP setup connection comes from or RTP/AVP the address the RTSP setup connection comes from or RTP/AVP
interleaved on the RTSP control channel. The server selects the RTP/ interleaved on the RTSP control channel. The server selects the RTP/
AVP/UDP transport and adds the address and ports it will send and AVP/UDP transport and adds the address and ports it will send and
receive RTP and RTCP from, and the RTP SSRC that will be used by the receive RTP and RTCP from, and the RTP SSRC that will be used by the
server. server.
The server MUST generate a session identifier in response to a The server MUST generate a session identifier in response to a
successful SETUP request, unless a SETUP request to a server includes successful SETUP request, unless a SETUP request to a server includes
a session identifier or a Pipelined-Requests header referencing an a session identifier or a Pipelined-Requests header referencing an
existing session context, in which case the server MUST bundle this existing session context, in which case the server MUST bundle this
setup request into the existing session (aggregated session) or SETUP request into the existing session (aggregated session) or
return error 459 (Aggregate Operation Not Allowed) (see return error 459 (Aggregate Operation Not Allowed) (see
Section 17.4.24). An Aggregate control URI MUST be used to control Section 17.4.24). An Aggregate control URI MUST be used to control
an aggregated session. This URI MUST be different from the stream an aggregated session. This URI MUST be different from the stream
control URIs of the individual media streams included in the control URIs of the individual media streams included in the
aggregate (see Section 13.4.2 for aggregated sessions and for the aggregate (see Section 13.4.2 for aggregated sessions and for the
particular URIs see Appendix D.1.1). The Aggregate control URI is to particular URIs see Appendix D.1.1). The Aggregate control URI is to
be specified by the session description if the server supports be specified by the session description if the server supports
aggregated control and aggregated control is desired for the session. aggregated control and aggregated control is desired for the session.
However, even if aggregated control is offered the client MAY chose However, even if aggregated control is offered the client MAY chose
to not set up the session in aggregated control. If an Aggregate to not set up the session in aggregated control. If an Aggregate
skipping to change at page 68, line 48 skipping to change at page 68, line 48
13.3.1. Changing Transport Parameters 13.3.1. Changing Transport Parameters
A client MAY issue a SETUP request for a stream that is already set A client MAY issue a SETUP request for a stream that is already set
up or playing in the session to change transport parameters, which a up or playing in the session to change transport parameters, which a
server MAY allow. If it does not allow changing of parameters, it server MAY allow. If it does not allow changing of parameters, it
MUST respond with error 455 (Method Not Valid In This State). The MUST respond with error 455 (Method Not Valid In This State). The
reasons to support changing transport parameters include allowing reasons to support changing transport parameters include allowing
application layer mobility and flexibility to utilize the best application layer mobility and flexibility to utilize the best
available transport as it becomes available. If a client receives a available transport as it becomes available. If a client receives a
455 when trying to change transport parameters while the server is in 455 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, Play state, it MAY try to put the server in Ready state using PAUSE,
before issuing the SETUP request again. If that also fails the before issuing the SETUP request again. If that also fails the
changing of transport parameters will require that the client changing of transport parameters will require that the client
performs a TEARDOWN of the affected media and then to set it up performs a TEARDOWN of the affected media and then to set it up
again. For an aggregated session avoiding tearing down all the media again. For an aggregated session avoiding tearing down all the media
at the same time will avoid the creation of a new session. at the same time will avoid the creation of a new session.
All transport parameters MAY be changed. However, the primary usage All transport parameters MAY be changed. However, the primary usage
expected is to either change the transport protocol completely, like expected is to either change the transport protocol completely, like
switching from Interleaved TCP mode to UDP or vice versa, or to switching from Interleaved TCP mode to UDP or vice versa, or to
change the delivery address. change the delivery address.
In a SETUP response for a request to change the transport parameters In a SETUP response for a request to change the transport parameters
while in Play state, the server MUST include the Range to indicate at while in Play state, the server MUST include the Range to indicate at
what point the new transport parameters will be used. Further, if what point the new transport parameters will be used. Further, if
RTP is used for delivery, the server MUST also include the RTP-Info RTP is used for delivery, the server MUST also include the RTP-Info
header to indicate at what timestamp and RTP sequence number the header to indicate at what timestamp and RTP sequence number the
change will take place. If both RTP-Info and Range are included in change will take place. If both RTP-Info and Range are included in
the response the "rtp_time" parameter and start point in the Range the response the "rtp_time" parameter and start point in the Range
header MUST be for the corresponding time, i.e. be used in the same header MUST be for the corresponding time, i.e., be used in the same
way as for PLAY to ensure the correct synchronization information is way as for PLAY to ensure the correct synchronization information is
available. available.
If the transport parameters change while in Play state results in a If the transport parameters change while in Play state results in a
change of synchronization related information, for example changing change of synchronization related information, for example changing
RTP SSRC, the server MUST provide in the SETUP response the necessary RTP SSRC, the server MUST provide in the SETUP response the necessary
synchronization information. However, the server is RECOMMENDED to synchronization information. However, the server is RECOMMENDED to
avoid changing the synchronization information if possible. avoid changing the synchronization information if possible.
13.4. PLAY 13.4. PLAY
skipping to change at page 70, line 51 skipping to change at page 70, line 51
For media with random access properties a client may express its For media with random access properties a client may express its
preference on which policy for start point selection the server shall preference on which policy for start point selection the server shall
use. This is done by including the Seek-Style header (Section 18.45) use. This is done by including the Seek-Style header (Section 18.45)
in the PLAY request. The Seek-Style applied will effect the content in the PLAY request. The Seek-Style applied will effect the content
of the Range header as it will be adjusted to indicate from what of the Range header as it will be adjusted to indicate from what
point the media actually is delivered. point the media actually is delivered.
A client desiring to play the media from the beginning MUST send a A client desiring to play the media from the beginning MUST send a
PLAY request with a Range header pointing at the beginning, e.g. PLAY request with a Range header pointing at the beginning, e.g.
npt=0-. If a PLAY request is received without a Range header and "npt=0-". If a PLAY request is received without a Range header and
media delivery has stopped at the end, the server SHOULD respond with media delivery has stopped at the end, the server SHOULD respond with
a 457 "Invalid Range" error response. In that response, the current a 457 "Invalid Range" error response. In that response, the current
pause point MUST be included in a Range header. pause point MUST be included in a Range header.
All range specifiers in this specification allow for ranges with an All range specifiers in this specification allow for ranges with an
implicit start point (e.g. "npt=-30"). When used in a PLAY request, implicit start point (e.g. "npt=-30"). When used in a PLAY request,
the server treats this as a request to start or resume delivery from the server treats this as a request to start or resume delivery from
the current pause point, ending at the end time specified in the the current pause point, ending at the end time specified in the
Range header. If the pause point is located later than the given end Range header. If the pause point is located later than the given end
value, a 457 (Invalid Range) response MUST be given. value, a 457 (Invalid Range) response MUST be given.
skipping to change at page 73, line 32 skipping to change at page 73, line 32
After playing the desired range, the presentation does NOT change to After playing the desired range, the presentation does NOT change to
the Ready state, media delivery simply stops. A PAUSE request MUST the Ready state, media delivery simply stops. A PAUSE request MUST
be issued to make the stream enter the Ready state. A PLAY request be issued to make the stream enter the Ready state. A PLAY request
while the stream is still in the Play state is legal, and can be while the stream is still in the Play state is legal, and can be
issued without an intervening PAUSE request. Such a request MUST issued without an intervening PAUSE request. Such a request MUST
replace the current PLAY action with the new one requested, i.e. replace the current PLAY action with the new one requested, i.e.
being handled the same as the request was received in Ready state. being handled the same as the request was received in Ready state.
In the case the range in Range header has an implicit start time In the case the range in Range header has an implicit start time
(-endtime), the server MUST continue to play from where it currently (-endtime), the server MUST continue to play from where it currently
was until the specified end point. This is useful to change end at was until the specified end point. This is useful to change the end
another point than in the previous request. to at another point than in the previous request.
The following example plays the whole presentation starting at SMPTE The following example plays the whole presentation starting at SMPTE
time code 0:10:20 until the end of the clip. Note: The RTP-Info time code 0:10:20 until the end of the clip. Note: The RTP-Info
headers has been broken into several lines, where following lines headers has been broken into several lines, where following lines
start with whitespace as allowed by the syntax. start with whitespace as allowed by the syntax.
C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0
CSeq: 833 CSeq: 833
Session: 12345678 Session: 12345678
Range: smpte=0:10:20- Range: smpte=0:10:20-
skipping to change at page 75, line 25 skipping to change at page 75, line 25
client can halt the media playout using PAUSE and try to establish client can halt the media playout using PAUSE and try to establish
the intended state again before issuing another PLAY request. the intended state again before issuing another PLAY request.
13.4.3. Updating current PLAY Requests 13.4.3. Updating current PLAY Requests
Clients can issue PLAY requests while the stream is in Play state and Clients can issue PLAY requests while the stream is in Play state and
thus updating their request. thus updating their request.
The important difference compared to a PLAY request in Ready state is The important difference compared to a PLAY request in Ready state is
the handling of the current play point and how the Range header in the handling of the current play point and how the Range header in
request is constructed. The session is actively playing media and the request is constructed. The session is actively playing media
the play point will be moving, making the exact time a request will and the play point will be moving, making the exact time a request
take action hard to predict. Depending on how the PLAY header will take action hard to predict. Depending on how the PLAY header
appears two different cases exist: total replacement or continuation. appears two different cases exist: total replacement or continuation.
A total replacement is signaled by having the first range A total replacement is signaled by having the first range
specification have an explicit start value, e.g. npt=45- or specification have an explicit start value, e.g. "npt=45-" or
npt=45-60, in which case the server stops playout at the current "npt=45-60", in which case the server stops playout at the current
playout point and then starts delivering media according to the Range playout point and then starts delivering media according to the Range
header. This is equivalent to having the client first send a PAUSE header. This is equivalent to having the client first send a PAUSE
and then a new PLAY request that isn't based on the pause point. In and then a new PLAY request that isn't based on the pause point. In
the case of continuation the first range specifier has an implicit the case of continuation the first range specifier has an implicit
start point and an explicit stop value (Z), e.g. npt=-60, which start point and an explicit stop value (Z), e.g. "npt=-60", which
indicate that it MUST convert the range specifier being played prior indicate that it MUST convert the range specifier being played prior
to this PLAY request (X to Y) into (X to Z) and continue as this was to this PLAY request (X to Y) into (X to Z) and continue as this was
the request originally played. If the current delivery point is the request originally played. If the current delivery point is
beyond the stop point, the server SHALL immediately pause delivery. beyond the stop point, the server SHALL immediately pause delivery.
As the request has been completed successfully it shall be responded As the request has been completed successfully it shall be responded
with 200 OK. A PLAY_NOTIFY with end-of-stream is also sent to with 200 OK. A PLAY_NOTIFY with end-of-stream is also sent to
indicate the actual stop point. The pause point is set to the indicate the actual stop point. The pause point is set to the
requested stop point. requested stop point.
Following is an example of this behavior: The server has received Following is an example of this behavior: The server has received
requests to play ranges 10 to 15. If the new PLAY request arrives at requests to play ranges 10 to 15. If the new PLAY request arrives at
the server 4 seconds after the previous one, it will take effect the server 4 seconds after the previous one, it will take effect
while the server still plays the first range (10-15). The server while the server still plays the first range (10-15). The server
changes the current play to continue to 25 seconds, i.e. the changes the current play to continue to 25 seconds, i.e. the
equivalent single request would be PLAY with range: npt=10-25. equivalent single request would be PLAY with "range: npt=10-25".
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
Range: npt=10-15 Range: npt=10-15
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 834 CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
skipping to change at page 81, line 9 skipping to change at page 81, line 9
the client can understand the received message body. This is related the client can understand the received message body. This is related
to DESCRIBE (see Section 13.2 ), but in this particular case the to DESCRIBE (see Section 13.2 ), but in this particular case the
client can state its acceptable message bodies by using the Accept client can state its acceptable message bodies by using the Accept
header. In the case of PLAY_NOTIFY, the server does not know which header. In the case of PLAY_NOTIFY, the server does not know which
message bodies are understood by the client. message bodies are understood by the client.
The Notify-Reason header (see Section 18.31) specifies the reason why The Notify-Reason header (see Section 18.31) specifies the reason why
the server sends the PLAY_NOTIFY request. This is extensible and new the server sends the PLAY_NOTIFY request. This is extensible and new
reasons MAY be added in the future (see Section 22.8). In case the reasons MAY be added in the future (see Section 22.8). In case the
client does not understand the reason for the notification it MUST client does not understand the reason for the notification it MUST
respond with an 465 (Notification Reason Unknown) (Section 17.4.30) respond with a 465 (Notification Reason Unknown) (Section 17.4.30)
error code. Servers can send PLAY_NOTIFY with these types: error code. Servers can send PLAY_NOTIFY with these types:
o end-of-stream (see Section 13.5.1); o end-of-stream (see Section 13.5.1);
o media-properties-update (see Section 13.5.2); o media-properties-update (see Section 13.5.2);
o scale-change (see Section 13.5.3). o scale-change (see Section 13.5.3).
13.5.1. End-of-Stream 13.5.1. End-of-Stream
skipping to change at page 81, line 49 skipping to change at page 81, line 49
PLAY_NOTIFY requests with Notify-Reason header set to end-of-stream PLAY_NOTIFY requests with Notify-Reason header set to end-of-stream
MUST include a Range header and the Scale header if the scale value MUST include a Range header and the Scale header if the scale value
is not 1. The Range header indicates the point in the stream or is not 1. The Range header indicates the point in the stream or
streams where delivery is ending with the timescale that was used by streams where delivery is ending with the timescale that was used by
the server in the PLAY response for the request being fulfilled. The the server in the PLAY response for the request being fulfilled. The
server MUST NOT use the "now" constant in the Range header; it MUST server MUST NOT use the "now" constant in the Range header; it MUST
use the actual numeric end position in the proper timescale. When use the actual numeric end position in the proper timescale. When
end-of-stream notifications are issued prior to having sent the last end-of-stream notifications are issued prior to having sent the last
media packets, this is evident as the end time in the Range header is media packets, this is evident as the end time in the Range header is
beyond the current time in the media being received by the client, beyond the current time in the media being received by the client,
e.g., npt=-15, if npt is currently at 14.2 seconds. The Scale header e.g., "npt=-15", if npt is currently at 14.2 seconds. The Scale
is to be included so that it is evident if the media time scale is header is to be included so that it is evident if the media time
moving backwards and/or have a non-default pace. The end-of-stream scale is moving backwards and/or have a non-default pace. The end-
notification does not prevent the client from sending a new PLAY of-stream notification does not prevent the client from sending a new
request. PLAY request.
If RTP is used as media transport, a RTP-Info header MUST be If RTP is used as media transport, a RTP-Info header MUST be
included, and the RTP-Info header MUST indicate the last sequence included, and the RTP-Info header MUST indicate the last sequence
number in the seq parameter. number in the seq parameter.
A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream
MUST NOT carry a message body. MUST NOT carry a message body.
This example request notifies the client about a future end-of-stream This example request notifies the client about a future end-of-stream
event: event:
skipping to change at page 83, line 30 skipping to change at page 83, line 30
Media-Range: npt=0-1:37:21.394 Media-Range: npt=0-1:37:21.394
Range: npt=1:15:49.873- Range: npt=1:15:49.873-
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 854 CSeq: 854
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
13.5.3. Scale-Change 13.5.3. Scale-Change
The server may be forced to change the rate, when a client request The server may be forced to change the rate, when a client requests
delivery using a Scale (Section 18.44) value other than 1.0 (normal delivery using a Scale (Section 18.44) value other than 1.0 (normal
playback rate). For time progressing media with some retention, i.e. playback rate). For time progressing media with some retention, i.e.
the server stores already sent content, a client requesting to play the server stores already sent content, a client requesting to play
with Scale values larger than 1 may catch up with the front end of with Scale values larger than 1 may catch up with the front end of
the media. The server will then be unable to continue to provide the media. The server will then be unable to continue to provide
content at Scale larger than 1 as content is only made available by content at Scale larger than 1 as content is only made available by
the server at Scale=1. Another case is when Scale < 1 and the media the server at Scale=1. Another case is when Scale < 1 and the media
retention is time-duration limited. In this case the delivery point retention is time-duration limited. In this case the delivery point
can reach the oldest media unit available, and further playback at can reach the oldest media unit available, and further playback at
this scale becomes impossible as there will be no media available. this scale becomes impossible as there will be no media available.
skipping to change at page 93, line 12 skipping to change at page 93, line 12
REDIRECT request with a Session header, if and only if, an end-to-end REDIRECT request with a Session header, if and only if, an end-to-end
session has been established. session has been established.
A client may receive a REDIRECT request without a Session header at A client may receive a REDIRECT request without a Session header at
any time when it has communication or a connection established with a any time when it has communication or a connection established with a
server. The scope of such a request is limited to the next-hop (i.e. server. The scope of such a request is limited to the next-hop (i.e.
the RTSP agent in direct communication with the server) and applies the RTSP agent in direct communication with the server) and applies
to all sessions controlled, as well as the control connection between to all sessions controlled, as well as the control connection between
the next-hop RTSP agent and the server. A REDIRECT request without a the next-hop RTSP agent and the server. A REDIRECT request without a
Session header indicates that all sessions and pending requests being Session header indicates that all sessions and pending requests being
managed via the control connection MUST be redirected. The REQUIRED managed via the control connection MUST be redirected. The Location
Location header, if included in such a request, SHOULD contain an header, if included in such a request, SHOULD contain an absolute URI
absolute URI with only the host address and the OPTIONAL port number with only the host address and the OPTIONAL port number of the server
of the server to which the RTSP agent SHOULD reconnect. Any to which the RTSP agent SHOULD reconnect. Any intervening proxies
intervening proxies SHOULD do all of the following in the order SHOULD do all of the following in the order listed:
listed:
1. respond to the REDIRECT request 1. respond to the REDIRECT request
2. disconnect the control channel from the requesting server 2. disconnect the control channel from the requesting server
3. connect to the server at the given host address 3. connect to the server at the given host address
4. pass the REDIRECT request to each applicable client (typically 4. pass the REDIRECT request to each applicable client (typically
those clients with an active session or an unanswered request) those clients with an active session or an unanswered request)
skipping to change at page 93, line 52 skipping to change at page 93, line 51
The exception to this is when the client has several sessions on the The exception to this is when the client has several sessions on the
server being managed by the given signaling connection. In this server being managed by the given signaling connection. In this
case, the client SHOULD close the connection when it has received and case, the client SHOULD close the connection when it has received and
responded to REDIRECT requests for all the sessions managed by the responded to REDIRECT requests for all the sessions managed by the
signaling connection. signaling connection.
The Terminate-Reason header "time" parameter MAY be used to indicate The Terminate-Reason header "time" parameter MAY be used to indicate
the wallclock time by when the redirection MUST have taken place. To the wallclock time by when the redirection MUST have taken place. To
allow a client to determine that redirect time without being time allow a client to determine that redirect time without being time
synchronized with the server, the server MUST include a Date header synchronized with the server, the server MUST include a Date header
in the request. The client should have before the redirection time- in the request. The client should have terminated the session and
line terminated the session and closed the control connection. The closed the control connection before the redirection time-line
server MAY simple cease to provide service when the deadline time has terminated. The server MAY simply cease to provide service when the
been reached, or it may issue TEARDOWN requests to the remaining deadline time has been reached, or it may issue TEARDOWN requests to
sessions. the remaining sessions.
If the REDIRECT request times out following the rules in Section 10.4 If the REDIRECT request times out following the rules in Section 10.4
the server MAY terminate the session or transport connection that the server MAY terminate the session or transport connection that
would be redirected by the request. This is a safeguard against would be redirected by the request. This is a safeguard against
misbehaving clients that refuse to respond to a REDIRECT request. misbehaving clients that refuse to respond to a REDIRECT request.
That should not provide any benefit. That should not provide any benefit.
After a REDIRECT request has been processed, a client that wants to After a REDIRECT request has been processed, a client that wants to
continue to send or receive media for the resource identified by the continue to send or receive media for the resource identified by the
Request-URI will have to establish a new session with the designated Request-URI will have to establish a new session with the designated
skipping to change at page 95, line 41 skipping to change at page 95, line 41
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 18.52). interleaved parameter (Section 18.52).
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 an interval containing a second channel in the indicated by including an interval containing a second channel in the
interleaved parameter of the Transport header, see Section 18.52. If interleaved parameter of the Transport header, see Section 18.52. If
RTCP is used, packets MUST be sent on the first available channel RTCP is used, packets MUST be sent on the first available channel
higher than the RTP channel. The channels are bi-directional, using higher than the RTP channel. The channels are bi-directional, using
the same ChannelD in both directions, and therefore RTCP traffic are the same Channel ID in both directions, and therefore RTCP traffic is
sent on the second channel in both directions. sent on the second channel in both directions.
RTCP is sometimes needed for synchronization when two or more RTCP is sometimes needed for synchronization when two or more
streams are interleaved in such a fashion. Also, this provides a streams are interleaved in such a fashion. Also, this provides a
convenient way to tunnel RTP/RTCP packets through the TCP control convenient way to tunnel RTP/RTCP packets through the TCP control
connection when required by the network configuration and transfer connection when required by the network configuration and transfer
them onto UDP when possible. them onto UDP when possible.
C->S: SETUP rtsp://example.com/bar.file RTSP/2.0 C->S: SETUP rtsp://example.com/bar.file RTSP/2.0
CSeq: 2 CSeq: 2
skipping to change at page 97, line 16 skipping to change at page 97, line 16
RTSP Proxies are RTSP agents that are located in between a client and RTSP Proxies are RTSP agents that are located in between a client and
a server. A proxy can take on both the role as a client and as 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 server depending on what it tries to accomplish. Proxies are also
introduced for several different reasons and the below listed are introduced for several different reasons and the below listed are
often combined. often combined.
In general there are two categories of RTSP proxies, transparent (of In general there are two categories of RTSP proxies, transparent (of
which the client is not aware) and the non-transparent proxies (of which the client is not aware) and the non-transparent proxies (of
which the client is aware). Transparent proxies are not visible to which the client is aware). Transparent proxies are not visible to
the client in terms of that the transport layer connection, e.g., TCP the client in terms of the transport layer connection, e.g., TCP for
for RTSP, as there is only a single transport connection which is RTSP, as there is only a single transport connection which is
terminated at the RTSP client and the RTSP server. In the case of terminated at the RTSP client and the RTSP server. In the case of
non-transparent proxies, there are two transport layer connections, non-transparent proxies, there are two transport layer connections,
one from the RTSP client to the RTSP proxy and a second from the RTSP one from the RTSP client to the RTSP proxy and a second from the RTSP
proxy to the RTSP server. proxy to the RTSP server.
There are these types of RTSP proxies: There are these types of RTSP proxies:
Caching Proxy: This type of proxy is used to reduce the workload on Caching Proxy: This type of proxy is used to reduce the workload on
servers and connections. By caching the description and media servers and connections. By caching the description and media
streams, i.e., the presentation, the proxy can serve a client streams, i.e., the presentation, the proxy can serve a client
skipping to change at page 97, line 44 skipping to change at page 97, line 44
Translator Proxy: This type of proxy is used to ensure that an RTSP Translator Proxy: This type of proxy is used to ensure that an RTSP
client gets access to servers and content on an external client gets access to servers and content on an external
network or using content encodings not supported by the client. network or using content encodings not supported by the client.
The proxy performs the necessary translation of addresses, The proxy performs the necessary translation of addresses,
protocols or encodings. This type of proxy is expected to also protocols or encodings. This type of proxy is expected to also
understand RTSP end-point functionality, i.e. functionality understand RTSP end-point functionality, i.e. functionality
identified in the Require header in addition to what Proxy- identified in the Require header in addition to what Proxy-
Require demands. Require demands.
Access Proxy: This type of proxy is used to ensure that an RTSP Access Proxy: This type of proxy is used to ensure that an RTSP
clients get access to servers on an external network. Thus client gets access to servers on an external network. Thus
this proxy is placed on the border between two domains, e.g. a this proxy is placed on the border between two domains, e.g. a
private address space and the public Internet. The proxy private address space and the public Internet. The proxy
performs the necessary translation, usually addresses. This performs the necessary translation, usually addresses. This
type of proxy is required to redirect the media to itself or a type of proxy is required to redirect the media to itself or a
controlled gateway that performs the translation before the controlled gateway that performs the translation before the
media can reach the client. media can reach the client.
Security Proxy: This type of proxy is used to help facilitate Security Proxy: This type of proxy is used to help facilitate
security functions around RTSP. For example when having a security functions around RTSP. For example when having a
firewalled network, the security proxy request that the firewalled network, the security proxy requests that the
necessary pinholes in the firewall are opened when a client in necessary pinholes in the firewall are opened when a client in
the protected network wants to access media streams on the the protected network wants to access media streams on the
external side. This proxy can also limit the clients access to external side. This proxy can also limit the client's access
certain types of content. This proxy can perform its function to certain types of content. This proxy can perform its
without redirecting the media between the server and client. function without redirecting the media between the server and
However, in deployments with private address spaces this proxy client. However, in deployments with private address spaces
is likely to be combined with the access proxy. Anyway, the this proxy is likely to be combined with the access proxy.
functionality of this proxy is usually closely tied into Anyway, the functionality of this proxy is usually closely tied
understanding all aspects of the media transport. into understanding all aspects of the media transport.
Auditing Proxy: RTSP proxies can also provide network owners with a Auditing Proxy: RTSP proxies can also provide network owners with a
logging and audit point for RTSP sessions, e.g. for logging and audit point for RTSP sessions, e.g. for
corporations that track their employees usage of the network. corporations that track their employees usage of the network.
This type of proxy can perform its function without inserting This type of proxy can perform its function without inserting
itself or any other node in the media transport. This proxy itself or any other node in the media transport. This proxy
type can also accept unknown methods as it doesn't interfere type can also accept unknown methods as it doesn't interfere
with the clients' requests. with the clients' requests.
All types of proxies can be used also when using secured All types of proxies can be used also when using secured
communication with TLS as RTSP 2.0 allows the client to approve communication with TLS as RTSP 2.0 allows the client to approve
certificate chains used for connection establishment from a proxy, certificate chains used for connection establishment from a proxy,
see Section 19.3.2. However, that trust model may not be suitable see Section 19.3.2. However, that trust model may not be suitable
for all types of deployment. In those cases, the secured sessions do for all types of deployment. In those cases, the secured sessions do
by-pass of the proxies. by-pass the proxies.
Access proxies SHOULD NOT be used in equipment like NATs and Access proxies SHOULD NOT be used in equipment like NATs and
firewalls that aren't expected to be regularly maintained, like home firewalls that aren't expected to be regularly maintained, like home
or small office equipment. In these cases it is better to use the or small office equipment. In these cases it is better to use the
NAT traversal procedures defined for RTSP 2.0 NAT traversal procedures defined for RTSP 2.0
[I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is [I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is
that any extensions of RTSP resulting in new media transport that any extensions of RTSP resulting in new media transport
protocols or profiles, new parameters, etc. may fail in a proxy that protocols or profiles, new parameters, etc. may fail in a proxy that
isn't maintained. This would impede RTSP's future development and isn't maintained. This would impede RTSP's future development and
usage. usage.
skipping to change at page 99, line 15 skipping to change at page 99, line 15
understood. The transport header and its parameters also shows that understood. The transport header and its parameters also shows that
headers that are extensible and require correct interpretation in the headers that are extensible and require correct interpretation in the
proxy also require handling rules. proxy also require handling rules.
Whether a proxy needs to understand a header is not easy to Whether a proxy needs to understand a header is not easy to
determine, as they serve a broad variety of functions. When determine, as they serve a broad variety of functions. When
evaluating if a header needs to be understood, one can divide the evaluating if a header needs to be understood, one can divide the
functionality into three main categories: functionality into three main categories:
Media modifying: The caching and translator proxies are modifying Media modifying: The caching and translator proxies are modifying
the actual media and therefore needs to understand also request the actual media and therefore need to understand also the request
directed to the server that affects how the media is rendered. directed to the server that affects how the media is rendered.
Thus, this type of proxy needs to also understand the server side Thus, this type of proxy needs to also understand the server side
functionality. functionality.
Transport modifying: The access and the security proxy both need to Transport modifying: The access and the security proxy both need to
understand how the transport is performed, either for opening understand how the transport is performed, either for opening
pinholes or to translate the outer headers, e.g. IP and UDP. pinholes or to translate the outer headers, e.g., IP and UDP.
Non-modifying: The audit proxy is special in that it does not modify Non-modifying: The audit proxy is special in that it does not modify
the messages in other ways than to insert the Via header. That the messages in other ways than to insert the Via header. That
makes it possible for this type to forward RTSP messages that makes it possible for this type to forward RTSP messages that
contain different types of unknown methods, headers or header contain different types of unknown methods, headers or header
parameters. parameters.
Based on the above classification, one should evaluate if the new Based on the above classification, one should evaluate if the new
functionality requires the Transport modifying type of proxies to functionality requires the Transport modifying type of proxies to
understand it or not. understand it or not.
skipping to change at page 100, line 38 skipping to change at page 100, line 38
DESCRIBE requests if it is currently serving the stream to the DESCRIBE requests if it is currently serving the stream to the
requester, as it is possible that low-level details of the stream requester, as it is possible that low-level details of the stream
description may have changed on the origin-server. description may have changed on the origin-server.
Note that an RTSP cache, is of the "cut-through" variety. Rather Note that an RTSP cache, is of the "cut-through" variety. Rather
than retrieving the whole resource from the origin server, the cache than retrieving the whole resource from the origin server, the cache
simply copies the streaming data as it passes by on its way to the simply copies the streaming data as it passes by on its way to the
client. Thus, it does not introduce additional latency. client. Thus, it does not introduce additional latency.
To the client, an RTSP proxy cache appears like a regular media To the client, an RTSP proxy cache appears like a regular media
server, to the media origin server like a client. Just as an HTTP server. To the media origin server an RTSP proxy cache appears like
cache has to store the content type, content language, and so on for a client. Just as an HTTP cache has to store the content type,
the objects it caches, a media cache has to store the presentation content language, and so on for the objects it caches, a media cache
description. Typically, a cache eliminates all transport-references has to store the presentation description. Typically, a cache
(e.g., multicast information) from the presentation description, eliminates all transport-references (e.g., multicast information)
since these are independent of the data delivery from the cache to from the presentation description, since these are independent of the
the client. Information on the encodings remains the same. If the data delivery from the cache to the client. Information on the
cache is able to translate the cached media data, it would create a encodings remains the same. If the cache is able to translate the
new presentation description with all the encoding possibilities it cached media data, it would create a new presentation description
can offer. with all the encoding possibilities it can offer.
16.1. Validation Model 16.1. Validation Model
When a cache has a stale entry that it would like to use as a When a cache has a stale entry that it would like to use as a
response to a client's request, it first has to check with the origin response to a client's request, it first has to check with the origin
server (or possibly an intermediate cache with a fresh response) to server (or possibly an intermediate cache with a fresh response) to
see if its cached entry is still usable. We call this "validating" see if its cached entry is still usable. We call this "validating"
the cache entry. Since we do not want to have to pay the overhead of the cache entry. Since we do not want to have to pay the overhead of
retransmitting the full response if the cached entry is good, and we retransmitting the full response if the cached entry is good, and we
do not want to pay the overhead of an extra round trip if the cached do not want to pay the overhead of an extra round trip if the cached
skipping to change at page 109, line 15 skipping to change at page 109, line 15
the session, and MAY reestablish the session using the resource the session, and MAY reestablish the session using the resource
indicated by the Location. indicated by the Location.
If the Location header is used in a response it MUST contain an If the Location header is used in a response it MUST contain an
absolute URI pointing out the media resource the client is redirected absolute URI pointing out the media resource the client is redirected
to, the URI MUST NOT only contain the host name. to, the URI MUST NOT only contain the host name.
17.3.1. 301 Moved Permanently 17.3.1. 301 Moved Permanently
The requested resource is moved permanently and resides now at the The requested resource is moved permanently and resides now at the
URI given by the location header. The user client SHOULD redirect URI 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. The Location header MUST be included in the response. message-body. The Location header MUST be included in the response.
17.3.2. 302 Found 17.3.2. 302 Found
The requested resource resides temporarily at the URI given by the The requested resource resides 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. This response is intended to be used for many types of response. This response is intended to be used for many types of
temporary redirects; e.g., load balancing. It is RECOMMENDED that temporary redirects; e.g., load balancing. It is RECOMMENDED that
the server set the reason phrase to something more meaningful than the server set the reason phrase to something more meaningful than
skipping to change at page 109, line 45 skipping to change at page 109, line 45
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 302 Try Other Server S->C: RTSP/2.0 302 Try Other Server
CSeq: 2 CSeq: 2
Location: rtsp://s2.example.com:8001/fizzle/foo Location: rtsp://s2.example.com:8001/fizzle/foo
17.3.3. 303 See Other 17.3.3. 303 See Other
This status code MUST NOT be used in RTSP 2.0. However, it was This status code MUST NOT be used in RTSP 2.0. However, it was
allowed to use in RTSP 1.0 (RFC 2326). allowed in RTSP 1.0 [RFC 2326].
17.3.4. 304 Not Modified 17.3.4. 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
Section 18.24) and the requested resource has not been modified, the Section 18.24) and the requested resource has not been modified, the
server SHOULD send a 304 response. This response MUST NOT contain a server 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 114, line 7 skipping to change at page 114, line 7
17.4.16. 451 Parameter Not Understood 17.4.16. 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 message body containing the offending sender SHOULD return a message body containing the offending
parameter(s). parameter(s).
17.4.17. 452 reserved 17.4.17. 452 reserved
This error code was removed from RFC 2326 [RFC2326] as it is This status code MUST NOT be used in RTSP 2.0. However, it was
obsolete. This error code MUST NOT be used anymore. allowed in RTSP 1.0 [RFC 2326].
17.4.18. 453 Not Enough Bandwidth 17.4.18. 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.
17.4.19. 454 Session Not Found 17.4.19. 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 133, line 7 skipping to change at page 133, line 7
bandwidth, for example due to that first hop is not a bottleneck. bandwidth, for example due to that first hop is not a bottleneck.
For example most local area networks (LAN) will not be a bottleneck For example most local area networks (LAN) will not be a bottleneck
if the server is not in the same LAN. Thus link speeds of WLAN or if the server is not in the same LAN. Thus link speeds of WLAN or
Ethernet networks are normally not a basis for estimating the Ethernet networks are normally not a basis for estimating the
available bandwidth. Cellular devices or other devices directly available bandwidth. Cellular devices or other devices directly
connected to a modem or connection enabling device may more connected to a modem or connection enabling device may more
accurately estimate the bottleneck bandwidth and what is reasonable accurately estimate the bottleneck bandwidth and what is reasonable
share of it for RTSP controlled media. The client will also need to share of it for RTSP controlled media. The client will also need to
take into account other traffic sharing the bottleneck. For example take into account other traffic sharing the bottleneck. For example
by only assigning a certain fraction to RTSP and its media streams. by only assigning a certain fraction to RTSP and its media streams.
It is RECOMMENDED that only clients that has accurate and explicit It is RECOMMENDED that only clients that have accurate and explicit
information about bandwidth bottlenecks uses this header. information about bandwidth bottlenecks uses this header.
This header is not a substitute for proper congestion control. Only This header is not a substitute for proper congestion control. It is
a method providing an initial estimate and coarsely determine if the only a method providing an initial estimate and coarsely determines
selected content can be delivered at all. if the selected content can be delivered at all.
Example: Example:
Bandwidth: 62360 Bandwidth: 62360
18.9. Blocksize 18.9. Blocksize
The Blocksize request-header field is sent from the client to the The Blocksize request-header field is sent from the client to the
media server asking the server for a particular media packet size. media server asking the server for a particular media packet size.
This packet size does not include lower-layer headers such as IP, This packet size does not include lower-layer headers such as IP,
UDP, or RTP. The server is free to use a blocksize which is lower UDP, or RTP. The server is free to use a blocksize which is lower
skipping to change at page 142, line 4 skipping to change at page 142, line 4
available. An origin server without a clock MUST NOT assign available. An origin server without a clock MUST NOT assign
Expires or Last-Modified values to a response, unless these values Expires or Last-Modified values to a response, unless these values
were associated with the resource by a system or user with a were associated with the resource by a system or user with a
reliable clock. It MAY assign an Expires value that is known, at reliable clock. It MAY assign an Expires value that is known, at
or before server configuration time, to be in the past (this or before server configuration time, to be in the past (this
allows "pre-expiration" of responses without storing separate allows "pre-expiration" of responses without storing separate
Expires values for each resource). Expires values for each resource).
A received message that does not have a Date header field MUST be A received message that does not have a Date header field MUST be
assigned one by the recipient if the message will be cached by that assigned one by the recipient if the message will be cached by that
recipient . An RTSP implementation without a clock MUST NOT cache recipient. An RTSP implementation without a clock MUST NOT cache
responses without revalidating them on every use. An RTSP cache, responses without revalidating them on every use. An RTSP cache,
especially a shared cache, SHOULD use a mechanism, such as NTP, to especially a shared cache, SHOULD use a mechanism, such as NTP, to
synchronize its clock with a reliable external standard. synchronize its clock with a reliable external standard.
The RTSP-date sent in a Date header SHOULD NOT represent a date and The RTSP-date sent in a Date header SHOULD NOT represent a date and
time subsequent to the generation of the message. It SHOULD time subsequent to the generation of the message. It SHOULD
represent the best available approximation of the date and time of represent the best available approximation of the date and time of
message generation, unless the implementation has no means of message generation, unless the implementation has no means of
generating a reasonably accurate date and time. In theory, the date generating a reasonably accurate date and time. In theory, the date
ought to represent the moment just before the message body is ought to represent the moment just before the message body is
skipping to change at page 143, line 48 skipping to change at page 143, line 48
the integrity of the presentation description, independent of how the the integrity of the presentation description, independent of how the
presentation description was received. The presentation description presentation description was received. The presentation description
can be fetched via means external to RTSP (such as HTTP) or via the can be fetched via means external to RTSP (such as HTTP) or via the
DESCRIBE message. In the case of retrieving the presentation DESCRIBE message. In the case of retrieving the presentation
description via RTSP, the server implementation is guaranteeing the description via RTSP, the server implementation is guaranteeing the
integrity of the description between the time of the DESCRIBE message integrity of the description between the time of the DESCRIBE message
and the SETUP message. By including the MTag given in or with the and the SETUP message. By including the MTag given in or with the
session description in an If-Match header part of the SETUP request, session description in an If-Match header part of the SETUP request,
the client ensures that resources set up are matching the the client ensures that resources set up are matching the
description. A SETUP request with the If-Match header for which the description. A SETUP request with the If-Match header for which the
MTag validation check fails, MUST response using 412 (Precondition MTag validation check fails, MUST generate a response using 412
Failed). (Precondition Failed).
This validation check is also very useful if a session has been This validation check is also very useful if a session has been
redirected from one server to another. redirected from one server to another.
18.24. If-Modified-Since 18.24. If-Modified-Since
The If-Modified-Since request-header field is used with the DESCRIBE The If-Modified-Since request-header field is used with the DESCRIBE
and SETUP methods to make them conditional. If the requested variant and SETUP methods to make them conditional. If the requested variant
has not been modified since the time specified in this field, a has not been modified since the time specified in this field, a
description will not be returned from the server (DESCRIBE) or a description will not be returned from the server (DESCRIBE) or a
skipping to change at page 150, line 19 skipping to change at page 150, line 19
The RTSP agent sending the request with a Pipelined-Requests header The RTSP agent sending the request with a Pipelined-Requests header
has the responsibility for using a unique and previously unused has the responsibility for using a unique and previously unused
identifier within the transport context. Currently only a TCP identifier within the transport context. Currently only a TCP
connection is defined as such transport context. A server MUST connection is defined as such transport context. A server MUST
delete the Pipelined-Requests identifier and its binding to a session delete the Pipelined-Requests identifier and its binding to a session
upon the termination of that session. Despite the previous mandate, upon the termination of that session. Despite the previous mandate,
RTSP agents are RECOMMENDED to not reuse identifiers to allow for RTSP agents are RECOMMENDED to not reuse identifiers to allow for
better error handling and logging. better error handling and logging.
RTSP Proxies may need to translate Pipelined-Requests identifier RTSP Proxies may need to translate Pipelined-Requests identifier
values from incoming request to outgoing to allow for aggregation of values from incoming requests to outgoing to allow for aggregation of
requests onto a persistent connection. requests onto a persistent connection.
18.33. Proxy-Authenticate 18.33. Proxy-Authenticate
The Proxy-Authenticate response-header field MUST be included as part The Proxy-Authenticate response-header field MUST be included as part
of a 407 (Proxy Authentication Required) response. The field value of a 407 (Proxy Authentication Required) response. The field value
consists of a challenge that indicates the authentication scheme and consists of a challenge that indicates the authentication scheme and
parameters applicable to the proxy for this Request-URI. parameters applicable to the proxy for this Request-URI.
The HTTP access authentication process is described in [RFC2617]. The HTTP access authentication process is described in [RFC2617].
skipping to change at page 155, line 41 skipping to change at page 155, line 41
header carries a reference to the request it reports on using the header carries a reference to the request it reports on using the
CSeq number for the session indicated by the Session header in the CSeq number for the session indicated by the Session header in the
request. It provides both a numerical status code (according to request. It provides both a numerical status code (according to
Section 8.1.1) and a human readable reason phrase. Section 8.1.1) and a human readable reason phrase.
Example: Example:
Request-Status: cseq=63 status=500 reason="Media data unavailable" Request-Status: cseq=63 status=500 reason="Media data unavailable"
18.41. Require 18.41. Require
The Require request-header field is used by clients or servers to The Require request-header field is used by clients to ensure that
ensure that the other end-point supports features that are required the other end-point supports features that are required in respect to
in respect to this request. It can also be used to query if the this request. It can also be used to query if the other end-point
other end-point supports certain features, however, the use of the supports certain features, however, the use of the Supported
Supported (Section 18.49) is much more effective in this purpose. (Section 18.49) is much more effective in this purpose. The server
The server MUST respond to this header by using the Unsupported MUST respond to this header by using the Unsupported header to
header to negatively acknowledge those feature-tags which are NOT negatively acknowledge those feature-tags which are NOT supported.
supported. The response MUST use the error code 551 (Option Not The response MUST use the error code 551 (Option Not Supported).
Supported). This header does not apply to proxies, for the same This header does not apply to proxies, for the same functionality in
functionality in respect to proxies see Proxy-Require header respect to proxies see Proxy-Require header (Section 18.35) with the
(Section 18.35) with the exception of media modifying proxies. Media exception of media modifying proxies. Media modifying proxies, due
modifying proxies, due to their nature of handling media in a way to their nature of handling media in a way that is very similar to a
that is very similar to a server, do need to understand also the server, do need to understand also the server features to correctly
server features to correctly serve the client. serve the client.
This is to make sure that the client-server interaction will This is to make sure that the client-server interaction will
proceed without delay when all features are understood by both proceed without delay when all features are understood by both
sides, and only slow down if features are not understood (as in sides, and only slow down if features are not understood (as in
the example below). For a well-matched client-server pair, the the example below). For a well-matched client-server pair, the
interaction proceeds quickly, saving a round-trip often required interaction proceeds quickly, saving a round-trip often required
by negotiation mechanisms. In addition, it also removes state by negotiation mechanisms. In addition, it also removes state
ambiguity when the client requires features that the server does ambiguity when the client requires features that the server does
not understand. not understand.
skipping to change at page 159, line 52 skipping to change at page 159, line 52
close to the nominal bit-rate of the content for Scale = 1. The close to the nominal bit-rate of the content for Scale = 1. The
server has to actively manipulate the data when needed to meet the server has to actively manipulate the data when needed to meet the
bitrate constraints. Implementation of scale changes depends on the bitrate constraints. Implementation of scale changes depends on the
server and media type. For video, a server may, for example, deliver server and media type. For video, a server may, for example, deliver
only key frames or selected frames. For audio, it may time-scale the only key frames or selected frames. For audio, it may time-scale the
audio while preserving pitch or, less desirably, deliver fragments of audio while preserving pitch or, less desirably, deliver fragments of
audio, or completely mute the audio. audio, or completely mute the audio.
The server and content may restrict the range of scale values that it The server and content may restrict the range of scale values that it
supports. The supported values are indicated by the Media-Properties supports. The supported values are indicated by the Media-Properties
header (Section 18.28). The client SHOULD only indicate values header (Section 18.28). The client SHOULD only indicate request
indicated to be supported. However, as the values may change as the values to be supported. However, as the values may change as the
content progresses a requested value may no longer be valid when the content progresses a requested value may no longer be valid when the
request arrives. Thus, a non-supported value in a request does not request arrives. Thus, a non-supported value in a request does not
generate an error, only forces the server to choose the closest generate an error, only forces the server to choose the closest
value. The response MUST always contain the actual scale value value. The response MUST always contain the actual scale value
chosen by the server. chosen by the server.
If the server does not implement the possibility to scale, it will If the server does not implement the possibility to scale, it will
not return a Scale header. A server supporting Scale operations for not return a Scale header. A server supporting Scale operations for
PLAY MUST indicate this with the use of the "play.scale" feature-tag. PLAY MUST indicate this with the use of the "play.scale" feature-tag.
skipping to change at page 166, line 38 skipping to change at page 166, line 38
The Transport header MAY also be used in subsequent SETUP requests to The Transport header MAY also be used in subsequent SETUP requests to
change transport parameters. A server MAY refuse to change change transport parameters. A server MAY refuse to change
parameters of an existing stream. parameters of an existing stream.
A transport specification may only contain one of any given parameter A transport specification may only contain one of any given parameter
within it. Parameters MAY be given in any order. Additionally, it within it. Parameters MAY be given in any order. Additionally, it
may only contain either of the unicast or the multicast transport may only contain either of the unicast or the multicast transport
type parameter. All parameters need to be understood in a transport type parameter. All parameters need to be understood in a transport
specification, if not, the transport specification MUST be ignored. specification, if not, the transport specification MUST be ignored.
RTSP proxies of any type that uses or modifies the transport An RTSP proxy of any type that uses or modifies the transport
specification, e.g. access proxy or security proxy, MUST remove specification, e.g. access proxy or security proxy, MUST remove
specifications with unknown parameters before forwarding the RTSP specifications with unknown parameters before forwarding the RTSP
message. If that result in no remaining transport specification the message. If that results in no remaining transport specification the
proxy SHALL send a 461 (Unsupported Transport) (Section 17.4.26) proxy SHALL send a 461 (Unsupported Transport) (Section 17.4.26)
response without any Transport header. response without any Transport header.
The Transport header is restricted to describing a single media The Transport header is restricted to describing a single media
stream. (RTSP can also control multiple streams as a single stream. (RTSP can also control multiple streams as a single
entity.) Making it part of RTSP rather than relying on a entity.) Making it part of RTSP rather than relying on a
multitude of session description formats greatly simplifies multitude of session description formats greatly simplifies
designs of firewalls. designs of firewalls.
The general syntax for the transport specifier is a list of slash The general syntax for the transport specifier is a list of slash
skipping to change at page 167, line 32 skipping to change at page 167, line 32
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 some cases the only allowed delivered depends on the use case. In some cases the only allowed
method will be to use no explicit address indication and have the method will be to use no explicit address indication and have the
server deliver media to the source of the RTSP messages. server deliver media to the source of the RTSP messages.
For Multicast there is several methods for specifying addresses but For Multicast there is several methods for specifying addresses but
they are different in how they work compared with unicast: they are different in how they work compared with unicast:
dest_addr with client picked address: The address and relevant dest_addr with client picked address: The address and relevant
parameters like TTL (scope) for the actual multicast group to parameters, like TTL (scope), for the actual multicast group to
deliver the media to. There are security implications deliver the media to. There are security implications
(Section 21) with this method that needs to be addressed if (Section 21) with this method that need to be addressed if
using this method because a RTSP server can be used as a DoS using this method because a RTSP server can be used as a DoS
attacker on an existing multicast group. attacker on an existing multicast group.
dest_addr using Session Description Information: The information dest_addr using Session Description Information: The information
included in the transport header can all be coming from the included in the transport header can all be coming from the
session description, e.g. the SDP c= and m= line. This session description, e.g. the SDP c= and m= line. This
mitigates some of the security issues of the previous methods mitigates some of the security issues of the previous methods
as it is the session provider that picks the multicast group as it is the session provider that picks the multicast group
and scope. The client MUST include the information if it is and scope. The client MUST include the information if it is
available in the session description. available in the session description.
skipping to change at page 169, line 22 skipping to change at page 169, line 22
This parameter MUST be specified by the server if it transmits This parameter MUST be specified by the server if it transmits
media packets from another address than the one RTSP messages media packets from another address than the one RTSP messages
are sent to. This will allow the client to verify source are sent to. This will allow the client to verify source
address and give it a destination address for its RTCP feedback address and give it a destination address for its RTCP feedback
packets, if RTP is used. The address or addresses indicated in packets, if RTP is used. The address or addresses indicated in
the src_addr parameter SHOULD be used both for sending and the src_addr parameter SHOULD be used both for sending and
receiving of the media streams data packets. The main reasons receiving of the media streams data packets. The main reasons
are threefold: First, indicating the port and source address(s) are threefold: First, indicating the port and source address(s)
lets the receiver know where from the packets is expected to lets the receiver know where from the packets is expected to
originate. Secondly, traversal of NATs is greatly simplified originate. Secondly, traversal of NATs is greatly simplified
when traffic is flowing symmetrically over an NAT binding. when 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" from which address and port to send so called "binding packets" from
the receiver to the sender, thus creating an address binding in the receiver to the sender, thus creating an address binding in
the NAT that the sender to receiver packet flow can use. the NAT that the sender to receiver packet flow can use.
This information may also be available through SDP. This information may also be available through SDP.
However, since this is more a feature of transport than However, since this is more a feature of transport than
media initialization, the authoritative source for this media initialization, the authoritative source for this
information should be in the SETUP response. information should be in the SETUP response.
skipping to change at page 169, line 44 skipping to change at page 169, line 44
this session. Currently defined valid values are "PLAY". If this session. Currently defined valid values are "PLAY". If
not provided, the default is "PLAY". The "RECORD" value was not provided, the default is "PLAY". The "RECORD" value was
defined in RFC 2326 and is in this specification unspecified defined in RFC 2326 and is in this specification unspecified
but reserved. RECORD and other values may be specified in the but reserved. RECORD and other values may be specified in the
future. future.
interleaved: The interleaved parameter implies mixing the media interleaved: The interleaved parameter implies mixing the media
stream with the control stream in whatever protocol is being stream with the control stream in whatever protocol is being
used by the control stream, using the mechanism defined in used by the control stream, using the mechanism defined in
Section 14. The argument provides the channel number to be Section 14. The argument provides the channel number to be
used in the $ block Section 14 and MUST be present. This used in the $ block (see Section 14) and MUST be present. This
parameter MAY be specified as a interval, e.g., interleaved=4-5 parameter MAY be specified as an interval, e.g.,
in cases where the transport choice for the media stream interleaved=4-5 in cases where the transport choice for the
requires it, e.g., for RTP with RTCP. The channel number given media stream requires it, e.g., for RTP with RTCP. The channel
in the request is only a guidance from the client to the server number given in the request is only a guidance from the client
on what channel number(s) to use. The server MAY set any valid to the server on what channel number(s) to use. The server MAY
channel number in the response. The declared channel(s) are set any valid channel number in the response. The declared
bi-directional, so both end-parties MAY send data on the given channel(s) are bi-directional, so both end-parties MAY send
channel. One example of such usage is the second channel used data on the given channel. One example of such usage is the
for RTCP, where both server and client send RTCP packets on the second channel used for RTCP, where both server and client send
same channel. RTCP packets on the same channel.
This allows RTP/RTCP to be handled similarly to the way This allows RTP/RTCP to be handled similarly to the way
that it is done with UDP, i.e., one channel for RTP and that it is done with UDP, i.e., one channel for RTP and
the other for RTCP. the other for RTCP.
MIKEY: This parameter is used in conjunction with transport MIKEY: This parameter is used in conjunction with transport
specifications that can utilize MIKEY [RFC3830] for security specifications that can utilize MIKEY [RFC3830] for security
context establishment. So far only the SRTP based RTP profiles context establishment. So far only the SRTP based RTP profiles
SAVP and SAVPF can utilize MIKEY and this is defined in SAVP and SAVPF can utilize MIKEY and this is defined in
Appendix C.1.4.1. This parameter can be included both in Appendix C.1.4.1. This parameter can be included both in
request and response messages. The binary MIKEY message SHALL request and response messages. The binary MIKEY message SHALL
be BASE64 [RFC4648] encoded before being included in the value be BASE64 [RFC4648] encoded before being included in the value
part of the parameter. part of the parameter.
Multicast-specific: Multicast-specific:
ttl: multicast time-to-live for IPv4. When included in requests the ttl: multicast time-to-live for IPv4. When included in requests the
value indicate the TTL value that the client request the server value indicate the TTL value that the client requests the
to use. In a response, the value actually being used by the server to use. In a response, the value actually being used by
server is returned. A server will need to consider what values the server is returned. A server will need to consider what
that are reasonable and also the authority of the user to set values that are reasonable and also the authority of the user
this value. Corresponding functions are not needed for IPv6 as to set this value. Corresponding functions are not needed for
the scoping is part of the IPv6 multicast address [RFC4291]. IPv6 as the scoping is part of the IPv6 multicast address
[RFC4291].
RTP-specific: RTP-specific:
These parameters MAY only be used if the media transport protocol is These parameters MAY only be used if the media transport protocol is
RTP. RTP.
ssrc: The ssrc parameter, if included in a SETUP response, indicates ssrc: The ssrc parameter, if included in a SETUP response, indicates
the RTP SSRC [RFC3550] value(s) that will be used by the media the RTP SSRC [RFC3550] value(s) that will be used by the media
server for RTP packets within the stream. It is expressed as server for RTP packets within the stream. It is expressed as
an eight digit hexadecimal value. an eight digit hexadecimal value.
skipping to change at page 171, line 8 skipping to change at page 171, line 8
request is deprecated as it is incompatible with the request is deprecated as it is incompatible with the
specification of RTP in RFC 3550[RFC3550]. If the parameter is specification of RTP in RFC 3550[RFC3550]. If the parameter is
included in the Transport header of a SETUP request, the server included in the Transport header of a SETUP request, the server
SHOULD ignore it, and choose appropriate SSRCs for the stream. SHOULD ignore it, and choose appropriate SSRCs for the stream.
The server SHOULD set the ssrc parameter in the Transport The server SHOULD set the ssrc parameter in the Transport
header of the response. header of the response.
RTCP-mux: Use to negotiate the usage of RTP and RTCP multiplexing RTCP-mux: Use to negotiate the usage of RTP and RTCP multiplexing
[RFC5761] on a single underlying transport stream / flow. The [RFC5761] on a single underlying transport stream / flow. The
presence of this parameter in a SETUP request indicates the presence of this parameter in a SETUP request indicates the
clients support and requires the server to use RTP and RTCP client's support and requires the server to use RTP and RTCP
multiplexing. The client SHALL only include one transport multiplexing. The client SHALL only include one transport
stream in the Transport header specification. To provide the stream in the Transport header specification. To provide the
server with a choice between using RTP/RTCP multiplexing or server with a choice between using RTP/RTCP multiplexing or
not, two different transport header specifications must be not, two different transport header specifications must be
included. included.
The parameters setup and connection defined below MAY only be used if The parameters setup and connection defined below MAY only be used if
the media transport protocol of the lower-level transport is the media transport protocol of the lower-level transport is
connection-oriented (such as TCP). However, these parameters MUST connection-oriented (such as TCP). However, these parameters MUST
NOT be used when interleaving data over the RTSP control connection. NOT be used when interleaving data over the RTSP control connection.
setup: Clients use the setup parameter on the Transport line in a setup: Clients use the setup parameter on the Transport line in a
SETUP request, to indicate the roles it wishes to play in a TCP SETUP request, to indicate the roles it wishes to play in a TCP
connection. This parameter is adapted from [RFC4145]. We connection. This parameter is adapted from [RFC4145]. We
discuss the use of this parameter in RTP/AVP/TCP non- discuss the use of this parameter in RTP/AVP/TCP non-
interleaved transport in Appendix C.2.2; the discussion below interleaved transport in Appendix C.2.2; the discussion below
is limited to syntactic issues. Clients may specify the is limited to syntactic issues. Clients may specify the
following values for the setup parameter: ["active":] The following values for the setup parameter:
client will initiate an outgoing connection. ["passive":] The
client will accept an incoming connection. ["actpass":] The ["active:"] The client will initiate an outgoing connection.
client is willing to accept an incoming connection or to
initiate an outgoing connection. ["passive":] The client will accept an incoming connection.
["actpass":] The client is willing to accept an incoming
connection or to initiate an outgoing connection.
If a client does not specify a setup value, the "active" value If a client does not specify a setup value, the "active" value
is assumed. is assumed.
In response to a client SETUP request where the setup parameter In response to a client SETUP request where the setup parameter
is set to "active", a server's 2xx reply MUST assign the setup is set to "active", a server's 2xx reply MUST assign the setup
parameter to "passive" on the Transport header line. parameter to "passive" on the Transport header line.
In response to a client SETUP request where the setup parameter In response to a client SETUP request where the setup parameter
is set to "passive", a server's 2xx reply MUST assign the setup is set to "passive", a server's 2xx reply MUST assign the setup
skipping to change at page 176, line 26 skipping to change at page 176, line 26
In addition to these recommendations, Section 19.3 gives further In addition to these recommendations, Section 19.3 gives further
recommendations of TLS usage with proxies. recommendations of TLS usage with proxies.
19.3. Security and Proxies 19.3. Security and Proxies
The nature of a proxy is often to act as a "man-in-the-middle", while The nature of a proxy is often to act as a "man-in-the-middle", while
security is often about preventing the existence of a "man-in-the- security is often about preventing the existence of a "man-in-the-
middle". This section provides clients with the possibility to use middle". This section provides clients with the possibility to use
proxies even when applying secure transports (TLS) between the RTSP proxies even when applying secure transports (TLS) between the RTSP
agents. The TLS proxy mechanism allows for server and proxy agents. The TLS proxy mechanism allows for server and proxy
identification using certificates. However, the client can not be identification using certificates. However, the client cannot be
identified based on certificates. The client needs to select between identified based on certificates. The client needs to select between
using the procedure specified below or using a TLS connection using the procedure specified below or using a TLS connection
directly (by-passing any proxies) to the server. The choice may be directly (by-passing any proxies) to the server. The choice may be
dependent on policies. dependent on policies.
There are basically two categories of proxies, the transparent There are basically two categories of proxies, the transparent
proxies (of which the client is not aware) and the non-transparent proxies (of which the client is not aware) and the non-transparent
proxies (of which the client is aware), see Section 15 for an proxies (of which the client is aware), see Section 15 for an
introduction to RTSP proxies. An infrastructure based on proxies introduction to RTSP proxies. An infrastructure based on proxies
requires that the trust model is such that both client and servers requires that the trust model is such that both client and servers
can trust the proxies to handle the RTSP messages correctly. To be can trust the proxies to handle the RTSP messages correctly. To be
able to trust a proxy, the client and server also needs to be aware able to trust a proxy, the client and server also needs to be aware
of the proxy. Hence, transparent proxies cannot generally be seen as of the proxy. Hence, transparent proxies cannot generally be seen as
trusted and will not work well with security (unless they work only trusted and will not work well with security (unless they work only
at transport layer). In the rest of this section any reference to at transport layer). In the rest of this section any reference to
proxy will be to a non-transparent proxy, which inspects or proxy will be to a non-transparent proxy, which inspects or
manipulate the RTSP messages. manipulates the RTSP messages.
HTTP Authentication is built on the assumption of proxies and can HTTP Authentication is built on the assumption of proxies and can
provide user-proxy authentication and proxy-proxy/server provide user-proxy authentication and proxy-proxy/server
authentication in addition to the client-server authentication. authentication in addition to the client-server authentication.
When TLS is applied and a proxy is used, the client will connect to When TLS is applied and a proxy is used, the client will connect to
the proxy's address when connecting to any RTSP server. This implies the proxy's address when connecting to any RTSP server. This implies
that for TLS, the client will authenticate the proxy server and not that for TLS, the client will authenticate the proxy server and not
the end server. Note that when the client checks the server the end server. Note that when the client checks the server
certificate in TLS, it MUST check the proxy's identity (URI or certificate in TLS, it MUST check the proxy's identity (URI or
possibly other known identity) against the proxy's identity as possibly other known identity) against the proxy's identity as
presented in the proxy's Certificate message. presented in the proxy's Certificate message.
The problem is that for a proxy accepted by the client, the proxy The problem is that for a proxy accepted by the client, the proxy
needs to be provided information on which grounds it should accept needs to be provided information on which grounds it should accept
the next-hop certificate. Both the proxy and the user may have rules the next-hop certificate. Both the proxy and the user may have rules
for this, and the user have the possibility to select the desired for this, and the user should have the possibility to select the
behavior. To handle this case, the Accept-Credentials header (See desired behavior. To handle this case, the Accept-Credentials header
Section 18.2) is used, where the client can force the proxy/proxies (See Section 18.2) is used, where the client can request the proxy/
to relay back the chain of certificates used to authenticate any proxies to relay back the chain of certificates used to authenticate
intermediate proxies as well as the server. Given the assumption any intermediate proxies as well as the server. The assumption that
that the proxies are viewed as trusted, it gives the user a the proxies are viewed as trusted, gives the user a possibility to
possibility to enforce policies to each trusted proxy of whether it enforce policies to each trusted proxy of whether it should accept
should accept the next agent in the chain. However, it should be the next agent in the chain. However, it should be noted that not
noted that not all deployments will return the chain of certificates all deployments will return the chain of certificates used to
used to authenticate any intermediate proxies as well as the server. authenticate any intermediate proxies as well as the server. An
An operator of such a deployment may want to hide its topology from operator of such a deployment may want to hide its topology from the
the client. client. It should be noted well that the client does not have any
insight into the proxy's operation. Even if the proxy is trusted, it
can still return an incomplete chain of certificates.
A proxy MUST use TLS for the next hop if the RTSP request includes a A proxy MUST use TLS for the next hop if the RTSP request includes a
"rtsps" URI. TLS MAY be applied on intermediate links (e.g. between "rtsps" URI. TLS MAY be applied on intermediate links (e.g. between
client and proxy, or between proxy and proxy), even if the resource client and proxy, or between proxy and proxy), even if the resource
and the end server are not required to use it. The proxy MUST, when and the end server are not required to use it. The proxy MUST, when
initiating the next hop TLS connection, use the incoming TLS initiating the next hop TLS connection, use the incoming TLS
connections cipher suite list, only modified by removing any cipher connections cipher suite list, only modified by removing any cipher
suits that the proxy does not support. In case a proxy fails to suites that the proxy does not support. In case a proxy fails to
establish a TLS connection due to cipher suite mismatch between proxy establish a TLS connection due to cipher suite mismatch between proxy
and next hop proxy or server, this is indicated using error code 472 and next hop proxy or server, this is indicated using error code 472
(Failure to establish secure connection). (Failure to establish secure connection).
19.3.1. Accept-Credentials 19.3.1. Accept-Credentials
The Accept-Credentials header can be used by the client to distribute The Accept-Credentials header can be used by the client to distribute
simple authorization policies to intermediate proxies. The client simple authorization policies to intermediate proxies. The client
includes the Accept-Credentials header to dictate how the proxy includes the Accept-Credentials header to dictate how the proxy
treats the server/next proxy certificate. There are currently three treats the server/next proxy certificate. There are currently three
methods defined: methods defined:
Any, which means that the proxy (or proxies) MUST accept whatever Any, which means that the proxy (or proxies) MUST accept whatever
certificate presented. This is of course not a recommended certificate presented. This is of course not a recommended
option to use, but may be useful in certain circumstances (such option to use, but may be useful in certain circumstances (such
as testing). as testing).
Proxy, which means that the proxy (or proxies) MUST use its own Proxy, which means that the proxy (or proxies) MUST use its own
policies to validate the certificate and decide whether to policies to validate the certificate and decide whether to
accept it or not. This is convenient in cases where the user accept it or not. This is convenient in cases where the user
has a strong trust relation with the proxy. Reason why a has a strong trust relation with the proxy. Reasons why a
strong trust relation may exist are; personal/company proxy, strong trust relation may exist are; personal/company proxy,
proxy has a out-of-band policy configuration mechanism. proxy has a out-of-band policy configuration mechanism.
User, which means that the proxy (or proxies) MUST send credential User, which means that the proxy (or proxies) MUST send credential
information about the next hop to the client for authorization. information about the next hop to the client for authorization.
The client can then decide whether the proxy should accept the The client can then decide whether the proxy should accept the
certificate or not. See Section 19.3.2 for further details. certificate or not. See Section 19.3.2 for further details.
If the Accept-Credentials header is not included in the RTSP request If the Accept-Credentials header is not included in the RTSP request
from the client, then the "Proxy" method MUST be used as default. If from the client, then the "Proxy" method MUST be used as default. If
another method than the "Proxy" is to be used, then the Accept- another method than the "Proxy" is to be used, then the Accept-
Credentials header MUST be included in all of the RTSP requests from Credentials header MUST be included in all of the RTSP requests from
the client. This is because it cannot be assumed that the proxy the client. This is because it cannot be assumed that the proxy
always keeps the TLS state or the users previous preference between always keeps the TLS state or the user's previous preference between
different RTSP messages (in particular if the time interval between different RTSP messages (in particular if the time interval between
the messages is long). the messages is long).
With the "Any" and "Proxy" methods the proxy will apply the policy as With the "Any" and "Proxy" methods the proxy will apply the policy as
defined for each method. If the policy does not accept the defined for each method. If the policy does not accept the
credentials of the next hop, the proxy MUST respond with a message credentials of the next hop, the proxy MUST respond with a message
using status code 471 (Connection Credentials not accepted). using status code 471 (Connection Credentials not accepted).
An RTSP request in the direction server to client MUST NOT include An RTSP request in the direction server to client MUST NOT include
the Accept-Credentials header. As for the non-secured communication, the Accept-Credentials header. As for the non-secured communication,
the possibility for these requests depends on the presence of a the possibility for these requests depends on the presence of a
client established connection. However, if the server to client client established connection. However, if the server to client
request is in relation to a session established over a TLS secured request is in relation to a session established over a TLS secured
channel, it MUST be sent in a TLS secured connection. That secured channel, it MUST be sent in a TLS secured connection. That secured
connection MUST also be the one used by the last client to server connection MUST also be the one used by the last client to server
request. If no such transport connection exist at the time when the request. If no such transport connection exists at the time when the
server desires to send the request, the server MUST discard the server desires to send the request, the server MUST discard the
message. message.
Further policies MAY be defined and registered, but should be done so Further policies MAY be defined and registered, but should be done so
with caution. with caution.
19.3.2. User approved TLS procedure 19.3.2. User approved TLS procedure
For the "User" method, each proxy MUST perform the following For the "User" method, each proxy MUST perform the following
procedure for each RTSP request: procedure for each RTSP request:
skipping to change at page 200, line 8 skipping to change at page 200, line 8
control-attribute = "a=control:" *SP RTSP-REQ-Ref CRLF control-attribute = "a=control:" *SP RTSP-REQ-Ref CRLF
a-range-def = "a=range:" ranges-spec CRLF a-range-def = "a=range:" ranges-spec CRLF
a-mtag-def = "a=mtag:" message-tag CRLF a-mtag-def = "a=mtag:" message-tag CRLF
21. Security Considerations 21. Security Considerations
The security considerations and threats around RTSP and its usage can The security considerations and threats around RTSP and its usage can
be divided to considerations around the signaling protocol itself and be divided into considerations around the signaling protocol itself
the issues related to the media stream delivery. However, when it and the issues related to the media stream delivery. However, when
comes to mitigations of security threats, a threat depending on the it comes to mitigations of security threats, a threat depending on
media stream delivery may in fact be mitigated by a mechanism in the the media stream delivery may in fact be mitigated by a mechanism in
signaling protocol. the signaling protocol.
There are several chapters and appendix in this document that defines There are several chapters and appendix in this document that define
security solutions for the protocol. We will reference them when security solutions for the protocol. We will reference them when
discussing the threats below. But the reader should take special discussing the threats below. But the reader should take special
notice of the Security Framework (Section 19) and the specification notice of the Security Framework (Section 19) and the specification
of how to use SRTP and its key-mangement (Appendix C.1.4) to achieve of how to use SRTP and its key-mangement (Appendix C.1.4) to achieve
certain aspects of the media security. certain aspects of the media security.
21.1. Signaling Protocol Threats 21.1. Signaling Protocol Threats
This section focus on issues related to the signaling protocol. This section focuses on issues related to the signaling protocol.
Because of the similarity in syntax and usage between RTSP servers Because of the similarity in syntax and usage between RTSP servers
and HTTP servers, the security considerations outlined in [H15] apply and HTTP servers, the security considerations outlined in [H15] apply
also. also.
Specifically, please note the following: Specifically, please note the following:
Abuse of Server Log Information: RTSP and HTTP servers will Abuse of Server Log Information: RTSP and HTTP servers will
presumably have similar logging mechanisms, and thus should be presumably have similar logging mechanisms, and thus should be
equally guarded in protecting the contents of those logs, thus equally guarded in protecting the contents of those logs, thus
protecting the privacy of the users of the servers. See protecting the privacy of the users of the servers. See
skipping to change at page 201, line 24 skipping to change at page 201, line 24
DNS Spoofing: Presumably, given the longer connection times DNS Spoofing: Presumably, given the longer connection times
typically associated to RTSP sessions relative to HTTP typically associated to RTSP sessions relative to HTTP
sessions, RTSP client DNS optimizations should be less sessions, RTSP client DNS optimizations should be less
prevalent. Nonetheless, the recommendations provided in prevalent. Nonetheless, the recommendations provided in
[H15.3] are still relevant to any implementation which attempts [H15.3] are still relevant to any implementation which attempts
to rely on a DNS-to-IP mapping to hold beyond a single use of to rely on a DNS-to-IP mapping to hold beyond a single use of
the mapping. the mapping.
Location Headers and Spoofing: If a single server supports multiple Location Headers and Spoofing: If a single server supports multiple
organizations that do not trust each another, then it needs to organizations that do not trust each another, then it MUST
check the values of Location and Content-Location header fields check the values of Location and Content-Location header fields
in responses that are generated under control of said in responses that are generated under control of said
organizations to make sure that they do not attempt to organizations to make sure that they do not attempt to
invalidate resources over which they have no authority. invalidate resources over which they have no authority.
([H15.4]) ([H15.4])
In addition to the recommendations in the current HTTP specification In addition to the recommendations in the current HTTP specification
(RFC 2616 [RFC2616], as of this writing) and also of the previous RFC (RFC 2616 [RFC2616], as of this writing) and also of the previous RFC
2068 [RFC2068], future HTTP specifications may provide additional 2068 [RFC2068], future HTTP specifications may provide additional
guidance on security issues. guidance on security issues.
The following are added considerations for RTSP implementations. The following are added considerations for RTSP implementations.
Session hijacking: Since there is no or little relation between a Session hijacking: Since there is no or little relation between a
transport layer connection and an RTSP session, it is possible transport layer connection and an RTSP session, it is possible
for a malicious client to issue requests with random session for a malicious client to issue requests with random session
identifiers which would affect unsuspecting clients. To identifiers which could affect other clients of an unsuspecting
mitigate this the server SHALL use a large, random and non- server. To mitigate this the server SHALL use a large, random
sequential session identifier to minimize the possibility of and non-sequential session identifier to minimize the
this kind of attack. However, unless the RTSP signaling is possibility of this kind of attack. However, unless the RTSP
always confidentiality protected, e.g. using TLS, an on-path signaling is always confidentiality protected, e.g. using TLS,
attacker will be able to hijack a session. To prevent session an on-path attacker will be able to hijack a session. To
hijacking client authentication needs to be performed and only prevent session hijacking client authentication needs to be
the authenticated client creating the session SHALL be able to performed and only the authenticated client creating the
access that session. session SHALL be able to access that session.
Authentication: Servers SHOULD implement both basic and digest Authentication: Servers SHOULD implement both basic and digest
[RFC2617] authentication. In environments requiring tighter [RFC2617] authentication. In environments requiring tighter
security for the control messages, the transport layer security for the control messages, the transport layer
mechanism TLS [RFC5246] SHOULD be used. mechanism TLS [RFC5246] SHOULD be used.
Persistently suspicious behavior: RTSP servers SHOULD return error Persistently suspicious behavior: RTSP servers SHOULD return error
code 403 (Forbidden) upon receiving a single instance of code 403 (Forbidden) upon receiving a single instance of
behavior which is deemed a security risk. RTSP servers SHOULD behavior which is deemed a security risk. RTSP servers SHOULD
also be aware of attempts to probe the server for weaknesses also be aware of attempts to probe the server for weaknesses
skipping to change at page 202, line 25 skipping to change at page 202, line 25
further requests from clients which are deemed to be in further requests from clients which are deemed to be in
violation of local security policy. violation of local security policy.
TLS through proxies: If one uses the possibility to connect TLS in TLS through proxies: If one uses the possibility to connect TLS in
multiple legs (Section 19.3) one really needs to be aware of multiple legs (Section 19.3) one really needs to be aware of
the trust model. That procedure requires full faith and trust the trust model. That procedure requires full faith and trust
in all proxies, which will be identified, that one allows to in all proxies, which will be identified, that one allows to
connect through. They are men in the middle and have access to connect through. They are men in the middle and have access to
all that goes on over the TLS connection. Thus it is important all that goes on over the TLS connection. Thus it is important
to consider if that trust model is acceptable in the actual to consider if that trust model is acceptable in the actual
application. Further discussion of the actual trust model in application. Further discussion of the actual trust model is
Section 19.3. in Section 19.3.
Resource Exhaustion: As RTSP is a stateful protocol and establish Resource Exhaustion: As RTSP is a stateful protocol and establishes
resource usage on the server there is a clear possibility to resource usage on the server there is a clear possibility to
attack the server by trying to overbook these resources to attack the server by trying to overbook these resources to
perform a denial of service attack. This attack can be both perform a denial of service attack. This attack can be both
against ongoing sessions and to prevent others from against ongoing sessions and to prevent others from
establishing sessions. RTSP agents will need to have establishing sessions. RTSP agents will need to have
mechanisms to prevent single peers from consuming extensive mechanisms to prevent single peers from consuming extensive
amounts of resources. The methods for guarding against this amounts of resources. The methods for guarding against this
are varied and depends on the agents role and capabilities and are varied and depends on the agent's role and capabilities and
policies. Each implementation have to careful consider their policies. Each implementation has to carefully consider their
methods and policies to mitigate this threat. For example methods and policies to mitigate this threat. For example
regarding handling of connections there is recommendations in regarding handling of connections there are recommendations in
Section 10.7. Section 10.7.
The above threats and consideration has resulted in a set of security The above threats and considerations have resulted in a set of
function and mechanism built into or used by the protocol. The security functions and mechanisms built into or used by the protocol.
signaling protocol relies on two security features defined in the The signaling protocol relies on two security features defined in the
Security Framework (Section 19) namely client authentication using Security Framework (Section 19) namely client authentication using
HTTP authentication and TLS based transport protection of the HTTP authentication and TLS based transport protection of the
signaling messages. Both these there mechanism are required to be signaling messages. Both of these mechanisms are required to be
implemented by any RTSP agent. implemented by any RTSP agent.
A number of different security mitigations has been designed into the A number of different security mitigations have been designed into
protocol and will be present by following the specification as the protocol and will be present by following the specification as
written, for example by ensuring sufficient amount of entropy in the written, for example by ensuring sufficient amount of entropy in the
randomly generated session identifiers when not using client randomly generated session identifiers when not using client
authentication to prevent session hijacking. When client authentication to prevent session hijacking. When client
authentication is used the protection against hijacking will be authentication is used the protection against hijacking will be
strongly improved by scoping the accessible sessions to the one this strongly improved by scoping the accessible sessions to the one this
client identity has created. Some of the above threats are such that client identity has created. Some of the above threats are such that
the implementation of the RTSP functionality itself needs to consider the implementation of the RTSP functionality itself needs to consider
which policy and strategy it uses to mitigate them. which policy and strategy it uses to mitigate them.
21.2. Media Stream Delivery Threats 21.2. Media Stream Delivery Threats
The fact that RTSP establish and controls a media stream delivery The fact that RTSP establishes and controls a media stream delivery
results in a set of security issues related to the media streams. results in a set of security issues related to the media streams.
This section will attempt to analyze general threats, however the This section will attempt to analyze general threats, however the
choice of media stream transport protocol, like RTP will result in choice of media stream transport protocol, like RTP will result in
some difference in threats and what mechanisms that exist to mitigate some differences in threats and what mechanisms that exist to
them. Thus it becomes important that each specification of a new mitigate them. Thus it becomes important that each specification of
media stream transport and delivery protocol usable by RTSP requires a new media stream transport and delivery protocol usable by RTSP
its own security analyses. This section will include such a one for requires its own security analysis. This section includes one for
RTP. RTP.
The set of general threats from or by the media stream delivery The set of general threats from or by the media stream delivery
itself are: itself are:
Concentrated denial-of-service attack: The protocol offers the Concentrated denial-of-service attack: The protocol offers the
opportunity for a remote-controlled denial-of-service (DoS) opportunity for a remote-controlled denial-of-service (DoS)
attack. Where the media stream is the hammer in that DoS attack. attack, where the media stream is the hammer in that DoS attack.
See Section 21.2.1. See Section 21.2.1.
Media Confidentiality: The media delivery may contain content of any Media Confidentiality: The media delivery may contain content of any
type and it is not possible in general to determine how sensitive type and it is not possible in general to determine how sensitive
this content is from a confidentiality point. Thus it is a strong this content is from a confidentiality point. Thus it is a strong
requirement that any media delivery protocol provides method for requirement that any media delivery protocol provides a method for
providing confidentiality of the actual media content. In providing confidentiality of the actual media content. In
addition to the media level confidentiality it becomes critical addition to the media level confidentiality it becomes critical
that no resource identifier used in the signaling are exposed to that no resource identifiers used in the signaling are exposed to
an attacker as they may have human understandable names, or may be an attacker as they may have human understandable names, or may be
also available to the attacker so they can determine the content also available to the attacker so they can determine the content
they user was delivered. Thus also the signaling protocol must the user was delivered. Thus also the signaling protocol must
provide confidentiality protection of any information related to provide confidentiality protection of any information related to
the media resource. the media resource.
Media Integrity and Authentication: There exist several reasons, Media Integrity and Authentication: There are several reasons, such
such as discrediting the target, misinformation of the target, why as discrediting the target, misinformation of the target, why an
an attacker will have interest to substitute the media stream sent attacker will have interest to substitute the media stream sent
out from the RTSP server with one of the attackers creation or out from the RTSP server with one of the attacker's creation or
selection. Therefore it is important that the media protocol selection. Therefore it is important that the media protocol
provides mechanism to verify the source authentication, integrity provides mechanisms to verify the source authentication, integrity
and prevent replay attacks on the media stream. and prevent replay attacks on the media stream.
Scope of Multicast: If RTSP is used to control the transmission of Scope of Multicast: If RTSP is used to control the transmission of
media onto a multicast network it is needed to consider the scope media onto a multicast network it is needed to consider the scope
that delivery has. RTSP supports the TTL Transport header that delivery has. RTSP supports the TTL Transport header
parameter to indicate this scope for IPv4. IPv6 has a different parameter to indicate this scope for IPv4. IPv6 has a different
mechanism for scope boundary. However, such scope control has mechanism for scope boundary. However, such scope control has
risks, as it may be set too large and distribute media beyond the risks, as it may be set too large and distribute media beyond the
intended scope. intended scope.
Below (Section 21.2.2) we do a protocol specific analysis of security Below (Section 21.2.2) we do a protocol specific analysis of security
considerations for RTP based media transport. In that section we considerations for RTP based media transport. In that section we
also make clear the requirements on implementing security functions also make clear the requirements on implementing security functions
for RTSP agents supporting media delivery over RTP. for RTSP agents supporting media delivery over RTP.
21.2.1. Remote denial of Service Attack 21.2.1. Remote Denial of Service Attack
The attacker may initiate traffic flows to one or more IP addresses The attacker may initiate traffic flows to one or more IP addresses
by specifying them as the destination in SETUP requests. While the by specifying them as the destination in SETUP requests. While the
attacker's IP address may be known in this case, this is not always attacker's IP address may be known in this case, this is not always
useful in prevention of more attacks or ascertaining the attackers useful in prevention of more attacks or ascertaining the attackers
identity. Thus, an RTSP server MUST only allow client-specified identity. Thus, an RTSP server MUST only allow client-specified
destinations for RTSP-initiated traffic flows if the server has destinations for RTSP-initiated traffic flows if the server has
ensured that the specified destination address accepts receiving ensured that the specified destination address accepts receiving
media through different security mechanisms. Security mechanisms media through different security mechanisms. Security mechanisms
that are acceptable in an increased generality are: that are acceptable in an increased generality are:
skipping to change at page 204, line 44 skipping to change at page 204, line 44
o A list of addresses that accept to be media destinations, o A list of addresses that accept to be media destinations,
especially considering user identity especially considering user identity
o Media path based verification o Media path based verification
The server SHOULD NOT allow the destination field to be set unless a The server SHOULD NOT allow the destination field to be set unless a
mechanism exists in the system to authorize the request originator to mechanism exists in the system to authorize the request originator to
direct streams to the recipient. It is preferred that this direct streams to the recipient. It is preferred that this
authorization be performed by the media recipient (destination) authorization be performed by the media recipient (destination)
itself and the credentials passed along to the server. However, in itself and the credentials passed along to the server. However, in
certain cases, such as when recipient address is a multicast group, certain cases, such as when the recipient address is a multicast
or when the recipient is unable to communicate with the server in an group, or when the recipient is unable to communicate with the server
out-of-band manner, this may not be possible. In these cases the in an out-of-band manner, this may not be possible. In these cases
server may chose another method such as a server-resident the server may chose another method such as a server-resident
authorization list to ensure that the request originator has the authorization list to ensure that the request originator has the
proper credentials to request stream delivery to the recipient. proper credentials to request stream delivery to the recipient.
One solution that performs the necessary verification of acceptance One solution that performs the necessary verification of acceptance
of media suitable for unicast based delivery is the ICE based NAT of media suitable for unicast based delivery is the ICE based NAT
traversal method described in [I-D.ietf-mmusic-rtsp-nat]. This traversal method described in [I-D.ietf-mmusic-rtsp-nat]. This
mechanism uses random passwords and username so that the probability mechanism uses random passwords and username so that the probability
of unintended indication as a valid media destination is very low. of unintended indication as a valid media destination is very low.
In addition the server includes in its STUN requests a cookie In addition the server includes in its STUN requests a cookie
(consisting of random material) that the destination echoes back, (consisting of random material) that the destination echoes back,
thus the solution also safe-guards against having a off-path attacker thus the solution also safe-guards against having an off-path
being able to spoof the STUN checks. This leaves this solution attacker being able to spoof the STUN checks. This leaves this
vulnerable only to on-path attackers that can see the STUN requests solution vulnerable only to on-path attackers that can see the STUN
go to the target of attack and thus forge a response. requests go to the target of attack and thus forge a response.
For delivery to multicast addresses there is a need for another For delivery to multicast addresses there is a need for another
solution which is not specified in this memo. solution which is not specified in this memo.
21.2.2. RTP Security analysis 21.2.2. RTP Security analysis
RTP is a commonly used media transport protocol and has been the most RTP is a commonly used media transport protocol and has been the most
common choice for RTSP 1.0 implementations. The core RTP protocol common choice for RTSP 1.0 implementations. The core RTP protocol
has been in use for a long time and it has well-known security has been in use for a long time and it has well-known security
properties and the RTP security consideration (Section 9 of properties and the RTP security consideration (Section 9 of
[RFC3550]) needs to be reviewed. In perspective of the usage of RTP [RFC3550]) needs to be reviewed. In perspective of the usage of RTP
in context of RTSP the following properties should be noted: in context of RTSP the following properties should be noted:
Stream Additions: RTP has support for multiple simultaneous media Stream Additions: RTP has support for multiple simultaneous media
streams in each RTP session. As some use case require support for streams in each RTP session. As some use cases require support
non-synchronized adding and removal of media streams and their for non-synchronized adding and removal of media streams and their
identifiers an attacker can easily insert additional media streams identifiers an attacker can easily insert additional media streams
into a session context that according to protocol design is into a session context that according to protocol design is
intended to be played out. Another threat vector is that one of intended to be played out. Another threat vector is one of denial
denial of service by exhausting the resources of the RTP session of service by exhausting the resources of the RTP session
receiver, for example by using a large number of SSRC identifier receiver, for example by using a large number of SSRC identifiers
simultaneously. The strong mitigation of this is to ensure that simultaneously. The strong mitigation of this is to ensure that
one cryptographically authenticates any incoming packet flow to one cryptographically authenticates any incoming packet flow to
the RTP session. Weak mitigations like blocking additional media the RTP session. Weak mitigations like blocking additional media
streams in session contexts easily lead to a denial of service streams in session contexts easily lead to a denial of service
vulnerability in addition to preventing certain RTP extensions or vulnerability in addition to preventing certain RTP extensions or
use cases which rely on multiple media streams, such as RTP use cases which rely on multiple media streams, such as RTP
retransmission [RFC4588] to function. retransmission [RFC4588] to function.
Forged Feedback: The built in RTP control Protocol (RTCP) also Forged Feedback: The built in RTP control Protocol (RTCP) also
offers a large attack surface for a couple of different types of offers a large attack surface for a couple of different types of
attacks. One venue is to send RTCP feedback to the media sender attacks. One venue is to send RTCP feedback to the media sender
indicating large amounts of packet loss and thus trigger an media indicating large amounts of packet loss and thus trigger a media
bit-rate adaptation response from the sender resulting in lowered bit-rate adaptation response from the sender resulting in lowered
media quality and potentially shut down of the media stream. media quality and potentially shut down of the media stream.
Another attack is to perform a resource exhaustion attack on the Another attack is to perform a resource exhaustion attack on the
receiver by using many SSRC identifiers to create large state receiver by using many SSRC identifiers to create large state
tables and increase the RTCP related processing demands. tables and increase the RTCP related processing demands.
RTP/RTCP Extensions: RTP and RTCP extensions generally provide RTP/RTCP Extensions: RTP and RTCP extensions generally provide
additional and sometimes extremely powerful tools to do denial of additional and sometimes extremely powerful tools to do denial of
service or service disruption. For example the Code Control service or service disruption. For example the Code Control
Message [RFC5104] RTCP extensions enables both locking down the Message [RFC5104] RTCP extensions enables both locking down the
bit-rate to low values and disrupt video quality by requesting bit-rate to low values and disrupt video quality by requesting
Intra frames. Intra frames.
Taking into account the above general discussion in Section 21.2 and Taking into account the above general discussion in Section 21.2 and
the RTP specific discussion in this section it is clear that strong the RTP specific discussion in this section it is clear that strong
security mechanism to protect RTP is necessary to support. Therefore security mechanism to protect RTP is necessary to support. Therefore
this specification has the following requirements on RTP security this specification has the following requirements on RTP security
functions for all RTSP agents that handles media streams and where functions for all RTSP agents that handles media streams and where
the media stream transport is done using RTP. the media stream transport is done using RTP.
RTSP agents supporting RTP MUST implement SRTP [RFC3711] and thus the RTSP agents supporting RTP MUST implement Secure RTP (SRTP) [RFC3711]
SAVP profile, in addition the secure profile SAVPF MUST also be and thus the SAVP profile. In addition the secure AVP profile
supported if the AVPF profile is implemented. This specification (SAVPF) [RFC5124] MUST also be supported if the AVPF profile is
requires no additional crypto transforms or configuration values implemented. This specification requires no additional crypto
beyond the mandatory to implement in RFC3711, i.e. AES-CM and HMAC- transforms or configuration values beyond the mandatory to implement
SHA1. The default key-management mechanism which MUST be implemented in RFC3711, i.e. AES-CM and HMAC-SHA1. The default key-management
is the one defined in the MIKEY Key Establishment (Appendix C.1.4.1). mechanism which MUST be implemented is the one defined in the MIKEY
The MIKEY implementation MUST implement the necessary functions for Key Establishment (Appendix C.1.4.1). The MIKEY implementation MUST
MIKEY-RSA-R mode [RFC4738] and in addition the SRTP parameter implement the necessary functions for MIKEY-RSA-R mode [RFC4738] and
negotiation necessary to negotiate the supported SRTP transforms and in addition the SRTP parameter negotiation necessary to negotiate the
parameters. supported SRTP transforms and parameters.
22. IANA Considerations 22. IANA Considerations
This section sets up a number of registries for RTSP 2.0 that should This section sets up a number of registries for RTSP 2.0 that should
be maintained by IANA. These registries are separate from any be maintained by IANA. These registries are separate from any
registries existing for RTSP 1.0. For each registry there is a registries existing for RTSP 1.0. For each registry there is a
description on what it is required to contain, what specification is description of what it is required to contain, what specification is
needed when adding an entry with IANA, and finally the entries that needed when adding an entry with IANA, and finally the entries that
this document needs to register. See also the Section 2.7 "Extending this document needs to register. See also the Section 2.7 "Extending
RTSP". There is also an IANA registration of two SDP attributes. RTSP". There is also an IANA registration of three SDP attributes.
Registries or entries in registries which have been made for RTSP 1.0 Registries or entries in registries which have been made for RTSP 1.0
are not moved to RTSP 2.0. The registries and entries in registries are not moved to RTSP 2.0. The registries and entries in registries
of RTSP 1.0 and RTSP 2.0 are indenpendent. If any registry or entry of RTSP 1.0 and RTSP 2.0 are independent. If any registry or entry
in a registry is also required in RTSP 2.0, it must follow the below in a registry is also required in RTSP 2.0, it MUST follow the below
defined procedure to allocated the registry or entry in a registry. defined procedure to allocate the registry or entry in a registry.
The sections describing how to register an item uses some of the The sections describing how to register an item uses some of the
requirements level described in RFC 5226 [RFC5226], namely "First requirements level described in RFC 5226 [RFC5226], namely "First
Come, First Served", "Expert Review, "Specification Required", and Come, First Served", "Expert Review, "Specification Required", and
"Standards Action". "Standards Action".
In case a registry requires a contact person, the authors are the In case a registry requires a contact person, the authors are the
contact person for any entries created by this document. contact person for any entries created by this document.
A registration request to IANA MUST contain the following A registration request to IANA MUST contain the following
skipping to change at page 208, line 25 skipping to change at page 208, line 25
The registering of feature-tags is done on a first come, first served The registering of feature-tags is done on a first come, first served
basis. basis.
The name of the feature MUST follow these rules: The name may be of The name of the feature MUST follow these rules: The name may be of
any length, but SHOULD be no more than twenty characters long. The any length, but SHOULD be no more than twenty characters long. The
name MUST NOT contain any spaces, or control characters. The name MUST NOT contain any spaces, or control characters. The
registration MUST indicate if the feature-tag applies to clients, registration MUST indicate if the feature-tag applies to clients,
servers, or proxies only or any combinations of these. Any servers, or proxies only or any combinations of these. Any
proprietary feature MUST have as the first part of the name a vendor proprietary feature MUST have as the first part of the name a vendor
tag, which identifies the organization. The registry entries tag, which identifies the organization. The registry entries consist
consists of the feature tag, a one paragraph description of what it of the feature tag, a one paragraph description of what it
represents, its applicability (server, client, proxy, any represents, its applicability (server, client, proxy, any
combination) and a reference to its specification where applicable. combination) and a reference to its specification where applicable.
Examples for a vendor tag describing a proprietary feature are: Examples for a vendor tag describing a proprietary feature are:
vendorA.specfeat01 vendorA.specfeat01
vendorA.specfeat02 vendorA.specfeat02
22.1.3. Registered entries 22.1.3. Registered entries
skipping to change at page 209, line 9 skipping to change at page 209, line 9
play.scale: Support of scale operations for media playback. Applies play.scale: Support of scale operations for media playback. Applies
only for servers. only for servers.
play.speed: Support of the speed functionality for media delivery. play.speed: Support of the speed functionality for media delivery.
Applies only for servers. Applies only for servers.
setup.rtp.rtcp.mux Support of the RTP and RTCP multiplexing as setup.rtp.rtcp.mux Support of the RTP and RTCP multiplexing as
discussed in Appendix C.1.6.4. Applies for both client and discussed in Appendix C.1.6.4. Applies for both client and
servers and any media caching proxy. servers and any media caching proxy.
This should be represented by IANA as table with the feature tags, This should be represented by IANA as a table with the feature tags,
contact person and their references. contact person and their references.
22.2. RTSP Methods 22.2. RTSP Methods
22.2.1. Description 22.2.1. Description
What a method is, is described in Section Section 13. Extending the Methods are described in Section Section 13. Extending the protocol
protocol with new methods allow for totally new functionality. with new methods allow for totally new functionality.
22.2.2. Registering New Methods with IANA 22.2.2. Registering New Methods with IANA
A new method MUST be registered through an IETF Standards Action. A new method MUST be registered through an IETF Standards Action.
The reason is that new methods may radically change the protocol's The reason is that new methods may radically change the protocol's
behavior and purpose. behavior and purpose.
A specification for a new RTSP method MUST consist of the following A specification for a new RTSP method MUST consist of the following
items: items:
o A method name which follows the ABNF rules for methods. o A method name which follows the ABNF rules for methods.
o A clear specification what a request using the method does and o A clear specification what a request using the method does and
what responses are expected. Which directions the method is used, what responses are expected. Which directions the method is used,
C->S or S->C or both. How the use of headers, if any, modifies C->S or S->C or both. How the use of headers, if any, modifies
the behavior and effect of the method. the behavior and effect of the method.
o A list or table specifying which of the IANA registered headers o A list or table specifying which of the IANA registered headers
that are allowed to be used with the method in request or/and that are allowed to be used with the method in request or/and
response. The list or table SHOULD follow the format of tables in response. The list or table SHOULD follow the format of tables in
Section Section 18. Section 18.
o Describe how the method relates to network proxies. o Describe how the method relates to network proxies.
22.2.3. Registered Entries 22.2.3. Registered Entries
This specification, RFCXXXX, registers 10 methods: DESCRIBE, This specification, RFCXXXX, registers 10 methods: DESCRIBE,
GET_PARAMETER, OPTIONS, PAUSE, PLAY, PLAY_NOTIFY, REDIRECT, SETUP, GET_PARAMETER, OPTIONS, PAUSE, PLAY, PLAY_NOTIFY, REDIRECT, SETUP,
SET_PARAMETER, and TEARDOWN. The initial table of the registry is SET_PARAMETER, and TEARDOWN. The initial table of the registry is
below provided. provided below.
Method Directionality Reference Method Directionality Reference
----------------------------------------------------- -----------------------------------------------------
DESCRIBE C->S [RFCXXXX] DESCRIBE C->S [RFCXXXX]
GET_PARAMETER C->S, S->C [RFCXXXX] GET_PARAMETER C->S, S->C [RFCXXXX]
OPTIONS C->S, S->C [RFCXXXX] OPTIONS C->S, S->C [RFCXXXX]
PAUSE C->S [RFCXXXX] PAUSE C->S [RFCXXXX]
PLAY C->S [RFCXXXX] PLAY C->S [RFCXXXX]
PLAY_NOTIFY S->C [RFCXXXX] PLAY_NOTIFY S->C [RFCXXXX]
REDIRECT S->C [RFCXXXX] REDIRECT S->C [RFCXXXX]
SETUP C->S [RFCXXXX] SETUP C->S [RFCXXXX]
SET_PARAMETER C->S, S->C [RFCXXXX] SET_PARAMETER C->S, S->C [RFCXXXX]
TEARDOWN C->S, S->C [RFCXXXX] TEARDOWN C->S, S->C [RFCXXXX]
22.3. RTSP Status Codes 22.3. RTSP Status Codes
22.3.1. Description 22.3.1. Description
A status code is the three digit numbers used to convey information A status code is the three digit number used to convey information in
in RTSP response messages, see Section 8. The number space is RTSP response messages, see Section 8. The number space is limited
limited and care should be taken not to fill the space. and care should be taken not to fill the space.
22.3.2. Registering New Status Codes with IANA 22.3.2. Registering New Status Codes with IANA
A new status code registration follows the policy of IETF Review. A A new status code registration follows the policy of IETF Review. A
specification for a new status code MUST specify the following: specification for a new status code MUST specify the following:
o The registered number. o The registered number.
o A description what the status code means and the expected behavior o A description of what the status code means and the expected
of the sender and receiver of the code. behavior of the sender and receiver of the code.
22.3.3. Registered Entries 22.3.3. Registered Entries
RFCXXXX, registers the numbered status code defined in the ABNF entry RFCXXXX, registers the numbered status code defined in the ABNF entry
"Status-Code" except "extension-code" (that defines the syntax "Status-Code" except "extension-code" (that defines the syntax
allowed for future extensions) in Section 20.2.2. allowed for future extensions) in Section 20.2.2.
22.4. RTSP Headers 22.4. RTSP Headers
22.4.1. Description 22.4.1. Description
skipping to change at page 211, line 30 skipping to change at page 211, line 30
encompassing all methods, their request or response, the direction encompassing all methods, their request or response, the direction
(C->S or S->C). (C->S or S->C).
o How the header is to be handled by proxies. o How the header is to be handled by proxies.
o A description of the purpose of the header. o A description of the purpose of the header.
22.4.3. Registered entries 22.4.3. Registered entries
All headers specified in Section 18 in RFCXXXX are to be registered. All headers specified in Section 18 in RFCXXXX are to be registered.
The Registry is to include header name, description, and reference. The Registry is to include header name and reference.
Furthermore the following legacy RTSP headers defined in other Furthermore the following legacy RTSP headers defined in other
specifications are registered with header name, reference and specifications are registered with header name, reference and
description according to below list. Note: These references may not description according to below list. Note: These references may not
fulfill all of the above rules for registrations due to their legacy fulfill all of the above rules for registrations due to their legacy
status. status.
o x-wap-profile defined in [TS-26234]. The x-wap-profile request o x-wap-profile defined in [TS-26234]. The x-wap-profile request
header contains one or more absolute URLs to the requesting agents header contains one or more absolute URLs to the requesting
device capability profile. agent's device capability profile.
o x-wap-profile-diff defined in [TS-26234]. The x-wap-profile-diff o x-wap-profile-diff defined in [TS-26234]. The x-wap-profile-diff
request header contains a subset of an device capability profile. request header contains a subset of a device capability profile.
o x-wap-profile-warning defined in [TS-26234]. The x-wap-profile- o x-wap-profile-warning defined in [TS-26234]. The x-wap-profile-
warning is a response header that contains error codes explaining warning is a response header that contains error codes explaining
to what extent the server has been able to match the terminal to what extent the server has been able to match the terminal
request in regards to device capability profile as described using request in regards to device capability profile as described using
x-wap-profile and x-wap-profile-diff headers. x-wap-profile and x-wap-profile-diff headers.
o x-predecbufsize defined in [TS-26234]. This response header o x-predecbufsize defined in [TS-26234]. This response header
provides an RTSP agent with the TS 26.234 Annex G hypothetical provides an RTSP agent with the TS 26.234 Annex G hypothetical
pre-decoder buffer size. pre-decoder buffer size.
skipping to change at page 212, line 20 skipping to change at page 212, line 20
o x-initpostdecbufperiod defined in [TS-26234]. This response o x-initpostdecbufperiod defined in [TS-26234]. This response
header provides an RTSP agent with the TS 26.234 Annex G post- header provides an RTSP agent with the TS 26.234 Annex G post-
decoder buffering period. decoder buffering period.
o 3gpp-videopostdecbufsize defined in [TS-26234]. This response o 3gpp-videopostdecbufsize defined in [TS-26234]. This response
header provides an RTSP agent with the TS 26.234 defined post- header provides an RTSP agent with the TS 26.234 defined post-
decoder buffer size usable for H.264 (AVC) video streams. decoder buffer size usable for H.264 (AVC) video streams.
o 3GPP-Link-Char defined in [TS-26234]. This request header o 3GPP-Link-Char defined in [TS-26234]. This request header
provides the RTSP server with the RTSP client's link provides the RTSP server with the RTSP client's link
charateristics as deterimined from the raido interface. The charateristics as deterimined from the radio interface. The
information that can be provided are guararnteed bit-rate, maximum information that can be provided are guaranteed bit-rate, maximum
bit-rate and maximum transfer delay. bit-rate and maximum transfer delay.
o 3GPP-Adaptation defined in [TS-26234]. This general header is o 3GPP-Adaptation defined in [TS-26234]. This general header is
part of the bit-rate adaptation solution specified for PSS. It part of the bit-rate adaptation solution specified for PSS. It
provides the RTSP clients buffer sizes and target buffer levels to provides the RTSP client's buffer sizes and target buffer levels
the server and responses are used to acknowledge the support and to the server and responses are used to acknowledge the support
values. and values.
o 3GPP-QoE-Metrics defined in [TS-26234]. This general header is o 3GPP-QoE-Metrics defined in [TS-26234]. This general header is
used by PSS RTSP agents to negotiate the quality of experince used by PSS RTSP agents to negotiate the quality of experince
metrics that a client should gather and report to the server. metrics that a client should gather and report to the server.
o 3GPP-QoE-Feedback defined in [TS-26234]. This request header is o 3GPP-QoE-Feedback defined in [TS-26234]. This request header is
used by RTSP clients supporting PSS to report the actual values of used by RTSP clients supporting PSS to report the actual values of
the metrics gathered in its quality of experince metering. the metrics gathered in its quality of experince metering.
The use of "x-" is NOT RECOMMENDED but the above headers in the The use of "x-" is NOT RECOMMENDED but the above headers in the
register list was defined prior to the clarification. register list were defined prior to the clarification.
22.5. Accept-Credentials 22.5. Accept-Credentials
The security framework's TLS connection mechanism has two registrable The security framework's TLS connection mechanism has two registrable
entities. entities.
22.5.1. Accept-Credentials policies 22.5.1. Accept-Credentials policies
In Section 19.3.1 three policies for how to handle certificates are In Section 19.3.1 three policies for how to handle certificates are
specified. Further policies may be defined and MUST be registered specified. Further policies may be defined and MUST be registered
skipping to change at page 214, line 43 skipping to change at page 214, line 43
The registry should be represented as: Name of the directive, contact The registry should be represented as: Name of the directive, contact
person and reference. person and reference.
22.7. Media Properties 22.7. Media Properties
22.7.1. Description 22.7.1. Description
The media streams being controlled by RTSP can have many different The media streams being controlled by RTSP can have many different
properties. The media properties required to cover the use cases properties. The media properties required to cover the use cases
that was in mind when writing the specification are defined. that were in mind when writing the specification are defined.
However, it can be expected that further innovation will result in However, it can be expected that further innovation will result in
new use cases or media streams with properties not covered by the new use cases or media streams with properties not covered by the
ones specified here. Thus new media properties can be specified. As ones specified here. Thus new media properties can be specified. As
new media properties may need a substantial amount of new definitions new media properties may need a substantial amount of new definitions
to correctly specify behavior for this property the bar is intended to correctly specify behavior for this property the bar is intended
to be high. to be high.
22.7.2. Registration Rules 22.7.2. Registration Rules
Registering new media property MUST fulfill the following Registering a new media property MUST fulfill the following
requirements requirements
o Follow the Specification Required policy and get the approval of o Follow the Specification Required policy and get the approval of
the designated Expert. the designated Expert.
o Have an ABNF definition of the media property value name that o Have an ABNF definition of the media property value name that
meets "media-prop-ext" definition meets "media-prop-ext" definition
o A Contact Person for the Registration o A Contact Person for the Registration
skipping to change at page 216, line 9 skipping to change at page 216, line 9
o A Contact Person for the Registration o A Contact Person for the Registration
o Description of which headers shall be included in the request and o Description of which headers shall be included in the request and
response, when it should be sent, and any effect it has on the response, when it should be sent, and any effect it has on the
server client state. server client state.
22.8.3. Registered Values 22.8.3. Registered Values
This specification registers 3 values defined in the Notify-Reas-val This specification registers 3 values defined in the Notify-Reas-val
ABNFSection 20.2.3: ABNF, Section 20.2.3:
end-of-stream: This Notify-Reason header indicates the end of a end-of-stream: This Notify-Reason value indicates the end of a media
media stream. stream.
media-properties-update: This Notify-Reason header allows the server media-properties-update: This Notify-Reason value allows the server
to indicate that the properties of the media has changed during to indicate that the properties of the media has changed during
the playout. the playout.
scale-change: This Notify-Reason header allows the server to notify scale-change: This Notify-Reason value allows the server to notify
the client about a change in the Scale of the media. the client about a change in the Scale of the media.
The registry entries should be represented in the registry as: Name, The registry entries should be represented in the registry as: Name,
short description, contact and reference. short description, contact and reference.
22.9. Range header formats 22.9. Range header formats
22.9.1. Description 22.9.1. Description
The Range header (Section 18.38) allows for different range formats. The Range header (Section 18.38) allows for different range formats.
skipping to change at page 217, line 11 skipping to change at page 217, line 11
The registry should be represented as: Name of the range format, The registry should be represented as: Name of the range format,
contact person and reference. This specification registers the contact person and reference. This specification registers the
following values. following values.
npt: Normal Play Time npt: Normal Play Time
clock: UTC Clock format clock: UTC Clock format
smpte: SMPTE Timestamps smpte: SMPTE Timestamps
smpte-30-drop: SMPTE Timestamps
smpte-25: SMPTE Timestamps
22.10. Terminate-Reason Header 22.10. Terminate-Reason Header
The Terminate-Reason header (Section 18.50) has two registries for The Terminate-Reason header (Section 18.50) has two registries for
extensions. extensions.
22.10.1. Redirect Reasons 22.10.1. Redirect Reasons
Registrations are done under the policy of Expert Review. The Registrations are done under the policy of Expert Review. The
registered value needs to follow syntax, i.e. be a token. The registered value needs to follow the Terminate-Reason ABNF, i.e., be
specification needs to provide a definition of what procedures are to a token. The specification needs to provide a definition of what
be followed when a client receives this redirect reason. This procedures are to be followed when a client receives this redirect
specification registers two values: reason. This specification registers three values:
o Session-Timeout o Session-Timeout
o Server-Admin o Server-Admin
o Internal-Error
The registry should be represented as: Name of the Redirect Reason, The registry should be represented as: Name of the Redirect Reason,
contact person and reference. contact person and reference.
22.10.2. Terminate-Reason Header Parameters 22.10.2. Terminate-Reason Header Parameters
Registrations are done under the policy of Specification Required. Registrations are done under the policy of Specification Required.
The registrations must define a syntax for the parameter that also The registrations must define a syntax for the parameter that also
follows the syntax allowed by the RTSP 2.0 specification. A contact follows the syntax allowed by the RTSP 2.0 specification. A contact
person is also required. This specification registers: person is also required. This specification registers:
skipping to change at page 218, line 4 skipping to change at page 218, line 13
contact person and reference. contact person and reference.
22.11. RTP-Info header parameters 22.11. RTP-Info header parameters
22.11.1. Description 22.11.1. Description
The RTP-Info header (Section 18.43) carries one or more parameter The RTP-Info header (Section 18.43) carries one or more parameter
value pairs with information about a particular point in the RTP value pairs with information about a particular point in the RTP
stream. RTP extensions or new usages may need new types of stream. RTP extensions or new usages may need new types of
information. As RTP information that could be needed is likely to be information. As RTP information that could be needed is likely to be
generic enough and to maximize the interoperability registration generic enough and to maximize the interoperability, new registration
requires Specification Required. requires Specification Required.
22.11.2. Registration Rules 22.11.2. Registration Rules
Registrations for new RTP-Info value MUST fulfill the following Registrations for new RTP-Info value MUST fulfill the following
requirements requirements
o Follow the Specification Required policy and get the approval of o Follow the Specification Required policy and get the approval of
the designated Expert. the designated Expert.
skipping to change at page 222, line 41 skipping to change at page 222, line 49
Status: Permanent Status: Permanent
URI scheme syntax: See Section 20.2.1 of RFC XXXX. URI scheme syntax: See Section 20.2.1 of RFC XXXX.
URI scheme semantics: The rtsp scheme is used to indicate resources URI scheme semantics: The rtsp scheme is used to indicate resources
accessible through the usage of the Real-time Streaming accessible through the usage of the Real-time Streaming
Protocol (RTSP). RTSP allows different operations on the Protocol (RTSP). RTSP allows different operations on the
resource identified by the URI, but the primary purpose is the resource identified by the URI, but the primary purpose is the
streaming delivery of the resource to a client. However, the streaming delivery of the resource to a client. However, the
operations that are currently defined are: DESCRIBE, operations that are currently defined are: DESCRIBE,
GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, SETUP, GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT,
SET_PARAMETER, and TEARDOWN. SETUP, SET_PARAMETER, and TEARDOWN.
Encoding considerations: IRIs in this scheme are defined and needs Encoding considerations: IRIs in this scheme are defined and needs
to be encoded as RTSP URIs when used within the RTSP protocol. to be encoded as RTSP URIs when used within the RTSP protocol.
That encoding is done according to RFC 3987. That encoding is done according to RFC 3987.
Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC
2326), RTSP 2.0 (RFC XXXX) 2326), RTSP 2.0 (RFC XXXX)
Interoperability considerations: The extensions in the URI syntax Interoperability considerations: The extensions in the URI syntax
performed between RTSP 1.0 and 2.0 can create interoperability performed between RTSP 1.0 and 2.0 can create interoperability
issues. The changes are: issues. The changes are:
Support for IPV6 literal in host part and future IP Support for IPV6 literal in host part and future IP
literals through RFC 3986 defined mechanism. literals through RFC 3986 defined mechanism.
A new relative format to use in the RTSP protocol A new relative format to use in the RTSP protocol
elements that is not required to start with "/". elements that is not required to start with "/".
Security considerations: All the security threats identified in Security considerations: All the security threats identified in
Section 7 of RFC 3986 applies also to this scheme. They need Section 7 of RFC 3986 apply also to this scheme. They need to
to be reviewed and considered in any implementation utilizing be reviewed and considered in any implementation utilizing this
this scheme. scheme.
Contact: Magnus Westerlund, magnus.westerlund@ericsson.com Contact: Magnus Westerlund, magnus.westerlund@ericsson.com
Author/Change controller: IETF Author/Change controller: IETF
References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX
22.14.2. The rtsps URI Scheme 22.14.2. The rtsps URI Scheme
URI scheme name: rtsps URI scheme name: rtsps
skipping to change at page 223, line 40 skipping to change at page 223, line 47
Status: Permanent Status: Permanent
URI scheme syntax: See Section 20.2.1 of RFC XXXX. URI scheme syntax: See Section 20.2.1 of RFC XXXX.
URI scheme semantics: The rtsps scheme is used to indicate resources URI scheme semantics: The rtsps scheme is used to indicate resources
accessible through the usage of the Real-time Streaming accessible through the usage of the Real-time Streaming
Protocol (RTSP) over TLS. RTSP allows different operations on Protocol (RTSP) over TLS. RTSP allows different operations on
the resource identified by the URI, but the primary purpose is the resource identified by the URI, but the primary purpose is
the streaming delivery of the resource to a client. However, the streaming delivery of the resource to a client. However,
the operations that are currently defined are: DESCRIBE, the operations that are currently defined are: DESCRIBE,
GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, SETUP, GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT,
SET_PARAMETER, and TEARDOWN. SETUP, SET_PARAMETER, and TEARDOWN.
Encoding considerations: IRIs in this scheme are defined and needs Encoding considerations: IRIs in this scheme are defined and needs
to be encoded as RTSP URIs when used within the RTSP protocol. to be encoded as RTSP URIs when used within the RTSP protocol.
That encoding is done according to RFC 3987. That encoding is done according to RFC 3987.
Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC
2326), RTSP 2.0 (RFC XXXX) 2326), RTSP 2.0 (RFC XXXX)
Interoperability considerations: The extensions in the URI syntax Interoperability considerations: The extensions in the URI syntax
performed between RTSP 1.0 and 2.0 can create interoperability performed between RTSP 1.0 and 2.0 can create interoperability
issues. The changes are: issues. The changes are:
Support for IPV6 literal in host part and future IP Support for IPV6 literal in host part and future IP
literals through RFC 3986 defined mechanism. literals through RFC 3986 defined mechanism.
A new relative format to use in the RTSP protocol A new relative format to use in the RTSP protocol
elements that is not required to start with "/". elements that is not required to start with "/".
Security considerations: All the security threats identified in Security considerations: All the security threats identified in
Section 7 of RFC 3986 applies also to this scheme. They need Section 7 of RFC 3986 apply also to this scheme. They need to
to be reviewed and considered in any implementation utilizing be reviewed and considered in any implementation utilizing this
this scheme. scheme.
Contact: Magnus Westerlund, magnus.westerlund@ericsson.com Contact: Magnus Westerlund, magnus.westerlund@ericsson.com
Author/Change controller: IETF Author/Change controller: IETF
References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX
22.14.3. The rtspu URI Scheme 22.14.3. The rtspu URI Scheme
URI scheme name: rtspu URI scheme name: rtspu
skipping to change at page 224, line 40 skipping to change at page 224, line 47
Status: Permanent Status: Permanent
URI scheme syntax: See Section 3.2 of RFC 2326. URI scheme syntax: See Section 3.2 of RFC 2326.
URI scheme semantics: The rtspu scheme is used to indicate resources URI scheme semantics: The rtspu scheme is used to indicate resources
accessible through the usage of the Real-time Streaming accessible through the usage of the Real-time Streaming
Protocol (RTSP) over unreliable datagram transport. RTSP Protocol (RTSP) over unreliable datagram transport. RTSP
allows different operations on the resource identified by the allows different operations on the resource identified by the
URI, but the primary purpose is the streaming delivery of the URI, but the primary purpose is the streaming delivery of the
resource to a client. However, the operations that are resource to a client. However, the operations that are
currently defined are: DESCRIBE, GET_PARAMETER, OPTIONS, PLAY, currently defined are: DESCRIBE, GET_PARAMETER, OPTIONS,
PLAY_NOTIFY, PAUSE, SETUP, SET_PARAMETER, and TEARDOWN. REDIRECT,PLAY, PLAY_NOTIFY, PAUSE, SETUP, SET_PARAMETER, and
TEARDOWN.
Encoding considerations: IRIs in this scheme are not defined. Encoding considerations: IRIs in this scheme are not defined.
Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC
2326) 2326)
Interoperability considerations: The definition of the transport Interoperability considerations: The definition of the transport
mechanism of RTSP over UDP has interoperability issues. That mechanism of RTSP over UDP has interoperability issues. That
makes the usage of this scheme problematic. makes the usage of this scheme problematic.
Security considerations: All the security threats identified in Security considerations: All the security threats identified in
Section 7 of RFC 3986 applies also to this scheme. They needs Section 7 of RFC 3986 apply also to this scheme. They needs to
to be reviewed and considered in any implementation utilizing be reviewed and considered in any implementation utilizing this
this scheme. scheme.
Contact: Magnus Westerlund, magnus.westerlund@ericsson.com Contact: Magnus Westerlund, magnus.westerlund@ericsson.com
Author/Change controller: IETF Author/Change controller: IETF
References: RFC 2326 References: RFC 2326
22.15. SDP attributes 22.15. SDP attributes
This specification defines three SDP [RFC4566] attributes that it is This specification defines three SDP [RFC4566] attributes that it is
skipping to change at page 226, line 24 skipping to change at page 227, line 5
the encoding of the parameter values. The default charset is the encoding of the parameter values. The default charset is
UTF-8, if the 'charset' parameter is not present. UTF-8, if the 'charset' parameter is not present.
Encoding considerations: 8bit Encoding considerations: 8bit
Security considerations: This format may carry any type of Security considerations: This format may carry any type of
parameters. Some can have security requirements, like privacy, parameters. Some can have security requirements, like privacy,
confidentiality or integrity requirements. The format has no confidentiality or integrity requirements. The format has no
built in security protection. For the usage it was defined the built in security protection. For the usage it was defined the
transport can be protected between server and client using TLS. transport can be protected between server and client using TLS.
However, care must be take to consider if also the proxies are However, care must be taken to consider if also the proxies are
trusted with the parameters in case hop-by-hop security is used. trusted with the parameters in case hop-by-hop security is used.
If stored as file in file system the necessary precautions needs If stored as file in file systemi, the necessary precautions need
to be taken in relation to the parameters requirements including to be taken in relation to the parameters requirements including
object security such as S/MIME [RFC5751]. object security such as S/MIME [RFC5751].
Interoperability considerations: This media type was mentioned as a Interoperability considerations: This media type was mentioned as a
fictional example in RFC 2326 but was not formally specified. fictional example in [RFC2326], but was not formally specified.
This has resulted in usage of this media type which may not match This has resulted in usage of this media type which may not match
its formal definition. its formal definition.
Published specification: RFC XXXX, Appendix F. Published specification: RFC XXXX, Appendix F.
Applications that use this media type: Applications that use RTSP Applications that use this media type: Applications that use RTSP
and have additional parameters they like to read and set using the and have additional parameters they like to read and set using the
RTSP GET_PARAMETER and SET_PARAMETER methods. RTSP GET_PARAMETER and SET_PARAMETER methods.
Additional information: Additional information:
skipping to change at page 228, line 23 skipping to change at page 228, line 23
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
skipping to change at page 229, line 16 skipping to change at page 229, line 19
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005. Identifiers (IRIs)", RFC 3987, January 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", RFC 4288, December 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35, Registration Procedures for New URI Schemes", BCP 35,
RFC 4395, February 2006. RFC 4395, February 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
skipping to change at page 230, line 30 skipping to change at page 230, line 34
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009. Languages", BCP 47, RFC 5646, September 2009.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. Specification", RFC 5751, January 2010.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[TS-26234] [TS-26234]
Third Generation Partnership Project (3GPP), "Transparent Third Generation Partnership Project (3GPP), "Transparent
end-to-end Packet-switched Streaming Service (PSS); end-to-end Packet-switched Streaming Service (PSS);
Protocols and codecs; Technical Specification 26.234", Protocols and codecs; Technical Specification 26.234",
December 2002. December 2002.
23.2. Informative References 23.2. Informative References
[I-D.ietf-mmusic-rtsp-nat] [I-D.ietf-mmusic-rtsp-nat]
Goldberg, J., Westerlund, M., and T. Zeng, "A Network Goldberg, J., Westerlund, M., and T. Zeng, "A Network
Address Translator (NAT) Traversal mechanism for media Address Translator (NAT) Traversal mechanism for media
controlled by Real-Time Streaming Protocol (RTSP)", controlled by Real-Time Streaming Protocol (RTSP)",
draft-ietf-mmusic-rtsp-nat-12 (work in progress), draft-ietf-mmusic-rtsp-nat-14 (work in progress),
May 2012. November 2012.
[ISO.13818-6.1995] [ISO.13818-6.1995]
International Organization for Standardization, International Organization for Standardization,
"Information technology - Generic coding of moving "Information technology - Generic coding of moving
pictures and associated audio information - part 6: pictures and associated audio information - part 6:
Extension for digital storage media and control", Extension for digital storage media and control",
ISO Draft Standard 13818-6, November 1995. ISO Draft Standard 13818-6, November 1995.
[ISO.8601.2000] [ISO.8601.2000]
International Organization for Standardization, "Data International Organization for Standardization, "Data
skipping to change at page 231, line 19 skipping to change at page 231, line 26
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, January 1997. RFC 2068, January 1997.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999. RFC 2663, August 1999.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
skipping to change at page 232, line 5 skipping to change at page 232, line 9
July 2006. July 2006.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008. with Feedback (AVPF)", RFC 5104, February 2008.
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding
Dependency in the Session Description Protocol (SDP)", Dependency in the Session Description Protocol (SDP)",
RFC 5583, July 2009. RFC 5583, July 2009.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298,
June 2011.
[Stevens98] [Stevens98]
Stevens, W., "Unix Networking Programming - Volume 1, Stevens, W., "Unix Networking Programming - Volume 1,
second edition", 1998. second edition", 1998.
Appendix A. Examples Appendix A. 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
these are examples and the normative and syntax description in the these are examples and the normative and syntax description in the
other sections takes precedence. Please also note that many of the other sections take precedence. Please also note that many of the
examples contain syntax illegal line breaks to accommodate the examples contain syntax illegal line breaks to accommodate the
formatting restriction that the RFC series impose. formatting restriction that the RFC series impose.
A.1. Media on Demand (Unicast) A.1. Media on Demand (Unicast)
This is an example of media on demand streaming of a media stored in This is an example of media on demand streaming of a media stored in
a container file. For purposes of this example, a container file is a container file. For purposes of this example, a container file is
a storage entity in which multiple continuous media types pertaining a storage entity in which multiple continuous media types pertaining
to the same end-user presentation are present. In effect, the to the same end-user presentation are present. In effect, the
container file represents an RTSP presentation, with each of its container file represents an RTSP presentation, with each of its
skipping to change at page 233, line 41 skipping to change at page 233, line 41
It is also possible that the presentation author may wish to prevent It is also possible that the presentation author may wish to prevent
selective retrieval of the streams by the client in order to preserve selective retrieval of the streams by the client in order to preserve
the artistic effect of the combined media presentation. Similarly, the artistic effect of the combined media presentation. Similarly,
in such a tightly bound presentation, it is desirable to be able to in such a tightly bound presentation, it is desirable to be able to
control all the streams via a single control message using an control all the streams via a single control message using an
aggregate URI. aggregate URI.
The following is an example of using a single RTSP session to control The following is an example of using a single RTSP session to control
multiple streams. It also illustrates the use of aggregate URIs. In multiple streams. It also illustrates the use of aggregate URIs. In
a container file it is also desirable to not write any URI parts a container file it is also desirable to not write any URI parts
which is not kept, when the container is distributed, like the host which are not kept, when the container is distributed, like the host
and most of the path element. Therefore this example also uses the and 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.
Also this presentation description (SDP) is not cachable, as the Also this presentation description (SDP) is not cachable, as the
Expires header is set to an equal value with date indicating Expires header is set to an equal value with date indicating
immediate expiration of its valididty. immediate expiration of its valididty.
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.
skipping to change at page 240, line 9 skipping to change at page 240, line 9
as language or copyright restrictions. It may also give an as language or copyright restrictions. It may also give an
indication about the timeline of the movie. indication about the 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.1 200 OK
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 278 Content-Length: 278
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 198.51.100.5 o=- 2890844526 2890842807 IN IP4 198.51.100.5
s=RTSP Session s=RTSP Session
e=adm@example.com e=adm@example.com
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
skipping to change at page 246, line 40 skipping to change at page 246, line 40
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
Seek-Style: Next Seek-Style: Next
Range:npt=1256- Range:npt=1256-
RTP-Info: url="rtsp://live.example.com/concert/audio" RTP-Info: url="rtsp://live.example.com/concert/audio"
ssrc=0D12F123:seq=1473; rtptime=80000 ssrc=0D12F123:seq=1473; rtptime=80000
A.6. Capability Negotiation A.6. Capability Negotiation
This example illustrates how the client and server determines their This example illustrates how the client and server determine 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 the client supports RTSP 2.0, and also supports the header, learns the client supports RTSP 2.0, and also supports the
playback time scaling feature of RTSP. The server's response playback time scaling feature of RTSP. The server's response
contains the following feature related information to the client; it contains the following feature related information to the client; it
supports the basic media delivery functions (play.basic), the supports the basic media delivery functions (play.basic), the
extended functionality of time scaling of content (play.scale), and extended functionality of time scaling of content (play.scale), and
one "example.com" proprietary feature (com.example.flight). The one "example.com" proprietary feature (com.example.flight). The
client also learns the methods supported (Public header) by the client also learns the methods supported (Public header) by the
server for the indicated resource. server for the indicated resource.
skipping to change at page 248, line 24 skipping to change at page 248, line 24
two or more is part of the session it is in aggregated control. two or more is part of the session it is in aggregated control.
The below state machine is an informative description of the The below state machine is an informative description of the
protocols behavior. In case of ambiguity with the earlier parts of protocols behavior. In case of ambiguity with the earlier parts of
this specification, the description in the earlier parts take this specification, the description in the earlier parts take
precedence. precedence.
B.1. States B.1. States
The state machine contains three states, described below. For each The state machine contains three states, described below. For each
state there exist a table which shows which requests and events are state there exists a table which shows which requests and events are
allowed and whether they will result in a state change. allowed and whether they will result in a state change.
Init: Initial state no session exists. Init: Initial state no session exists.
Ready: Session is ready to start playing. Ready: Session is ready to start playing.
Play: Session is playing, i.e. sending media stream data in the Play: Session is playing, i.e. sending media stream data in the
direction S->C. direction S->C.
B.2. State variables B.2. State variables
This representation of the state machine needs more than its state to This representation of the state machine needs more than its state to
work. A small number of variables is also needed and they are work. A small number of variables are also needed and they are
explained below. explained below.
NRM: The number of media streams part of this session. NRM: The number of media streams part of this session.
RP: Resume point, the point in the presentation time line at which RP: Resume point, the point in the presentation time line at which
a request to continue playing will resume from. A time format a request to continue playing will resume from. A time format
for the variable is not mandated. for the variable is not mandated.
B.3. Abbreviations B.3. Abbreviations
skipping to change at page 249, line 27 skipping to change at page 249, line 27
SES: Session. SES: Session.
B.4. State Tables B.4. State Tables
This section contains a table for each state. The table contains all This section contains a table for each state. The table contains all
the requests and events that this state is allowed to act on. The the requests and events that this state is allowed to act on. The
events which are method names are, unless noted, requests with the events which are method names are, unless noted, requests with the
given method in the direction client to server (C->S). In some cases given method in the direction client to server (C->S). In some cases
there exist one or more requisite. The response column tells what there exist one or more requisite. The response column tells what
type of response actions should be performed. Possible actions that type of response actions should be performed. Possible actions that
are requested for an event includes: response codes, e.g. 200, are requested for an event include: response codes, e.g., 200,
headers that needs to be included in the response, setting of state headers that need to be included in the response, setting of state
variables, or setting of other session related parameters. The new variables, or setting of other session related parameters. The new
state column tells which state the state machine changes to. state column tells which state the state machine changes to.
The response to a valid request meeting the requisites is normally a The response to a valid request meeting the requisites is normally a
2xx (SUCCESS) unless other noted in the response column. The 2xx (SUCCESS) unless otherwise noted in the response column. The
exceptions need to be given a response according to the response exceptions need to be given a response according to the response
column. If the request does not meet the requisite, is erroneous or column. If the request does not meet the requisite, is erroneous or
some other type of error occur, the appropriate response code is to some other type of error occurs, the appropriate response code is to
be sent. If the response code is a 4xx the session state is be sent. If the response code is a 4xx the session state is
unchanged. A response code of 3rr will result in that the session is unchanged. A response code of 3rr will result in that the session is
ended and its state is changed to Init. A response code of 304 ended and its state is changed to Init. A response code of 304
results in no state change. However, there are restrictions to when results in no state change. However, there are restrictions to when
a 3rr response may be used. A 5xx response does not result in any a 3rr response may be used. A 5xx response does not result in any
change of the session state, except if the error is not possible to change of the session state, except if the error is not possible to
recover from. A unrecoverable error results in the ending of the recover from. A unrecoverable error results in the ending of the
session. As it in the general case can't be determined if it was a session. As it in the general case can't be determined if it was a
unrecoverable error or not the client will be required to test. In unrecoverable error or not the client will be required to test. In
the case that the next request after a 5xx is responded with 454 the case that the next request after a 5xx is responded with 454
skipping to change at page 252, line 9 skipping to change at page 252, line 9
+-------------+------------------------+---------+------------------+ +-------------+------------------------+---------+------------------+
Table 15: State: Ready Table 15: State: Ready
In the Ready state, see Table 15, some of the actions are depending In the Ready state, see Table 15, some of the actions are depending
on the number of media streams (NRM) in the session, i.e., aggregated on the number of media streams (NRM) in the session, i.e., aggregated
or non-aggregated control. A SETUP request in the Ready state can or non-aggregated control. A SETUP request in the Ready state can
either add one more media stream to the session or, if the media either add one more media stream to the session or, if the media
stream (same URI) already is part of the session, change the stream (same URI) already is part of the session, change the
transport parameters. TEARDOWN is depending on both the Request-URI transport parameters. TEARDOWN is depending on both the Request-URI
and the number of media stream within the session. If the Request- and the number of media streams within the session. If the Request-
URI is the presentations URI the whole session is torn down. If a URI is the presentations URI the whole session is torn down. If a
media URI is used in the TEARDOWN request and more than one media media URI is used in the TEARDOWN request and more than one media
exists in the session, the session will remain and a session header exists in the session, the session will remain and a session header
is returned in the response. If only a single media stream remains is returned in the response. If only a single media stream remains
in the session when performing a TEARDOWN with a media URI the in the session when performing a TEARDOWN with a media URI the
session is removed. The number of media streams remaining after session is removed. The number of media streams remaining after
tearing down a media stream determines the new state. tearing down a media stream determines the new state.
+----------------+-----------------------+--------+-----------------+ +----------------+-----------------------+--------+-----------------+
| Action | Requisite | New | Response | | Action | Requisite | New | Response |
skipping to change at page 255, line 28 skipping to change at page 255, line 28
The available RTP profiles and lower layer transports are described The available RTP profiles and lower layer transports are described
below along with rules on signaling the available combinations. below along with rules on signaling the available combinations.
C.1.1. AVP C.1.1. AVP
The usage of the "RTP Profile for Audio and Video Conferences with The usage of the "RTP Profile for Audio and Video Conferences with
Minimal Control" [RFC3551] when using RTP for media transport over Minimal Control" [RFC3551] when using RTP for media transport over
different lower layer transport protocols is defined below in regards different lower layer transport protocols is defined below in regards
to RTSP. to RTSP.
One such case is defined within this document, the use of embedded One such case is defined within this document: the use of embedded
(interleaved) binary data as defined in Section 14. The usage of (interleaved) binary data as defined in Section 14. The usage of
this method is indicated by including the "interleaved" parameter. this method is indicated by including the "interleaved" parameter.
When using embedded binary data the "src_addr" and "dest_addr" MUST When using embedded binary data the "src_addr" and "dest_addr" MUST
NOT be used. This addressing and multiplexing is used as defined NOT be used. This addressing and multiplexing is used as defined
with use of channel numbers and the interleaved parameter. with use of channel numbers and the interleaved parameter.
C.1.2. AVP/UDP C.1.2. AVP/UDP
This part describes sending of RTP [RFC3550] over lower transport This part describes sending of RTP [RFC3550] over lower transport
skipping to change at page 257, line 7 skipping to change at page 257, line 7
C.1.3. AVPF/UDP C.1.3. AVPF/UDP
The RTP profile "Extended RTP Profile for RTCP-based Feedback (RTP/ The RTP profile "Extended RTP Profile for RTCP-based Feedback (RTP/
AVPF)" [RFC4585] MAY be used as RTP profiles in sessions using RTP. AVPF)" [RFC4585] MAY be used as RTP profiles in sessions using RTP.
All that is defined for AVP MUST also apply for AVPF. All that is defined for AVP MUST also apply for AVPF.
The usage of AVPF is indicated by the media initialization protocol The usage of AVPF is indicated by the media initialization protocol
used. In the case of SDP it is indicated by media lines (m=) used. In the case of SDP it is indicated by media lines (m=)
containing the profile RTP/AVPF. That SDP MAY also contain further containing the profile RTP/AVPF. That SDP MAY also contain further
AVPF related SDP attributes configuring the AVPF session regarding AVPF related SDP attributes configuring the AVPF session regarding
reporting interval and feedback messages to be used. This reporting interval and feedback messages to be used [RFC4585]. This
configuration MUST be followed. configuration MUST be followed.
C.1.4. SAVP/UDP C.1.4. SAVP/UDP
The RTP profile "The Secure Real-time Transport Protocol (SRTP)" The RTP profile "The Secure Real-time Transport Protocol (SRTP)"
[RFC3711] is an RTP profile (SAVP) that MAY be used in RTSP sessions [RFC3711] is an RTP profile (SAVP) that MAY be used in RTSP sessions
using RTP. All that is defined for AVP MUST also apply for SAVP. using RTP. All that is defined for AVP MUST also apply for SAVP.
The usage of SRTP requires that a security context is established. The usage of SRTP requires that a security context is established.
The default key-management unless otherwise signalled shall be MIKEY The default key-management unless otherwise signalled SHALL be MIKEY
in RSA-R mode as defined in Appendix C.1.4.1, and not according to in RSA-R mode as defined in Appendix C.1.4.1, and not according to
the procedure defined in "Key Management Extensions for Session the procedure defined in "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)" Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)"
[RFC4567]. The reason is that RFC 4567 sends the initial MIKEY [RFC4567]. The reason is that RFC 4567 sends the initial MIKEY
message in SDP, thus both requiring the usage of the DESCRIBE method message in SDP, thus both requiring the usage of the DESCRIBE method
and forcing the server to keep state for clients performing DESCRIBE and forcing the server to keep state for clients performing DESCRIBE
in anticipation that they might require key management. in anticipation that they might require key management.
MIKEY is selected as default method for establishing SRTP MIKEY is selected as default method for establishing SRTP
cryptographic context within an RTSP session as it can be embedded in cryptographic context within an RTSP session as it can be embedded in
the RTSP messages, while still ensuring confidentiality of content of the RTSP messages, while still ensuring confidentiality of content of
the keying material, even when using hop-by-hop TLS security for the the keying material, even when using hop-by-hop TLS security for the
RTSP messages. This method does also support pipelining of the RTSP RTSP messages. This method does also support pipelining of the RTSP
messages. messages.
C.1.4.1. MIKEY Key Establishment C.1.4.1. MIKEY Key Establishment
This method for using MIKEY [RFC3830] to establish the SRTP This method for using MIKEY [RFC3830] to establish the SRTP
cryptographic context is initiated in the client's SETUP request, and cryptographic context is initiated in the client's SETUP request, and
the servers response to the SETUP carries the MIKEY response. Thus the server's response to the SETUP carries the MIKEY response. This
ensuring that the crypto context establishment happens simultaneously ensures that the crypto context establishment happens simultaneously
with the establishment of the media stream being protected. By using with the establishment of the media stream being protected. By using
MIKEY's RSA-R mode [RFC4738] the client can be the initiator and MIKEY's RSA-R mode [RFC4738] the client can be the initiator and
still allow the server to set the parameters in accordance with the still allow the server to set the parameters in accordance with the
actual media stream. actual media stream.
The SRTP cryptographic context establishment is done according to the The SRTP cryptographic context establishment is done according to the
following process: following process:
1. The client determines that SAVP or SAVPF shall be used from 1. The client determines that SAVP or SAVPF shall be used from
media description format, e.g. SDP. If no other key management media description format, e.g. SDP. If no other key management
skipping to change at page 258, line 15 skipping to change at page 258, line 15
2. The client SHALL establish a TLS connection for RTSP messages, 2. The client SHALL establish a TLS connection for RTSP messages,
directly or hop by hop with the server. If hop-by-hop TLS directly or hop by hop with the server. If hop-by-hop TLS
security is used, the User method SHALL be indicated in the security is used, the User method SHALL be indicated in the
Accept-Credentials header. We do note that using hop-by-hop Accept-Credentials header. We do note that using hop-by-hop
does allow the proxy to insert itself as a man in the middle does allow the proxy to insert itself as a man in the middle
also in the MIKEY exchange by providing one of its certificates, also in the MIKEY exchange by providing one of its certificates,
rather than the server's in the Connection-Credentials header. rather than the server's in the Connection-Credentials header.
The client SHALL therefore validate the server certificate. The client SHALL therefore validate the server certificate.
3. The client retrieves the servers certificate from a direct TLS 3. The client retrieves the server's certificate from a direct TLS
connection, or if hop by hop from Connection-Credentials header. connection, or if hop by hop from Connection-Credentials header.
The client then checks that the server certificate is valid and The client then checks that the server certificate is valid and
belongs to the server. belongs to the server.
4. The client forms the MIKEY Initiator message using RSA-R mode in 4. The client forms the MIKEY Initiator message using RSA-R mode in
unicast mode as specified in [RFC4738]. The client SHOULD use unicast mode as specified in [RFC4738]. The client SHOULD use
the same certificate for TLS and in MIKEY to enable the server the same certificate for TLS and in MIKEY to enable the server
to bind the two together. The client's certificate SHALL be to bind the two together. The client's certificate SHALL be
included in the MIKEY message. The client SHALL indicate its included in the MIKEY message. The client SHALL indicate its
SRTP capabilities in the message. SRTP capabilities in the message.
5. The MIKEY message from the previous step is base64 [RFC4648] 5. The MIKEY message from the previous step is base64 [RFC4648]
encoded and becomes the value of the MIKEY parameter that is encoded and becomes the value of the MIKEY parameter that is
included in the transport specification(s) that specifies a SRTP included in the transport specification(s) that specifies a SRTP
based profile (SAVP, SAVPF) in the SETUP request. based profile (SAVP, SAVPF) in the SETUP request.
6. Any proxy encountering the MIKEY parameter SHALL forward it 6. Any proxy encountering the MIKEY parameter SHALL forward it
without modification. A proxy requiring to understand transport without modification. A proxy requiring to understand transport
specification which doesn't support SAVP/SAVPF with MIKEY will specification which doesn't support SAVP/SAVPF with MIKEY will
discard the whole transport specification. Most types of proxy discard the whole transport specification. Most types of
can easily support SAVP and SAVPF with MIKEY. If possible proxies can easily support SAVP and SAVPF with MIKEY. If
bypassing the proxy should be tried. possible bypassing the proxy should be tried.
7. The server upon receiving the SETUP request, will need to decide 7. The server upon receiving the SETUP request, will need to decide
upon the transport specification to use, if multiple are upon the transport specification to use, if multiple are
included by the client. In the determination of which transport included by the client. In the determination of which transport
specifications that are supported and preferred, the server specifications that are supported and preferred, the server
SHOULD decode the MIKEY message to take the embedded SRTP SHOULD decode the MIKEY message to take the embedded SRTP
parameters into account. If all transport specs require SRTP parameters into account. If all transport specs require SRTP
but no MIKEY parameter or other supported keying method is but no MIKEY parameter or other supported keying method is
included, the server SHALL respond with 403. included, the server SHALL respond with 403.
skipping to change at page 259, line 28 skipping to change at page 259, line 28
client. That message is included in the MIKEY parameter part client. That message is included in the MIKEY parameter part
of the single selected transport specification in the SETUP of the single selected transport specification in the SETUP
response. The server will set the SRTP parameters as response. The server will set the SRTP parameters as
preferred for this media stream within the supported range by preferred for this media stream within the supported range by
the client. the client.
9. The server transmits the SETUP response back to the client. 9. The server transmits the SETUP response back to the client.
10. The client receives the SETUP response and if the response code 10. The client receives the SETUP response and if the response code
indicates a successful request it decodes the MIKEY message and indicates a successful request it decodes the MIKEY message and
establish the SRTP cryptographic context from the parameters in establishes the SRTP cryptographic context from the parameters
the MIKEY response. in the MIKEY response.
In the above method the client's certificate may be self-signed in In the above method the client's certificate may be self-signed in
cases where the client's identity is not necessary to establish and cases where the client's identity is not necessary to authenticate
the security goal is only to ensure that the RTSP signaling client is and the security goal is only to ensure that the RTSP signaling
the same as the one receiving the SRTP security context. client is the same as the one receiving the SRTP security context.
C.1.5. SAVPF/UDP C.1.5. SAVPF/UDP
The RTP profile "Extended Secure RTP Profile for RTCP-based Feedback The RTP profile "Extended Secure RTP Profile for RTCP-based Feedback
(RTP/SAVPF)" [RFC5124] is an RTP profile (SAVPF) that MAY be used in (RTP/SAVPF)" [RFC5124] is an RTP profile (SAVPF) that MAY be used in
RTSP sessions using RTP. All that is defined for AVP MUST also apply RTSP sessions using RTP. All that is defined for AVPF MUST also
for SAVPF. apply for SAVPF.
The usage of SRTP requires that a cryptographic context is The usage of SRTP requires that a cryptographic context is
established. The default mechanism for establishing that security established. The default mechanism for establishing that security
association is to use MIKEY[RFC3830] with RTSP as defined in association is to use MIKEY[RFC3830] with RTSP as defined in
Appendix C.1.4.1. Appendix C.1.4.1.
C.1.6. RTCP usage with RTSP C.1.6. RTCP usage with RTSP
RTCP has several usages when RTP is used for media transport as RTCP has several usages when RTP is used for media transport as
explained below. Due to that RTCP MUST be supported if an RTSP agent explained below. Due to that RTCP MUST be supported if an RTSP agent
skipping to change at page 261, line 49 skipping to change at page 261, line 49
A client codes the support of RTP over independent TCP by specifying A client codes the support of RTP over independent TCP by specifying
an RTP/AVP/TCP transport option without an interleaved parameter in an RTP/AVP/TCP transport option without an interleaved parameter in
the Transport line of a SETUP request. This transport option MUST the Transport line of a SETUP request. This transport option MUST
include the "unicast" parameter. include the "unicast" parameter.
If the client wishes to use RTP with RTCP, two ports (or two address/ If the client wishes to use RTP with RTCP, two ports (or two address/
port pairs) are specified by the dest_addr parameter. If the client port pairs) are specified by the dest_addr parameter. If the client
wishes to use RTP without RTCP, one port (or one address/port pair) wishes to use RTP without RTCP, one port (or one address/port pair)
is specified by the dest_addr parameter. If the client wishes to is specified by the dest_addr parameter. If the client wishes to
multiplex RTP and RTCP on a single port (see Section multiplex RTP and RTCP on a single port (see Appendix C.1.6.4), one
Appendix C.1.6.4, one port (or one address/port pair) is specified by port (or one address/port pair) is specified by the dest_addr
the dest_addr parameter. Ordering rules of dest_addr ports follow parameter. Ordering rules of dest_addr ports follow the rules for
the rules for RTP/AVP/UDP. RTP/AVP/UDP.
If the client wishes to play the active role in initiating the TCP If the client wishes to play the active role in initiating the TCP
connection, it MAY set the "setup" parameter (See Section 18.52) on connection, it MAY set the "setup" parameter (See Section 18.52) on
the Transport line to be "active", or it MAY omit the setup the Transport line to be "active", or it MAY omit the setup
parameter, as active is the default. If the client signals the parameter, as active is the default. If the client signals the
active role, the ports for all dest_addr values MUST be set to 9 (the active role, the ports for all dest_addr values MUST be set to 9 (the
discard port). discard port).
If the client wishes to play the passive role in TCP connection If the client wishes to play the passive role in TCP connection
initiation, it MUST set the "setup" parameter on the Transport line initiation, it MUST set the "setup" parameter on the Transport line
to be "passive". If the client is able to assume the active or the to be "passive". If the client is able to assume the active or the
passive role, it MUST set the "setup" parameter on the Transport line passive role, it MUST set the "setup" parameter on the Transport line
to be "actpass". In either case, the dest_addr port value for RTP to be "actpass". In either case, the dest_addr port value for RTP
MUST be set to the TCP port number on which the client is expecting MUST be set to the TCP port number on which the client is expecting
to receive the RTP stream connection, and the dest_addr port value to receive the RTP stream connection, and the dest_addr port value
for RTCP MUST be set to the TCP port number on which the client is for RTCP MUST be set to the TCP port number on which the client is
expecting to receive the RTCP stream connection. expecting to receive the RTCP stream connection. In the case that
the client wishes to multiplex RTP and RTCP on a single port, one
port is specified by the dest_addr parameter, as mentioned earlier in
this section.
If upon receipt of a non-interleaved RTP/AVP/TCP SETUP request, a If upon receipt of a non-interleaved RTP/AVP/TCP SETUP request, a
server decides to accept this requested option, the 2xx reply MUST server decides to accept this requested option, the 2xx reply MUST
contain a Transport option that specifies RTP/AVP/TCP (without using contain a Transport option that specifies RTP/AVP/TCP (without using
the interleaved parameter, and with using the unicast parameter). the interleaved parameter, and with using the unicast parameter).
The dest_addr parameter value MUST be echoed from the parameter value The dest_addr parameter value MUST be echoed from the parameter value
in the client request unless the destination address (only port) was in the client request unless the destination address (only port) was
not provided in which case the server MAY include the source address not provided in which case the server MAY include the source address
of the RTSP TCP connection with the port number unchanged. of the RTSP TCP connection with the port number unchanged.
In addition, the server reply MUST set the setup parameter on the In addition, the server reply MUST set the setup parameter on the
Transport line, to indicate the role the server will play in the Transport line, to indicate the role the server will play in the
connection setup. Permissible values are "active" (if a client set connection setup. Permissible values are "active" (if a client set
"setup" to "passive" or "actpass") and "passive" (if a client set "setup" to "passive" or "actpass") and "passive" (if a client set
"setup" to "active" or "actpass"). "setup" to "active" or "actpass").
If a server sets "setup" to "passive", the "src_addr" in the reply If a server sets "setup" to "passive", the "src_addr" in the reply
MUST indicate the ports the server is willing to receive an RTP MUST indicate the ports the server is willing to receive an RTP
connection and (if the client requested an RTCP connection by connection and (if the client requested an RTCP connection by
specifying two dest_addr ports or address/port pairs) and RTCP specifying two dest_addr ports or address/port pairs) an RTCP
connection. If a server sets "setup" to "active", the ports connection. If a server sets "setup" to "active", the ports
specified in "src_addr" MUST be set to 9. The server MAY use the specified in "src_addr" MUST be set to 9. The server MAY use the
"ssrc" parameter, following the guidance in Section 18.52. Port "ssrc" parameter, following the guidance in Section 18.52. The
ordering for src_addr follows the rules for RTP/AVP/UDP. server sets only one port in the case that the client has indicated
only a single port. Port ordering for src_addr follows the rules for
RTP/AVP/UDP.
Servers MUST support taking the passive role and MAY support taking Servers MUST support taking the passive role and MAY support taking
the active role. Servers with a public IP address take the passive the active role. Servers with a public IP address take the passive
role, thus enabling clients behind NATs and Firewalls a better chance role, thus enabling clients behind NATs and Firewalls a better chance
of successful connect to the server by actively connecting outwards. of successful connect to the server by actively connecting outwards.
Therefore the clients are RECOMMENDED to take the active role. Therefore the clients are RECOMMENDED to take the active role.
After sending (receiving) a 2xx reply for a SETUP method for a non- After sending (receiving) a 2xx reply for a SETUP method for a non-
interleaved RTP/AVP/TCP media stream, the active party SHOULD interleaved RTP/AVP/TCP media stream, the active party SHOULD
initiate the TCP connection as soon as possible. The client MUST NOT initiate the TCP connection as soon as possible. The client MUST NOT
skipping to change at page 263, line 42 skipping to change at page 263, line 48
TCP RTP and RTCP connections for the URI, or does the client wish to TCP RTP and RTCP connections for the URI, or does the client wish to
continue using the existing TCP RTP and RTCP connections? The client continue using the existing TCP RTP and RTCP connections? The client
SHOULD use the "connection" parameter (defined in Section 18.52) on SHOULD use the "connection" parameter (defined in Section 18.52) on
the Transport line to make its intention clear (by setting the Transport line to make its intention clear (by setting
"connection" to "new" if new connections are needed, and by setting "connection" to "new" if new connections are needed, and by setting
"connection" to "existing" if the existing connections are to be "connection" to "existing" if the existing connections are to be
used). After a 2xx reply for a SETUP request for a new connection, used). After a 2xx reply for a SETUP request for a new connection,
parties should close the pre-existing connections, after waiting a parties should close the pre-existing connections, after waiting a
suitable period for any stray RTP or RTCP packets to arrive. suitable period for any stray RTP or RTCP packets to arrive.
The usage of SRTP, i.e. either SAVP or SAVPF profiles requires that a The usage of SRTP, i.e., either SAVP or SAVPF profiles, requires that
security association is established. The default mechanism for a security association is established. The default mechanism for
establishing that security association is to use MIKEY[RFC3830] with establishing that security association is to use MIKEY[RFC3830] with
RTSP as defined Appendix C.1.4.1. RTSP as defined Appendix C.1.4.1.
Below, we rewrite part of the example media on demand example shown Below, we rewrite part of the example media on demand example shown
in Appendix A.1 to use RTP/AVP/TCP non-interleaved: in Appendix A.1 to use RTP/AVP/TCP non-interleaved:
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
skipping to change at page 267, line 6 skipping to change at page 267, line 6
stream is continuous without gaps in RTP timestamp or sequence stream is continuous without gaps in RTP timestamp or sequence
number. However, when delivery has been halted for some reason the number. However, when delivery has been halted for some reason the
RTP timestamp when resuming MUST represent the duration the delivery RTP timestamp when resuming MUST represent the duration the delivery
was halted. RTP sequence number MUST generally be the next number, was halted. RTP sequence number MUST generally be the next number,
i.e. monotonically increasing modulo 65536. For media resources with i.e. monotonically increasing modulo 65536. For media resources with
the properties Time-Progressing and Time-Duration=0.0 the server MAY the properties Time-Progressing and Time-Duration=0.0 the server MAY
create RTP media streams with RTP sequence number jumps in them due create RTP media streams with RTP sequence number jumps in them due
to the client first halting delivery and later resuming it (PAUSE and to the client first halting delivery and later resuming it (PAUSE and
then later PLAY). However, servers utilizing this exception must then later PLAY). However, servers utilizing this exception must
take into consideration the resulting RTCP receiver reports that take into consideration the resulting RTCP receiver reports that
likely contains loss reports for all the packets part of the likely contain loss reports for all the packets part of the
discontinuity. A client cannot rely on that a server will align when discontinuity. A client cannot rely on that a server will align when
resuming playing even if it is RECOMMENDED. The RTP-Info header will resuming playing even if it is RECOMMENDED. The RTP-Info header will
provide information on how the server acts in each case. provide information on how the server acts in each case.
We cannot assume that the RTSP client can communicate with the RTP We cannot assume that the RTSP client can communicate with the RTP
media agent, as the two may be independent processes. If the RTP media agent, as the two may be independent processes. If the RTP
timestamp shows the same gap as the NPT, the media agent will timestamp shows the same gap as the NPT, the media agent will
assume that there is a pause in the presentation. If the jump in assume that there is a pause in the presentation. If the jump in
NPT is large enough, the RTP timestamp may roll over and the media NPT is large enough, the RTP timestamp may roll over and the media
agent may believe later packets to be duplicates of packets just agent may believe later packets to be duplicates of packets just
skipping to change at page 270, line 38 skipping to change at page 270, line 38
ssrc=0D12F123:seq=4;rtptime=164400 ssrc=0D12F123:seq=4;rtptime=164400
The ensuing RTP data stream is depicted below: The ensuing RTP data stream is depicted below:
S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s
S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s
S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s
First, NPT 10 through 10.3 is played, then a PAUSE is received by the First, NPT 10 through 10.3 is played, then a PAUSE is received by the
server. After 20 seconds a PLAY is received by the server which server. After 20 seconds a PLAY is received by the server which
takes 15ms to process. The duration of time for which the session takes 15 ms to process. The duration of time for which the session
was paused is reflected in the RTP timestamp of the RTP packets sent was paused is reflected in the RTP timestamp of the RTP packets sent
after this PLAY request. after this PLAY request.
A client can use the RTSP range header and RTP-Info header to map NPT A client can use the RTSP range header and RTP-Info header to map NPT
time of a presentation with the RTP timestamp. time of a presentation with the RTP timestamp.
Note: In RFC 2326 [RFC2326], this matter was not clearly defined and Note: In RFC 2326 [RFC2326], this matter was not clearly defined and
was misunderstood commonly. However, for RTSP 2.0 it is expected was misunderstood commonly. However, for RTSP 2.0 it is expected
that this will be handled correctly and no exception handling will be that this will be handled correctly and no exception handling will be
required. required.
skipping to change at page 272, line 41 skipping to change at page 272, line 41
it. This tag is required to be an ABNF "token" to be possible to it. This tag is required to be an ABNF "token" to be possible to
use in the Transport header specification. use in the Transport header specification.
o The useful combinations of protocol, profiles and lower layer o The useful combinations of protocol, profiles and lower layer
transport for this extension needs to be defined. For each transport for this extension needs to be defined. For each
combination declare the necessary parameters to use in the combination declare the necessary parameters to use in the
Transport header. Transport header.
o For new media protocols the interaction with RTSP needs to be o For new media protocols the interaction with RTSP needs to be
addressed. One important factor will be the media addressed. One important factor will be the media
synchronization. May need new headers similar to RTP info to synchronization. It may be necessary to have new headers similar
carry information. to RTP info to carry this information.
o Discuss congestion control for media, especially if transport o Discuss congestion control for media, especially if transport
without built in congestion control is used. without built in congestion control is used.
See the IANA section (Section 22) for information how to register new See the IANA section (Section 22) for information how to register new
attributes. attributes.
Appendix D. Use of SDP for RTSP Session Descriptions Appendix D. Use of SDP for RTSP Session Descriptions
The Session Description Protocol (SDP, [RFC4566]) may be used to The Session Description Protocol (SDP, [RFC4566]) may be used to
skipping to change at page 273, line 38 skipping to change at page 273, line 38
The "a=control:" attribute is used to convey the control URI. This The "a=control:" attribute is used to convey the control URI. This
attribute is used both for the session and media descriptions. If attribute is used both for the session and media descriptions. If
used for individual media, it indicates the URI to be used for used for individual media, it indicates the URI to be used for
controlling that particular media stream. If found at the session controlling that particular media stream. If found at the session
level, the attribute indicates the URI for aggregate control level, the attribute indicates the URI for aggregate control
(presentation URI). The session level URI MUST be different from any (presentation URI). The session level URI MUST be different from any
media level URI. The presence of a session level control attribute media level URI. The presence of a session level control attribute
MUST be interpreted as support for aggregated control. The control MUST be interpreted as support for aggregated control. The control
attribute MUST be present on media level unless the presentation only attribute MUST be present on media level unless the presentation only
contains a single media stream, in which case the attribute MAY only contains a single media stream, in which case the attribute MAY be
be present on the session level and then also apply to that single present on the session level only and then also apply to that single
media level. media stream.
ABNF for the attribute is defined in Section 20.3. ABNF for the attribute is defined in Section 20.3.
Example: Example:
a=control:rtsp://example.com/foo a=control:rtsp://example.com/foo
This attribute MAY contain either relative or absolute URIs, This attribute MAY contain either relative or absolute URIs,
following the rules and conventions set out in RFC 3986 [RFC3986]. following the rules and conventions set out in RFC 3986 [RFC3986].
Implementations MUST look for a base URI in the following order: Implementations MUST look for a base URI in the following order:
skipping to change at page 274, line 20 skipping to change at page 274, line 20
entire base URI. entire base URI.
Note, RFC 2326 was very unclear on the processing of relative URI Note, RFC 2326 was very unclear on the processing of relative URI
and several RTSP 1.0 implementations at the point of publishing and several RTSP 1.0 implementations at the point of publishing
this document did not perform RFC 3986 processing to determine the this document did not perform RFC 3986 processing to determine the
resulting URI, instead simple concatenation is common. To avoid resulting URI, instead simple concatenation is common. To avoid
this issue completely it is recommended to use absolute URI in the this issue completely it is recommended to use absolute URI in the
SDP. SDP.
The URI handling for SDPs from container files need special The URI handling for SDPs from container files need special
consideration. For example lets assume that a container file has the consideration. For example let's assume that a container file has
URI: "rtsp://example.com/container.mp4". Lets further assume this the URI: "rtsp://example.com/container.mp4". Let's further assume
URI is the base URI, and that there is an absolute media level URI: this URI is the base URI, and that there is an absolute media level
"rtsp://example.com/container.mp4/trackID=2". A relative media level URI: "rtsp://example.com/container.mp4/trackID=2". A relative media
URI that resolves in accordance with RFC 3986 [RFC3986] to the above level URI that resolves in accordance with RFC 3986 [RFC3986] to the
given media URI is: "container.mp4/trackID=2". It is usually not above given media URI is: "container.mp4/trackID=2". It is usually
desirable to need to include in or modify the SDP stored within the not desirable to need to include in or modify the SDP stored within
container file with the server local name of the container file. To the container file with the server local name of the container file.
avoid this, one can modify the base URI used to include a trailing To avoid this, one can modify the base URI used to include a trailing
slash, e.g. "rtsp://example.com/container.mp4/". In this case the slash, e.g. "rtsp://example.com/container.mp4/". In this case the
relative URI for the media will only need to be: "trackID=2". relative URI for the media will only need to be: "trackID=2".
However, this will also mean that using "*" in the SDP will result in However, this will also mean that using "*" in the SDP will result in
control URI including the trailing slash, i.e. control URI including the trailing slash, i.e.
"rtsp://example.com/container.mp4/". "rtsp://example.com/container.mp4/".
Note: The usage of TrackID in the above is not a standardized Note: The usage of TrackID in the above is not a standardized
form, but one example out of several similar strings such as form, but one example out of several similar strings such as
TrackID, Track_ID, StreamID that is used by different server TrackID, Track_ID, StreamID that is used by different server
vendors to indicate a particular piece of media inside a container vendors to indicate a particular piece of media inside a container
skipping to change at page 276, line 22 skipping to change at page 276, line 22
was received. Note that this overrules the normal default rule was received. Note that this overrules the normal default rule
defined in SDP[RFC4566]. The usage of "a=sendonly" or "a=sendrecv" defined in SDP[RFC4566]. The usage of "a=sendonly" or "a=sendrecv"
is not defined, nor is the interpretation of SDP by other entities is not defined, nor is the interpretation of SDP by other entities
than the RTSP client. than the RTSP client.
D.1.6. Range of Presentation D.1.6. Range of Presentation
The "a=range" attribute defines the total time range of the stored The "a=range" attribute defines the total time range of the stored
session or an individual media. Non-seekable live sessions can be session or an individual media. Non-seekable live sessions can be
indicated as specified below, while the length of live sessions can indicated as specified below, while the length of live sessions can
be deduced from the "t" and "r" SDP parameters. be deduced from the "t=" and "r=" SDP parameters.
The attribute is both a session and a media level attribute. For The attribute is both a session and a media level attribute. For
presentations that contain media streams of the same durations, the presentations that contain media streams of the same duration, the
range attribute SHOULD only be used at session-level. In case of range attribute SHOULD only be used at session-level. In case of
different length the range attribute MUST be given at media level for different lengths the range attribute MUST be given at media level
all media, and SHOULD NOT be given at session level. If the for all media, and SHOULD NOT be given at session level. If the
attribute is present at both media level and session level the media attribute is present at both media level and session level the media
level values MUST be used. level values MUST be used.
Note: Usually one will specify the same length for all media, even if Note: Usually one will specify the same length for all media, even if
there isn't media available for the full duration on all media. there isn't media available for the full duration on all media.
However, that requires that the server accepts PLAY requests within However, that requires that the server accepts PLAY requests within
that range. that range.
Servers MUST take care to provide RTSP Range (see Section 18.38) Servers MUST take care to provide RTSP Range (see Section 18.38)
values that are consistent with what is presented in the SDP for the values that are consistent with what is presented in the SDP for the
skipping to change at page 282, line 46 skipping to change at page 282, line 46
This use case is similar to the above on-demand content case (see This use case is similar to the above on-demand content case (see
Appendix E.1) the difference is the nature of the content itself. Appendix E.1) the difference is the nature of the content itself.
Live content is continuously distributed as it becomes available from Live content is continuously distributed as it becomes available from
a source; i.e., the main difference from on-demand is that one starts a source; i.e., the main difference from on-demand is that one starts
distributing content before the end of it has become available to the distributing content before the end of it has become available to the
server. server.
In many cases the consumer of live content is only interested in In many cases the consumer of live content is only interested in
consuming what actually happens "now"; i.e., very similar to consuming what actually happens "now"; i.e., very similar to
broadcast TV. However, in this case it is assumed that there exist broadcast TV. However, in this case it is assumed that there exists
no broadcast or multicast channel to the users, and instead the no broadcast or multicast channel to the users, and instead the
server functions as a distribution node, sending the same content to server functions as a distribution node, sending the same content to
multiple receivers, using unicast traffic between server and client. multiple receivers, using unicast traffic between server and client.
This unicast traffic and the transport parameters are individually This unicast traffic and the transport parameters are individually
negotiated for each receiving client. negotiated for each receiving client.
Another aspect of live content is that it often has a very limited Another aspect of live content is that it often has a very limited
time of availability, as it is only available for the duration of the time of availability, as it is only available for the duration of the
event the content covers. An example of such a live content could be event the content covers. An example of such a live content could be
a music concert which lasts 2 hour and starts at a predetermined a music concert which lasts 2 hour and starts at a predetermined
skipping to change at page 287, line 28 skipping to change at page 287, line 28
The following considerations should exist for operation of RTSP over The following considerations should exist for operation of RTSP over
an unreliable transport protocol: an unreliable transport protocol:
o Request shall be acknowledged by the receiver. If there is no o Request shall be acknowledged by the receiver. If there is no
acknowledgement, the sender may resend the same message after a acknowledgement, the sender may resend the same message after a
timeout of one round-trip time (RTT). Any retransmissions due to timeout of one round-trip time (RTT). Any retransmissions due to
lack of acknowledgement must carry the same sequence number as the lack of acknowledgement must carry the same sequence number as the
original request. original request.
o The round-trip time can be estimated as in TCP (RFC 1123) o The round-trip time can be estimated as in TCP (RFC 6298)
[RFC1123], with an initial round-trip value of 500 ms. An [RFC6298], with an initial round-trip value of 500 ms. An
implementation may cache the last RTT measurement as the initial implementation may cache the last RTT measurement as the initial
value for future connections. value for future connections.
o The Timestamp header (Section 18.51) is used to avoid the o The Timestamp header (Section 18.51) is used to avoid the
retransmission ambiguity problem [Stevens98]. retransmission ambiguity problem [Stevens98].
o The registered default port for RTSP over UDP for the server is o The registered default port for RTSP over UDP for the server is
554. 554.
o RTSP messages can be carried over any lower-layer transport o RTSP messages can be carried over any lower-layer transport
skipping to change at page 291, line 40 skipping to change at page 291, line 40
o The Transport header has been changed in the following way: o The Transport header has been changed in the following way:
* The ABNF has been changed to define that extensions are * The ABNF has been changed to define that extensions are
possible, and that unknown parameters result in that servers possible, and that unknown parameters result in that servers
ignore the transport specification. ignore the transport specification.
* To prevent backwards compatibility issues, any extension or new * To prevent backwards compatibility issues, any extension or new
parameter requires the usage of a feature-tag combined with the parameter requires the usage of a feature-tag combined with the
Require header. Require header.
* Syntax unclarities with the Mode parameter has been resolved. * Syntax unclarities with the Mode parameter have been resolved.
* Syntax error with ";" for multicast and unicast has been * Syntax error with ";" for multicast and unicast has been
resolved. resolved.
* Two new addressing parameters has been defined, src_addr and * Two new addressing parameters have been defined, src_addr and
dest_addr. These replaces the parameters "port", dest_addr. These replace the parameters "port", "client_port",
"client_port", "server_port", "destination", "source". "server_port", "destination", "source".
* Support for IPv6 explicit addresses in all address fields has * Support for IPv6 explicit addresses in all address fields has
been included. been included.
* To handle URI definitions that contain ";" or "," a quoted URI * To handle URI definitions that contain ";" or "," a quoted URI
format has been introduced and is required. format has been introduced and is required.
* Defined IANA registries for the transport headers parameters, * Defined IANA registries for the transport headers parameters,
transport-protocol, profile, lower-transport, and mode. transport-protocol, profile, lower-transport, and mode.
skipping to change at page 293, line 14 skipping to change at page 293, line 14
o The HTTP references have been updated to RFC 2616 and RFC 2617. o The HTTP references have been updated to RFC 2616 and RFC 2617.
Most of the text has been copied and then altered to fit RTSP into Most of the text has been copied and then altered to fit RTSP into
this specification. Public, and the Content-Base header has also this specification. Public, and the Content-Base header has also
been imported from RFC 2068 so that they are defined in the RTSP been imported from RFC 2068 so that they are defined in the RTSP
specification. Known effects on RTSP due to HTTP clarifications: specification. Known effects on RTSP due to HTTP clarifications:
* Content-Encoding header can include encoding of type * Content-Encoding header can include encoding of type
"identity". "identity".
o The state machine section has completely been rewritten. It o The state machine section has been completely rewritten. It now
includes now more details and is also more clear about the model includes more details and is also more clear about the model used.
used.
o An IANA section has been included with contains a number of o An IANA section has been included which contains a number of
registries and their rules. This will allow us to use IANA to registries and their rules. This will allow us to use IANA to
keep track of RTSP extensions. keep track of RTSP extensions.
o The transport of RTSP messages has seen the following changes: o The transport of RTSP messages has seen the following changes:
* The use of UDP for RTSP message transport has been deprecated * The use of UDP for RTSP message transport has been deprecated
due to missing interest and to broken specification. due to missing interest and to broken specification.
* The rules for how TCP connections are to be handled has been * The rules for how TCP connections are to be handled has been
clarified. Now it is made clear that servers should not close clarified. Now it is made clear that servers should not close
skipping to change at page 293, line 40 skipping to change at page 293, line 39
time. time.
* Strong recommendations why server and clients should use * Strong recommendations why server and clients should use
persistent connections have also been added. persistent connections have also been added.
* There is now a requirement on the servers to handle non- * There is now a requirement on the servers to handle non-
persistent connections as this provides fault tolerance. persistent connections as this provides fault tolerance.
* Added wording on the usage of Connection:Close for RTSP. * Added wording on the usage of Connection:Close for RTSP.
* specified usage of TLS for RTSP messages, including a scheme to * Specified usage of TLS for RTSP messages, including a scheme to
approve a proxy's TLS connection to the next hop. approve a proxy's TLS connection to the next hop.
o The following header related changes have been made: o The following header related changes have been made:
* Accept-Ranges response header is added. This header clarifies * Accept-Ranges response header is added. This header clarifies
which range formats that can be used for a resource. which range formats that can be used for a resource.
* Fixed the missing definitions for the Cache-Control header. * Fixed the missing definitions for the Cache-Control header.
Also added to the syntax definition the missing delta-seconds Also added to the syntax definition the missing delta-seconds
for max-stale and min-fresh parameters. for max-stale and min-fresh parameters.
skipping to change at page 294, line 47 skipping to change at page 294, line 44
Request-URI as base URI. Also clarified that the used URI must Request-URI as base URI. Also clarified that the used URI must
be the one that was used in the SETUP request. The URIs are be the one that was used in the SETUP request. The URIs are
now also required to be quoted. The header also expresses the now also required to be quoted. The header also expresses the
SSRC for the provided RTP timestamp and sequence number values. SSRC for the provided RTP timestamp and sequence number values.
* Added text that requires the Range to always be present in PLAY * Added text that requires the Range to always be present in PLAY
responses. Clarified what should be sent in case of live responses. Clarified what should be sent in case of live
streams. streams.
* The headers table has been updated using a structure borrowed * The headers table has been updated using a structure borrowed
from SIP. Those tables carries much more information and from SIP. Those tables convey much more information and should
should provide a good overview of the available headers. provide a good overview of the available headers.
* It has been clarified that any message with a message body is * It has been clarified that any message with a message body is
required to have a Content-Length header. This was the case in required to have a Content-Length header. This was the case in
RFC 2326, but could be misinterpreted. RFC 2326, but could be misinterpreted.
* ETag has changed name to MTag. * ETag has changed name to MTag.
* To resolve functionality around MTag. The MTag and If-None- * To resolve functionality around MTag. The MTag and If-None-
Match header have been added from HTTP with necessary Match header have been added from HTTP with necessary
clarification in regards to RTSP operation. clarification in regards to RTSP operation.
skipping to change at page 296, line 34 skipping to change at page 296, line 34
* The use of PLAY method for keep-alive in Play state. * The use of PLAY method for keep-alive in Play state.
* The RECORD and ANNOUNCE methods and all related functionality. * The RECORD and ANNOUNCE methods and all related functionality.
Some of the syntax has been removed. Some of the syntax has been removed.
* The possibility to use timed execution of methods with the time * The possibility to use timed execution of methods with the time
parameter in the Range header. parameter in the Range header.
* The description on how rtspu works is not part of the core * The description on how rtspu works is not part of the core
specification and will require external description. Only that specification and will require external description. Only that
it exist is defined here and some requirements for the it exists is defined here and some requirements for the
transport is provided. transport is provided.
o The following changes have been made in relation to methods: o The following changes have been made in relation to methods:
* The OPTIONS method has been clarified with regards to the use * The OPTIONS method has been clarified with regards to the use
of the Public and Allow headers. of the Public and Allow headers.
* Added text clarifying the usage of SET_PARAMETER for keep-alive * Added text clarifying the usage of SET_PARAMETER for keep-alive
and usage without any body. and usage without any body.
 End of changes. 192 change blocks. 
382 lines changed or deleted 402 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/